//Lepszy Product Owner

Czy AI zastąpi analityka biznesowego i Product Ownera? Wnioski z HackYeah

Natalia Cholewa jako mentorka na HackYeah — czy AI zastąpi analityka biznesowego

Słyszysz, że AI zastąpi analityków biznesowych i Product Ownerów?

Też mi się obiło o uszy.

A potem pojechałam na hackaton.

Krótko: AI nie zastąpi analityków ani product ownerów. Ale zmieni to, za co nam płacą. I jak dla mnie super 🙂

AI napisze kod i wygeneruje aplikację w 24 godziny. Nie ustali jednak, czy ktoś tej aplikacji potrzebuje, nie pogodzi sprzecznych interesariuszy i nie weźmie odpowiedzialności za decyzję. To jest zadanie analityka biznesowego i Product Ownera, i w erze AI ważniejsze niż kiedykolwiek.

Ostatnio brałam udział w HackYeah, największym stacjonarnym hackatonie w Europie.

Nie w roli uczestnika, bo 24 godziny pracy nad rozwiązaniem bez snu przerastają moje możliwości.

Wybrałam więc opcję, w której dało się zdrzemnąć, nawet jeśli tylko 3 godziny. Rolę Mentora.

W czasie hackatonu powstało ponad 700 projektów. Niektóre bardzo ciekawe i nowatorskie, inne pragmatyczne, ale spokojnie mogą na siebie zarobić.

A jeszcze inne… bardzo przeciętne.

W erze AI kod nie jest już wyzwaniem

Ten etap mamy za sobą. W 24 godziny możesz przygotować w pełni działającą aplikację: z rejestracją, logowaniem, mnóstwem funkcjonalności i niezłym designem.

Widziałam to na żywo, niektóre rozwiązania były tak dopracowane, aż ciężko było uwierzyć, że 24h wystarczyły.

No, ale w sumie prostego agenta AI zbudujesz w 8 minut, więc w sumie może nie powinno mnie to dziwić?

Tylko co z tego, jeżeli taka aplikacja nie odpowiada na żadną realną potrzebę?

Umrze na śmietniku innych aplikacji, które miały “się udać”.

Nie używaj AI do szukania potrzeb i wymyślania ich rozwiązania.

To nie ten etap. Gdyby AI było rewelacyjne w szukanie realnych potrzeb do zaadresowania to już mielibyśmy wysyp świetnych aplikacji.

A jakoś jest cisza.

Na hackatonie część osób wrzuciła do AI samo zadanie, co skończyło się tym, że parę zespołów pracowało nad dokładnie takim samym (mizernym) pomysłem.
Było nawet tak, że pięć aplikacji nazywało się tak samo….cóż za zbieg okoliczności 😉

Było mnóstwo aplikacji, które łączą różne grupy ze sobą. Uczestnicy przyznali nawet, że sami nie zapłaciliby za takie rozwiązanie.

Działające. I nikomu niepotrzebne.

I okazuje się, że zupełnie odwrotnie, niż nam, analitykom i Product Ownerom, wieszczono, nie wyginiemy. Wręcz przeciwnie.

Wszystko zaczyna się od potrzeby (nie od wymagania)

Wiesz czemu powstają systemy IT? Złośliwi żartują, że dlatego, że nie wszyscy kumają wystarczająco Excela.

Ale rzeczywistość jest taka, że wszystko zaczyna się od jakieś potrzeby, która powinna być zaspokojona. Dopiero to jest podstawa do stworzenia wymagań.

Tego AI z kodu nie wyciągnie (zwłaszcza jeśli tego kodu jeszcze nie ma). Od interesariuszy też ma średnią szansę, bo musieliby wiedzieć czego potrzebują, a to w sumie rzadsze niż może się wydawać. W tym świetnie właśnie odnajdują się analitycy biznesowi albo Product Ownerzy.
A w co pójdzie LLM, jeśli nie dostanie wymagań? W prościznę. W odtwórczość. Pójdzie po linii najmniejszego oporu, bo do tego został stworzony.

W rezultacie powstaje rozwiązanie miałkie, które nie odpowiada na nowe potrzeby, tylko na takie, które już zostały zaspokojone. Stąd pięć aplikacji o tej samej nazwie.

Co AI już robi za analityka, a czego nie?

To nie jest tak, że hejtuję AI. Zupełnie nie! Sama korzystam i to korzystam dużo. Ale trzeba to robić z głową.

