Większość firm technologicznych nie ma problemu z pomysłami. Ma problem z tempem dowożenia. Roadmapa rośnie szybciej niż zespół, rekrutacja seniorów ciągnie się miesiącami, a funkcje, które miały wyjść w tym kwartale, przesuwają się na następny. Product engineering to odpowiedź na tę właśnie lukę: rozwój produktu dowożony tam, gdzie on realnie powstaje, czyli wewnątrz Twoich zespołów, a nie w oderwanym software housie, który odda Ci kod i zniknie.
Z naszego doświadczenia najważniejsze jest jedno rozróżnienie. Nie przejmujemy Twojego produktu, tylko przyspieszamy jego rozwój od środka. Nasi inżynierowie wchodzą do istniejących zespołów, pracują na Twojej roadmapie i pod Twoim product ownerem, a Ty zachowujesz pełną kontrolę nad kierunkiem. Dalej pokazujemy, jak robimy to u realnych klientów, od wiodącej firmy technologicznej po lidera z Doliny Krzemowej.
Czym jest product engineering i kiedy go potrzebujesz?
Product engineering to budowanie i rozwijanie oprogramowania jako żywego produktu, a nie jednorazowego projektu z datą końcową. Liczy się ciągłość: kolejne wersje, dług techniczny trzymany w ryzach, funkcje dokładane iteracyjnie i utrzymanie, które nie blokuje rozwoju.
Sięgasz po nie zwykle wtedy, gdy pojawia się jeden z tych sygnałów:
- roadmapa wyprzedza możliwości zespołu i backlog puchnie szybciej, niż go domykacie,
- brakuje konkretnej kompetencji (np. doświadczonego front-endowca, inżyniera od integracji albo mobilnego), a rekrutacja trwa zbyt długo,
- chcecie przyspieszyć bez budowania działu od zera, który potem trzeba utrzymać mimo spadku obłożenia,
- produkt wszedł w fazę skalowania i nagle wymaga więcej rąk niż w etapie MVP.
W każdym z tych przypadków nie potrzebujesz nowego dostawcy produktu. Potrzebujesz więcej mocy inżynierskiej w zespołach, które już masz.
Jak dowozimy funkcje w zespołach produktowych?
Wpinamy inżynierów bezpośrednio w Twoje zespoły i Twój rytm pracy. Pracują na wspólnej tablicy, biorą udział w planningach i przeglądach kodu, a za priorytety i kierunek odpowiada Twój product owner. Dzięki temu dowożą funkcje w tym samym tempie i według tych samych standardów co reszta zespołu, tylko że szybciej, bo kompetencja jest na miejscu od pierwszego sprintu.
Taki układ ma realną przewagę nad klasycznym zlecaniem całości na zewnątrz. Wiedza o produkcie zostaje u Ciebie, bo powstaje w Twoim zespole, a nie wyparowuje razem z odejściem zewnętrznego dostawcy. Nie powstaje też druga, równoległa roadmapa, którą trzeba potem godzić z własną. Jako partner nearshore z Polski pracujemy w zbliżonej strefie czasowej, więc nasi ludzie wchodzą w codzienne spotkania i code review bez przesuwania godzin i bez długiego rozruchu.
Jak wzmacniamy front-end i back-end produktu?
Większość pracy w produkcie dzieje się na dwóch warstwach i obie obsadzamy doświadczonymi inżynierami fullstack. Po stronie front-endu budujemy interfejsy i komponenty, które realnie dotykają użytkownika, a po stronie back-endu rozwijamy logikę, usługi i integracje, na których opiera się cała reszta.
W praktyce obejmuje to:
- front-end aplikacji i paneli (nowoczesne frameworki, komponenty wielokrotnego użytku, spójny UX),
- back-end i usługi (logika biznesowa, bazy danych, wydajność i skalowanie),
- integracje systemów, czyli spięcie produktu z resztą ekosystemu klienta,
- pracę fullstack tam, gdzie zespół potrzebuje ludzi domykających funkcję end-to-end.
Nie dobieramy składu „na zapas”. Patrzymy na to, czego brakuje w konkretnym zespole, i uzupełniamy dokładnie tę lukę.
Jak projektujemy i wersjonujemy API?
API to kręgosłup każdego dojrzałego produktu, bo decyduje o tym, jak łatwo dokładacie nowe funkcje i jak bezboleśnie integrujecie się z innymi systemami. Dlatego projektujemy je jako kontrakt, a nie przypadkowy efekt uboczny implementacji.
W tej warstwie dbamy o czyste, spójne kontrakty, żeby zespoły konsumujące API nie musiały zgadywać, jak ono działa. Wprowadzamy wersjonowanie, które pozwala rozwijać interfejs bez rozbijania istniejących integracji, i pilnujemy wstecznej kompatybilności tam, gdzie z API korzystają klienci zewnętrzni albo inne wewnętrzne zespoły. Dokumentację traktujemy jako część dostarczenia, a nie dodatek po fakcie, bo dobrze opisane API to mniej pytań i szybsze wdrożenia po Twojej stronie.
Jak modernizujemy i refaktoryzujemy legacy?
Każdy produkt, który żyje kilka lat, zbiera dług techniczny. Nie musi to oznaczać przepisywania wszystkiego od zera, co zwykle jest najdroższą i najbardziej ryzykowną drogą. Zamiast tego modernizujemy stopniowo, utrzymując produkt w ruchu.
Najczęściej robimy to tak:
- refaktoryzujemy newralgiczne moduły, które najbardziej spowalniają rozwój,
- podnosimy wersje bibliotek i frameworków, żeby odzyskać bezpieczeństwo i wydajność,
- wydzielamy usługi z monolitu tam, gdzie to realnie upraszcza dalszy rozwój,
- dokładamy testy wokół starego kodu, zanim zaczniemy go zmieniać.
Kluczem jest kolejność. Modernizujemy to, co blokuje roadmapę, a nie wszystko naraz, więc zespół cały czas dowozi funkcje, a dług maleje w tle.
Jak budujemy aplikacje mobilne w ramach produktu?
Dla wielu produktów aplikacja mobilna to główny punkt styku z użytkownikiem, więc traktujemy ją jak pełnoprawną część inżynierii produktu, a nie osobny byt. Obsadzamy role mobilne (iOS, Android) i wpinamy je w ten sam rytm co resztę zespołu, żeby funkcje na web i na mobile szły spójnie, a nie dwoma rozjeżdżającymi się torami. Współtworzymy warstwę aplikacji, dbamy o jej integrację z back-endem i API oraz o to, żeby codzienne ścieżki użytkownika były proste i szybkie. Gdy produkt łączy kilka platform, patrzymy na niego całościowo, bo wartość powstaje dopiero wtedy, gdy wszystkie warstwy grają razem.
Jak dbamy o jakość i tempo jednocześnie?
To pozorna sprzeczność: można dowozić szybko i porządnie, jeśli jakość jest wbudowana w proces, a nie doklejana na końcu. W praktyce oznacza to code review jako normę, a nie wyjątek, testy automatyczne wokół kluczowych ścieżek, udział w CI/CD i wspólnych pipeline’ach oraz weryfikację kompetencji przed startem, żeby do zespołu trafiali ludzie, którzy realnie podnoszą poprzeczkę. Mierzymy się nie liczbą linii kodu, tylko tym, czy roadmapa idzie do przodu w przewidywalnym tempie.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, który wpina inżynierów w zespoły produktowe klientów technologicznych i dowozi rozwój od środka.
Dla wiodącej firmy technologicznej rozwijamy custom front-end i integracje systemów od 2022 roku, pracując fullstack przy różnych projektach w ramach jej produktu. To przykład product engineeringu w czystej postaci: nasi ludzie są częścią zespołu długoterminowo, a nie wykonawcą pojedynczego zlecenia.
Dla lidera z Doliny Krzemowej budujemy aplikacje, narzędzia inżynierskie i komponenty platformy chmurowej. Tu product engineering sięga głębiej, bo dotyczy nie tylko funkcji dla użytkownika, ale też wewnętrznych narzędzi i fundamentów platformy, na których stoi reszta produktu.
W obu przypadkach działa ta sama zasada: wzmacniamy zespół klienta, a nie zastępujemy go, a wiedza o produkcie zostaje po jego stronie.
Od czego zacząć rozwój produktu w zespołach?
Zacznij od najwęższego wąskiego gardła. Wskaż jeden zespół albo jeden obszar produktu, w którym brak mocy najbardziej boli roadmapę, i nazwij konkretną kompetencję, której brakuje. To wystarczy, żebyśmy dobrali ludzi pod rzeczywistą lukę, a nie pod ogólne „potrzebujemy developerów”. Jeśli wahasz się między wzmocnieniem zespołu, zespołem dedykowanym a usługą zarządzaną, różnice rozpisaliśmy w artykule o modelach współpracy IT.
Rozwijasz produkt technologiczny i potrzebujesz więcej mocy inżynierskiej w zespołach? Porozmawiajmy, dobierzemy ludzi pod Twoją roadmapę.