Product Engineering - Jak przestać być klepaczem kodu
Skrót prezentacji wygłoszonej na Boiling Frogs 2025.
Niedawno wystąpiłem na konferencji Boiling Frogs 2025 z prezentacją
"Product Engineering - jak przestać być klepaczem kodu".
Nagranie z wydarzenia pojawi się wkrótce i podzielę się nim, gdy tylko będzie dostępne. W międzyczasie chcę podzielić się z Tobą głównymi treściami tej prezentacji.
Czy czasem nie masz wrażenia, że tkwisz w roli "klepacza kodu" zamiast prawdziwego inżyniera produktu?
Moja prezentacja dotyczyła tego właśnie problemu:
jak przejść od biernego wykonawcy cudzych pomysłów
do aktywnego współtwórcy wartościowych rozwiązań,
z korzyścią zarówno dla ciebie, jak i dla biznesu.
Product Engineering dla developera
W tradycyjnym modelu współpracy diagram odpowiedzialności wygląda następująco:
W modelu produktowym granica przesuwa się:
Product Engineering burzy mur między biznesem a technologią. Zamiast sztywnego podziału, gdzie biznes wymyśla, a programiści wykonują, tworzymy środowisko, w którym inżynierowie mają realny wpływ na kształt produktu.
Jakie korzyści daje to programiście?
Masz realny wpływ na produkt - nie jesteś już tylko wykonawcą cudzych pomysłów, ale aktywnie kształtujesz rozwiązania.
Projektujesz rozwiązania, nie tylko kod - wychodzisz poza samą implementację i współtworzysz kompleksowe podejście do problemu.
Uczysz się sprzedawać usprawnienia techniczne - potrafisz komunikować wartość biznesową swoich propozycji technicznych, dzięki czemu spłata długu technologicznego staje się możliwa.
Masz większą satysfakcję z pracy - widzisz pełen obraz i efekty swoich działań, co zwiększa poczucie sensu wykonywanej pracy.
Przejdźmy teraz do konkretnych technik, które pozwalają wdrożyć podejście produktowe w codziennej pracy deweloperskiej.
Techniki Product Engineeringu
W ramach prezentacji poruszyłem 4, wg mnie najważniejsze praktyki:
1. Od problemu do rozwiązania
Jaki problem rozwiązujemy?
W tradycyjnym modelu biznes przychodzi do programistów i mówi
Potrzebujemy zbudować duży system X z funkcjami A, B i C.
Przedstawia to typowy scenariusz:
Biznes narzuca gotowe rozwiązania bez konsultacji.
Programiści koncentrują się wyłącznie na technikaliach, nie znają celu biznesowego.
Powstaje mur między tymi dwiema grupami.
W efekcie dostarczamy rozwiązania, które:
Mogą nie trafiać w faktyczne potrzeby
Są nadmiernie skomplikowane
Zabierają znacznie więcej czasu i zasobów niż potrzeba
Opis podejścia - Impact Mapping
Jak to zmienić? Wychodzimy z poziomu rozwiązania na poziom problemu. Gdy biznes przychodzi z gotowym rozwiązaniem, kluczowe jest zadanie pytania:
Jaki cel chcemy osiągnąć? Jaki problem rozwiązujemy?
Tu z pomocą przychodzi technika Impact Mapping, o której pisałem już w newsletterze o celach, możliwościach i rozwiązaniach. Impact Mapping to wizualna metoda planowania, która pomaga:
Jasno zdefiniować cel biznesowy.
Zidentyfikować kluczowych aktorów (kto może pomóc osiągnąć cel?).
Określić wpływ (jak aktorzy mogą pomóc w osiągnięciu celu?).
Dopiero na końcu - wypracować rozwiązania wspierające te wpływy.
Dzięki temu podejściu wspólnie z biznesem wypracowujemy najlepsze rozwiązanie dla danego problemu, zamiast ślepo implementować pierwsze pomysły. Biznes ma możliwość szybszej realizacji danego celu. My unikamy olbrzymich projektów, które nigdy się nie kończą.
2. Adaptacyjne podejście
Jaki problem rozwiązujemy?
W tradycyjnym modelu współpracy często występuje następujący konflikt:
Biznes chce szybkich wyników i MVP, zawsze z rozwiązaniem na już, na teraz.
Programiści chcą solidnych, dobrze zaprojektowanych rozwiązań.
Rezultatem są niekończące się dyskusje o tym, co jest "wystarczająco dobre":
Biznes wpada w pułapkę szybkich rozwiązań, które generują dług techniczny.
Technologia wpada w pułapkę przeprojektowania i perfekcjonizmu.
Obie strony są sfrustrowane, pomimo że ze swojej perspektywy mają racje.
Opis podejścia - 3X
Rozwiązaniem jest adaptacyjne podejście inspirowane modelem 3X (Explore-Expand-Extract) Kenta Becka, o którym pisałem w newsletterze o Wahadle Proof of Concept.
W tym podejściu:
Dopasowujesz poziom inwestycji do etapu rozwoju produktu.
Komunikujesz jasno ograniczenia i konsekwencje biznesowe każdego etapu.
Przygotowujesz drogę wyjścia dla nietrafionych pomysłów.
Model 3X dzieli rozwój produktu na trzy etapy:
Explore - faza eksperymentalna, gdy testujemy pomysł:
Minimalne rozwiązania, prowizorki są OK.
Niskie koszty porażki.
Szybkie iteracje.
Jasna komunikacja ograniczeń.
Expand - faza skalowania, gdy wiemy, że pomysł działa:
Solidniejsze rozwiązania, ale wciąż z kompromisami.
Skupienie na szybkim dostarczaniu wartości.
Przygotowanie do potencjalnej pełnej skali.
Extract - faza dojrzałości, gdy produkt osiąga sukces na dużą skalę:
Pełna inwestycja w solidność i wydajność.
Eliminacja długu technicznego.
Optymalizacja kosztów operacyjnych.
Dzięki temu podejściu obie strony zyskują wspólny język i zrozumienie procesów. Zamiast prowadzić niekończące się dyskusje o tym, czy rozwiązanie ma być "szybkie" czy "dobre", wspólnie ustalamy właściwy poziom inwestycji dla każdego etapu rozwoju.
3. Praca z danymi produktowymi
Jaki problem rozwiązujemy?
W tradycyjnym modelu współpracy często napotykamy taki schemat:
Biznes podejmuje decyzje na podstawie własnych opinii i przeczuć: "Ja wiem co działa, jestem 100 lat w branży!".
Technologia skupia się wyłącznie na technicznych metrykach: "CPU jest na 50%, więc wszystko działa świetnie".
Nikt nie sprawdza, jak produkt faktycznie sprawdza się u użytkowników.
Skutki? Budujemy funkcje, których nikt nie używa, optymalizujemy nie te elementy co trzeba, a prawdziwe problemy użytkowników pozostają nierozwiązane.
Opis podejścia - Lean Analytics
Rozwiązaniem jest oparcie decyzji o konkretne dane z produktu, co nawiązuje do podejścia Lean Analytics opisanego w jednym z moich wcześniejszych newsletterów:
Stawianie hipotez biznesowych - tworzenie sprawdzalnych założeń dotyczących produktu.
Implementacja pomiarów - dodanie odpowiednich mechanizmów śledzenia.
Analiza i wnioskowanie - podejmowanie decyzji w oparciu o zebrane dane.
Praktyczna implementacja tego podejścia zaczyna się od zadawania właściwych pytań: "Dlaczego użytkownicy porzucają proces na określonym etapie?" lub "Które funkcje przynoszą największą wartość?". Na ich podstawie definiujemy, co dokładnie chcemy zmierzyć.
Następne kroki to:
Wybór odpowiednich narzędzi analitycznych (Google Analytics, własne systemy).
Zdefiniowanie kluczowych wskaźników dla biznesu i technologii.
Przegląd danych i identyfikacja trendów.
Podejmowanie decyzji opartych na faktach, nie przeczuciach.
Ten proces daje solidne podstawy zarówno dla decyzji biznesowych, jak i technicznych. Zamiast opierać się na opiniach i intuicji, mówimy: "Dane pokazują, że ta zmiana zwiększy konwersję o 15%".
Dzięki podejściu opartemu na danych inżynierowie stają się partnerami w podejmowaniu decyzji produktowych. Mamy konkretne argumenty w dyskusjach z biznesem i możemy efektywniej priorytetyzować naszą pracę.
Sprzedawanie usprawnień technicznych
Jaki problem rozwiązujemy?
W tradycyjnym modelu współpracy często występuje taki scenariusz:
Biznes przyjmuje podejście "nie naprawiaj tego, co działa" - zero inwestycji w poprawę pracy systemu.
Programiści używają technicznych argumentów (SOLID, DDD, refaktoryzacja), które są kompletnie niezrozumiałe dla biznesu.
Dług techniczny narasta, a wydajność zespołu spada.
Efekt? Ważne usprawnienia techniczne nigdy nie dostają zielonego światła, bo nikt poza zespołem technicznym nie rozumie ich wartości. Biznes widzi tylko koszt, nie dostrzegając korzyści.
Opis podejścia - Tech Debt Wall i Stakeholder Mapping
Rozwiązaniem jest przełożenie technicznych problemów na wartość biznesową, o czym pisałem w artykule Dług w produkcie — jak uzasadnić jego spłatę?. Kluczowe elementy tego podejścia to:
Mapowanie problemów technicznych na wpływ biznesowy - konkretne liczby i wartości.
Dostosowanie przekazu do różnych interesariuszy - każdy interesariusz ma inne priorytety.
Wizualizacja problemów - za pomocą technik jak Tech Debt Wall.
Praktyczne zastosowanie wymaga przygotowania. Najpierw identyfikujemy techniczne problemy i przekładamy je na konkretne straty biznesowe - np. czas, pieniądze, reputację. Następnie tworzymy mapę interesariuszy, by zrozumieć kto ma wpływ na decyzje i co jest dla nich ważne.
W kolejnym kroku dopasowujemy nasz przekaz do każdego interesariusza:
Dla CFO: argumenty finansowe i oszczędnościowe.
Dla dyrektora produktu: szybkość iteracji i feedback od klientów.
Dla działu obsługi klienta: redukcja liczby zgłoszeń i problemów.
Dla zespołu sprzedaży: przewaga konkurencyjna i nowe możliwości.
Warto też wykorzystać wizualizacje, takie jak Tech Debt Wall, aby pokazać gdzie znajdują się problemy o wysokiej wartości i niskim koszcie naprawy. Ta technika pozwala przejrzyście przedstawić, które usprawnienia przyniosą najszybszy zwrot z inwestycji.
Dzięki temu podejściu usprawnienia techniczne przestają być "fanaberiami programistów", a stają się inwestycjami. Zamiast walczyć o zasoby, pokazujemy konkretny zwrot z inwestycji w poprawę jakości kodu czy infrastruktury.
Podsumowanie
To tylko cztery z wielu technik, które pomagają deweloperom przejść od roli "klepacza kodu" do prawdziwego inżyniera produktu. Każda z nich pozwala lepiej współpracować z biznesem, podejmować lepsze decyzje i mieć realny wpływ na kształt rozwiązań.
W ramach pogłębiania wiedzy polecam te 4 artykuły: