„Jestem nietechniczna” – i co z tego?
Nietechniczny Product Owner i Analityk Biznesowy bardzo często mają poczucie, że są „mniej merytoryczni” niż osoby techniczne.
Zdanie „jestem nietechniczna / nietechniczny” wraca w rozmowach, mailach i na szkoleniach jak bumerang — i niemal zawsze kryje się za nim nie brak kompetencji, tylko brak pewności siebie i jasnych ram pracy.
Gdybym za każdego maila zaczynającego się od zdania „jestem nietechnicznym product ownerem” dostawała 5 zł, prawdopodobnie nie musiałabym prowadzić kursów.
Jeżeli wolisz oglądać, zapraszam na YouTube
Kim naprawdę jest „nietechniczny” Product Owner / Analityk?
W praktyce „nietechniczny” oznacza jedno:
nie jesteś programistą, nie kodujesz, nie skończyłaś studiów technicznych.
I dokładnie tak wygląda większość dobrych PO i BA, z którymi pracowałam — w projektach i na kursach .
Ja sama:
-
jestem magistrem biologii,
-
później skończyłam zarządzanie,
-
a moje „techniczne” doświadczenia to LOGO w liceum i trochę HTML-a sprzed kilkunastu lat.
I wiesz co?
Nigdy nie przeszkodziło mi to w byciu kluczową osobą w projektach IT.
Dlaczego?
Bo Product Owner i Analityk Biznesowy nie są od technologii.
Rola PO i BA to nie technologia. To decyzje.
W praktyce nietechniczny Product Owner nie traci na wartości dlatego, że nie pisze kodu.
Traci ją dopiero wtedy, gdy nie ma systemu podejmowania decyzji, nie domyka ustaleń i nie potrafi jasno ustawić priorytetów w projekcie.
Dobry Product Owner i Analityk Biznesowy jest od podejmowania właściwych decyzji we właściwym momencie
I to jest realna, mierzalna wartość — znacznie większa niż znajomość frameworków czy języków programowania.
Co realnie robi kompetentny, „nietechniczny” PO/BA?
1. Wie, kogo trzeba wciągnąć do rozmowy
Nie tylko „biznes”.
Dobry PO/BA:
-
wie, kto podejmuje decyzję,
-
kto ponosi konsekwencje,
-
kto później powie „nie tak się umawialiśmy”.
A jeśli nie ma dostępu do kluczowego interesariusza — nazywa to ryzykiem, zamiast udawać, że „jakoś to będzie” .
2. Umie dojść do prawdziwego problemu
„Chcemy nowy dashboard” prawie nigdy nie jest potrzebą.
To objaw.
Kompetentny PO/BA:
-
odróżnia deklarację od potrzeby,
-
potrafi zapytać „po co?” bez wkurzania rozmówcy,
-
zatrzymuje rozmowę na poziomie problemu, zanim zespół zacznie projektować rozwiązanie.
To jest kompetencja analityczna, nie techniczna.
3. Rozróżnia poziomy wymagań (i nie miesza ich ze sobą)
Dobry PO/BA wie, że:
-
wymaganie biznesowe ≠ cel biznesowy,
-
wymaganie funkcjonalne ≠ user story,
-
wymagania niefunkcjonalne ≠ „jakieś technikalia”.
Dzięki temu:
-
zespół wie dlaczego coś robi,
-
rozumie, co jest istotą rozwiązania,
-
ma przestrzeń zaproponować sensowne opcje techniczne, zamiast zgadywać intencje.
4. Pilnuje spójności i jakości wymagań w czasie
Największy chaos w projektach nie bierze się z braku wiedzy technicznej, tylko z:
-
dopisywania rzeczy „w locie”,
-
sprzecznych ustaleń,
-
decyzji, które nigdy nie zostały domknięte.
Dobry PO/BA:
-
pamięta, co było ustalone,
-
wie, co się zmieniło i dlaczego,
-
potrafi to jasno zakomunikować zespołowi .
5. Umie rozmawiać z zespołem developerskim normalnym językiem
To właśnie dlatego nietechniczny Product Owner bywa dla zespołu developerskiego większym wsparciem niż osoba, która zna techniczne detale, ale nie potrafi jasno określić celu i granic rozwiązania
Nie musi znać:
-
frameworków,
-
wzorców projektowych,
-
architektury systemu.
Musi:
-
jasno określić efekt,
-
ustalić granice rozwiązania,
-
odpowiedzieć na pytanie „co jest ważne, a co opcjonalne”.
To oszczędza zespołowi dziesiątki godzin — i dokładnie dlatego dobrzy developerzy cenią współpracę z PO/BA.
6. Jest pomostem, a nie przekaźnikiem
Product Owner i Analityk Biznesowy:
-
nie przenosi ticketów,
-
nie jest sekretarką spotkań.
Jest od:
-
filtrowania chaosu,
-
tłumaczenia intencji,
-
upraszczania komunikacji w obie strony.
Dzięki temu:
-
zespół developerski nie musi zgadywać sensu pracy,
-
biznes nie musi wchodzić w detale techniczne .
7. Dyskutuje o rozwiązaniach, zamiast je narzucać
Bo wie, że:
-
pierwsze rozwiązanie rzadko jest najlepsze,
-
dobre decyzje rodzą się z alternatyw,
-
„da się” ≠ „warto”.
To jest kompetencja decyzyjna, nie techniczna.
8. Ustala ramy, które chronią zespół
Bez jasnych granic zespół:
-
dorabia funkcje,
-
optymalizuje nie to, co trzeba,
-
robi „ładnie”, zamiast „potrzebnie”.
Dobry PO/BA pilnuje:
-
zakresu,
-
celu,
-
kryteriów „wystarczająco dobrze”.
9. Chroni czas zespołu (i swój własny)
Jest mistrzem:
-
przygotowanych spotkań,
-
jasnych decyzji,
-
zamykania tematów.
I nie zabiera zespołu na każde spotkanie „na wszelki wypadek”.
To też jest dojrzałość roli.
I teraz najważniejsze
Nietechniczny Product Owner nie jest „gorszą wersją PO”.
Jest osobą w innej roli — roli, która spina decyzje, priorytety i sens pracy zespołu.
Żadna z tych kompetencji nie wymaga umiejętności pisania kodu.
Wymagają:
-
myślenia systemowego,
-
decyzyjności,
-
komunikacji,
-
odwagi mówienia: „tego jeszcze nie wiemy”.
„Nietechniczna” nie oznacza:
„mam braki”
Najczęściej oznacza:
„jestem w innej roli — i ta rola jest krytyczna dla sukcesu projektu” .
Co faktycznie bywa problemem u PO i BA?
Z mojego doświadczenia najczęściej nie brakuje wiedzy, tylko:
-
struktury pracy,
-
ram decyzyjnych,
-
uporządkowania procesów,
-
domykania tematów.
To prowadzi do poczucia chaosu, improwizacji i siedzenia po nocach — mimo że „teoretycznie ogarniasz”.
I dobra wiadomość jest taka: to da się poukładać.
