„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ć.