Nie piszę wymagań z AI. Uważam, że to głupota z dwóch powodów.

Po pierwsze, oddając to AI, stopniowo tracimy wiedzę o rozwiązaniu. Dużo lepiej pamiętasz rzeczy, które sama wymyśliłaś i opisałaś, niż te, które po prostu przeczytałaś. Tak po prostu działa ludzki mózg.

Po drugie, w 99% przypadków taka specyfikacja będzie bardzo długa. A to dokłada roboty developerom. Albo, co gorsza, triggeruje ich, żeby wrzucić to do AI, żeby podsumowało…

No więc definicję rozwiązania z podziałem na user stories robię ja. Wspomagam się AI przy pisaniu kryteriów akceptacji. Ale uczyłam go naprawdę długo, jak to ma być zrobione. Zazwyczaj: zwięźlej niż zaproponował.

Używam też AI przed refinementem z zespołem, żeby wyłapać oczywiste dziury czy braki w mojej specyfikacji (to krok, który u mnie zawsze był, ale zajmowałam wtedy czas testera i developera). Na refinemencie zostaje czas na prawdziwe rozkminy, a nie na „oczywistości”.

Drugi przykład, jak wykorzystuję AI, to notatki ze spotkań. Ale nie tak, jak Ci się wydaje 😉

Zawsze prowadzę notatki ręcznie. Jestem wtedy zmuszona przeformułować i streścić na bieżąco, a to dla mnie świetne ćwiczenie do zapamiętywania, co się wydarzyło. I są badania, które potwierdzają, że tak właśnie działa ludzki mózg. Czasem podpieram się transkrypcją.

W sumie chyba najważniejszy feature AI, jaki wykorzystuję, to przedyktowanie tego co napisałam ręcznie do notatki cyfrowej 😀 Polecam Wispr Flow.

Świetnie się też modeluje procesy ze wsparciem AI. Jeszcze 2 lata temu średnio to miało sens – budował obrazki (co mi po obrazku, którego nigdzie nie przeniosę i ciężko będzie nanosić zmiany). Dziś dostaniesz modele do zaimportowania do różnych narzędzi – i to ma sens.

Ostatnie z codziennych zastosowań AI to przygotowywanie makiet dla developerów. Niestety nie mam obecnie w zespole designera, więc spadło to na nas. I to faktycznie super działa. W kilka chwil ustalamy, jak najlepiej coś zaadresować i w rezultacie dostajemy klikalny prototyp html. Rozmowa z interesariuszami jest zupełnie inna, kiedy możemy na bieżąco wprowadzać zmiany w prototypie i widzieć zmiany od razu.

Dlaczego AI nie zastąpi analityka biznesowego ani Product Ownera

Bo zbuduje rozwiązanie, które klient opisał.

Nie takie, którego potrzebował.

Nie takie, które przyniesie mu jakiś zysk.

Model nie siedzi na spotkaniu, na którym dwóch interesariuszy chce sprzecznych rzeczy. Nie dopyta o to, czego nikt nie powiedział na głos. I nie weźmie odpowiedzialności za decyzję.

Czasami zapominamy, że ani analitycy, ani Product Ownerzy nie są od „zbierania wymagań”.

Naszym zadaniem jest wprowadzić zmianę. Taką, która będzie miała znaczenie.

I czasem ta zmiana to coś zupełnie innego, niż klient zakładał na początku.

Czasem zamiast budowania agenta AI wystarczy dodać filtr albo dashboard. Niskim kosztem mamy rozwiązaną, zaspokojoną potrzebę.

Agent wyglądałby efektowniej. Filtr rozwiązuje problem.

Ważny jest efekt końcowy.

Niektórzy powiedzą, że kod napisany przez AI jest do d**y

Być może. Nie jestem programistką, nie mnie to oceniać.

ALE

Jak masz dobry pomysł, to kod da się poprawić.

A jak go nie masz, to najlepszy kod tego nie uratuje.

Dlatego o nasze role jestem dziś spokojniejsza niż kiedykolwiek.

Warto przeczytać

Lepszy Product Owner

Jak napisać wizję produktu, która NIE jest bullsh*tem

Zacznijmy od prawdy: Większość wizji produktu to… bullsh*t. Brzmią tak: „dostarczamy wysokiej jakości usługi” „zapewniamy innowacyjne rozwiązania” „tworzymy nowoczesną platformę” „kompleksowe wsparcie…