Zarządzanie produktem · 2 min czytania

Ten o inżynierze produktu

Developer czy inżynier produktu? Kod i zamknięte tickety to wyniki, rezultat jest u użytkownika. Jak AI zmienia rolę developera. Zapowiedź serii.

Co jest rezultatem pracy developera?

Od tego pytania zacząłem w maju prezentację „Developer to dobry start. Inżynier produktu to kierunek”. Na tak zadane pytanie zwykle padają odpowiedzi: kod, nowa funkcjonalność, zamknięte tickety albo poprawione błędy.

To wszystko są wyniki. Rezultat pojawia się dopiero u użytkownika, gdy zmienia się to, co robi, albo czego już robić nie musi.

Każdy, kto dłużej pracuje w branży, pamięta pogoń za funkcją, która potem nie trafiła na produkcję albo nikt jej nie używał. Wynik był, a rezultatu zabrakło.

Developer to dobry start. Inżynier produktu to kierunek. Co jest rezultatem pracy developera?

Przez lata praca developera w trybie „ticket, kod, PR, następny” jakoś się broniła, bo napisanie kodu było drogie i wymagało specjalistów. Teraz dużą część kodu potrafi wygenerować AI. Kiedy wynik tanieje, coraz więcej zależy od tego, czy developer wie, po co go dostarcza, i czy jest w stanie powiedzieć, co się z tym kodem dzieje później.

Ta sama technologia pozwala developerom wyjść poza własny stack. Z pomocą AI można zrozumieć, jak działa inny dział firmy, przejrzeć kilkaset zgłoszeń z supportu w poszukiwaniu powtarzających się problemów albo złożyć dashboard z danymi biznesowymi, nawet bez doświadczenia w pracy analityka. Próg wejścia w niektóre tematy znacząco się obniżył.

Rola developera musi ewoluować, choć może raczej trzeba wrócić do korzeni.

Jedną z możliwości jest inżynier produktu, czyli ktoś, kto zna technologię, rozumie klienta i model biznesowy, a przez to jest w stanie współtworzyć kierunek rozwoju firmy, zanim powstanie ticket.

Samo słowo „inżynier” ma swoją etymologię, która przez lata gdzieś się zagubiła.

A u Was co jest rezultatem pracy developera?


💬 Dołącz do dyskusji na LinkedIn → Komentuj i podziel się swoim podejściem