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.

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