Product Engineer - nowa rola?
Kim jest inżynier produktu i jakie są jego zalety pracy w organizacji?
Rolą programisty jest tylko pisanie kodu
Tak niedawno napisał mój znajomy. Jeśli tak jest (a nie chcę się sprzeczać), to może potrzebujemy innej roli? 😉
Do podobnego spostrzeżenia doszedł Wojciech Seliga w swojej prezentacji 'Plantacje programistów":
Następnym krokiem jest Product Engineering. Jest to przejście z kodu i technologii na produkt - rozwiązanie prawdziwego problemu.
A więc o co chodzi z tą rolą?
Nowa rola na rynku
Do pewnego momentu w branży mieliśmy wyraźny podział - programiści skupiali się tylko na kodzie. Jednak takie podejście przestaje się sprawdzać w dzisiejszych organizacjach.
Jak widać na grafice poniżej, tradycyjnie mamy do czynienia z 3 zakresami odpowiedzialności - biznes określa cele biznesowe i strategię produktową, Product Manager zajmuje się obszarami rozwoju i problemami klienta, a programiści skupiają się na architekturze i programowaniu.
Działa, ale wymaga nieustannego przerzucania pracy i domyślania się intencji drugiej strony. I buduje długą pętlę zwrotną.
W ramach podejścia produktowego inżynierowie zaczynają brać na siebie więcej odpowiedzialności. Zamiast skupiać się tylko na programowaniu, angażują się w szerszy kontekst produktowy.
Inżynierowie produktu rozumieją nie tylko kod, ale także problemy klienta, obszary rozwoju, a nawet strategię produktową.
(Zakres działania Product Managera też się zmienia, ale to temat na inny artykuł).
To podobny trend do tego, co opisuje John Cutler w swoim modelu Mandate Level - zespoły techniczne przestają być tylko wykonawcami, zaczynają być faktycznymi współtwórcami rozwiązań.
Powstaje pytanie - skąd taki trend?
Dlaczego organizacje idą w tę stronę?
Sparafrazujmy nazwę tego newslettera 😄
Pozwala to organizacjom dostarczać lepsze produkty cyfrowe szybciej.
Widzę 3 kluczowe zalety:
Szybsze reagowanie na zmiany
W obecnych czasach szybkość reakcji jest kluczowa.
Gdy inżynierowie produktów rozumieją cele biznesowe, mogą znacznie szybciej adaptować produkt do zmieniających się potrzeb rynku. Nie muszą czekać na szczegółową specyfikację - sami proponują rozwiązania znając kontekst biznesowy.
W ramach poprzedniego newslettera Cele -> Możliwości -> Rozwiązania pisałem o tym, jak ważne jest rozpoczynanie od zrozumienia celów. Gdy inżynierowie je rozumieją, to:
Szybciej podejmują decyzje techniczne
Proaktywnie proponują usprawnienia
Dostosowują architekturę pod faktyczne potrzeby
To skraca czas od pomysłu do wdrożenia i pozwala wyprzedzić konkurencję.
Redukcja marnotrawstwa
Tradycyjny model prowadzi do wielu strat, które zanikają gdy programiści są zaangażowani od początku procesu:
Wykrywanie nierealnych założeń
Było: Problemy wychodzą dopiero podczas implementacji.
Jest: Wyłapujemy je na etapie dyskusji i planowania.
Rozmiar funkcjonalności
Było: Biznes definiuje duże zmiany jako "całość do wdrożenia".
Jest: Dzielimy rozwiązania na mniejsze, inkrementalne części.
Alternatywne rozwiązania
Było: Programiści dostają gotową specyfikację do implementacji .
Jest: Uczestniczą w dyskusji i proponują prostsze podejścia.
Atrybuty jakościowe
Było: Pomijane przez presję na szybkie dostarczenie.
Jest: Uwzględniane od początku procesu projektowania.
Wyższa jakość produktu
Programiści, którzy rozumieją produkt i jego użytkowników, podejmują lepsze decyzje techniczne. Wiedzą, które aspekty są kluczowe dla klientów, a gdzie można pójść na kompromis.
Jak opisywałem w artykule o driverach architektonicznych, rozumiejąc cele biznesowe jesteśmy w stanie lepiej dobierać rozwiązania techniczne. A to prowadzi do:
Lepszej architektury dopasowanej do potrzeb.
Bardziej przemyślanych decyzji technicznych.
Skuteczniejszego zarządzania długiem technicznym.
Efektywniejszego wykorzystania zasobów.
To wszystko przekłada się na wyższą jakość rozwiązań - zarówno od strony technicznej, jak i biznesowej. A w dłuższej perspektywie oznacza niższe koszty utrzymania i rozwoju produktu.
—
Ok, to jeśli mamy tak duże zalety organizacyjne to w jaki sposób mogę pracować bardziej produktowo?
Jak pracuje inżynier produktu
Inżynier produktu to znacznie więcej niż tylko programista.
To osoba, która łączy:
umiejętności techniczne
ze zrozumieniem biznesu i potrzeb klienta.
Dzięki temu może aktywnie uczestniczyć w całym procesie tworzenia produktu - od planowania, przez wdrożenie, aż po analizę rezultatów.
Na etapie planowania i analizy:
Współpracuje z Product Managerem przy ustalaniu priorytetów.
Uczestniczy w rozmowach z klientami, by lepiej zrozumieć ich potrzeby.
Identyfikuje ryzyka techniczne i biznesowe.
Proponuje alternatywne rozwiązania, które mogą być prostsze w implementacji.
W trakcie realizacji i po wdrożeniu skupia się na:
Przeprowadzaniu eksperymentów, by znaleźć właściwe rozwiązanie.
Optymalizacji procesów produktowych, aby użytkownik łatwiej pracował z produktem.
Monitorowaniu wskaźników jakościowych produktu - wydajności, dostępności, błędach.
Zbieraniu i analizie feedbacku od użytkowników.
Śledzeniu metryk produktowych.
Inżynier produktu musi balansować pomiędzy kodem a biznesem. Nie jest to łatwe zadanie. Jednak dzięki temu może mieć realny wpływ na sukces produktu, zamiast być tylko wykonawcą zadań.
Czy nie mam więcej pracy?
Można tak powiedzieć. Jednocześnie podejście produktowe jest wspierane przez rozwój technologii - w dzisiejszych czasach po prostu łatwiej się programuje niż 10-20 lat temu:
Nowoczesne narzędzia przyspieszające pracę developerską - automatyzacja CI/CD, feature flags, monitoring.
Środowiska chmurowe upraszczające pracę z infrastrukturą i wdrożeniami.
Wszechobecny dostęp do wiedzy - książki, kursy, StackOverflow i GitHub.
AI zmniejszające obciążenie umysłowe programistów - nie musimy pamiętać o każdym średniku w kodzie 😉
A to pozwala skupić się inżynierom produktu na szerszym kontekście pracy, zamiast jedynie szczegółach implementacyjnych.
Jak rozwijać kompetencje produktowe
Droga do zostania inżynierem produktu nie jest trudna, ale wymaga systematycznego poszerzania swojej perspektywy.
Zacznij od małych kroków:
porozmawiaj ze swoim Product Ownerem o celach produktu i potrzebach klientów,
weź udział w rozmowie z klientem,
zaproponuj alternatywne rozwiązanie dla aktualnego zadania.
Z czasem zaczniesz zauważać szerszy kontekst swojej pracy i naturalnie będziesz przejmować więcej odpowiedzialności za produkt.
Warto również aktywnie szukać wiedzy i inspiracji na zewnątrz. Branża technologiczna bardzo mocno idzie w kierunku inżynierii produktowej, jest więc sporo materiałów na ten temat. Jeśli chcesz dowiedzieć się więcej, polecam:
Empowered - Książka Marty'ego Cagana pokazuje jak budować silne zespoły produktowe i dlaczego rola inżyniera produktowego jest w nich kluczowa.
Product Development – 5 przemyśleń - Moje przemyślenia na temat rozwoju produktu.
Jak tworzyć produkt, a nie zbiór funkcjonalności - Prezentacja z Beyond Code o podejściu produktowym.
What is a Product Engineer - PostHog świetnie opisuje tę rolę z perspektywy firmy produktowej.
The Product-Minded Engineer - Gergely Orosz zebrał kluczowe cechy inżyniera produktowego.
Product Engineers - Sherif Mansour pokazuje jak współpracować z Product Managerem.