Jak zwykle działają zespoły

Skupienie na wdrożonych rozwiązaniach to norma w większości zespołów. “Zrobiliśmy 10 feature’ów w tym sprincie”, “Wdrożyliśmy nowy system płatności”, “Ukończyliśmy migrację do nowej architektury”. Te metryki dominują w naszych rozmowach. Mierzymy ile dostarczamy, nie czy to coś zmienia.

Czasami ktoś zapyta o wyniki biznesowe - czy wzrosły przychody, czy spadły koszty operacyjne. Problem w tym, że między wdrożonymi rozwiązaniami a przychodami firmy jest przepaść. Nie wiemy co się dzieje pomiędzy. Nie wiemy co powinniśmy mierzyć.

Nikt systematycznie nie monitoruje czy użytkownicy faktycznie korzystają z tego, co zbudowaliśmy:

• Wdrożyliśmy nowy system rekomendacji produktów, ale czy ktokolwiek z niego korzysta?

• Zoptymalizowaliśmy proces zakupowy, ale czy faktycznie coś to dało?

• Zrefaktorowaliśmy moduł płatności, ale czy to przyspieszyło rozwój?

W rezultacie próbujemy bezpośrednio powiązać wdrożone rozwiązania z wynikami finansowymi. To się nie może udać - zbyt duży przeskok.

Powstaje jednak pytanie...

Dlaczego to jest ważne dla inżynierów

Bo możemy się tym nie przejmować. Ale ostatecznie “mimo wszystko” warto 🙃

Zbyt wolna pętla zwrotna

To pierwszy problem, który uderza w naszą pracę. Piszemy kod, deployujemy, i... cisza. Feedback przychodzi po miesiącach.

Bez szybkiej informacji zwrotnej nie możemy ocenić czy nasze decyzje były słuszne. Czy ten refactoring coś dał? Czy optymalizacja faktycznie pomogła? Czy nowa funkcja w ogóle jest używana?

Pracujemy w ciemno. Każda kolejna zmiana to strzał w nieznane. Nie wiemy co działa, a co leży odłogiem. Bez tego kontekstu nie potrafimy się uczyć ani poprawiać.

Narracje bez danych

Ten problem pojawia się gdy wyniki biznesowe spadają. Przychody nie rosną jak planowano. Retencja maleje. Ale dlaczego? Nikt nie wie. Nie ma nici łączących nasze wdrożone rozwiązania z wynikami biznesowymi.

W rezultacie szukamy winnych, a nie przyczyn:

• “To wina tego feature’a, który zespół X wdrożył”

• “Gdyby Y nie nalegał na tę zmianę, byłoby OK”

• “Ten refactoring zepsuł wszystko”

Obrzucamy się winą zamiast analizować fakty. Tworzymy narracje oparte na domysłach. Polityka zastępuje dane.

Brak odpowiedzialności zespołu

Skoro nie wiemy jak nasza praca wpływa na użytkowników, to dlaczego mielibyśmy się przejmować? “Zrobiliśmy zgodnie ze specyfikacją” - staje się naszą tarczą.

Tracimy ownership. Stajemy się wykonawcami, nie współtwórcami produktu. Nikt nie czuje się odpowiedzialny za efekt końcowy.

Brak uzasadnienia dla usprawnień

To codzienność każdego lidera technicznego. “Musimy zrefaktorować ten moduł” - mówisz na planowaniu. “A ile to przyniesie pieniędzy?” - słyszysz w odpowiedzi.

Trudno bezpośrednio znaleźć przełożenie zmian technicznych na wyniki biznesowe. Brakuje pośrodka, który połączyłby refactoring z zyskami firmy. Między naszym kodem a przychodami jest przepaść - ta sama, o której mówiliśmy na początku.

Output-Outcome-Impact

Podział Output-Outcome-Impact to sposób myślenia, który pozwala zrozumieć jak praca inżynierska przekształca się w wartość biznesową.

Poniżej znajduje się grafika, która bazuje na tej z artykułu Output vs Outcome vs Impact Christophe’a Achouiantza.

• Output to nasza codzienna praca. Namacalna i mierzalna w ticketach i feature’ach.

• Outcome to efekt naszej pracy widziany oczami użytkownika. Zmiana ich zachowań i sposób korzystania z produktu.

• Impact to wymierny efekt biznesowy dla organizacji. Liczby, którymi żyje C-level.

Metryki produktowe znajdują się między tym, co robimy, a efektem biznesowym. Pokazują jak użytkownicy faktycznie korzystają z naszych rozwiązań.

Kluczowe jest zrozumienie, że te elementy są ze sobą połączone. Nasz Output generuje Outcome (zmianę zachowań użytkowników). Ten z kolei generuje Impact (wyniki biznesowe).

Korzyści z metryk produktowych

Zbudowanie mostu pomiędzy rozwiązaniami, a wpływem biznesowym ma kilka zalet:

• Szybsza pętla zwrotna - Dni czy tygodnie zamiast miesięcy. Wiemy czy nasze decyzje były słuszne, zanim projekt się zakończy.

• Możliwość korygowania kursu - Zmiany można wprowadzać zanim dotrą do Impact. Nie czekamy aż metryki biznesowe pokażą problem.

• Wspólny język z biznesem - Zamiast “Zrobiliśmy nowy onboarding” mówimy “60% użytkowników ukończyło onboarding (vs 30%)”. Liczby zastępują domysły.

• Uzasadnianie usprawnień technicznych - “Refactoring przyspieszy wdrażanie zmian w X, co poprawi metric Y”. Znajdujemy brakujący pośrednik między kodem a zyskami.

Usprawnienia techniczne przestają być “zachciankami” inżynierów. Stają się inwestycjami w lepsze wyniki biznesowe.

Od czego zacząć

Krok 1: Wybierz jedną funkcję do obserwacji

Weź na tapet feature czy epic, nad którym obecnie pracujesz. Wybierz coś istotnego, ale nie krytycznego - potraktuj to jako eksperyment.

Krok 2: Określ co będziesz obserwować

Zadaj sobie pytanie: jak zaobserwujesz zmianę zachowania klienta?

• Jakie akcje użytkownik wykona inaczej niż dotychczas?

• Które ekrany/funkcje zacznie częściej odwiedzać?

• Co przestanie robić, bo nowe rozwiązanie jest lepsze?

• Jak zmieni się jego ścieżka w produkcie?

Krok 3: Zbuduj minimalną obserwowalność

Potrzebujesz narzędzia do obserwowania zachowań użytkowników. To może być Posthog, Amplitude, a nawet prosty dashboard w Kibanie.

Nie musisz od razu kupować drogich rozwiązań. Zacznij od tego, co masz pod ręką.

Krok 4: Poczekaj aż zmiana się wygrzejeje

Daj zmianie czas na wygrzanie się. Tydzień, dwa, może miesiąc - w zależności od częstotliwości użytkowania produktu.

Dopiero wtedy oceń wyniki. Zbyt wczesna ocena pokaże tylko szum, nie prawdziwy trend.

Krok 5: Wprowadź rytm przeglądu

Wprowadź regułę: wszystkie kolejne funkcje muszą być obserwowane produktowo. Ustal stały punkt w kalendarzu na przegląd obserwacji:

• Sprint review z danymi o zachowaniach użytkowników.

• Retrospektywy oparte o fakty, nie domysły.

• Decyzje produktowe wsparte obserwacjami.

Krok 6: Argumentuj usprawnienia danymi

Naucz się łączyć usprawnienia techniczne z obserwacjami użytkowników:

• “Ten refactoring przyspieszy wdrażanie zmian w X, dzięki czemu więcej użytkowników zrobi Y”

• “Spłata długu technicznego zmniejszy liczbę bugów, co zwiększy liczbę powracających użytkowników”

Metryki produktowe to brakujące ogniwo między kodem a wpływem na biznes. Zacznij od jednej funkcji, a zobaczysz jak zmienia się sposób pracy całego zespołu.

Czas na przejście do drugiej części etapu Orient w pętli OODA - syntezy informacji. W przypadku zespołów produktowych będzie to ewaluacja efektywności zespołowej. Celem jest znalezienie wzorców - co sprawia, że zespół jest szybki i skuteczny, a co go blokuje i spowalnia.

Jednak najpierw 2 słowa o tym, co właściwie rozumiemy przez syntezę.

Synteza - Wprowadzenie

W książce Science, Strategy and War Boyd opisywał syntezę jako:

This is done by finding some common features that interconnect some or many of these parts so that a new pattern can be created. We call this process of connection: synthesis.

Można to przedstawić następująco:

Analiza to poszerzanie. W mapowaniu kompetencji rozkładaliśmy zespół na czynniki pierwsze. Katalogowaliśmy umiejętności, identyfikowaliśmy luki, przypisywaliśmy ludzi do zadań. Rozszerzaliśmy obraz.

Synteza to domykanie. Teraz łączymy kropki. Szukamy wzorców między problemami. Odkrywamy, że 10 różnych symptomów to efekt 2 przyczyn źródłowych. Zawężamy do esencji.

Po tym krótkim wyjaśnieniu wróćmy na poziom zespołu produktowego.

Ewaluacja efektywności

Jak to zrobić w praktyce? Ewaluację przeprowadzamy w dwóch krokach:

1. Pytania syntezujące - łączymy elementy analizy w powtarzające się wzorce.

2. Budowanie mapy wpływów - przekształcamy odkryte wzorce w spójny obraz pokazujący mechanizmy działania zespołu.

To przejście od “co widzimy” (analiza) do “co to oznacza” (synteza).

Pytania syntezujące

Odpowiedzi na poniższe pytania będą się przeplatać - ten sam problem pojawi się w wielu miejscach. Tego właśnie szukamy - punktów, gdzie różne wymiary się krzyżują.

Wzorce szybkiego dostarczania

Szukamy mechanizmów przyspieszających lub spowalniających tworzenie produktu.

• Co sprawia, że niektóre funkcje dostarczamy bez problemów, a inne się przeciągają?

• Dlaczego niektóre decyzje techniczne podejmujemy szybko, a inne blokują nas na tygodnie?

• Jaki jest wspólny mianownik projektów, które zakończyły się sukcesem?

• Co łączy wszystkie sytuacje, gdy zależności międzyzespołowe nas blokowały?

Wzorce jakości i stabilności

Sprawdzamy, gdzie jakość jest efektem systemu, a gdzie heroicznych wysiłków jednostek.

• Dlaczego niektóre części systemu są stabilne, a inne ciągle sprawiają problemy?

• Co łączy sytuacje, w których dostarczamy wysoką jakość bez nadmiernego testowania?

• Jakie połączenie kompetencji i praktyk minimalizuje bugi w produkcji?

• Co jest wspólnego dla wszystkich repozytoriów, gdzie jakość zależy od konkretnej osoby?

Wzorce współpracy biznes-tech

Szukamy wzorców efektywnej komunikacji między światem biznesu a technologią.

• Co łączy wszystkie sytuacje, gdy dobrze rozumieliśmy potrzeby biznesowe?

• Co charakteryzuje projekty, gdzie wymagania są spójne i zrozumiałe od początku?

• Dlaczego niektóre kompromisy techniczne akceptujemy zbyt łatwo, przez co później cierpimy?

• Jaki wzorzec powtarza się w projektach, które wymagały największych zmian ad-hoc?

Wzorce zespołowe i zależności w zespole

Te pytania ujawniają niewidoczne zależności między ludźmi.

• Jaki wzorzec widać w sytuacjach, gdy brak jednej osoby blokował pracę zespołu?

• Gdzie mamy największe skupiska wiedzy vs. największe luki?

• Dlaczego z niektórymi osobami współpracuje się naturalnie, a z innymi wymaga to więcej wysiłku?

• Co charakteryzuje sytuacje, gdy współpraca w zespole działa wyjątkowo sprawnie?

Budowanie spójnego obrazu

Synteza to moment, gdy łączysz wszystkie odkryte wzorce w jedną mapę wpływów. To nie lista problemów - to sieć zależności pokazująca, jak zespół faktycznie działa.

Krzysztof Niewiński świetnie pokazał sposób wizualizacji takich wzorców w swoim video o Myśleniu systemowym:

Narzędziem do wizualizacji syntezy jest graf wpływów. Możesz go stworzyć jako diagram:

Taki graf pozwala zobaczyć:

• Źródła problemów - pierwotne przyczyny generujące kaskadę

• Ścieżki wpływu - jak jeden problem prowadzi do kolejnego

• Pętle zwrotne - gdzie problemy się samo-wzmacniają

• Punkty dźwigni - gdzie mała interwencja przerwie całą kaskadę

Dobra synteza pokazuje zespół jako system przepływów, gdzie problemy blokują wartość w przewidywalny sposób. Ujawnia mechanizmy utrzymujące status quo i wskazuje, co zmienić najpierw, by uruchomić pozytywną reakcję łańcuchową.

Przykład dla ecommerce “Checkout & Payments”

Wróćmy do zespołu z przykładu z artykułu o mapowaniu kompetencji.

Synteza ujawniła trzy kluczowe wzorce:

• kaskada spowolnienia (brak automatyzacji -> strach przed zmianami),

• wąskie gardło wiedzy (legacy system zna tylko senior), oraz

• ślepe decyzje (brak danych -> reaktywne poprawki).

Zobacz, jak te wzorce się ze sobą łączą:

Decyzja - Co dalej?

The concepts can then be used as decision-models for improving our capacity for independent action.

Boyd podkreślał, że synteza to fundament do podejmowania decyzji. Teraz musimy zdecydować, którędy prowadzić zespół.

Kluczowe pytania decyzyjne po syntezie:

• Który wzorzec jest źródłem pozostałych?

• Gdzie interwencja da największy efekt dźwigni?

• Jakie mamy ograniczenia (ludzie, czas, budżet)?

• Co możemy zrobić szybko vs co wymaga długoterminowej inwestycji?

I tymi pytaniami wejdziemy do kolejnego artykułu - o podejmowaniu decyzji i definiowaniu planu 😊

Jak sobie z tym poradzić? Spróbujmy najpierw zrozumieć źródło problemu.

Przeciążenie pracą utrzymaniową

Poniżej mamy macierz pracy produktowej:

Dolna część to praca nieplanowana - wszystkie ad hoc, wrzutki, “pilne” sprawy:

• Customer Success przychodzi z problemem dużego klienta

• Monitoring wyrzuca alerty o błędach w systemie

• Support eskaluje zgłoszenie od użytkownika

• Sami zauważamy, że coś nie działa jak powinno

• Logi pokazują podejrzane wzorce, które trzeba zbadać

To właśnie ta praca utrzymaniowa zjada większość czasu zespołu. Awarie, bugi, pytania o konfigurację, drobne poprawki. Niektóre zgłoszenia przychodzą z zewnątrz, inne generujemy sami.

Zespół próbuje nadążyć:

• Przerywa pracę nad nową funkcją, żeby naprawić błąd.

• Odkłada refaktoring, bo trzeba odpowiedzieć na pytanie o konfigurację.

• Zmienia priorytety w środku sprintu dla “krytycznego” zgłoszenia.

• Pracuje w trybie reaktywnym - gasi to, co się pali najgłośniej.

Sprint za sprintem mija, a postęp minimalny. Roadmapa produktowa stoi w miejscu, bo zespół tonie w pracy reaktywnej.

Wszystko jest istotne = nic nie jest

Co stoi za tą sytuacją?

Każde zgłoszenie ma taki sam priorytet. Nie ma systemu, który pozwala odróżnić to, co krytyczne, od tego, co może poczekać.

Zespół nie ma ustalonych poziomów istotności:

• Osoba A może uważać, że błąd w raportach jest krytyczny.

• Osoba B twierdzi, że wolny checkout to większy problem.

• Osoba C mówi, że najpierw trzeba naprawić integrację z kurierem.

Nie ma obiektywnych kryteriów, które pozwolą rozstrzygnąć ten spór. Każdy ma swoją własną definicję “pilne”.

To samo dotyczy zgłaszających:

• Dla Customer Success każdy problem klienta jest krytyczny - przecież klient płaci.

• Dla Product Managera najważniejsze są nowe funkcje - konkurencja nie śpi.

• Dla Supportu liczy się liczba ticketów - im szybciej zamkną, tym lepiej.

• Dla CEO liczy się on sam - skoro zgłasza, to jest najważniejsze 🤣.

Każdy patrzy ze swojej perspektywy.

A że zgłoszenie nic nie kosztuje? Klik w “new issue”, opis “pilne dla klienta X” i czekamy. Nie trzeba uzasadniać wpływu na biznes. Nie trzeba porównywać z innymi zadaniami. Nie trzeba nawet sprawdzić, czy problem dotyczy jednego użytkownika czy tysięcy.

W efekcie naprawiamy kosmetyczne błędy, podczas gdy krytyczne problemy czekają w kolejce.

Na szczęście jest tutaj rozwiązanie, a przynosi je sektor medyczny ❤️‍🩹

Lekcja z medycznego triażu

Szpitalny Oddział Ratunkowy radzi sobie z setkami pacjentów dziennie. Każdy twierdzi, że jego przypadek jest pilny. SOR rozwiązał ten problem systemem triażu - pacjenci są kategoryzowani według rzeczywistego zagrożenia życia i zdrowia.

System triażu medycznego dzieli pacjentów na poziomy:

• Czerwony (natychmiastowy) - zagrożenie życia, natychmiastowa pomoc.

• Żółty (pilny) - stan może się pogorszyć, wymaga szybkiej interwencji.

• Zielony (standardowy) - stabilny stan, może poczekać.

• Biały - nie wymaga leczenia szpitalnego, może iść do apteki.

Kryteria są transparentne. Pacjent z zawałem dostaje czerwony. Złamana ręka to żółty lub zielony w zależności od komplikacji. Katar? Biały - idź do apteki.

System działa, bo:

• Kryteria są jasne - każdy wie, dlaczego trafił do danej kategorii.

• Ocena jest obiektywna - parametry życiowe, nie opinie.

• Priorytet wynika z rzeczywistego ryzyka - nie z tego, kto głośniej prosi.

• Zasady są znane wszystkim - transparentność w praktyce.

To ostatnie to kluczowa zasada z Kanbana - Make Policies Explicit. Reguły są ustalone i spójne dla wszystkich. Pacjenci ze skręconą kostką rozumieją, dlaczego osoba z urazem głowy jest przyjmowana przed nimi. System jest “uczciwy”.

Dokładnie tego potrzebują zespoły produktowe. Obiektywnego systemu kategoryzacji zadań według rzeczywistego wpływu na biznes i użytkowników.

Triaż w produkcie

Podobnie jak SOR kategoryzuje pacjentów, zespoły produktowe mogą kategoryzować zgłoszenia. Zamiast reagować na wszystko z taką samą intensywnością, wprowadzamy poziomy istotności oparte na obiektywnych kryteriach.

Kryteria triażu

Patrzymy na kilka wymiarów:

• Wpływ na przychody - czy tracimy pieniądze w tej chwili?

• Liczba dotkniętych użytkowników - wszyscy, segment, czy pojedynczy przypadek?

• Ryzyko eskalacji - czy problem się pogarsza z czasem?

• Wpływ na reputację - czy to psuje wizerunek naszej firmy?

• Zgodność prawna - czy naruszamy przepisy lub umowy?

Kluczowe jest przełożenie tych pytań na konkretne liczby i progi. Każdy zespół musi ustalić własne, mierzalne granice między poziomami. Przykładowe progi:

• Wpływ na przychody: utrata >50% transakcji (critical) vs 5-20% (medium) vs <5% (low)

• Liczba użytkowników: >80% dotkniętych (critical) vs 10-50% (medium) vs <10% (low)

• Wydajność: czas odpowiedzi >10s (critical) vs 2-5s (medium) vs <2s (low)

• Eskalacja: problem narasta co godzinę (critical) vs stabilny (medium) vs izolowany (low)

• Reputacja: publiczne posty w social media (critical) vs tickety (medium) vs wewnętrzne zgłoszenia (low)

Proces oceny

Przychodzi zgłoszenie. Co robimy?

• Sprawdzamy rzeczywisty wpływ na produkt - dane z monitoringu, logi, metryki.

• Wyciągamy checklistę kryteriów i sprawdzamy, które są spełnione.

• Przypisujemy poziom na podstawie najwyższego spełnionego kryterium.

• Dokumentujemy decyzję - dlaczego taki poziom, nie inny.

• Informujemy zgłaszającego o przypisanym priorytecie i przewidywanym czasie reakcji.

Zgłaszający widzi, gdzie wylądowało jego zgłoszenie i dlaczego. Ma jasność co do kolejnych kroków.

Przykład kryteriów dla ecommerce

Pracujesz w firmie B2B ecommerce, która obsługuje setki sklepów internetowych. Twój zespół Checkout & Payments odpowiada za proces finalizacji zakupów. Codziennie wpływają dziesiątki zgłoszeń od różnych klientów.

Twoje poziomy mogą wyglądać następujące:

Każdy poziom ma jasno zdefiniowane kryteria. Zespół wie, że Critical oznacza natychmiastową reakcję. Low może poczekać do kolejnego sprintu. No Maintenance - przekierowujemy do Product Managera.

Wdrożenie procesu w zespole

Mamy kryteria, mamy poziomy. Teraz trzeba to wdrożyć. Nie da się tego zrobić odgórnie - zespół musi być częścią procesu od początku.

Aby proces zakorzenił się w organizacji warto go rozbić na kilka kroków:

1. Warsztaty z zespołem

Rozpoczynamy od wspólnego ustalenia poziomów. Zbieramy zespół na godzinny warsztat:

• Przechodzimy przez przykłady realnych zgłoszeń z ostatnich miesięcy.

• Dyskutujemy, gdzie powinny trafić według nowych kryteriów.

• Tam, gdzie są niezgodności - doprecyzowujemy kryteria.

• Zapisujemy decyzje, tworzymy pierwszą wersję poziomów triażu.

Zespół musi czuć, że to ich system, nie narzucony z góry.

2. Pierwszy dry-run

Bierzemy bieżące zgłoszenia z backlogu. Przechodzimy przez nie używając nowych kryteriów:

• Każde zgłoszenie oceniamy według checklisty.

• Przypisujemy poziom triażu i zapisujemy uzasadnienie.

• Notujemy przypadki, gdzie kryteria nie pasują lub są niejednoznaczne.

• Sprawdzamy czy rozkład poziomów ma sens biznesowy.

To pokaże, czy system działa. Czy 80% zgłoszeń nie wpadło przypadkiem do Critical? Czy może wszystko jest Low? Jeśli tak - trzeba skorygować progi.

3. Retrospektywa po dry-runie

Na najbliższym retro omawiamy:

• Co było najtrudniejsze do oceny?

• Których informacji brakowało w zgłoszeniach?

• Czy kryteria są zrozumiałe i jednoznaczne?

• Gdzie pojawiły się największe rozbieżności w ocenach?

Na podstawie feedbacku dopracowujemy kryteria. Dodajemy brakujące przypadki. Upraszczamy to, co było za skomplikowane.

4. Drugi dry-run z biznesem

Teraz czas na edukację interesariuszy. Organizujemy spotkanie z Customer Success, Product Managerem, Supportem:

• Pokazujemy system triażu i kryteria.

• Przechodzimy przez przykłady ich zgłoszeń - gdzie by trafiły.

• Wyjaśniamy czasy reakcji dla każdego poziomu.

• Zbieramy feedback - czego nie rozumieją, z czym się nie zgadzają.

To kluczowy moment. Interesariusze muszą zrozumieć, że nie wszystko może być Critical. Że są obiektywne kryteria. Że Low nie oznacza “nieważne”, tylko “może poczekać”.

5. Oficjalne uruchomienie

Po dwóch dry-runach i zebranym feedbacku możemy wystartować:

• Ogłaszamy nowy proces wszystkim zainteresowanym.

• Udostępniamy kryteria i poziomy w widocznym miejscu.

• Ustalamy osobę odpowiedzialną za triażowanie na początku.

• Monitorujemy, jak idzie, i korygujemy na bieżąco.

Pamiętajmy - to proces. Będzie ewoluował wraz z naszym produktem i organizacją.

Automatyzacja z GenAI

Dużą część pracy dookoła utrzymania można zautomatyzować, jeśli mamy ją ustrukturyzowaną. Triaż i jasne kryteria pozwalają nam zastosować automatyzację połączoną z GenAI.

Bot może zanalizować każde zgłoszenie zanim trafi do zespołu:

• Wyciągnie kluczowe informacje z treści.

• Zada dodatkowe pytania: “Ilu użytkowników to dotyczy?”.

• Sprawdzi logi i metryki z ostatniej godziny.

• Zasugeruje poziom triażu na podstawie kryteriów.

Człowiek tylko weryfikuje i potwierdza decyzję. Zgłaszający od razu dostaje informację, na jaki poziom trafiło zgłoszenie i dlaczego. Transparentność buduje zaufanie.

To działa w praktyce. Khan Academy używa automatycznego triażu osiągając 92% satysfakcji klientów. Equinix z Moveworks drastycznie zredukował kolejkę IT. Firma e-commerce zanotowała 40% redukcję czasu odpowiedzi. Wystarczy dobrze ustrukturyzowany prompt i integracja z monitoringiem.

Korzyści i moc push backu

Triaż produktowy to narzędzie organizacyjne, które przynosi konkretne, mierzalne korzyści.

Zespół odzyskuje skupienie. Zamiast przeskakiwać między dziesiątkami “pilnych” zgłoszeń, koncentruje się na tym, co naprawdę ważne. Czas na deep work wzrasta. Nowe funkcje powstają szybciej, bo nikt nie przerywa pracy dla kosmetycznych poprawek.

Interesariusze uczą się lepiej zgłaszać problemy. Muszą uzasadnić wpływ biznesowy. Przestają rzucać “to pilne” bez kontekstu. Widzą transparentną kolejkę i rozumieją, dlaczego ich zgłoszenie trafiło na dany poziom. Zgłaszają mniej “na wszelki wypadek”, bo wiedzą, że system i tak to odfiltruje.

Efekt? Roadmapa przestaje być fikcją. Sprint faktycznie kończy się dostarczeniem nowych funkcji. Liczba zgłoszeń maintenance spada, bo interesariusze sami się filtrują. Zespół wreszcie może budować produkt, zamiast biegać jak kot z pęcherzem.

Czym jest Orient?

Orient to szeroki temat prezentowany przez Boyda jako pięciokąt obejmujący kontekst decyzyjny - od dziedzictwa i kultury po nowe informacje i doświadczenia. W świecie produktów cyfrowych te aspekty są wartościowe - historia zespołu, kultura organizacji i poprzednie doświadczenia wpływają na podejmowane decyzje.

Jednak na pierwsze przejście przez pętlę skupimy się na fundamencie: analizie i syntezie obserwacji. John Boyd w eseju "Destruction and Creation" opisał to jako:

"To comprehend and cope with our environment we develop mental patterns or concepts of meaning. The purpose is to sketch out how we destroy and create these patterns to permit us to both shape and be shaped by a changing environment."

Boyd podkreślał, że skuteczne zrozumienie rzeczywistości wymaga najpierw destructive deduction - rozbicia istniejących wzorców na części, a następnie creative induction - złożenia ich w nowe, bardziej trafne obrazy sytuacji.

W kontekście intencjonalnego lidera przełożyłem to na 2 kroki:

• Analiza - przekształcenie obserwacji z 6 wymiarów w mapę kompetencji zespołu.

• Synteza - identyfikacja wzorców efektywności zespołu i czynników ograniczających jego wydajność.

Ten artykuł mówi o pierwszej części - analizie. Synteza to kolejny artykuł.

Dlaczego mapowanie kompetencji?

Obserwacje z 6 wymiarów dały nam surowe dane o zespole. Teraz musimy je przekształcić w decyzje liderskie. Ale żeby wybrać właściwe działanie, trzeba najpierw zrozumieć dwie rzeczy: co jest naprawdę istotne dla sukcesu zespołu i jak nasi ludzie się w to wpisują.

Boyd nazywał to:

"creating mental images or impressions that correspond to that world."

Aby to wykonać potrzebujemy:

• Na podstawie obserwacji wybrać kluczowe kompetencje zespołowe

• Zmapować jak kompetencje zespołu wpisują się w te wymagania

Mapowanie kompetencji to most między obserwacją a działaniem - przekształcasz wiedzę o zespole w świadome decyzje rozwojowe.

Wybór kluczowych kompetencji zespołowych

Nie wszystkie kompetencje są równie ważne. Zespół nie może rozwijać się jednocześnie w 20 obszarach - to prowadzi do rozproszenia i braku postępów. Musisz wybrać 3-7 kluczowych kompetencji, które będą fundamentem działań rozwojowych.

Wybór nie jest przypadkowy. Opiera się na analizie obserwacji z poprzedniego etapu. Łączysz wyzwania biznesowe z obecnymi możliwościami zespołu i znajdujesz te kompetencje, które mają największy wpływ na sukces.

Pytania do zadania

Te pytania pomogą Ci przejść systematycznie przez obserwacje i wyłowić najważniejsze kompetencje.

Na podstawie obserwacji domenowych i organizacyjnych:

• Które kompetencje są krytyczne dla naszych największych wyzwań biznesowych?

• Które kompetencje pozwalają skupić energię zespołu na rozwoju w obszarach, które przyniosą największą wartość?

• Gdzie brak kompetencji generuje największe ryzyko dla dostarczania wartości?

• Które kompetencje mogą być "good enough" vs. muszą być na poziomie eksperckim?

Na podstawie obserwacji produktowych i technicznych:

• Które umiejętności są niezbędne do rozwiązania naszych bolączek technicznych?

• Jakie kompetencje potrzebujemy do realizacji najbliższych celów produktowych?

• Gdzie nasza przewaga konkurencyjna wymaga utrzymania najwyższego poziomu?

Na podstawie obserwacji delivery i zespołowych:

• Które kompetencje najsilniej wpływają na naszą efektywność dostarczania?

• Gdzie indywidualne umiejętności przekładają się na kolektywną wydajność zespołu?

• Które obszary rozwoju najlepiej pasują do motywacji i aspiracji członków zespołu?

Potencjalne kompetencje zespołowe

Katalog poniżej to punkt wyjścia do dyskusji w zespole. Nie musisz wybierać tylko z tej listy - możesz dodać swoje kompetencje lub zmodyfikować istniejące pod kątem specyfiki swojego zespołu.

Strategiczno-biznesowe

• Rozumienie celów biznesowych - przełożenie celów organizacyjnych na działania techniczne

• Orientacja na potrzeby klienta - identyfikacja problemów użytkowników, korzeni dysfunkcji produktowych

• Myślenie architektoniczne - rozumienie driverów architektonicznych i ograniczeń jakościowych

• Decyzje architektoniczne - umiejętność identyfikacji kompromisów i wyboru rozwiązań

Planistyczno-organizacyjne

• Podział prac - dekompozycja zadań, identyfikacja zależności

• Analiza ryzyk - identyfikacja ryzyk (ludzie, procesy, technologie) i planowanie ich ograniczania

• Projektowanie procesów - mapowanie domeny biznesowej, organizowanie procesów

• Dostarczanie - wąskie gardła, efektywność, eksperymenty, iteracyjne podejście

Jakościowo-techniczne

• Strategia jakości - definiowanie metryk, narzędzi i praktyk zapewnienia jakości

• Observability - określanie co obserwować, łączenie narzędzi monitoringu

• Code review - balansowanie jakości i szybkości, automatyzacja

• Dokumentacja techniczna - tworzenie i utrzymywanie dokumentacji (np. C4)

Zespołowo-rozwojowe

• Dzielenie się wiedzą - mentoring, teaching, dokumentowanie

• Współpraca zespołowa - praca z różnymi typami osobowości, modele współpracy

• Delegowanie - stosowanie poziomów delegacji, dopasowanie stylu do sytuacji

• Facylitacja - prowadzenie warsztatów (Event Storming, design sessions)

Przykład dla ecommerce "Checkout & Payments":

Wróćmy do zespołu z przykładu z artykułu o obserwacji. Zebraliśmy obserwacje z 6 wymiarów. Na tej podstawie wybieramy kluczowe kompetencje:

1. Komunikacja z interesariuszami biznesowymi - krytyczne ze względu na chaos organizacyjny i rozproszoną odpowiedzialność.

2. Refaktoring i modernizacja legacy kodu - system rabatów PHP blokuje rozwój i generuje ryzyko.

3. Projektowanie odpornych integracji - błędy z operatorami płatności co tydzień przez brak retry mechanizmów.

4. Planowanie i estymacja pracy - problemy z przewidywalnością dostarczania, ciągłe przerywniki.

5. Analiza danych produktowych - 15% abandon rate bez zrozumienia przyczyn.

Te kompetencje nie są wybrane przypadkowo. Każda adresuje konkretne bolączki zidentyfikowane w obserwacjach i ma potencjał znacząco poprawić sytuację zespołu.

Mapowanie obecnych kompetencji zespołu

Mamy już wybrane kluczowe kompetencje. Teraz czas sprawdzić, jak osoby w zespole radzą sobie w tych obszarach. To nie jest ocena wydajności ani ranking - to próba zrozumienia obecnego stanu, żeby móc planować rozwój.

Boyd podkreślał znaczenie łączenia różnych umiejętności w zespole:

"Where skills and talents are pooled, the removal or overcoming of obstacles represents an improved capacity for independent action for all concerned."

Teraz czas systematycznie zmapować kompetencje osób w zespole.

Pytania do zadania

Te pytania pomogą przejść przez osoby w zespole i ocenić ich kompetencje w kluczowych obszarach.

Wiedza domenowa

• Na ile głęboko rozumie biznesowe konteksty naszych produktów?

• Czy zna potrzeby użytkowników końcowych i ich journey?

• Jak dobrze orientuje się w procesach organizacji?

• Czy potrafi przewidzieć biznesowe konsekwencje decyzji technicznych?

Kompetencje techniczne

• Jakie technologie zna na poziomie eksperckim vs. podstawowym?

• Czy nadąża za zmianami w naszym stosie technologicznym?

• Jak radzi sobie z debugowaniem i rozwiązywaniem złożonych problemów?

• Czy potrafi zaprojektować rozwiązanie od zera?

Umiejętności przekrojowe

• Jak skutecznie komunikuje się z różnymi grupami (biznes, tech, użytkownicy)?

• Czy dzieli się wiedzą i wspiera rozwój innych?

• Jak radzi sobie z analizą i podejmowaniem decyzji pod presją?

• Czy potrafi pracować autonomicznie vs. potrzebuje stałego wsparcia?

Potencjał i motywacja

• W których obszarach wykazuje największą chęć rozwoju?

• Jak szybko przyswaja nową wiedzę i umiejętności?

• Czy podejmuje inicjatywy wykraczające poza podstawowe obowiązki?

• Jak reaguje na zmiany i nowe wyzwania?

Spektrum oceny dla kompetencji:

Żeby mapowanie było użyteczne, potrzebujesz sposobu na określenie poziomu kompetencji. Spektrum poniżej pomoże sklasyfikować umiejętności bez tworzenia sztucznych kategorii.

Konkretny poziom ma swoją wartość w zespole - czasem potrzebujesz eksperta, czasem kogoś z podstawową wiedzą, ale wysoką motywacją do nauki.

Przykład dla ecommerce "Checkout & Payments":

Zobaczmy, jak wyglądałoby mapowanie kompetencji dla dwóch członków naszego przykładowego zespołu "Checkout & Payments". To pokazuje, jak przekładać pytania na konkretne profile kompetencyjne.

Anna - Senior Backend Developer:

• Wiedza domenowa: Ekspercka - 2 lata w płatnościach, zna wszystkie edge cases, rozumie wpływ zmian na conversion.

• Integracje płatnicze: Zaawansowane - implementowała 5 różnych operatorów, zna ich specyfikę.

• Komunikacja z interesariuszami: Rozwijająca się - komfortowo współpracuje z PM, ale unika kontaktu z Customer Success.

• Refaktoring legacy: Podstawowe - unika PHP jak ognia, preferuje przepisywanie od zera.

• Motywacja: Wysoka do challengów technicznych, niska do "polityki organizacyjnej".

Tomek - Junior Frontend Developer:

• Wiedza domenowa: Początkująca - 6 miesięcy w firmie, dopiero poznaje niuanse e-commerce.

• React/TypeScript: Podstawowe do średniego - pisze kod, ale czasem potrzebuje wsparcia przy skomplikowanych wzorcach.

• Planowanie i estymacja: Podstawowe - nie ma doświadczenia w szacowaniu, często się myli.

• Współpraca zespołowa: Dojrzałe - bardzo komunikatywny, chętnie pyta, dzieli się tym, co wie.

• Motywacja: Bardzo wysoka do nauki wszystkiego, frustruje się, gdy nie nadąża za tempem Anny.

Zakończenie - Przygotowanie do syntezy

Boyd podkreślał:

"Without this unstructuring, the creation of a new structure cannot proceed – since the bits and pieces are still tied together as meaning within unchallenged domains."

Wykonaliśmy "unstructuring" - rozbiliśmy surowe obserwacje na katalogowane kompetencje i profile. Mamy teraz:

• 5 kluczowych kompetencji zidentyfikowanych na podstawie obserwacji zespołu i wyzwań biznesowych

• Szczegółowe profile kompetencyjne członka zespołu w tych obszarach

• Spektrum oceny od podstawowego do eksperckiego poziomu

• Zrozumienie motywacji i potencjału rozwojowego danej osoby

Czego jeszcze nie mamy:

• Wzorców i połączeń między kompetencjami a problemami zespołu

• Priorytetyzacji - które luki są najważniejsze do uzupełnienia

• Syntezy - spójnego obrazu sytuacji zespołu

W kolejnym artykule połączymy te informacje w spójny obraz sytuacji zespołu i przygotujemy grunt pod podejmowanie świadomych decyzji liderskich.

Rozważania o tym, kim jest inżynier produktu i jak nim zostać dobrze byłoby zacząć od tego, czym właściwie jest ten "produkt" i w jakim kontekście osadza on pracujących nad nim inżynierów.

Czym jest produkt?

To, czym jest produkt, zależy od tego, z której strony na niego spojrzymy:

• Z perspektywy funkcjonalnej - produkt to rozwiązanie, które klienci 'zatrudniają', aby wykonało za nich określoną pracę. Są skłonni zapłacić zarówno za efekt tej pracy, jak i za sposób, w jaki została wykonana.

• Z perspektywy biznesowej - produkt to jednostka wymiany wartości między firmą, która go tworzy, a klientem, który go kupuje.

• Z perspektywy systemowej - produkt jest interfejsem pomiędzy technologią a potrzebą rynkową.

Zmiana sposobu myślenia

Przejście od „zwykłego" inżyniera do inżyniera produktu zaczyna się więc od zmiany sposobu myślenia na takie, które stawia w centrum produkt, a nie technologię.

Dobrym pierwszym krokiem jest oswojenie się z samym pojęciem produktu i pamiętanie, że tworzone rozwiązania nie istnieją w próżni. Technologia wyraża się poprzez produkt - a ten z kolei musi rozwiązywać realne problemy klientów w taki sposób, aby chcieli za niego zapłacić. Jeśli to się uda, przynosi on także zysk biznesowi, dla którego pracujemy.

Doświadczenia z prawdziwymi inżynierami produktu

W ciągu pięciu lat kariery produktowej miałam okazję współpracować z kilkoma inżynierami, których - mimo że "na papierze" ich role nazywały się inaczej - spokojnie nazwałabym inżynierami produktu.

Porównując poziom "nastawienia produktowego" z poziomem seniority widzę między nimi delikatną korelację. Jest ona jednak na tyle słaba, że dołączając do nowego zespołu nie zakładam automatycznie, że z pewnością znajdę "swoich ludzi" wśród tych najstarszych rangą. Np. jeden z najlepszych inżynierów produktowych, z którym pracowałam, był stażystą w późniejszym czasie przemianowanym na juniora.

Stąd wniosek: nastawienie produktowe nie zależy od lat doświadczenia, ale od konkretnych umiejętności.

Kluczowe umiejętności

(Nieoficjalni) inżynierowie produktu, z którymi do tej pory pracowałam, charakteryzowali się kilkoma umiejętnościami, które wyróżniały ich na tle zespołu. Choć są to głównie kompetencje „miękkie" i trudne do uchwycenia, to nadal są to umiejętności, których można się nauczyć i które można ćwiczyć i je rozwijać.

A ja postaram się podsunąć Wam kilka pomysłów, jak to robić.

Zaangażowanie

To chyba najważniejsza z umiejętności „produktowca".

Jeśli miałabym wybierać między:

• bardzo utalentowanym, ale zamkniętym na rozmowę inżynierem, a

• „średnim", ale ciekawym, współpracującym i podsuwającym pomysły programistą, to

zawsze lepiej będę wspominać tego drugiego.

Tworzenie dobrej, realistycznej wizji produktu i opracowywanie jego wymagań to praca zespołowa. Owszem, product manager wyznacza kierunek i bierze odpowiedzialność za cały proces, ale nie powinien tworzyć go sam.

Aby zbudować coś wartościowego, konieczne jest wyjście z funkcyjnego silosu i bliska współpraca PMa, developera, designera, a często też innych ról, jak analityk danych czy SME (o czym od dawna pisze Teresa Torres, bogini product discovery).

Dzięki takiej współpracy można:

• Wyłapać ukryte założenia dotyczące zachowań użytkowników

• Sprawdzić wykonalność i używalność rozwiązania

• Wspólnie zaprojektować flow

• Znaleźć edge case'y

• Stworzyć jasne przypadki testowe

Z mojego doświadczenia największym blokerem nie jest zwykle brak wiedzy - tylko to, że ktoś po prostu nie chce angażować się w taką eksploracyjną pracę, skupioną na rozmowie o sytuacjach klientów, zanim jeszcze przejdziemy do projektowania konkretnego rozwiązania.

Jak trenować zaangażowanie?

Dobra wiadomość jest taka, że „mięsień" zaangażowania da się stosunkowo łatwo wytrenować. Często wystarczy poszukać okazji, by wejść głębiej w jakiś temat.

W zespołach, z którymi pracuję, mamy zwyczaj wyznaczania „ownera" dla danej inicjatywy lub epika. Taki owner:

• Dołącza do mnie i designera w rozmowach z użytkownikami

• Uczestniczy w brainstormingach i sesjach projektowych

• Pilnuje dyskusji technicznych w zespole

• Dba o zaprojektowanie rozwiązania od strony technicznej

• Rozwiązuje z PMem oraz designerem edge case'y, które przeszły przez sito początkowego designu

Polecam spróbować takiego podejścia - nam pomogło nie tylko w sprawniejszym dowożeniu, ale też w rozwoju inżynierów, którzy pełnili rolę „właścicieli" tematów.

A nawet jeśli u Was nie ma takiej formalnej roli, jestem przekonana, że wystarczy dać PMowi znać, że chcecie wejść głębiej w dany temat - jestem przekonana, że każdy PM chętnie wciągnie Was we wcześniejsze etapy projektowania.

Empatia

Empatia to umiejętność wczuwania się w perspektywę innych ludzi - rozumienia ich emocji, potrzeb i ograniczeń - oraz brania tego pod uwagę w swoim działaniu.

Mówiąc o empatii mam na myśli empatię:

• Do użytkowników

• Do biznesu

• Do środowiska, w którym się znajdujemy (ze szczególnym naciskiem na inne role występujące w zespole)

Istnieje specjalne miejsce w produktowym piekle dla inżynierów i designerów, którzy ze sobą nie rozmawiają.

Produkty nie istnieją dla siebie

Produkty i ich funkcjonalności nie istnieją „dla siebie". Powstają po to, by rozwiązywać konkretne problemy konkretnych osób - w taki sposób, który jednocześnie przynosi firmie realne pieniądze.

Dystans między developerami a użytkownikami sprawia, że łatwo o decyzje pozornie dobre, ale w praktyce szkodliwe:

• Drobne zmiany, które psują flow użytkowników.

• Overengineering funkcjonalności, które zostałyby wykonane dużo prościej.

Brak empatii działa oczywiście w obie strony (w tym miejscu przepraszam wszystkich moich współpracowników za czekające w czeluściach backlogu taski na spłacenie długu technicznego) - stąd istotne jest, aby tę przepaść we wzajemnej empatii codziennie zmniejszać.

Jak budować empatię?

Najprościej: przez częstą wymianę informacji i gotowość do mówienia językiem drugiej strony.

Sama regularnie (= kilka razy w tygodniu) dzielę się z zespołem:

• Przykładami z rozmów z użytkownikami

• Ich cytatami

• Problemami, z którymi się mierzą

W zamian proszę ich, by tłumaczyli mi tematy techniczne w prosty sposób. Aby to jakoś uściślić proszę ich, żeby mówili do mnie tak, jak gdybym właśnie zaczęła pierwszy rok studiów z informatyki :)

Celowo kładę nacisk na częstotliwość. Dużo lepiej budują wzajemną empatię krótkie, ale bardzo częste interakcje niż rzadkie, „strategiczne" sesje, o których szybko się zapomina. Komu z nas nie zdarzyło się przeczytać kiedyś strategii firmy tylko raz i od razu o niej zapomnieć - niech pierwszy rzuci kamieniem.

Regularne obcowanie z problemami użytkowników buduje intuicję:

• Udział w wywiadach

• Śledzenie cytatów z nagrań

Dzięki niej naturalnie zaczynamy „czuć", które pomysły mają szansę powodzenia.

Inicjatywa

Mało co cieszy mnie tak bardzo, jak wiadomość od kogoś z zespołu zaczynająca się od:

„Ilona, myślałem/am o tym przypadku, o którym rozmawialiśmy, i mam pomysł…".

Product engineer to dla mnie ktoś, kto potrafi zaangażowanie i empatię przekuć w konkretne propozycje, na które sama bym nie wpadła. A wtedy, pracując razem, możemy je wprowadzić w życie.

Inicjatywa przyjmuje różne formy:

• Dokument z propozycją rozwiązania

• Draft nowej funkcjonalności

• Prosta makieta interakcji

• Szybki proof of concept

Cokolwiek, co pomoże zespołowi i stakeholderom zrozumieć ideę rozwiązania i zaplanować, jak przetestować ją z użytkownikami.

Steve Jobs powiedział kiedyś, że

"doers are the major thinkers"

i miał rację. To właśnie budując produkt, developerzy dostrzegają możliwości, których osoby w rolach „spajających" (takich jak PM) często nie widzą.

Jestem przekonana, że najlepsze pomysły pochodzą od ludzi pracujących najbliżej technologii - to oni wiedzą, jak przekuć ją w coś, co naprawdę zainteresuje klientów. Moja rola polega w dużej mierze na tworzeniu środowiska sprzyjającego takiej innowacji:

• Dzielenie się feedbackiem od klientów

• Definiowanie i badanie metryk

• Analiza konkurencji

• Ustalanie jasnych priorytetów biznesowych

• Facylitacja dyskusji

Podsumowanie

Myślę, że rozwój w kierunku produktowym to przede wszystkim zmiana nastawienia, niż zdobywanie twardej wiedzy. Tego nowego nastawienia można się nauczyć, tak każdej innej umiejętności - zaangażowanie, empatia i inicjatywa to „mięśnie", które można wytrenować poprzez konkretne nawyki w codziennej pracy.

Wierzę, że właśnie taki sposób działania pozwala budować lepsze produkty - a ostatecznie daje też większą satysfakcję zarówno inżynierom, jak i product managerom.

Wobec czego nasuwa się pytanie...

Czym jest Observe?

W książce Science, Strategy and War opisano podejście Boyda do pętli OODA. Boyd, podkreślał, że skuteczne podejmowanie decyzji wymaga obserwacji z wielu perspektyw:

"We must be able to examine the world from a number of perspectives so that we can generate mental images or impressions that correspond to that world."

Obserwacja to pierwszy krok w pętli OODA. Bez dobrej obserwacji następne etapy - Orient, Decide, Act - będą oparte na błędnych założeniach. Jako lider nie możesz polegać tylko na jednym źródle informacji. Potrzebujesz wielu punktów widzenia, żeby zbudować pełny obraz rzeczywistości swojego zespołu.

Celem obserwacji jest rozumieć jak najlepiej nasze otoczenie i zbierać jak najszybciej informacje, by móc dostosowywać nasze działanie. Chodzi o to, żeby widzieć nie tylko to, co dzieje się na powierzchni, ale także ukryte wzorce, potencjalne problemy i możliwości rozwoju. Dzięki temu możesz wyprzedzać problemy zamiast tylko na nie reagować.

To jest oczywiście ciągły proces (stąd pętla), ale od czegoś trzeba rozpocząć.

Moje podejście do Observe

Przykłady u Johna Boyda są skupione na sferze wojennej. Nie do końca aplikuje się to do produktów cyfrowych 😅

Wobec czego wypracowałem 6 wymiarów obserwacji otoczenia zespołu produktowego:

• Domenowy - co robimy

• Organizacyjny - z kim robimy

• Produktowy - dla kogo robimy

• Techniczny - jakimi technologiami

• Delivery - jakimi procesami

• Zespołowy - jakie osoby mamy w zespole

Dla każdego wymiaru możesz wspomóc się materiałami:

• Pytania - kierują naszą uwagę na kluczowe aspekty danego wymiaru. Zamiast zgadywać, zadajesz konkretne pytania, które odsłaniają sytuację zespołu. Dzięki nim nie przegapisz ważnych sygnałów.

• Spektrum - sposób na zobrazowanie, gdzie znajduje się naszzespół w danym wymiarze. Nie wszystko jest binarne - często sytuacja jest gdzieś pośrodku. Spektrum pokazuje Ci zakres możliwości i pomaga zrozumieć, w którą stronę się kierować.

Nie musimy skupiać się na wszystkich wymiarach naraz. Jednak musimy wiedzieć, że obszar obserwacji istnieje, by ocenić go jako istotny - niektóre wymiary będą ważniejsze od innych.

Żeby jednak materiały miały wymiar praktyczny to warto je oprzeć o przykładową domenę. A nie ma bardziej przystępnej domeny niż ecommerce 🙃

Domena przykładowa - ecommerce

Wyobraźmy sobie firmę TechShop, która tworzy platformę ecommerce dla średnich przedsiębiorstw:

• Firma istnieje od 5 lat i obsługuje około 200 sklepów internetowych w różnych branżach - od odzieży po elektronikę

• Platforma oferuje kompletne rozwiązanie: zarządzanie produktami, obsługę płatności, system logistyczny i analitykę sprzedaży

• W firmie pracuje kilka zespołów produktowych

W ramach tej domeny pracujesz w zespole odpowiedzialnym za "Checkout & Payments" - proces finalizacji zakupów i obsługi płatności:

• To kluczowy obszar dla całej platformy, bo tu klienci podejmują ostateczną decyzję o zakupie

• Zespół składa się z 7 osób: Product Managera, lidera zespołu (Ciebie) 4 programistów (frontend, backend, 2x fullstack) i QA

• Odpowiadacie za cały proces od koszyka, przez wybór opcji dostawy, metod płatności, aż po potwierdzenie zamówienia

Skoro przykładową domenę mamy za sobą to przejdźmy do poszczególnych wymiarów obserwacji.

Wymiary obserwacji

Przejdźmy przez każdy wymiar i zobaczmy, jak zastosować go w praktyce.

Poniższy zbiór pytań i spektrum jest oczywiście do rozwinięcia - potraktuj go jako wstęp do twojego własnego narzędziownika 😊

Domenowy

Ten wymiar pomaga zrozumieć, w jakiej dziedzinie biznesowej działamy i jakie są kluczowe elementy tej domeny. Tutaj skupiamy się na mapowaniu poddomen, zrozumieniu ich dojrzałości i wartości biznesowej.

Pytania

Struktura domenowa

• Jakie poddomeny składają się na naszą domenę główną?

• Jak różnią się te poddomeny pod względem złożoności i stabilności?

• Na jakim etapie ewolucji jest każda z poddomen np. 3X: Explore, Expand, Extract?

• Jak dobrze zintegrowane są procesy między poddomenami?

Wartość biznesowa

• Które poddomeny generują największą wartość biznesową?

• Jak szybko rosną wymagania w każdej poddomenie?

• Które części domeny są krytyczne dla działania całego produktu?

• Jak silne są zależności biznesowe między subdomenami?

Spektrum

Przykład dla ecommerce

W przypadku zespołu "Checkout & Payments" widzimy, że nasza poddomena znajduje się w centrum platformy ecommerce. Składa się z kilku mniejszych obszarów: zarządzanie koszykiem, kalkulacja kosztów dostawy, integracja z operatorami płatności i potwierdzenie zamówienia.

Pod względem stabilności jesteśmy raczej ustabilizowani - podstawowe funkcje działają, ale ciągle dodajemy nowe metody płatności i opcje dostawy. Złożoność jest średnia do wysokiej ze względu na integracje z zewnętrznymi systemami płatności. Wartość biznesowa to absolutny priorytet - każdy błąd w checkout oznacza bezpośrednią stratę przychodów dla naszych klientów.

Organizacyjny

Ten wymiar pomaga zrozumieć, jak nasza domena funkcjonuje w kontekście całej organizacji i jakie są relacje z interesariuszami. Tutaj obserwujemy strukturę odpowiedzialności, autonomię zespołu i bliskość z biznesem.

Pytania

Struktura organizacyjna

• Jak wygląda podział ról naszej domeny - czy mamy jednego głównego interesariusza czy kilku?

• Jakie są główne zależności organizacyjne między naszym zespołem a innymi?

• Czy jesteś zespołem produktowym z wpływem na roadmapę czy raczej feature factory?

• Jak silny jest konflikt interesów między różnymi grupami interesariuszy?

Bliskość z biznesem

• Jak blisko współpracujemy z kluczowymi interesariuszami?

• Czy mamy bezpośredni dostęp do feedbacku od użytkowników końcowych?

• Jak często zmieniają się priorytety i kto je ustala?

• Jakie są główne wyzwania i ograniczenia organizacyjne?

Spektrum

Przykład odpowiedzi dla ecommerce

Mamy problem z rozproszonymi interesariuszami. Head of Product ustala jedne priorytety, ale Customer Success przychodzi z "pilnymi" prośbami od dużych klientów, które kłócą się z roadmapą. Dodatkowo zespół Logistics często zmienia wymagania dotyczące kalkulacji kosztów dostawy na ostatnią chwilę.

Jesteśmy gdzieś pomiędzy feature factory, a pełną decyzyjnością. Mamy wpływ na niektóre decyzje, ale często czujemy się jak wykonawcy cudzych pomysłów. Największym problemem organizacyjnym jest chaos w komunikacji - nie wiadomo kto podejmuje ostateczne decyzje o priorytetach i jak rozwiązywać konflikty między różnymi działami.

Produktowy

Ten wymiar pomaga zrozumieć, dla kogo robimy nasz produkt i jak mierzymy jego skuteczność. Tutaj skupiamy się na segmentach użytkowników, ich potrzebach i metrykach produktowych.

Pytania

Segmenty użytkowników

• Kim są nasi główni użytkownicy i jak różnią się ich potrzeby?

• Które segmenty użytkowników są dla nas najważniejsze biznesowo?

• Jak dobrze rozumiemy ścieżki użytkowników (user journeys) w naszej domenie?

• Jakie są główne problemy i frustracje naszych użytkowników?

Metryki i mierzenie

• Jakie kluczowe metryki produktowe śledzimy i jak często?

• Czy mamy dostęp do danych behawioralnych użytkowników?

• Jak mierzymy sukces nowych funkcji i zmian?

• Jakie mamy mechanizmy zbierania feedbacku od użytkowników?

Spektrum

Przykład odpowiedzi dla ecommerce

Rozumiemy podstawowe potrzeby użytkowników, ale brakuje nam głębszej wiedzy. Wiemy, że kupujący chcą szybkiego procesu, administratorzy elastyczności, ale nie wiemy dlaczego 15% użytkowników porzuca proces na etapie wyboru dostawy.

Brakuje nam bezpośredniego dostępu do danych - musimy prosić zespół Analytics o raporty z tygodniowym opóźnieniem. Feedback to głównie skargi przez Customer Success, nie mamy A/B testów. Podejmujemy decyzje na podstawie domysłów, a nie danych.

Techniczny

Ten wymiar pomaga zrozumieć stan techniczny systemu i możliwości dostarczania wartości. Tutaj badamy architekturę, dług techniczny i jakość rozwiązań technicznych.

Pytania

Architektura i struktura

• Jak wygląda podział na systemy/serwisy i ich zależności?

• Które części to legacy vs nowoczesne technologie?

• Czy struktura techniczna odzwierciedla strukturę zespołów (prawo Conwaya)?

• Jak dobrze zmodularyzowana jest architektura - czy możemy rozwijać części niezależnie?

Stan techniczny i jakość

• Jaki jest poziom długu technicznego w różnych częściach systemu?

• Jak wygląda pokrycie testami i automatyzacja?

• Czy mamy monitoring, obserwowalność i alerting na produkcji?

• Jak często występują błędy produkcyjne i jak szybko je naprawiamy?

Spektrum

Przykład odpowiedzi dla ecommerce

Pracujemy z mieszanką technologii. Frontend to React z TypeScript, backend to Node.js z PostgreSQL. Mamy mikrousługi dla płatności i jedną większą aplikację dla checkout. Legacy to stary system rabatów napisany w PHP sprzed 4 lat - kod bez testów, dokumentacji i z bardzo słabym monitoringiem.

W nowych częściach testy chronią nas przed regresją, ale stary system rabatów musimy testować ręcznie. Monitoring pokazuje tylko podstawowe błędy, brakuje alertingu biznesowego. Błędy produkcyjne zdarzają się co tydzień, głównie przez niestabilne integracje z operatorami płatności i brak retry mechanizmów w starym kodzie. Największym długiem technicznym jest system rabatów - refaktoring zajmie minimum 3 miesiące.

Delivery

Ten wymiar pomaga zrozumieć, jakimi procesami dostarczamy wartość i jak sprawnie funkcjonujemy jako zespół. Tutaj skupiamy się na cyklu dostarczania, automatyzacji i rytmie pracy.

Pytania

Proces dostarczania

• Jak długo trwa cykl od pomysłu do produkcji?

• Czy możemy wdrażać niezależnie w różnych domenach?

• Jaki poziom automatyzacji mamy (testy, CI/CD)?

• Czy istnieją feature flags i możliwość stopniowego rollout?

Rytm i planowanie

• Jak wygląda nasz rytm pracy (sprinty, kanban, continuous flow)?

• Jak planujemy i priorytetyzujemy zadania?

• Czy mamy regularne retrospektywy i czy z nich wynikają zmiany?

• Jak radzenie sobie z nieprzewidzianymi sytuacjami i bugami?

Spektrum

Przykład odpowiedzi dla ecommerce

Próbujemy pracować w 2-tygodniowych sprintach, ale ciągle coś nam przerywa rytm pracy. Od pomysłu do produkcji mija 3-4 sprinty przez problemy z testowaniem i długą procedurą wdrożeniową. Wdrażamy 1-2 razy w tygodniu, ale każde wdrożenie to stres.

CI/CD mamy tylko częściowo - testy uruchamiają się automatycznie, ale deployment wymaga manualnych kroków i często się wywala. Brak feature flags sprawia, że każda zmiana idzie od razu do wszystkich użytkowników. Retrospektywy robimy, ale zmiany wprowadzamy rzadko. Największym problemem są ciągłe przerywniki - "pilne" poprawki, które rujnują całe planowanie sprintów.

Zespołowy

Ten wymiar pomaga zrozumieć, jakie osoby tworzą zespół i jakie są ich kompetencje oraz potrzeby rozwojowe. Tutaj rozpoznajemy kompetencje, dynamikę zespołu i potrzeby rozwojowe.

Pytania

Kompetencje i doświadczenie

• Jakie są kluczowe kompetencje członków zespołu i gdzie są luki?

• Jak rozkładają się seniorzy vs juniorzy w zespole?

• Czy mamy single points of failure w wiedzy lub umiejętnościach?

• Jak dobrze zespół zna domenę biznesową, w której pracuje?

Dynamika zespołu

• Jak długo członkowie zespołu ze sobą współpracują?

• Jaka jest motywacja i zaangażowanie poszczególnych osób?

• Czy są konflikty interpersonalne lub różnice w podejściu do pracy?

• Jakie są indywidualne cele kariery i jak wpływają na pracę zespołu?

Spektrum

Przykład odpowiedzi dla ecommerce

Mamy doświadczony zespół - większość osób pracuje razem od 2 lat. Ja i senior backend developer świetnie znają domenę płatności, ale junior frontend developer dopiero uczy się biznesowych niuansów.

Zespół jest zmotywowany i autonomiczny - ludzie sami podejmują decyzje techniczne w swoich obszarach. Jedynym wyzwaniem jest różnica w tempie pracy między seniorem a juniorem, co czasem prowadzi do frustracji. Wszyscy chcą rozwijać się technicznie, QA rozważa przejście na automation testing.

Perspektywy innych osób

Boyd podkreślał wagę różnorodnych punktów widzenia w procesie obserwacji:

"We can't just look at our own personal experiences or use the same mental recipes over and over again"

O obserwacje dla wymiarów warto pytać inne osoby, by pokazywały swój punkt widzenia. Product Manager będzie inaczej postrzegał wymiar produktowy niż programista. Designer spojrzy na użytkowników z innej perspektywy niż QA Manager będzie miał inne obserwacje organizacyjne niż Tech Lead.

Kluczem jest zbieranie tych różnych perspektyw i konfrontowanie ich ze sobą. Tam gdzie widzisz stabilność, ktoś inny może dostrzec problemy. Tam gdzie ty widzisz wysoką jakość techniczną, Product Manager może widzieć powolne dostarczanie wartości.

Te różnice w postrzeganiu są cennym źródłem informacji - pokazują pełniejszy obraz rzeczywistości zespołu.

W kolejnym odcinku przeniesiemy nasze obserwacje na obszar Orient - naszego odniesienia się do zaobserwowanej sytuacji.

Jak zacząłem przedstawiać mój sposób myślenia, to zauważyłem, że bardzo mocno wzoruję się na pętli OODA. Ponieważ ten temat nie jest szeroko znany, postanowiliśmy to wspólnie opisać.

Całość nazwaliśmy Intencjonalny Lider. Cel takiego lidera to:

Świadome kształtowanie działań zespołu w oparciu o ewolucję otoczenia biznesowego i strategii firmy.

Najpierw jednak rozpoczniemy od samej pętli OODA.

Pętla OODA

Pętla OODA to koncepcja stworzona przez pułkownika Johna Boyda, amerykańskiego pilota myśliwskiego i stratega wojskowego. Boyd opracował ją analizując, dlaczego amerykańscy piloci wygrywali starcia powietrzne podczas wojny koreańskiej. Okazało się, że kluczem nie była przewaga techniczna, ale szybsze podejmowanie decyzji.

Dziś pętla OODA stosowana jest wszędzie - od zarządzania po sport. Wykorzystują ją firmy przy planowaniu strategii, trenerzy sportowi przy nauczaniu podejmowania decyzji, a nawet zespoły cybersecurity przy zarządzaniu zagrożeniami. Dlaczego? Bo w świecie, gdzie wszystko zmienia się błyskawicznie, wygrywa ten, kto szybciej się adaptuje - nie ten, kto ma najlepszy plan.

Z czego składa się pętla OODA?

Observe (Obserwuj)

Zbierasz dane o tym, co się dzieje w zespole. Kim są twoi ludzie? Jakie mają kompetencje? Jakie wyzwania stoją przed produktem? Jakich mamy interesariuszy? Skąd pochodzą cele?

Po co? Żeby zobaczyć rzeczywistość zespołu, a nie swoje wyobrażenia o nim.

Orient (Zorientuj się)

Analizujesz zebrane informacje przez pryzmat strategii firmy, kultury organizacji i celów produktu. Przypisujesz kompetencje zespołu do wyzwań biznesowych. To najtrudniejszy i najważniejszy krok.

Po co? Żeby zrozumieć, gdzie są luki i jakie masz opcje działania jako lider.

Decide (Zdecyduj)

Wybierasz konkretne działania - jakie inicjatywy uruchomić, jakie kompetencje rozwijać, które procesy zmienić. Nie czekasz na idealny moment - decydujesz teraz.

Po co? Żeby przejść od analizy do akcji. Lepsza jest dobra decyzja teraz niż idealna za tydzień.

Act (Działaj)

Wdrażasz decyzje w zespole. Przydzielasz zadania, rozpoczynasz szkolenia, zmieniasz procesy. Ale to nie koniec - działanie generuje nowe informacje o zespole, które znów obserwujesz. I koło się zamyka.

Po co? Żeby sprawdzić swoją hipotezę w rzeczywistości zespołu i zebrać informację zwrotną do kolejnej pętli.

Mając podstawy za sobą możemy przejść do motywu działania Intencjonalnego Lidera wraz z pętlą OODA.

Intencjonalny Lider w akcji

Intencjonalny Lider to sposób działania, który łączy pętlę OODA z realiami zarządzania zespołem produktowym.

Jak działa Intencjonalny Lider?

Observe:

1 - Analizujesz otoczenie biznesowe i definiujesz związane z nim wyzwania.
2 - Równolegle badasz środowisko techniczno-produktowe i identyfikujesz kolejne wyzwania.

Orient:
3 - Na tej podstawie określasz główne kompetencje potrzebne do zaadresowania tych wyzwań. To moment, gdy rzeczywistość spotyka się ze strategią.
4 - Mając te informacje, przypisujesz osoby w zespole do wyzwań i kompetencji. Określasz braki kompetencyjne. Widzisz, gdzie jesteś, a gdzie musisz być.

Decide:
5 - To stanowi podstawę do stworzenia planu, który adresuje główne wyzwania i braki. Plan, który łączy bieżące potrzeby z długoterminowym rozwojem.

Act:
6 - W miarę upływu czasu wdrażasz plan, weryfikując progres i efekty. Korygujesz na bieżąco. Uczysz się z każdego działania.
7 - Dodatkowo dopasujesz styl przywództwa do sytuacji i potrzeb zespołu.

Całość tworzy pętlę, którą powtarzasz, coraz lepiej dostosowując się do otoczenia biznesowego. Z każdym cyklem stajesz się skuteczniejszy.

Po co to wszystko?

Bo alternatywą jest reaktywne gaszenie pożarów. Lider, który tylko reaguje na kryzysy. Zespół, który nie wie, dokąd zmierza. Kompetencje, które nie nadążają za potrzebami rynku.

Intencjonalny Lider działa inaczej. Wyprzedzasz problemy. Rozwijasz zespół zanim zabraknie kompetencji. Dostosujesz się do zmian zanim staną się kryzysem.

W kolejnych artykułach omówimy szczegółowo każdy element tej pętli. Pokażemy konkretne narzędzia i techniki. Ale już teraz możesz zacząć - wybierz jeden obszar i przejdź przez całą pętlę. Zobaczysz różnicę.

• Mierzenie

• Nauka

• Praca wielozespołowa

Dziś czas na rozwiązania. Jak sobie radzić z tymi ograniczeniami?

Measure

Rozpoczniemy od tego jakie praktyki są potrzebne, by mierzenie dostarczało wartość.

Monitoring jako Definition of Done

Zadanie nie jest skończone bez dodania monitoringu. To samo podejście jak z testami - nie deployujesz bez testów, nie deployujesz bez mierzenia.

GenAI wzmacnia potrzebę tej praktyki. Generuje kod szybko, ale nie doda automatycznie event trackingu, metryk biznesowych czy alertów. Musisz to zaplanować z góry - narzucić, dołączyć do instrukcji, sprawdzać czy faktycznie została zaimplementowana.

Znajomy sprzedał mi taką praktykę:

Zawsze jak dostarczam jakąś funkcję to tworzę dashboard, lub przynajmniej wykres, by pokazać czy to faktycznie zadziałało.

To jest mindset, jaki jest wymagany w czasach GenAI.

Efektywny pipeline danych

Techniki mapowania procesów, jak „Value Stream Mapping", można zastosować również do potoków danych.

Mapujesz ścieżkę od zdarzenia użytkownika do dashboard'u z metrykami. Ile czasu zajmuje każdy krok? Gdzie są kolejki i opóźnienia? Te wąskie gardła powinny być pierwszymi do optymalizacji.

Typowe wąskie gardła w pipeline'ie danych to:

• Przetwarzanie wsadowe raz dziennie zamiast w czasie rzeczywistym

• Manualne tworzenie raportów

• Brak automatyzacji w łączeniu danych z różnych źródeł

Optymalizacja tych miejsc skraca czas od eksperymentu do wyników.

Rozplątywanie zmian dla niezależnego mierzenia

Nie chodzi o wprowadzanie jednej zmiany na raz - to spowalnia dostarczanie. Chodzi o projektowanie zmian tak, by dały się niezależnie mierzyć.

GenAI dostarcza zestaw zmian. Twoja rola to rozplątanie ich na wymiary, które można osobno weryfikować. Nowa rekomendacja + lepszy checkout to dwa różne eksperymenty. Jeden wpływa na zaangażowanie, drugi na konwersję.

Praktyczne podejście to definiowanie:

• Właściwych podejść mierzenia dla każdej zmiany

• Różnych segmentów użytkowników do testowania

• Odpowiednich wymiarów dla wdrożenia

Dzięki temu możesz dostarczać szybko, ale weryfikować precyzyjnie.

Learn

Następnie przejdziemy do tego, jak skupić się na nauce, zamiast tylko dostarczać.

Metryki wpływu zamiast ilości

GenAI wzmacnia iluzję produktywności - dostarczasz 10x więcej, ale bezużytecznych funkcji.

Przestań mierzyć velocity i story pointy. Zacznij mierzyć wpływ na klientów. Na Sprint Review nie pokazuj "co zrobiliśmy", ale "czego się nauczyliśmy o klientach". Zmień pytanie:

• z "ile dostarczyliśmy"

• na "czy rozwiązaliśmy problem".

I następnie zacznij mierzyć jak dobrze ten problem rozwiązaliście.

Jak rozpoczynać od problemu? Opisuję to w „Tech Lead w Discovery". Bardzo dobry przykład ma również Dawid Szkiełka w swoim artykule Product Trio - grupa prowadząca zespół wspólnie definiuje problem PRZED napisaniem kodu.

Mając problem zdefiniowany możesz faktycznie mierzyć wpływ po wdrożeniu. Co nas przekierowuje do kolejnego punktu.

Czas na analizę i wnioski

Tak jak w artykule „Mierzenie zmian w produkcie" - wprowadź rytm oceny każdej zmiany. Bez tego nie wiesz co działa, a co marnuje czas.

Zablokuj czas na analizę wyników. Poniedziałek rano = zespół analizuje dane z tygodnia. Nie nowe zadania, nie kolejny sprint planning. Czysta analiza: co zadziałało, co nie, dlaczego. GenAI dostarcza eksperymenty szybciej niż możesz je zrozumieć - musisz nadążyć z analizą.

Każdy eksperyment przechodzi przez jasny proces:

• Hipoteza - co chcemy sprawdzić i dlaczego

• Eksperyment - jak to testujemy, dla kogo

• Wyniki - twarde dane, nie opinie

• Wnioski - co nam to mówi o problemie

• Następne kroki - rozwijamy, pivotujemy czy kasujemy

GenAI może pomóc w dokumentowaniu tego procesu. Ale wyciągnięcie wniosków to wciąż praca człowieka.

Autonomia eksperymentów

Daj zespołom autonomię decyzyjną w ramach ustalonych granic. Zamiast czekać miesiąc na decyzję CTO, zespół może sam zdecydować o pivotowaniu w ramach swojego obszaru. GenAI przyspiesza tempo - hierarchia musi nadążyć.

Jak wypracować autonomię jako lider techniczny czy PM:

• Ustal budżet eksperymentów - np. "możemy testować wszystko co zajmie mniej niż tydzień pracy"

• Zdefiniuj kryteria sukcesu z góry - "jeśli metryka X spadnie o 10%, kasujemy funkcję bez pytania szefa"

• Komunikuj decyzje, nie pytaj o pozwolenie - wysyłaj weekly update z podjętymi decyzjami zamiast czekać na approval

• Buduj zaufanie małymi krokami - zacznij od drobnych decyzji, pokazuj wyniki, zyskuj większą swobodę

• Oddziel wdrożenie od uruchomienia - "Szefie, kod jest już na produkcji ale wyłączony. Włączymy dla 0.1% użytkowników, jeśli coś pójdzie źle - wyłączamy jednym kliknięciem"

Roadmapa to hipoteza, nie zobowiązanie. Jeśli dane pokazują, że idziemy w złym kierunku - zmieniamy. GenAI pozwala testować więcej hipotez szybciej. Ale tylko jeśli organizacja potrafi szybko reagować na wyniki.

Praca wielozespołowa

Na koniec musimy pracować efektywnie jako organizacja, nie jako pojedynczy zespół.

Value-Stream Mapping całego dostarczania

Zmapuj całą ścieżkę od pomysłu do produkcji. Nie patrz tylko na swój zespół, ale na wszystkie zależności. Gdzie są kolejki między zespołami? Gdzie czekasz tygodniami na decyzje?

Praktyczne działania:

• Wizualizuj przepływ między zespołami - jedna tablica pokazująca gdzie utyka praca między obszarami

• Mierz rzeczywisty lead time - nie tylko czas kodowania, ale całkowity czas przejścia przez organizację

• Limituj pracę w toku na poziomie organizacji - jeśli 50 zadań czeka na security review, to przestań dodawać kolejne

• Synchronizuj kadencje - jeśli zespół A deployuje co tydzień, a zespół B co miesiąc, to A czeka 3 tygodnie na wdrożenie

GenAI przyspiesza pracę pojedynczego zespołu. Ale jeśli kolejny zespół w łańcuchu ma miesięczny backlog, to nic nie zyskujesz. Musisz optymalizować całość, nie fragmenty.

Globalna optymalizacja produktowa

Przestań mierzyć sukces pojedynczych zespołów:

• Zespół Recommendations zwiększył personalizację - pokazuje więcej trafnych produktów.

• Zespół Content zoptymalizował ładowanie - ukrywa obrazy produktów dla szybkości.

Klienci widzą świetne rekomendacje, ale bez zdjęć nie mogą podjąć decyzji. Globalnie tracisz.

Zamiast lokalnych optymalizacji, wprowadź wspólne metryki sukcesu dla całego obszaru produktu. Zespoły pracujące nad różnymi częściami ścieżki klienta muszą mieć ten sam North Star - czy to konwersja end-to-end, retencja, czy NPS.

Przykład:

• zamiast "zespół rekomendacji zwiększył CTR o 8%",

• mierz "użytkownicy wykonują o 5% więcej wartościowych akcji w produkcie".
  To wymusza myślenie o całej ścieżce użytkownika, nie tylko o swojej części.

Tutaj duży wpływ ma sama struktura organizacyjna - vide prawo Conway'a. Musimy tworzyć takie struktury, które wspierają i zachęcają do pracy ponadzespołowej. Ciekawie ten problem rozwiązał Pandadoc, co opisał w prezentacji Denis Salnikov.

GenAI może pomóc każdemu zespołowi osobno osiągnąć świetne wyniki. Ale jeśli te wyniki się wykluczają, to tylko marnujesz czas.

Strategia technologiczna organizacji

Wspólna strategia techniczna to fundament spójnych decyzji w organizacji. Jak pisałem w artykule "Strategia inżynierska zespołów produktowych", strategia pozwala skupić rozproszone wysiłki zespołów na wspólnym kierunku rozwoju. Bez niej każdy zespół podejmuje decyzje we własnym zakresie, często sprzeczne z innymi.

Jak wprowadzić porządek:

• Zdefiniuj drivery architektoniczne - jak w artykule "Drivery architektoniczne", określ kryteria wyboru technologii

• Technology radar organizacji - wspólna mapa co jest w adopt/trial/assess/hold

• Gildie technologiczne - frontend guild, backend guild dzielą się wiedzą i standaryzują podejścia

• Architekci jako facylitatorzy, nie strażnicy - pomagają zespołom podjąć dobre decyzje, nie blokują

Przykład driverów:

• "TypeScript everywhere - frontend, backend, infrastruktura" - jeden język, płynna rotacja ludzi

• "PostgreSQL jako domyślna baza, wyjątki tylko z biznesowym uzasadnieniem" - łatwiejsze utrzymanie

• "React dla UI, nie eksperymentujemy z frameworkami" - standaryzacja kompetencji

GenAI może generować kod w 50 technologiach. Ale utrzymanie tego wszystkiego to koszmar. Wspólna strategia pozwala wykorzystać GenAI bez tworzenia chaosu.

Jednocześnie, jak mówi Teoria Ograniczeń, zawsze istnieje wąskie gardło. GenAI usuwa problem z dostarczaniem produktów, ale nie z wpływem produktów na klientów i biznes.

Załóżmy, że dostarczanie pojedynczej funkcji skraca się nam do 0. Że mamy pomysł, odpalamy RUN i jest live na produkcji - przetestowany i z właściwą jakością. Co zostanie wąskim gardłem?

Widzę 3 potencjalne miejsca - dwa związane z pętlą Build-Measure-Learn i jedno związane z pracą wielozespołową. W artykule miały być też rozwiązania, ale ostatecznie wyszedłby z tego zbyt długi artykuł 😃

Measure

Measure to faza, w której sprawdzasz czy wprowadzone zmiany działają zgodnie z oczekiwaniami.

GenAI przyspiesza dostarczanie funkcji, ale mierzenie zachowań klientów dalej wymaga czasu i odpowiednich praktyk.

Delivery nieprzystosowane do mierzenia

Zespoły dostarczają funkcje bez planowania ich pomiaru. Data pipeline nie istnieje. Monitoring dopiero planowany. Wszystko skupia się na dostarczaniu.

GenAI nie dostarczy Ci danych od klientów - musisz je zebrać sam. Trzeba określić jakie metryki śledzić, jakie procesy mierzyć, z jaką częstotliwością i w jakim zakresie dat.

Rezultat? Garbage in, garbage out - bez mierzenia klientów jedyne co masz to wdrożenie. GenAI wygeneruje kod, ale nie zastąpi analityki produktowej.

Wolne przetwarzanie danych

Eksperymenty robisz szybko, ale wyniki otrzymujesz wolno. GenAI dostarcza funkcję w godzinę. Analiza zajmuje tydzień. Problem leży w infrastrukturze danych.

ETL działa raz dziennie w nocy. Raporty generują się manualnie. Dashboard ładuje się 20 minut. Dane z wczoraj dostajesz jutro. GenAI przyspiesza tworzenie kodu, ale nie poprawi wydajności baz danych.

Tworzy się kolejka eksperymentów czekających na wyniki:

• Funkcja A wdrożona w poniedziałek - dane w piątek

• Funkcja B wdrożona we wtorek - dane w następny poniedziałek

• Funkcja C wdrożona w środę - dane za 10 dni

Kiedy w końcu otrzymujesz informacje, zespół już pracuje nad czymś innym. Decyzje podejmowane są na podstawie przestarzałych danych.

Brak atomowych eksperymentów

Masz przed sobą plan na 10 funkcji - co robisz?

• Odpalasz 10 agentów AI

• Każdy z nich dostarcza funkcję

• Wszystkie zostają wdrożone jednocześnie

• Na końcu metryki się poprawiają

Tylko która funkcja za to odpowiada? Trudno powiedzieć...

To klasyczny problem opisany w moim artykule „Mierzenie zmian w produkcie". Zespoły dostarczają kilka funkcji naraz. Potem widzą poprawę wskaźników. Ale nie wiedzą, która zmiana za to odpowiada.

Z GenAI będzie analogicznie, tylko bardziej 😅

Learn

Learn to faza, w której wyciągasz wnioski z zebranych danych i podejmujesz decyzje o dalszych krokach. GenAI sprawia, że zespoły dostarczają więcej eksperymentów, ale organizacyjne uczenie się z ich rezultatów nie przyspiesza automatycznie.

Skupienie na dostarczaniu zabija uczenie się

Zespół mierzy się velocity i story points. Nie ma czasu na analizę wyników. GenAI przyspiesza delivery, ale nikt nie sprawdza, czy to co dostarczamy ma sens.

Metryki zespołu koncentrują się na ilości dostarczonych funkcji. Nie na ich wpływie na klientów. Sprint Review pokazuje co zostało zrobione. Nie czy to przyniosło wartość.

GenAI wzmacnia ten problem. Zespoły dostarczają jeszcze więcej funkcji w tym samym czasie. Wszyscy ogłaszają sukces, tylko że sukcesu brak.

Brak czasu na przeprocesowanie wyników

Masz wyniki eksperymentu. Wiesz, że funkcja A działa, funkcja B nie. Co dalej? Potrzebujesz czasu na zrozumienie dlaczego tak się stało.

Przeprocesowanie to proces głębszego zrozumienia wyników. Nie wystarczy wiedzieć "co". Trzeba zrozumieć "dlaczego". To wymaga dyskusji zespołowej, analizy danych, testowania hipotez.

GenAI dostarcza kolejne funkcje zanim zespół zrozumiał poprzednie:

• Poniedziałek: wyniki eksperymentu A

• Wtorek: nowy eksperyment B na produkcji

• Środa: nowy eksperyment C na produkcji

• Czwartek: wyniki eksperymentu B

Kiedy masz czas na przemyślenie wyników? Na wyciągnięcie wniosków? Na zastanowienie się nad przyszłymi eksperimentami?

Hierarchia spowalnia uczenie się

CTO potrzebuje miesiąc na zrozumienie, że kierunek jest zły. Zespół czeka. GenAI dostarcza błędne rozwiązania coraz szybciej.

Decyzje o kierunku produktu przechodzą przez hierarchię. Każdy poziom potrzebuje czasu na zrozumienie danych. W międzyczasie zespół pracuje dalej w błędnym kierunku.

Często interesariusze pracują na roadmapie, do której się zobowiązali. Wyniki eksperymentów pokazują dziury w naszym planie, sugerując zmianę kierunku. Ale trzeba dalej realizować to co zaplanowane. Bo przecież "się umówiliśmy".

Klasyczna sytuacja: zespół dostarcza 5 funkcji w tygodniu dzięki GenAI. Dyrektor produktu analizuje wyniki co miesiąc. Przez 3 tygodnie zespół rozwija funkcje, które nie działają. Marnotrawstwo rośnie wykładniczo.

Praca wielozespołowa

Praca wielozespołowa to obszar, gdzie GenAI ma wątpliwy wpływ na przyspieszenie. Może wygenerować kod dla jednego zespołu, ale nie rozwiąże problemów między zespołami. Tu leżą najgłębsze ograniczenia organizacyjny.

Lead time end-to-end

Deployment zespołu trwa 5 minut. Zmiana przez organizację przechodzi 2 miesiące. GenAI nie pomoże z wewnętrznymi procedurami i procesami.

Zespół może dostarczyć funkcję w godzinę dzięki GenAI. Ale żeby wdrożyć ją na produkcję, potrzebuje approval od bezpieczeństwa, architektów, product managerów z innych zespołów. Każdy etap to tydzień czekania.

Przykładowa ścieżka zmiany:

• Zespół A tworzy funkcję - 1 dzień z GenAI

• Approval od zespołu bezpieczeństwa - 1 tydzień

• Koordynacja z zespołem B (API) - 2 tygodnie

• Approval od architektów - 1 tydzień

• Wdrożenie przez ops - 3 dni

GenAI skrócił developement z tygodnia do dnia. Ale całość dalej trwa miesiąc.

Optymalizacja lokalna zamiast globalnej

Każdy zespół ma swój backlog, swoje metryki, swoje cele. Product Manager A walczy z Product Managerem B o priorytety. Zespół frontend ma inne cele niż backend. Optymalizujemy lokalnie, psując globalnie.

GenAI wzmacnia ten problem. Każdy zespół dostarcza więcej funkcji. Ale nie koordynują się między sobą. Rezultat?

• Zespół A optymalizuje swoją część - metryki rosną

• Zespół B niezależnie optymalizuje swoją część - jego metryki też rosną

• Globalne metryki spadają - systemy ze sobą nie współgrają

Każdy zespół lokalnie wygrywa. Organizacja przegrywa.

Chaos w decyzjach technologicznych

Zespół A wybiera MongoDB, zespół B PostgreSQL, zespół C Redis jako główną bazę. Każdy ma swoje powody. Nikt nie patrzy na całość. Zwiększamy dopasowanie zespołów do problemu, ale w organizacji rośnie technologiczny chaos.

Problem nasila się z GenAI:

• Zespoły eksperymentują szybciej z nowymi technologiami.

• GenAI samo rekomenduje kolejne serwisy do wykorzystania.

• Łatwiej stworzyć proof of concept w nowym frameworku.

GenAI może wygenerować rozwiązanie w każdej możliwej technologii. Ale kto będzie to wszystko utrzymywał?

Organizacja kończy z technologicznym zoo. Każda zmiana wymaga innej ekspertyzy. Rotacja w zespołach staje się koszmarem.

Pytanie na koniec

Które wąskie gardło wydaje Ci się najbardziej prawdopodobne? Masz może na myśli inne miejsce?

Te przepisy będą się różnić w zależności od liczby osób, zespołów, domeny biznesowej, ograniczeń firmowych, a przede wszystkim wielkości projektu. Ale żeby uciec od "to zależy", załóżmy, że mamy projekt na kilka tygodni, z jednym zespołem liczącym 5 developerów.

Jednak rozpoczniemy od czegoś bardziej bazowego - czym jest Delivery.

Czym jest Delivery

Warto tutaj zacytować autorów książki "Continuous Delivery" Jez Humble i David Farley:

Done means "released". This implies ownership of a project right up until it's in the hands of the user and working properly. There's none of this "I've checked in my code, so it's done as far as I'm concerned".

Done nie znaczy "napisane". Done znaczy "wydane".

Delivery to cały proces od ukształtowanego pomysłu do działającego rozwiązania na produkcji. To oznacza wszystkie działania:

• od rozpoczęcia pracy nad wstępnym pomysłem rozwiązania,

• do pozytywnego uruchomienia rozwiązania dla klienta na środowisku produkcyjnym.

Mówiąc wprost - zadanie jest skończone dopiero wtedy, gdy klient może z niego korzystać.

I tutaj pewna uwaga: poniższy opis wydaje się mieć dużo kroków. I będziesz miał rację - tak się wydaje 😃

Jest tak dlatego, ponieważ:

• NIE optymalizujemy kodowania,

• optymalizujemy czas do uruchomienia na produkcji,

a to są 2 różne podejścia optymalizacji.

Z racji, że Discovery zwykle poprzedza Delivery, warto powiedzieć dwa słowa, jak wykonać taką tranzycję.

Discovery vs Delivery

Na wejściu zakładamy, że tematy zostały przeanalizowane architektonicznie - mamy rozpisane drivery architektoniczne, zaplanowaną strukturę systemu, wybrane rozwiązania. W końcu Discovery to także temat techniczny, o czym pisałem w artykule "Jaka jest rola Tech Leada w Discovery?".

Jeśli poprawnie pracowaliśmy z Product Trio w Discovery, to mamy ustalone główne ryzyka produktowe.

Z perspektywy technicznej interesują nas przede wszystkim dwa rodzaje ryzyka:

• Ryzyko dostarczalności - wątpliwości, czy rozwiązanie może działać w założonej strukturze i serwisach.

• Ryzyko biznesowej spójności - czy będziemy w stanie na tym zarobić i czy koszty (budowy + operacyjne) nie będą za wysokie. Szczególnie przy rozwiązaniach z LLM-ami czy heavy computingiem koszty operacyjne mogą zabić cały biznes.

W zależności od skali ryzyka:

• albo wciągamy te zadania w część delivery, planując je na początek,

• albo wycofujemy się i wracamy do discovery, aby przeprowadzić bardziej bezpieczne i mniej angażujące zespół testy.

Nie trzeba być całkiem bezpiecznym i wszystkie ryzyka ogarniać w discovery. Czasem lepiej wziąć ryzyko na klatę i sprawdzić je w trakcie delivery.

Jak to mamy za sobą, możemy przejść do planowania naszej roboty.

Planowanie dostarczania

Aby dostarczanie było efektywne, należy je zaplanować - podzielić na części, które można szybko wdrażać i weryfikować.

Slicing - dziel i rządź

Pierwszym krokiem planowania dostarczania jest podzielenie zadania na atomowe wdrożenia. Cel to szybkie dostarczenie wartości lub przetestowanie, czy rozwiązanie działa.

Vertical slices

Dla większego rozwiązania staraj się dostarczać je za pomocą pionowych części - vertical slices. Chcemy upewnić się, że rozwiązania będą dostarczane w formule end-to-end. Każdy slice powinien przechodzić przez wszystkie warstwy systemu - od interfejsu użytkownika, przez logikę biznesową, aż po bazę danych i zewnętrzne systemy.

Tutaj polecam wykorzystać metaforę hamburgera od Gojko Adzica i ją wdrożyć np. stosując Event Modeling od Adama Dymitruka.

Więcej o technikach podziału pisałem w artykule "✂ 5 technik podziału funkcjonalności na mniejsze".

Podział techniczny

Kiedy mamy za sobą podział na pionowe części, możemy zacząć dzielić poziomo po kwestiach technicznych. Co można robić równolegle:

• Pisać frontend i backend.

• Pisać API, logikę biznesową i strukturę bazy.

• Tworzyć testy na podstawie struktury API.

• Konfigurować obserwowalność i metryki.

Dla danego wertykału powinno się dać utworzyć podział tak, aby naraz pracowały nad nim 2-3 osoby. To daje nam możliwość prawdziwego zespołowego dostarczania.

Strategia zapewniania jakości dla każdego slice

Dla każdego kawałka warto określić strategię zapewniania jakości. To znaczy zaplanować, jak sprawdzisz, czy rozwiązanie działa poprawnie, zanim trafi do klienta.

Shift left testów

Zadaniem jest przeniesienie odpowiedzialności za jakość na początek procesu - czyli Shift Left Testing. Zamiast sprawdzać jakość na końcu, wbudowujesz ją od samego początku. Określ przypadki testowe i podziel je na mniejsze części wdrożeniowe. Im szybciej wykonasz tego rodzaju pracę, tym większa szansa, że wdrożenie będzie dobre jakościowo.

Wykorzystaj Behavior-Driven Development - projektowanie w oparciu o scenariusze użycia, jakie użytkownik oczekuje podczas interakcji z aplikacją. Testy powinny potwierdzać faktyczne sytuacje, a nie widzimisie developera.

W czasach AI scenariusze użycia świetnie współtworzą praktykę AI-Driven TDD . Testy automatyczne przyśpieszają pracę, zamiast ją opóźniać.

Strategia testów i dobór właściwej metody

Jak mówił Jacek Milewski na prezentacji "Testing Code is Simple - Strategy is to write units and integration"

It's not that every system, every component in my system is the same – they are much different.

Jeśli masz systemy zewnętrzne, to testy jednostkowe nic nie dają. Chcesz zrobić testy integracyjne, kontraktowe, lub jeśli nie można, to stawiać na obserwowalność. Dla kodu bez zależności zewnętrznych - testy jednostkowe. Dla integracji z API, bazami danych, kolejkami - testy integracyjne.

Jeśli nie możesz testować automatycznie (np. legacy systemy, wolne API), postaw na monitoring i obserwowalność na produkcji. O tym pisałem w artykule "Zapewniaj jakość dzięki obserwowalności".

Plan wdrożenia dla każdego slice

Dla każdego kawałka musisz zaplanować, jak bezpiecznie dostanie się na produkcję. To nie tylko kwestia wciśnięcia guzika "deploy".

Stopniowe wdrażanie

Istotne jest oddzielenie wdrożenia od uruchomienia. Jak pisałem w artykule "Szybko czy dobrze? Poproszę oba", można oddzielić wdrożenie od uruchomienia. Wdrożenie nie będzie równało się już wydaniu. Pozwala to unikać problemów z dużymi mergami, testować rozwiązanie o wiele szybciej, wdrażać nawet jeśli brakuje pewnych informacji.

Praktyk stopniowego wdrażania jest wiele.

• Feature Toggles / Feature Flags pozwalają przetestować zmianę, flagując daną funkcję. Sprawdzasz w małej skali, jak się zachowuje i poprawiasz już przy kolejnych wdrożeniach.

• Dark Launching - wdrażana funkcja jest uruchamiana, ale jej wyniki są ignorowane.

• Canary Release - zaczynasz od uruchomienia funkcji dla małej grupy użytkowników i dalej otwierasz, gdy potwierdzisz, że działa odpowiednio.

Dla danego slice warto dodać 1 zdanie o tym, jaką strategię wdrożeniową wybieramy.

Monitoring - co obserwować po wdrożeniu

Musisz wiedzieć, co monitorować po wdrożeniu i kto reaguje na problemy. Wykorzystane zasoby infrastrukturalne, występujące błędy, dłużej trwające procesy, stopień odrzuceń procesów, wybrane wskaźniki biznesowe.

Na tym etapie trzeba zadać sobie pytania:

• Jakie sygnały chcę obserwować z mojego produktu?

• Jakie logowanie muszę wdrożyć, aby takie sygnały dostać?

• Gdzie i kiedy będę je obserwować?

No dobra, tyle planowania, czas wziąć się za robotę 💪

Efektywne dostarczanie

Mając plan, możemy przejść do efektywnego wykonania. Tutaj liczy się współpraca zespołu i płynność pracy.

Koordynacja i kolejność prac

Zwykle potrzebujesz koordynatora z zespołu, który zadba o spinanie prac razem. Nie jest to rocket science, ale ktoś musi pilnować całości.

Kluczowe jest zrównoleglenie pracy nad zadaniem. Zamiast sekwencyjnego podejścia "najpierw backend, potem frontend, na końcu testy", wykorzystujesz podział z etapu planowania i pracujecie nad jednym tematem jednocześnie.

Wypracowujemy optymalną kolejność zadań:

• Nad danym slice staramy się zrównoleglić pracę jak tylko się da - jedna para/trójka robi backend, druga frontend, trzecia testy tego samego kawałka

• Jeśli się nie da, to bierzesz kolejne slice'y - różne pary pracują nad różnymi kawałkami funkcjonalności równolegle

• Bloker w jednym slice - ludzie migrują i pomagają w innych, zamiast siedzieć z założonymi rękami, starając się pomóc sobie nawet jako gumowa kaczuszka

Oficer łącznikowy

Jeśli zadanie wychodzi poza zespół i wymaga współpracy innego zespołu np. prawnego, wyznacz jedną osobę do koordynacji tej współpracy. Taki oficer łącznikowy koordynuje współpracą między ośrodkami pracy i pilnuje, żeby zewnętrzne zależności nie zablokowały zespołu.

To wzorzec z rzeczywistości - w wojsku, dyplomacji i korporacjach oficerowie łącznikowi od lat zapewniają płynną komunikację między jednostkami organizacyjnymi.

CI/CD - małe commity i szybka integracja

Continuous Integration i Continuous Delivery to fundament efektywnego dostarczania.

Szybka integracja i wdrażanie

Celem jest szybki feedback po napisaniu fragmentu rozwiązania. Wykrycie błędu powinno nastąpić praktycznie w tym samym momencie, w którym się pojawił. Wszystkie commity przechodzą przez ten sam proces sprawdzania jakości. Commitujesz małymi kawałkami, każdy commit jest automatycznie testowany i wdrażany.

Najważniejsze praktyki z artykułu "Automatyzacja wdrożeń i zapewniania jakości":

• Identyczny proces budowania lokalnie i zdalnie - dzięki powtarzalności masz mniej rozbieżności "u mnie działa, a na serwerze nie"

• Promowanie tej samej paczki - na kolejne środowisko trafia ta sama paczka, z różnicą jedynie w konfiguracji

• Dbanie o prędkość automatyzacji - pipeline musi działać szybko, każde stracone 15 minut to godziny straty w miesiącu

• Stop the line - jeśli proces wykryje błąd, jego naprawa staje się priorytetem

PR Review utrudnia efektywny proces

Istnieje coraz więcej dowodów, że Pull Request Review spowalnia zespół i tworzy niepotrzebne wąskie gardła. Jak opisywałem w serii artykułów "PR Review - problemy i rozwiązania", większość PR Review jest błędogenna, powolna i tworzy relacje ping-pong.

Zamiast tego przyjmij Trunk-based development - pracę bezpośrednio na głównej gałęzi kodu. Ten mechanizm pozwala drastycznie skrócić pętlę pomiędzy zmianą a wdrożeniem. Wykorzystuj Continuous Code Review - pair programming, automatyczne testy i review po wdrożeniu - Mob PR Review.

Stop starting, start finishing

Kluczowa filozofia efektywnego zespołu to kończenie rzeczy zamiast rozpoczynania nowych.

Praca od końca tablicy

W ramach spotkań synchronizujących pytaj od końca tablicy - co możemy dzisiaj zrobić, aby domknąć dane zadanie. Zamiast tradycyjnego podejścia "co robiłem wczoraj, co robię dziś", skupiaj się na "co możemy wspólnie zrobić, żeby to zadanie było DONE".

Każdy członek zespołu powinien zadać sobie pytanie: jak mogę pomóc, aby jak najszybciej ten temat domknąć?

Wspólne programowanie i wzajemna pomoc

Jeśli skończyłeś zadanie i weszło na produkcję, w teorii mógłbyś brać coś nowego. Ale widzisz, że kolega ma zadanie w developmencie. Zaproponuj pomoc.

Możliwości jest wiele:

• wspólne programowanie,

• przetestowanie czegoś,

• przygotowanie danych testowych,

• pomoc jako gumowa kaczuszka w debugowaniu.

Można tutaj wymyślić masę tematów, które faktycznie pozwolą pomóc.

Migracja osób między ośrodkami pracy

W przypadku wąskiego gardła zwykle możesz wydzielić zadania na tyle nieskomplikowane, że spokojnie można je oddelegować. Być może pomóc będzie w stanie nawet osoba, która nie jest ekspertem w danym obszarze.

Dzięki podejściu międzyobszarowemu do pracy rośnie zrozumienie zespołu nad tematami crossfunkcyjnymi. To ostatecznie pozwala łatwiej współpracować i ograniczać pracę zawieszoną w toku.

Feedback z rzeczywistości

Wracamy do fundamentalnej definicji z początku artykułu - "Done means released". Zadanie jest skończone dopiero wtedy, gdy działa na produkcji i użytkownik może z niego korzystać. Nawet za feature flagą, ale przetestowane i działające.

Definition of Done - potwierdzenie spełnienia kryteriów

Definition of Done powinien być zdefiniowany wcześniej, na etapie planowania każdego slice'a. Tutaj potwierdzasz, że wszystko jest spełnione - kod na produkcji, testy przechodzą, monitoring działa, alerty skonfigurowane, dokumentacja aktualna.

Sprawdzasz listę i upewniasz się, że nic nie zostało pominięte.

Szybki feedback z produkcji

Skupiaj się na jak najszybszym otrzymaniu feedbacku z rzeczywistości - sprawdzeniu, jak rozwiązanie zachowuje się na produkcji z prawdziwymi danymi, prawdziwym ruchem, prawdziwą infrastrukturą.

Nie musi to być od razu z faktycznymi klientami - może być za feature flagą widoczną tylko dla zespołu. Ale już na prawdziwym środowisku, z prawdziwymi warunkami.

Wdrożenie to początek, nie koniec

Jak pisałem w artykule "Wdrożenie ≠ koniec pracy", po wdrożeniu pozostaje jeszcze kilka rzeczy do zrobienia. Monitorowanie, czy aplikacja się odpowiednio zachowuje, dokonfigurowanie, sprzątanie feature flag, dokumentacja. Jeśli po wdrożeniu przesuwasz zadanie na DONE i zapominasz o nim, to elementy pracy uciekają bokiem.

A to się mści.

Prawdziwe delivery kończy się dopiero wtedy, gdy otrzymasz feedback z rzeczywistości i potwierdzisz, że rozwiązanie faktycznie działa w produkcyjnych warunkach.

"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:

1. Jasno zdefiniować cel biznesowy.

2. Zidentyfikować kluczowych aktorów (kto może pomóc osiągnąć cel?).

3. Określić wpływ (jak aktorzy mogą pomóc w osiągnięciu celu?).

4. 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:

1. Dopasowujesz poziom inwestycji do etapu rozwoju produktu.

2. Komunikujesz jasno ograniczenia i konsekwencje biznesowe każdego etapu.

3. 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:

1. Stawianie hipotez biznesowych - tworzenie sprawdzalnych założeń dotyczących produktu.

2. Implementacja pomiarów - dodanie odpowiednich mechanizmów śledzenia.

3. 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:

1. Mapowanie problemów technicznych na wpływ biznesowy - konkretne liczby i wartości.

2. Dostosowanie przekazu do różnych interesariuszy - każdy interesariusz ma inne priorytety.

3. 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:

• Cele, możliwości i rozwiązania.

• Wahadło Proof of Concept.

• Mierzenie zmian w produkcie

• Dług w produkcie — jak uzasadnić jego spłatę?.

GenAI pomaga bardzo mocno przy dostarczaniu rozwiązań. Jednak, jak zauważa Marty Cagan w wizji dla zespołów produktowych, choć AI zautomatyzuje procesy delivery, to etap discovery wciąż pozostanie domeną człowieka.

A więc jak GenAI może wspomóc siebie w pracy z klientami i biznesem? Najpierw odpowiedzmy sobie jak nie powinna Ciebie wesprzeć 😉

Dlaczego AI nie zastąpi zadawania pytań

Pavel Samsonov, lider świata UX, w swoim artykule "No, AI user research is not 'better than nothing'—it's much worse" stawia sprawę jasno:

Compared with the incredible value of things customers have actually said, things that sound like customers might say them are worthless.

Jako lider techniczny potrzebujesz prawdziwych odpowiedzi, nie wygenerowanych przypuszczeń, które tylko brzmią wiarygodnie.

"Syntetyczne odpowiedzi" prowadzą wprost do generycznych, ustandaryzowanych produktów:

• Wszystkie zespoły korzystają z tych samych modeli AI.

• Otrzymują podobne sugestie i wnioski.

• Produkty stają się nieodróżnialne od konkurencji.

Pavel kończy artykuł z:

The LLM can't buy your product. *

Modele językowe nie są prawdziwymi klientami i nie kupią twojego produktu. Więc nie odpowiadaj za kogoś - zamiast pytać AI "jakie są potrzeby klientów w branży X?", lepiej zapytaj bezpośrednio faktycznych użytkowników.

Choć AI nie udzieli Ci wiarygodnych odpowiedzi za Twoich klientów, może zrobić coś bardzo wartościowego - pomóc Ci przygotować lepsze pytania do nich.

* (wiem, że istnieją już np. tablice pracy dla Agentów, ale to raczej wyjątek od reguły)

LLM jako propozycja pytań

Zamiast pytać LLM o odpowiedzi, poproś o przygotowanie pytań, którymi wesprzesz się w dyskusji z biznesem i klientami.

Technika "poszerzania horyzontu" pozwala znaleźć pytania, których sami byśmy nie zadali. AI nie ma naszych ograniczeń poznawczych i ślepych punktów - może zaproponować pytania z obszarów, które moglibyśmy pominąć lub uważać za oczywiste.

Najbardziej skuteczne jest strukturyzowanie pytań według znanych ram. Techniki takie jak Impact Mapping czy Opportunity Solution Tree świetnie sprawdzają się jako struktury, które wspomogą nas w wymyślaniu pytań

Z takimi ramami GenAI może pomóc nam:

• Weryfikować kompletność struktury - "Czy o czymś zapomnieliśmy w obszarze 'KTO'?"

• Znajdować luki w rozumowaniu - "Jakie połączenia między 'JAK' a 'CO' wydają się niepełne?"

• Kwestionować nasze założenia - "Czy nasz cel biznesowy faktycznie adresuje problem klienta?"

Warto wykorzystać LLM do eksplorowania struktur, które zwiększają naszą zdolność do zadawania właściwych pytań, zamiast szukania gotowych odpowiedzi.

Przykład dla domeny rowerowej

Wykorzystamy jako przykład domenę biznesową Wypożyczalni Rowerów z poprzedniego artykułu.

LLM może nam pomóc wygenerować pytania, jeśli wskażemy mu strukturę IM i OST:

Pytania do biznesu

DLACZEGO (cel biznesowy):

• "Czy bardziej zależy Wam na zwiększeniu liczby nowych klientów czy utrzymaniu stałych użytkowników?"

• "Co jest ważniejsze: zwiększenie ogólnej liczby wypożyczeń czy wydłużenie czasu pojedynczego wypożyczenia?"

• "Które stacje generują najmniej wypożyczeń i dlaczego?"

• "Jak duży problem stanowią dla Was uszkodzone rowery i ile to kosztuje rocznie?"

KTO (aktorzy, interesariusze):

• "Czy więcej mamy klientów indywidualnych czy firmowych?"

• "Jakie typy rowerów cieszą się największą popularnością wśród różnych grup klientów?"

• "Które grupy klientów najczęściej zwracają rowery do innych stacji niż te, z których je wypożyczyli?"

• "Jak wygląda współpraca z serwisantami rowerów - co działa, a co wymaga usprawnienia?"

JAK (zmiany zachowania):

• "Jak często klienci rezygnują z wypożyczenia, gdy nie znajdują odpowiedniego roweru na stacji?"

• "W jaki sposób klienci najczęściej wybierają konkretną stację do wypożyczenia roweru?"

• "Jak często zdarza się, że klienci chcą zwrócić rower, ale stacja jest pełna?"

• "Jak wielu klientów zgłasza problemy z rowerami po ich wypożyczeniu?"

Pytania do klientów

Ukierunkowane na konkretne doświadczenia:

• "Opowiedz mi o ostatnim razie, gdy wypożyczyłeś/aś rower z naszej stacji. Co dokładnie się wydarzyło?"

• "Przypomnij sobie sytuację, gdy chciałeś/aś zwrócić rower, ale stacja była pełna. Co wtedy zrobiłeś/aś?"

• "Czy możesz mi opowiedzieć o konkretnym przypadku, gdy miałeś/aś problem z aplikacją do wypożyczania?"

Eksplorujące kontekst:

• "Jak znalazłeś/aś się w sytuacji, gdy potrzebowałeś/aś roweru tego dnia?"

• "Co robiłeś/aś bezpośrednio przed i po wypożyczeniu roweru podczas ostatniej przejażdżki?"

• "W jakich okolicznościach zdecydowałeś/aś się po raz pierwszy skorzystać z naszej wypożyczalni?"

Pogłębiające historię:

• "Co dokładnie zrobiłeś/aś, gdy zobaczyłeś/aś, że hamulce w rowerze nie działają prawidłowo?"

• "Jak zareagowałeś/aś, gdy aplikacja pokazała błąd podczas płatności?"

• "Opowiedz mi więcej o tym, jak znalazłeś/aś alternatywną stację, gdy ta przy dworcu była pusta?"

Podczas wywiadu z klientami należy unikać pytań, które:

• Dotyczą hipotetycznych sytuacji ("Co byś zrobił, gdyby...")

• Skupiają się na ogólnych preferencjach ("Co zazwyczaj robisz...")

• Proszą o wróżenie przyszłości ("Czy korzystałbyś/abyś z...")

Każda z odpowiedzi ułatwi Ci następnie dopasować rozwiązanie do faktycznych potrzeb.

Jednak te pytania trzeba zadać, a następnie zebrać odpowiedzi. Jak sobie ułatwić ten proces nowymi technologiami?

Transkrypcja rozmów

Notatki robić warto. Jednak nie wszystko wyłapiesz podczas rozmowy z klientem czy biznesem. Skupiając się na zadawaniu pytań i budowaniu relacji, często umkną ci szczegóły wypowiedzi.

Aplikacje które automatycznie łączą się do spotkania i robią notatki rozwiązują ten problem. Serwisy jak otter.ai czy fireflies.ai integrują się z popularnymi platformami do spotkań online i tworzą szczegółowe transkrypcje.

Nie zawsze jest to spotkanie online - spotkanie może odbywać się na miejscu. Wtedy zrobisz to za pomocą aplikacji do samej transkrypcji jak transkriptor.com czy transcribe.com, które pozwalają przetwarzać pliki audio na tekst.

Ja osobiście korzystam z Azure AI Speech, które jest dość surowe, ale jest tanie 😅 Posiada API do automatyzacji - w ten sposób możesz zintegrować transkrypcję z innymi narzędziami.

Synteza informacji

Przy mniejszej liczbie rozmów wyniki możesz przetworzyć samemu. Jednak posiadając dziesiątki czy setki, analiza przestaje być wykonalna w rozsądnym czasie.

Jeśli masz transkrypcje z rozmów lub wyniki ankiet, możesz wykorzystać GenAI do syntezy tych informacji - wyciągnięcia najistotniejszych wniosków i odkrycia ukrytych wzorców.

Co można zrobić?

Identyfikacja wzorców w wielu rozmowach

GenAI pomaga znaleźć powtarzające się tematy i problemy:

• "Przeanalizuj te transkrypcje i zidentyfikuj 5 najczęściej występujących problemów z dostępnością rowerów na stacjach"

• "Znajdź wspólne wzorce w opiniach klientów na temat procesu wypożyczania rowerów"

• "Porównaj problemy zgłaszane przez weekendowych i codziennych użytkowników systemu rowerowego"

Jak wspomniałem w artykule o bazie wiedzy, GenAI może analizować duże ilości tekstu znacznie szybciej niż człowiek, wyciągając z nich najważniejsze informacje.

Klasyfikacja i grupowanie opinii

Możesz poprosić model o pogrupowanie podobnych odpowiedzi i przypisanie im etykiet:

• "Pogrupuj te odpowiedzi na pytanie o problemy z aplikacją do wypożyczania rowerów według głównych kategorii"

• "Sklasyfikuj opinie klientów według tego, czy dotyczą stanu technicznego rowerów, rozmieszczenia stacji czy procesu płatności"

Wychwytywanie emocji i problemów

AI doskonale radzi sobie z analizą sentymentu, wyłapując nie tylko fakty, ale i emocje:

• "Zidentyfikuj wypowiedzi klientów, które wyrażają największą frustrację związaną z brakiem dostępnych rowerów"

• "Znajdź pozytywne opinie o naszym nowym systemie zwrotu rowerów do dowolnej stacji"

W newsletterze o mierzeniu zmian w produkcie pisałem o tym, jak ważne jest zbieranie informacji zwrotnej. GenAI może znacząco usprawnić analizę tej informacji.

Tworzenie profili użytkowników

Na podstawie zebranych danych możesz poprosić AI o stworzenie profili typowych użytkowników:

• "Utwórz 3-4 profile typowych klientów wypożyczalni rowerów w oparciu o ich potrzeby i nawyki"

• "Opisz typowego użytkownika wypożyczającego rowery w weekend i porównaj go z użytkownikiem dojeżdżającym do pracy"

Te profile mogą następnie wspomóc projektowanie rozwiązań dostosowanych do konkretnych grup odbiorców.

Identyfikacja ukrytych potrzeb w zebranych danych

Najbardziej wartościowe jest odkrywanie potrzeb, których klienci nawet nie wyrażają wprost:

• "Jakie nieoczywiste problemy z systemem rowerowym wynikają z tych transkrypcji?"

• "Zidentyfikuj ukryte możliwości biznesowe związane z wypożyczalnią rowerów na podstawie tych rozmów z klientami"

• "Jakie potrzeby użytkownicy rowerów miejskich wyrażają pośrednio, nie mówiąc o nich wprost?"

W swojej istocie GenAI to narzędzie do znajdowania wzorców - może więc dostrzec połączenia i trendy, które Tobie by umknęły.

Przykład syntezy z domeny rowerowej

Wracając do naszego przykładu wypożyczalni rowerów, tak mogłaby wyglądać synteza:

Przeanalizowałem 50 transkrypcji rozmów z klientami. Najczęściej powtarzające się problemy:

1. Brak dostępności rowerów na popularnych stacjach (73% rozmów)
   - Szczególnie dotkliwy w godzinach porannych (7-9)
   - Najczęściej wymieniane lokalizacje: Centrum, Dworzec, Hala Stulecia

2. Problemy z aplikacją mobilną (58% rozmów)
   - Długi czas ładowania (szczególnie mapa stacji)
   - Nieaktualne informacje o dostępności
   - Awarie podczas płatności

3. Stan techniczny rowerów (47% rozmów)
   - Szczególnie hamulce i przerzutki
   - Problem nasila się pod koniec tygodnia

Zidentyfikowano trzy główne profile użytkowników:
- Dojeżdżający do pracy (35%): wypożyczają codziennie rano i po południu, wrażliwi na czas
- Weekendowi rekreacyjni (40%): wypożyczają na dłużej, cenią komfort i stan techniczny
- Okazjonalni (25%): korzystają nieregularnie, największe problemy z aplikacją i procesem płatności

Ukryte potrzeby:
- Potrzeba przewidywalności - wielu użytkowników planuje dzień wokół dostępności rowerów
- Potrzeba statusu - część klientów chciałaby się wyróżniać (sugestie programu lojalnościowego)
- Potrzeba pomocy - wielu nowych użytkowników obawia się zadawać pytania personelowi

Mając takie informacje możesz podejmować lepsze decyzje techniczne.

Podsumowanie

Jak widzisz, narzędzia Gen AI można wykorzystać również w pracy z klientem i biznesem. Nie jest to “core” pracy lidera technicznego, jednak musimy tutaj poświęcać czas. Dlatego warto zadbać, by wyniki były wysokiej jakości.

Daj znać w komentarzu jak Tobie narzędzia Gen AI ułatwiają pracę w tym obszarze!

Jednocześnie znam kilku świetnych liderów technicznych w obszarze danych. A o tej roli niewiele się mówi. Pomyślalem więc, aby porozmawiać z moją znajomą Olą Mozdyniewicz o szczegółach tej roli.

Wyszła z tego bogata rozmowa, która daje szerokie spektrum informacji pracy lidera technicznego w obszarze Data.

Wstęp

Radek:

Możesz przedstawić swoją drogę kariery do roli lidera technicznego?

Ola:

Mam na imię Ola i rozpoczęłam swoją pracę na stażu w zespole data science. Później byłam analitykiem danych w dużym banku, potem pracowałam jako data analyst, a później data scientistem w firmie zajmującej się bettingiem oraz iGaming .

Moje ostatnie stanowisko to technical lead, które polegało na łączeniu wszystkich obszarów - wykształcanie techniczne zespołu, projektowanie workflow dla danych, żeby system, który implementujemy, działał.

Radek:

Co skłoniło cię, żeby pójść bardziej w ścieżkę lidera technicznego niż ścieżkę menadżerską?

Ola:

Rola, którą miałam, jeszcze nie istniała na rynku. W startupie była potrzeba na techniczną osobę, która skoordynuje cały proces od wylądowania danych na SFTP do pojawienia się w dashboardzie, żeby klient otrzymywał biznes value.

W obszarze Data i Data Science nie są jeszcze tak wykształcone pozycje Engineering Managera. Menedżerem zwykle zostaje osoba, która umie data science i jest komunikatywna. Tylko że ludzie, którzy zajmują się data science, często wolą robić modele niż użerać się ze stakeholderami.

Senior a Lider

Radek:

W jaki sposób rola lidera technicznego różni się od pozycji seniora? Co jest twoją nową odpowiedzialnością?

Ola:

Senior to pozycja, gdzie nie trzeba się opiekować młodszymi członkami zespołów, wystarczy robić wyniki i dobrze pisać kod. Natomiast na lidera zespołu trzeba mieć skile miękkie i być gotowym na więcej rozmów około technologicznych niż samego kodowania

Lider techniczny daje zadania tak, żeby wykształcić zespół. Prolem pojawia się, kiedy ktoś choruje albo jedzie na wakacje - potrzebna jest zastępowalność. Tech Lead skupia się nie tylko na swojej karierze, ale też na tym, żeby pomagać innym członkom zespołu w rozwoju, szczególnie tym mniej doświadczonym.

Radek:

Gdy patrzysz na współpracę z klientami i biznesem, co odróżnia podejście lidera technicznego od podejścia seniora?

Ola:

Lider musi patrzeć całościowo na cały obrazek. W mojej karierze zdarzyło się, że ludzie mówili "to nie jest nasza odpowiedzialność". Ale koniec końców, jeśli mamy odpowiedzialność za cały proces, to trzeba znaleźć rozwiązanie. To nie jest wymówka, żeby powiedzieć klientowi, że przesuwamy termin, bo nasz wewnętrzny zespół nie miał czasu.

Dodatkowo, jako lider techniczny zdecydowanie chodzi się na więcej spotkań z wyższą rangą ludźmi. Współpracujesz z headami działów, z Engineering menagerami, delivery i project managerami. Korzystasz z nich jako źródła wiedzy o produkcie. Trudność polega na tym, by wspierać inicjatywy bez wkraczania w obszary odpowiedzialności innych zespołów - balansowanie między proaktywnością a respektowaniem granic to kluczowa umiejętność.

Rola lidera technicznego wymaga znalezienia wszystkich możliwych opcji rozwiązania problemu. Zamiast mówić, że czegoś się nie da, lepiej jest zrozumieć, czego klient potrzebuje i dlaczego, i bazując na naszej wiedzy, zaproponować rozwiązanie.

Od czego rozpocząć

Radek:

Jak wybierałaś obszary, które wymagały twojej pierwszej uwagi?

Ola:

Wybierałam tematy bazując na rozmowie z moim menedżerem, jego KPI, oraz na kontrakcie dla klienta.

Przykładowo, przy ostatnim projekcie skoncentrowałam się na observability połączonym z PagerDuty. Było to ważne, ponieważ za złamanie SLA są kary kontraktowe. Jeśli nie wiedziałam od czego zacząć, to koncentrowałam się na tym, żeby nie tracić pieniędzy i żeby system był odporny - żebyśmy nie musieli wstawać w środku nocy, gdy coś się wysypie.

Radek:

Brzmi, jakbyś była orędownikiem jakości technicznej w procesie dostarczania.

Ola:

To dobre określenie. Zależało mi, żeby dane były dobrze zmapowane, żeby biznes klienta działał jak najlepiej, ale też żeby wszyscy wokół byli zadowoleni. Żebyśmy stosowali zaawansowane techniki, żeby ludziom w zespole się nie nudziło. Żeby klient nie wypisywał maili o problemach, żeby było jak najmniej alertów na produkcji.

Współpracując z klientem trzeba też umieć rozpoznać, kiedy nasze wewnętrzne pomysły są lepsze. Wtedy warto siąść z klientem, zrozumieć jego potrzeby i przetłumaczyć to na język techniczny, żeby na koniec wszyscy byli zadowoleni.

Umiejętności

Radek:

Jakie umiejętności interpersonalne są potrzebne liderom technicznym?

Ola:

Soft skile są bardzo ważne. Umiejętność zainteresowania się tematem, ponieważ liczy się wartość biznesowa. Trzeba umieć przewidywać problemy i adresować je z wyprzedzeniem.

Ważne jest też dbanie o zespół. Bycie seniorem to bycie doświadczonym i niezależnym. Rola lidera powinna to wszystko obejmować, plus umożliwianie rozwoju młodszym członkom zespołu. Tech lead zarządza całym procesem i większą liczbą osób. Musiałam implementować kulturę pracy i integrację zespołu, żeby ludzie wiedzieli, że zawsze mogą przyjść po poradę.

Najtrudniejszą umiejętnością jest dawanie konstruktywnego feedbacku tak, żeby ludzie nie czuli się źle. Trzeba powiedzieć osobie, co ma zmienić, tak żeby chciała dalej to robić i wiedziała jak.

Radek:

Jak zmienia się dynamika pracy z zespołem, gdy stajesz się liderem?

Ola:

Jest się na świeczniku. Decyzje mogą być dobre albo złe. W jednym zespole miałam doświadczenie z analitykami i data scientistami, gdzie dzięki mojemu doświadczeniu we wszystkich tych obszarach, czułam się na siłach decydować.

Czasami zespół nie rozumie twoich decyzji, szczególnie seniorzy. Kiedy człowiek jest seniorem, myśli, że "seniority coś znaczy" i nie zawsze chce przełknąć, że ktoś zdecydował inaczej.

Inaczej wygląda sytuacja, gdy jesteś liderem technicznym zespołu technologii, której nie znasz. W moim drugim projekcie system był pisany w Javie przez software inżynierów. Nie czułam się na tyle mocna, żeby im mówić, co mają robić. Skupiłam się więc na rozwiązywaniu problemów i komunikacji z klientem.

Czasami wystarczyło zmienić 2 linijki kodu, ale niektóre procesy to utrudniały. A deweloperzy chcieli mieć ładnie opisane zadania, tickety są ładnie opisane, jak ktoś porozmawia z biznesem.

Przyszłość roli lidera

Radek: Jaką widzisz przyszłość dla roli lidera technicznego, szczególnie w obszarze Data?

Ola: Coraz częściej w ofertach pracy dla liderów widzę więcej miękkich niż technicznych wymagań. Myślę, że tacy liderzy techniczni mogą w przyszłości częściowo zastąpić menedżerów. Obecnie menedżerowie zajmują się konfliktem, budżetem, zadowoleniem zespołu, a techniczni liderzy skupiają się na edukacji młodszych stażem.

Dużo trudniej nauczyć się technicznych skili niż zostać menedżerem. Rola menedżerska może sprowadzić się do zarządzania ludźmi, a prowadzenie projektu i dbanie o dostarczanie może przejść na lidera technicznego.

Jak wejść na ścieżkę lidera

Radek: Jakie masz porady dla seniorów, którzy chcieliby zostać liderami technicznymi?

Ola: Polecam książkę "Staff Engineer". Dużo ludzi awansuje na seniora, ale mniej na poziom staff, bo nie ma jasnych wymagań.

Nawet jeśli jesteś przygotowany, może nie być otwartej pozycji albo budżetu. Warto się rozwijać i mieć swoją niszę, ale trzeba pamiętać, że awans wymaga nie tylko wykazania się.

Można zawsze robić rzeczy z tej roli, bo nikt nie zabrania udziału w otwartych spotkaniach czy czytania dokumentacji. Jestem zwolenniczką proaktywności - na każde nowe stanowisko mam już przygotowane job description. Jeśli możesz odciążyć menedżera, napisać opis roli i pomóc w przygotowaniu awansu - zrób to. Korzysta na tym organizacja, menedżer, i ty sam.

Radek: Czy można stworzyć rolę lidera wewnątrz organizacji poprzez wykonywanie zadań liderskich, a następnie inicjowanie dyskusji o formalizacji tej roli?

Ola: Szczególnie gdy się ją dobrze uzasadni i widać efekty i wpływ, to znajdą się ludzie, którzy pomogą napisać job description i wybronić to przed odpowiednimi osobami. Jestem zwolenniczką proaktywności. Na każde nowe stanowisko mam już przygotowane job description i wiem, jak to robić.

Niektórzy wolą czekać na nagrodę. Oba podejścia są dobre, ale jeśli możesz odciążyć menedżera i zrobić parę rzeczy za niego, to napisanie opisu roli i pomoc w awansie jest korzystne dla wszystkich. Menedżer dalej zajmuje się swoimi obowiązkami, osoba chcąca awansować dba o swój interes, a organizacja tylko zyskuje.

Radek: Dzięki wielkie Ola za rozmowę!

Dziś skupimy się na fundamentach – bazie wiedzy produktu. To od niej zależy, czy GenAI będzie w stanie nam efektywnie pomagać.

Dlaczego nie działa nam GenAI?

Rozmowy z liderami technicznymi brzmią podobnie:

Próbowałem ChatGPT, ale odpowiedzi są bardzo ogólne.

Copilot nie rozumie po co piszę ten kod.

Claude wypluwa same truizmy, nic wartościowego.

W efekcie ludzie rezygnują z narzędzi AI, bo nie widzą wartości. Ale problem nie leży w samym narzędziu.

Prawda jest brutalna – nie mamy wiedzy na wejściu.

• LLM nie będzie znał Twojej domeny biznesowej - zaproponuje generyczne odpowiedzi oparte o standardowe przypadki użycia.

• Nie zrozumie architektury i decyzji technicznych - jego sugestie będą ignorować Twoje ścieżki krytyczne, SLA i problemy, które już rozwiązaliście. Dorzuci do tego kolejną warstwę skomplikowania.

• Nie będzie miał pojęcia o procesach w Twoim zespole - zaproponuje rozwiązania wymagające nieistniejących standardów i procesów. A te, które macie, zostaną pominięte.

• Nie weźmie pod uwagę Twoich celów biznesowych i wskaźników - Skupi się na rzeczach, które mogą wyglądać fajnie, ale niekoniecznie przyniosą wartość dla Twojej organizacji.

To nie jest problem sztucznej inteligencji. To brak uporządkowanej wiedzy w naszym zespole.

W poprzednim newsletterze pisałem o minimalnej dokumentacji w zespole produktowym. Dziś rozwinę ten temat pod kątem pracy z GenAI. Bo jeśli chcemy wykorzystać potencjał sztucznej inteligencji, musimy najpierw zadbać o bazę wiedzy naszego produktu.

Zbieramy wiedzę o produkcie

LLM potrzebuje kontekstu, więc musimy zebrać kluczowe informacje o naszym produkcie.

Nie musi to być od razu pełna dokumentacja. Skupmy się na najważniejszych aspektach.

Funkcje produktu

Co nasz produkt oferuje:

• Opis produktu - krótkie podsumowanie, do czego służy i jakie problemy rozwiązuje.

• Główne funkcje - jakie kluczowe możliwości oferujemy użytkownikom.

• Przypadki użycia - typowe i nietypowe scenariusze wykorzystania produktu.

• Słownik domenowy - jak nazywamy rzeczy w naszej organizacji.

Architektura techniczna

Jak produkt jest zbudowany:

• Stack technologiczny - jakich technologii używamy (frontend, backend, baza).

• Komponenty systemu - główne części produktu i ich odpowiedzialności.

• Struktura danych - kluczowe encje i ich powiązania.

• Integracje - z jakimi systemami zewnętrznymi się łączymy.

Jakość i bezpieczeństwo

Jak dbamy o stan wewnętrzny produktu:

• Wymagania jakościowe - wydajność, skalowalność, dostępność.

• Optymalizacja - co i jak optymalizujemy.

• Bezpieczeństwo - jakie zabezpieczenia stosujemy.

• Standardy - wytyczne dla developmentu.

Stan produktu

Gdzie jesteśmy teraz:

• Status prac - co jest gotowe, nad czym pracujemy.

• KPI produktowe - co mierzymy w zachowaniach klienta.

• Cele biznesowe - do czego dążymy jako organizacja.

Nie wszystko potrzebujesz zawsze. Ale niekiedy kilka prostych zdań skieruje LLM do właściwego rozwiązania.

LLM pomoże nam zebrać wiedzę

A skoro mamy już szablon, to pora go wypełnić. Pokażę to na przykładzie domeny wypożyczenia rowerów, którą wykorzystuję podczas szkoleń DDD i modelowania danych.

Zapytaj LLM o pytania

Na początek wysyłamy do LLM nasz szablon i kilka bazowych zdań o naszej domenie. Następnie prosimy o wygenerowanie pytań.

Oto przykładowe pytania, które może nam zadać, w kontekście naszej domeny rowerowej:

Funkcje produktu

• Jakie są główne procesy wypożyczenia roweru?

• Jakie mamy rodzaje rowerów i stacji?

• Czym różni się wypożyczenie zwykłego roweru od elektrycznego?

• Jakie restrykcje mamy na wypożyczanie rowerów?

Architektura techniczna

• Jak podzieliliśmy system na moduły?

• Jak wygląda proces rezerwacji od strony technicznej?

• Jakie dane zbieramy o wypożyczeniach?

• Z jakimi systemami musimy się integrować?

Jakość i bezpieczeństwo

• Ile wypożyczeń na minutę musimy obsłużyć?

• Jak długo może trwać niedostępność systemu?

• Jak zabezpieczamy płatności?

• Jakie mamy standardy dla wypożyczeń elektrycznych?

Stan produktu

• Które funkcje są już dostępne?

• Po czym poznamy, że system działa dobrze?

• Jakie cele biznesowe mamy na najbliższy kwartał?

• Co planujemy dodać w następnej kolejności?

Odpowiadamy na pytania

Ja do nagrywania odpowiedzi używam AudioPen polecane przez Jakuba Mrugalskiego. Mogę uzyskać ustrukturyzowane informacje na bazie luźnej opowieści.

Przykładowe odpowiedzi dla wypożyczalni rowerów:

Główne procesy

• Klient wypożycza rower ze stacji początkowej

• Może wcześniej zarezerwować rower przez system

• Jeździ max 12h, później płaci kary

• Oddaje na dowolnej stacji końcowej

• Płaci kartą podpiętą do konta

Architektura

• System podzielony na moduły: wypożyczenia, płatności, rezerwacje.

• Moduły komunikują się przez zdarzenia.

• Dane o rowerach i wypożyczeniach trzymamy w CosmosDB.

• Integrujemy się z systemem płatności i monitoringiem miasta.

Wymagania jakościowe

• System obsługuje 1000 wypożyczeń na godzinę.

• 99.9% dostępności w godzinach 6-22.

• Maksymalny czas odpowiedzi to 2 sekundy na ścieżce krytycznej.

• Monitoring stanu rowerów co 5 minut.

• Automatyczne alerty przy problemach.

To tylko fragment tej wiedzy - docelowe odpowiedzi byłyby o wiele dłuższe. Ale daje to wartościowy wkład do pracy LLMa.

Narzędzia do pracy z bazą wiedzy

Zebranie wiedzy to pierwszy krok. Teraz trzeba ją efektywnie wykorzystać w pracy z AI. Oto kilka sprawdzonych podejść:

Doklejanie do prompta

Najprostsze rozwiązanie - kopiujemy całość / potrzebny fragment wiedzy i wklejamy do kontekstu rozmowy z LLM.

Działa, ale ma istotne ograniczenie - trzeba ręcznie przeklejać 😅

Więc przejdźmy do innych podejść...

Dedykowane asystenty

Na rynku pojawia się coraz więcej dedykowaych asystentów, które posiadają własne bazy wiedzy.

ThoughtWorks ze swoim Haiven Team Assistant pokazuje zaawansowane podejście:

• Baza wiedzy jest wbudowana w narzędzie.

• Asystent automatycznie wybiera potrzebny kontekst.

• Może łączyć wiedzę z różnych źródeł.

• Rozumie strukturę i powiązania w projekcie.
  Znam kilka polskich firm, które się przymierzają do tego narzędzia. Ale można prościej...

Zarządzanie projektami w LLM

Platformy GenAI pozwalają tworzyć bazy wiedzy, które wykorzystujemy w ramach zapytania.

Świetnym przykładem jest tutaj Projects w Claude. Możemy sobie ułatwić pracę, a nie wykorzystywać złożonych narzędzi:

• Tworzymy osobne projekty dla różnych produktów / części systemu.

• Łatwo aktualizować bazę wiedzy - edycja bezpośrednio z portalu, lub przez dysk Google.

• Baza wiedzy może obsługiwać wielostronicowe dokumenty.

Claude łączy się z Google Drive. Zadziała nawet jeśli głównie korzystamy z narzędzi Microsoftu - można sobie napisać prosty synchronizator w Power Automate pomiędzy dyskami.

Rozszerzenia do IDE

Nasze AI-owe narzędzia IDE pozwalają definiować bazowy prompt. Można w niego wbudować wiedzę o domenie. Tutaj przykład Cursor ze specjalnym promptem:

• Ciągnie informacje z pliku projects.md.

• Automatycznie dodaje kontekst do zapytań.

• Może budować bardziej złożone prompty.

Inne narzędzia

Istnieją też rozwiązania łączące się bezpośrednio z bazami wiedzy (jak Notion AI), ale osobiście z nich nie korzystałem.

Kluczem jest wybranie rozwiązania, które:

• Pasuje do Twojego stylu pracy.

• Pozwala łatwo aktualizować wiedzę.

• Efektywnie wykorzystuje kontekst w rozmowie z AI.

Dowozimy zadania w 2-3 dni

Zapytałem wtedy o czas oczekiwania na odpowiedź od innych zespołów. Po szybkim
przeliczeniu wyszło, że takie uzgodnienia trwają nawet 2 tygodnie. Tego czasu zespół już jednak nie wliczał do swoich metryk.

Podobna sytuacja (choć w innych dziedzinach) powtórzyła się wielokrotnie. Zespoły wąsko mierzyły SLA. Narzekały na koszty zakupu, ale nie developmentu. Liczyły błędy zgłaszane przez klientów, nie zauważając tych, którzy po prostu rezygnowali z produktu.

Problem w tym, że mierzymy to, co jest łatwe do zmierzenia, zamiast tego, co faktycznie ma znaczenie. Patrzymy na to, co wygodne, a nie na to, co wpływa na efektywność. A tymczasem rzeczywistość wygląda zupełnie inaczej.

Przyjrzyjmy się więc najczęstszym błędom w mierzeniu naszej pracy.

Przykłady błędnego mierzenia

Przejdziemy sobie od kwestii technicznych, przez procesowe, po produktowe.

Dostępność systemu (SLA)

Zacznijmy od dostępności systemu (SLA). Temat, o którym kiedyś wspominali też Patoarchitekci w swoim podcaście.

Zespoły często pokazują imponujące metryki dostępności swoich systemów - 99.9%. Wszystko pięknie się świeci na zielono. Jest tylko jeden szkopuł - nikt nie patrzy na dostępność systemów zależnych. A to właśnie one często są źródłem problemów.

Spójrzmy na typowe wartości dostępności:

• Baza danych - 99% dostępności

• Bramka płatności - 95% dostępności

• System logistyczny - 90% dostępności

• System mailowy - 98% dostępności

I tutaj przychodzi matematyka - dostępność systemów zawsze się mnoży. 99.9% 99% 95% * 90% = 84.4%. W skali miesiąca to ponad 100 godzin przestoju. A my wciąż chwalimy się tymi 99.9% 🤦‍♂️

Jak pisałem w poprzednim newsletterze o niezawodności - klienta nie obchodzi czy system nie działa przez naszą bazę czy zewnętrzną bramkę płatności. Dla niego system po prostu nie działa. Kropka (nienawiści).

Decyzje Build vs Buy

Przejdźmy do klasycznego dylematu Build vs Buy. Stajemy przed decyzją - kupić gotowe rozwiązanie czy zbudować własne. Patrzymy na cenę zewnętrznego narzędzia - 50 tysięcy rocznie. "Za drogo" - pada decyzja. "Zbudujemy sami, będzie taniej".

Problem w tym, że patrzymy tylko na jeden wymiar kosztów. Pomijamy wszystkie pozostałe:

• Koszt pracy zespołu - dwóch seniorów na pół roku to już 100 tysięcy.

• Koszt utraconych możliwości - w tym czasie moglibyśmy dostarczyć funkcje generujące 200 tysięcy przychodu.

• Koszt utrzymania - jeden developer na stałe zajmuje się poprawkami.

• Koszt opóźnienia wejścia na rynek - konkurencja już sprzedaje, a my dopiero budujemy.

W efekcie "oszczędzamy" 50 tysięcy, tracąc 500 tysięcy w skali roku. 🤦‍♂️ Jak pisałem w artykule o Buy vs Build - 4 koszta, musimy spojrzeć znacznie szerzej na temat kosztów.

Mój ulubiony przykład? Pisanie od zera biblioteki do zarządzania transakcjami rozproszonymi, zamiast wykorzystania Mass Transit. Kopiemy się z koniem przez pół roku, zamiast zapłacić Chrisowi kilka tysięcy i mieć gotowe rozwiązanie na jutro.

Dług technologiczny

Czas na temat długu technologicznego. Część zespołów w ogóle nie zastanawia się nad tym tematem. Nie wiedzą nawet jak głęboko siedzą w problemach. Po prostu jadą do przodu, aż w końcu system się posypie. 😅

Ale załóżmy, że jednak próbujemy to mierzyć. Co zwykle robimy? Idziemy po linii najmniejszego oporu:

• Tworzymy tickety na każdy problem

• Wrzucamy je do backloga

• ...i tam umierają, bo nikt ich nie realizuje

W 90% przypadków takie zadania nigdy nie trafiają do sprint backloga. Bo zawsze jest coś ważniejszego. Coś, co "musi wejść na produkcję już".

Lepsze podejście proponuje Brandolini ze swoim Design integrity. Nie patrzmy na dług jako listę zaległości. Skupmy się na tym, jak mocno nasz kod pasuje do swoich celów. Wymaga to jednak mierzenia o wiele więcej:

• Wpływu długu na różnych interesariuszy.

• Potencjalnych zysków z naprawy.

• Czasu wymaganego na naprawę.

Więcej o tym, jak skutecznie mierzyć dług technologiczny opisałem w artykule Dług w produkcie - jak uzasadniać jego spłatę.

Czas dostarczania

Kolejnym problemem jest mierzenie czasu dostarczania. Zespoły zwykle skupiają się tylko na czasie developmentu. "Zrobiliśmy to w 2 dni!" - krzyczą z dumą. Tylko że to nie jest pełny obraz.

Co zwykle pomijamy w pomiarach?

• Czas oczekiwania na tłumaczenia

• Czas na security review

• Czas na compliance check

• Czas na code review (o którym pisałem w newsletterze o PR Review)

• Czas na faktyczne uruchomienie na produkcji (zobacz na Przyśpieszaj uruchamianie, zamiast tylko dostarczać)

W efekcie zespół widzi 2 dni pracy, a zadanie realnie trwa 2 tygodnie.

To trochę jak z liczeniem średniej prędkości w mieście - jazda między światłami może być szybka, ale i tak głównie stoimy w korkach. 😅

Skuteczność testów

A teraz rzućmy okiem na temat testów. Duża część firm ma rozbudowane testy E2E sprawdzające scenariusze między domenami. Mierzymy pokrycie kodu, liczymy ile przypadków obsługujemy, patrzymy na szerokość testów. Wskaźniki wyglądają świetnie - 80% pokrycia!

Tylko że kompletnie pomijamy inne aspekty:

• Czas wykonywania testów - dziesiątki czy setki minut.

• Niestabilność testów - raz przechodzą, raz nie.

• Brak pewności - nie wiemy, czy faktycznie znaleźliśmy błąd, czy to tylko niestabilny test

W efekcie nikt już nie ufa testom. Kiedy testy nie przechodzą, to nie słychać "O kurde, mam błąd w kodzie", tylko "Znowu te testy E2E się popsuły". Testy stały się wrogiem zespołu, zamiast być jego sprzymierzeńcem.

A skoro nikt nie ufa testom, to po co w ogóle je mamy? Jak pisałem w artykule o zapewnianiu jakości przez obserwowalność, często lepiej jest zainwestować w monitoring produkcji. Mała inwestycja potrafi dać znacznie większy zwrot niż kolejne niestabilne testy.

Wykorzystanie produktowe

Przejdźmy do mierzenia wykorzystania produktu. Chwalimy się na spotkaniach:

Mamy 1000 aktywnych użytkowników miesięcznie.

Liczby może i wyglądają świetnie, ale czy na pewno mierzą to, co istotne? Warto zadać pytanie:

• Ile czasu użytkownicy faktycznie spędzają w systemie?

• Które funkcje naprawdę wykorzystują?

• Czy w ogóle wracają do produktu po pierwszym użyciu?

• Jak głęboko wchodzą w nasz produkt?

W efekcie cieszymy się z tysiąca użytkowników, podczas gdy 900 z nich zagląda do aplikacji raz w miesiącu, klika jeden przycisk i wychodzi. To trochę jak chwalenie się, że mamy dużo followersów na LinkedIn - liczba może i imponująca, ale co z tego? 😅

To klasyczny przykład metryki próżności - wygląda świetnie w prezentacji, ale kompletnie nie pokazuje realnej wartości naszego produktu. Zamiast liczyć użytkowników, może warto zacząć mierzyć ich faktyczne zaangażowanie?

Problemy użytkowników

Na koniec został temat zgłoszeń od użytkowników. Liczymy, że mamy tylko 10 zgłoszeń miesięcznie. Wydaje się dobrze, ale jak poszukamy głębiej, to okazuje się że pomijamy:

• Klientów, którzy po prostu zrezygnowali bez słowa

• Użytkowników, którzy znaleźli obejście problemu

• Osoby, które przestały korzystać z problematycznej funkcji

• Tych, którzy nawet nie spróbowali, bo przeczytali negatywne opinie

Działa tu tzw. błąd przeżywalności - docierają do nas tylko te przypadki, które "przeżyły".

W efekcie, chwaląc się małą liczbą zgłoszeń, kompletnie pomijamy sygnały od niezadowolonych klientów. Oni po prostu odpuszczają i idą do konkurencji. A my dalej żyjemy w przekonaniu, że wszystko jest super, bo nikt nie narzeka.

No cóż, martwi też nie narzekają. 💀

Mierzenie, które daje wartość

Aby faktycznie wyciągać wartość z naszych pomiarów, musimy unikać typowych pułapek.

Po pierwsze, nie możemy patrzeć lokalnie. Musimy widzieć szerszy obraz - nie tylko nasz system, ale też systemy zależne. Nie tylko nasz zespół, ale całą organizację.

Po drugie, trzeba zastanawiać się nad konsekwencjami mierzenia. Łatwo grywalizować metryki, które nie wprowadzają długofalowej wartości.

Po trzecie, nie możemy zrzucać odpowiedzialności na innych. To, że problem leży w innym zespole nie znaczy, że nie jest to nasz problem. Końcowy użytkownik widzi całość, nie pojedyncze kawałki.

Po czwarte, nie skupiajmy się tylko na miarach ilościowych. Liczby to nie wszystko - informacje jakościowe mogą nam powiedzieć o czymś, co trudno skwantyfikować.

Po piąte, mierzmy to, co warto, a nie to, co łatwo zmierzyć. Tak, to wymaga więcej wysiłku. Tak, to trudniejsze. Ale tylko wtedy nasze pomiary będą miały rzeczywistą wartość.

W przeciwnym przypadku możemy skończyć w gorszej sytuacji, niż gdybyśmy w ogóle nie mierzyli.

Warto przyjrzeć się jej bliżej, gdyż ma bezpośredni wpływ na efektywność organizacji.

Po co mi strategia

W zespołach produktowych codzienność zdominowana jest dostarczaniem kolejnych funkcji, naprawianiem błędów i wdrażaniem zmian.

W natłoku operacyjnych zadań nie zastanawiamy się nad szerszym kontekstem naszych decyzji technicznych. Nie wiemy nawet, że coś takiego jak strategia inżynierska może nam pomóc uporządkować chaos i nadać kierunek naszym działaniom.

Na co wpływa brak uporządkowanej strategii?

• Zespoły tracą czas na powtarzające się dyskusje techniczne zamiast skupić się na dostarczaniu wartości.

• Decyzje technologiczne są podejmowane ad-hoc, bez spójnej wizji.

• Nowe projekty powstają w różnych technologiach, utrudniając późniejsze utrzymanie.

• Trudno przekonać interesariuszy do inwestycji w aspekty techniczne

• Nowe osoby muszą metodą prób i błędów poznawać 'jak tu się rzeczy robi'

Co ciekawe, nawet jeśli myślisz, że nie masz strategii, to i tak ją masz. Decyzje, które podejmujesz jako lider techniczny, każdy wybór narzędzia czy technologii – to wszystko bazuje na jakiejś strategii. Pytanie na ile ona jest spójna, oraz zrozumiała dla szerszego zespołu.

Czym jest strategia

Zanim pójdziemy dalej, warto określić czym właściwie jest strategia inżynierska.

Richard Rumelt w swojej książce "Good Strategy, Bad Strategy" definiuje ją następująco:

Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favorable outcomes.

Przekładając to na nasz obszar inżynierski - strategia polega na identyfikacji i rozwiązaniu kluczowego problemu technicznego, który blokuje rozwój produktu. Właściwie wybrany i rozwiązany problem prowadzi do kaskadowej poprawy w wielu obszarach technicznych i biznesowych. Skuteczna strategia koncentruje zasoby zespołu na tym właśnie krytycznym elemencie.

Jak opisywałem w newsletterze o Celach -> Możliwościach -> Rozwiązaniach, skupienie się jest kluczowe by faktycznie coś osiągnąć 😉

Wg. Rumelta strategia składa się z trzech głównych elementów, które poniżej opiszę na przykładach:

• Diagnosis (diagnoza) - zrozumienie obecnej sytuacji i wyzwań.

• Guiding policy (Kluczowe podejście) - określenie jak zamierzamy rozwiązać zidentyfikowane problemy.

• Coherent actions (Zbiór spójnych działań) - konkretnye kroki, które podejmujemy by wdrożyć nasze rozwiązanie.

Warto zaznaczyć, że strategia inżynieryjna nie powstaje w próżni. Zespół inżynierski jest częścią większej organizacji, która ma swoje cele biznesowe. Nasza strategia musi więc wspierać te cele - nie możemy skupiać się tylko na aspektach technicznych, ignorując biznesową wartość naszych działań.

Od czego rozpoczynamy? Od diagnozy!

Diagnosis

Pracę nad strategią nie rozpoczynamy od działania, a raczej od analizy tego co dookoła.

A great deal of strategy work is trying to figure out what is going on. Not just deciding what to do, but the more fundamental problem of comprehending the situation. At a minimum, a diagnosis names or classifies the situation, linking facts into patterns and suggesting that more attention be paid to some issues and less to others.

Pierwszym krokiem w budowie strategii jest dobra diagnoza - zrozumienie sytuacji, w której się znajdujemy. Nie chodzi tu o proste wylistowanie problemów, ale o głębsze zrozumienie wzorców i powiązań pomiędzy nimi.

W przypadku produktów cyfrowych musimy spojrzeć naprawdę szeroko. Źródła informacji do naszej diagnozy to:

• Analiza celów biznesowych i produktowych - na czym zależy naszym interesariuszom (Cele -> Możliwości -> Rozwiązania)

• Otoczenie biznesowe - czy działamy w środowisku regulowanym, jaki wielu klientów posiadamy, czy to jest B2B czy B2C

• Struktura produktu - jak podzielony jest produkt na mniejsze obszary (Projektowanie organizacji)

• Dojrzałość techniczna - metryki DORA, obserwowalność (Obserwowalność)

• Funkcje biznesowe - obecne i przyszłe rozwiązania na roadmapie, zależności między nimi

• Ludzie - skład zespołu, wiedza techniczna, jak współpracują ze sobą

• Infrastruktura - stabilność środowisk, koszty utrzymania, skalowalność

• Wskaźniki jakościowe - wydajność, niezawodność (Drivery architektoniczne)

Na podstawie zebranych informacji musimy zidentyfikować kluczowe problemy i wyzwania. Jednak, jak zauważa Rumelt:

Because the challenge was ill-structured, a real-world strategy could not be logically deduced from the observed facts.

Nie wystarczy więc proste ocenienie ryzyk w skali 1-5 i wybranie tego z najniższą oceną. Musimy aktywnie zdecydować, który problem jest dla nas najważniejszy i będzie miał największy wpływ na sukces produktu.

Przykład diagnozy

Przyjrzyjmy się przykładowi startupu rolniczego, który chce udostępniać rolnikom dane ze stacji pogodowych. System ma agregować i analizować informacje z wielu źródeł, by dostarczać rekomendacje upraw.

Zbierając informacje do diagnozy, zauważamy:

• Wymagania skalowalności:

  • Kilkadziesiąt tysięcy odczytów ze stacji na początku każdej godziny.

  • Nocne przetwarzanie danych i generowanie wykresów.

  • Masowa wysyłka maili do klientów.

  • Bardzo skokowe obciążenie - od 0 do 10000 odczytów w ciągu 5 minut i znów 0.

• Ograniczone zasoby:

  • Startup w początkowej fazie wzorstu z ograniczonym budżetem.

  • Brak dedykowanego zespołu Ops.

  • Konieczność optymalizacji kosztów infrastruktury.

• Zespół techniczny:

  • 4-osobowy zespół developerski.

  • Doświadczenie głównie w aplikacjach monolitycznych.

  • Niewielka wiedza na temat rozwiązań chmurowych.

  • Brak doświadczenia w przetwarzaniu dużych wolumenów danych.

• Stan obecny:

  • Wszystko hostowane na pojedynczym VPSie.

  • Problemy z wydajnością w godzinach szczytu.

  • Brak automatycznego skalowania.

  • Ręczne procesy deploymentu.

• Otoczenie biznesowe:

  • Firma-matka ma podpisane umowy z Microsoftem.

  • Klienci wymagają wysokiej dostępności danych.

  • Planowana ekspansja na rynki zagraniczne.

• Presja czasowa:

  • 4 miesiące do startu w kolejnym sezonie.

Główne wyzwanie staje się jasne:

• jak zbudować rozwiązanie na tyle solidne technicznie, by było gotowe na szybki wzrost skali,

• jednocześnie na tyle optymalne kosztowo, by startup mógł je efektywnie utrzymywać przy obecnej liczbie klientów.

Potrzebujemy infrastruktury, która pozwoli nam płynnie rosnąć wraz z biznesem, bez konieczności rewolucyjnych zmian architektonicznych w przyszłości.

Guiding Policy

Po diagnozie sytuacji, musimy określić kierunek naszych działań. To właśnie jest tzw. Guiding Policy - metoda, która pomoże nam rozwiązać zidentyfikowane problemy. Jak pisze Rumelt:

A guiding policy creates advantage by anticipating the actions and reactions of others, by reducing the complexity and ambiguity in the situation, by exploiting the leverage inherent in concentrating effort on a pivotal or decisive aspect of the situation, and by creating policies and actions that are coherent, each building on the other rather than canceling one another out.

Dobra metoda redukuje złożoność problemu i wskazuje, na czym powinniśmy się skupić.

W kontekście produktów cyfrowych może to być:

• Skupienie technologiczne - wykorzystania konkretnego stosu technologicznego.

• Alokacja zasobów - przesunięcie ludzi pomiędzy zespołami, aby realizowali konkretne rozwiązania.

• Procesy pracy - zmiana podejścia do dostarczania.

• Wymagana jakość - skupienie na konkretnych atrybutach jakościowych.

• Dług technologiczny - świadome poświęcenie określonych aspektów systemu.

• Partnerstwo - współpraca z zewnętrznymi dostawcami.

• Poziom autonomii - określenie samodzielności zespołów.

• Okrojenie funkcjonalne - zrezygnowanie z części funkcji rozwiązań z planu.

Kluczowe jest to, by nie wybierać pierwszego rozwiązania, które przychodzi nam do głowy. Trzeba wypracować kilka potencjalnych kierunków działania. Każdy z nich niesie ze sobą pewne kompromisy - musimy je zrozumieć i świadomie wybrać te, na które jesteśmy gotowi pójść.

W ramach wyboru kierunku warto rozważyć:

• Jak potwierdzimy, że działa, że faktycznie rozwiązujemy problem? Aby szybko zebrać feedback, zamiast czekać miesiącami.

• Co jest kompromisem? Jakie problemy musimy zaakceptować? Aby świadomie podjąć decyzje o wadach i konsekwencjach.

• Które aspekty są dla nas kluczowe, a które drugorzędne.

Podobnie jak w przypadku analizy wymagań (o czym pisałem w Cele -> Możliwości -> Rozwiązania), musimy zdecydować na czym się skupiamy. Nie da się zoptymalizować wszystkiego naraz.

Przykład kierunków działania

Wróćmy do naszego startupu rolniczego. Możemy rozważyć kilka kierunków:

1. Dotychczasowe technologie na klasycznych VPSach:

• Własne serwery z tradycyjnym stosem technologicznym.

• Potwierdzenie: Szybkie wdrożenie prototypu na 2-3 serwerach.

• Kompromisy:

  • Sami musimy zarządzać skalowaniem

  • Płacimy za serwery 24/7, nawet gdy nie są używane

  • Wysokie koszty przy większej skali

  • Brak wbudowanych narzędzi do analityki

2. Outsourcing całej infrastruktury:

• Zewnętrzny partner zarządza hostingiem i skalowaniem.

• Potwierdzenie: Pilotaż z małym zbiorem danych na 2 tygodnie.

• Kompromisy:

  • Wyższe koszty miesięczne

  • Zależność od zewnętrznego dostawcy

  • Mniej kontroli nad architekturą

  • Trudniejsza zmiana kierunku w przyszłości

3. Azure i rozwiązania serverless:

• Wykorzystanie chmury i automatycznego skalowania funkcji Azure.

• Potwierdzenie: Proof of concept z kilkoma funkcjami i testami wydajności + kosztów.

• Kompromisy:

  • Dłuższy czas na naukę technologii

  • Vendor lock-in na rozwiązania Microsoftu

  • Trudniejsze debugowanie rozproszonego systemu

  • Wyższe koszty przy stałym obciążeniu

Po analizie wybrano Azure - głównie ze względu na:

• Płatność za faktyczne wykorzystanie przy mocno zmiennym obciążeniu.

• Wbudowane narzędzia do przetwarzania danych.

• Istniejące umowy z Microsoftem - szybki start.

Coherent Actions

Strategia musi przekładać się na konkretne działania. Jak pisze Rumelt:

Many people call the guiding policy "the strategy" and stop there. This is a mistake. Strategy is about action, about doing something. The kernel of a strategy must contain action.

Wdrażanie strategii wymaga skoordynowanych działań na wielu poziomach. Nie mogą być one przypadkowe - muszą się wzajemnie wspierać i prowadzić do celu.

Aby sobie pomóc, w ramach spójnych akcji można wykorzystać podział z artykułu Writing an engineering strategy Willa Larsona:

Egzekwowanie - jak będziemy utrzymywać spójność z wybranym kierunkiem? Bez jasnych zasad nawet najlepsza strategia pozostanie tylko na papierze.

• Automatyzacja sprawdzania zgodności

• Regularne przeglądy odstępstw

• Audyty wdrożonych rozwiązań

• Mierzenie postępu zmian

Eskalacje - jak usprawniamy obrany kierunek? Konstruktywny feedback pomoże nam wyłapać problemy, zanim staną się krytyczne.

• Dedykowane kanały komunikacji

• Cykliczne spotkania przeglądowe

• Ustalony proces eskalacji

• System proponowania zmian

Przejścia - jak przechodzimy do nowego stanu? Zmiana musi być przeprowadzona w sposób kontrolowany i bezpieczny.

• Plan migracji z jasno zdefiniowanymi krokami

• Ograniczenie liczby równoległych zmian

• Regularna synchronizacja postępów

• Jasne kryteria sukcesu

Te działania muszą się wzajemnie wspierać, jak podkreśla Rumelt:

The actions should be coherent - consistent and coordinated. The coordination of action provides the most basic source of leverage or advantage available in strategy.

Przykład spójnych kroków

Po wyborze Azure jako kierunku działania, musimy zaplanować konkretne kroki. Przede wszystkim, potrzebujemy upewnić się, że nasz zespół jest gotowy na taką zmianę technologiczną i organizacyjną. Wdrażanie rozpoczynamy od fundamentów.

Egzekwowanie:

• Przeprowadzimy testy PoC by zmierzyć wydajność rozwiązania.

• Ustalimy budżet dla pierwszych wdrożeń.

• Stworzymy standardy pisania funkcji serverless.

Eskalacje:

• Będziemy spotykać się co tydzień by omawiać postępy.

• Ustalimy proces podnoszenia krytycznych problemów.

• Wyznaczymy osoby odpowiedzialne za komunikację z partnerem.

Przejścia:

• Przeprowadzimy cykl szkoleń Azure dla całego zespołu.

• Przeniesiemy komponenty do chmury według ustalonego harmonogramu.

• Przeanalizujemy wymagania wydajnościowe dla każdej funkcji.

Te działania wspierają nasz kierunek - Azure z serverless, prowadząc do coraz bardziej efektywnego wykorzystania chmury.

Podsumowanie

To tylko wprowadzenie do tematu strategii inżynierskiej. Wiele istotnych aspektów, takich jak mierzenie sukcesu strategii, najczęstsze pułapki czy rola zespołu w jej tworzeniu i realizacji, zasługuje na osobne omówienie.

Zachęcam do zgłębienia tych tematów w poniższych materiałach:

• Książka Good Strategy, Bad Strategy - Richard Rumelt

• Zbiór artykułów o Engineering Strategy - Will Larson

• Zbiór artykułów Designing an Engineering Strategy - Aleix Morgadas

• Artykuł Strategy basics - Alex Ewerlof

Uczestnik zadał mi pytanie:

Jakimi heurystykami dobrze jest się kierować przy wyborze konkretnej techniki?

Jak się pewnie spodziewacie - nie mogę dać prostej odpowiedzi "użyj techniki X w sytuacji Y". Zamiast tego, przedstawię proces wyboru technik.

Główne pytanie przy wyborze techniki to:

Jak pomoże nam poradzić sobie z niepewnością?

Ale żeby na to pytanie odpowiedzieć to trzeba najpierw trzeba zdefiniować niepewność 😅

Niepewność

Za autorem książki The Art of Action niepewność objawia się w 3 lukach:

(autor wykorzystuje słowo Friction zamiast Uncertainty, ale na potrzeby artykułu możemy to połączyć)

1. Luka wiedzy (Knowledge gap):

• Różnica między tym co wiemy, a co chcielibyśmy wiedzieć.

• Często nie widzimy jak mało wiemy + jak wiele własnych interpretacji narzucamy.

• Brak wiedzy prowadzi do nietrafionych decyzji.

• Przykład: Myślimy że znamy potrzeby klienta, ale tak naprawdę zgadujemy.

2. Luka zgodności (Alignment gap):

• Różnica między tym co chcemy by ludzie robili, a co faktycznie robią.

• Każdy ma swoją perspektywę i doświadczenie, własna agendę i wewnętrzne priorytety.

• Pomysły i zadania są róznie interpretowane, a przez to różnie wdrażane w życie.

• Przykład: Zespół rozumie założenia inaczej niż zamierzaliśmy, przez co zbuduje inne rozwiązanie.

3. Luka rezultatów (Effects gap):

• Różnica między oczekiwanymi a faktycznymi efektami.

• Rzeczywistość zawsze nas zaskakuje, nie sprzyja naszym planom.

• To co działa na papierze, niekoniecznie działa w praktyce.

• Przykład: Wdrożenie trwa 2x dłużej niż planowaliśmy, ponieważ w kupionej bibliotece był błąd.

Te luki wpływają na siebie nawzajem:

• Gdy brakuje nam wiedzy, trudno przekazać jasne instrukcje. Zespół działa po omacku.

• Gdy zespół nie jest zgrany, każdy ciągnie w swoją stronę. Efekty są przypadkowe.

• Gdy efekty są inne niż oczekiwane, odkrywamy czego nie wiedzieliśmy na początku.

Koło się zamyka.

Techniki vs Luki

Skoro wiemy już jakie luki niepewności występują w organizacji, to warto się zastanowić jakie techniki je adresują. Nie ma tu bowiem podejścia "one size fits all" - każdą z luk adresujemy w nieco inny sposób:

Luka wiedzy:

• Przeprowadzamy warsztaty z ekspertami domenowymi.

• Zbieramy i analizujemy dane o procesach i użytkownikach.

• Wykonujemy research techniczny i biznesowy.

Luka zgodności:

• Tworzymy wspólne modele i wizualizacje rozwiązania.

• Wypracowujemy wspólne słownictwo i rozumienie domeny.

• Konfrontujemy różne perspektywy by znaleźć punkty wspólne.

Luka rezultatów:

• Przeprowadzamy tanie eksperymenty.

• Wdrażamy rozwiązania iteracyjnie, zaczynając od małej skali.

• Testujemy hipotezy na części ruchu.

Przykładowe rozpisanie technik, wraz z lukami:

Dana technika może adresować różne luki np. Event Storming:

• Luka wiedzy - Analiza jak działa nasz proces biznesowy, z happy path i ścieżkami pobocznymi.

• Luka zgodności - Wybór jednego z 3 pomysłów na implementację docelowego procesu.

• Luka rezultatów - Określenie jak mierzyć sukces wdrożenia, by szybko wyłapać, że nie idzie po naszej myśli.

Od jakiej więc techniki rozpocząć? Proponuję rozpocząć od początku 😉

Kolejność niepewności

Zanim wybierzemy technikę, musimy wiedzieć na jakim etapie jesteśmy. Nie ma sensu rozmawiać o rozwiązaniach, gdy nie rozumiemy problemu. Zmniejszenie niepewności odnośnie rozwiązania sprawi, że dowieziemy rozwiązanie dla nieistniejącego problemu.

Dawno temu, z Michałem Bartyzelem opracowaliśmy Value-Chain pokazujący kolejne etapy pracy z klientem (na potrzeby niezrealizowanego kursu Zostań architektem rozwiązań biznesowych):

Można na tym wzorować się tworząc podział technik.

"Houston, mamy problem?"

Klient nie widzi problemu. Często maskuje go przyzwyczajeniami lub obejściami.

Pierwszy krok: pokazać, że problem istnieje.

Użyteczne techniki:

• Empathy map -> pokazuje ukryte frustracje użytkowników.

• Gemba Walk -> obserwacja rzeczywistej pracy.

• Porter's 5 Forces -> pokazuje presję z rynku.

"Co dokładnie boli?"

Klient czuje, że coś jest nie tak. Ale nie umie nazwać źródła problemu.

Drugi krok: zdefiniować precyzyjnie problem,

Użyteczne techniki:

• 5 Whys -> dociera do źródła problemów.

• Fishbone diagram -> analizuje przyczyny występowania usterek.

• Impact Mapping -> pozwala zdefiniować cele przeprowadzanych zmian.

"Jak to ugryźć?"

Klient zna problem. Nie wie jednak jak go rozwiązać.

Trzeci krok: znaleźć możliwe rozwiązania

Użyteczne techniki:

• 1-2-4-All -> generuje pomysły na rozwiązanie.

• Work-Breakdown Structure -> strukturyzuje zakres prac.

• Impact/Effort -> ocenia rozwiązania i prace, by wskazać najbardziej zyskowne.

"Jak to dowieźć?"

Klient zna rozwiązanie. Ale nie umie tego wdrożyć.

Czwarty krok: zaplanować realizację.

• Story mapping -> planuje kolejność dowożenia.

• Stakeholder mapping -> identyfikuje kluczowe osoby w ramach dowożenia.

• Pre-mortem -> sprawdza ryzyka w planie.

Zasada jest prosta:

• Zmniejsz niepewność na aktualnym poziomie.

• Dopiero potem przechodź do następnego.

• Przeskakiwanie poziomów prowadzi do optymalizacji na błędnym celu.

Przykład:
❌ "Potrzebujemy nowego systemu" (poziom 3)
✅ "Czemu obecny system wam nie pasuje?" (poziom 1)

Kiedy wiemy już gdzie jesteśmy, możemy skupić się na największej luce niepewności. Pomoże nam w tym Gamestorming.

Największa luka niepewności

Twórcy podejścia Gamestorming zauważyli, że aktywność grupy można podzielić na 3 kategorie:

1. Podejście dywergentne (rozbieżne) - Zbieramy jak najwięcej danych i pomysłów. Nie oceniamy, tylko gromadzimy.

2. Podejście emergentne (eksploracyjne) - Analizujemy zebrane informacje, szukamy wzorców i powiązań. Pogłębiamy zrozumienie kontekstu i identyfikujemy połączenia.

3. Podejście konwergentne (zbieżne) - Zawężamy opcje, wybieramy najlepsze rozwiązanie. Podejmujemy decyzję w oparciu o zebrane informacje.

Podobny model zastosowała Annie Duke, opisując na podcaście u Lenniego podejście 3Ds:

1. Discover (Odkrywaj) - Każdy najpierw zbiera pomysły samodzielnie.

2. Discuss (Dyskutuj) - Porównujemy różne perspektywy.

3. Decide (Decyduj) - Decyzje podejmujemy indywidualnie po dyskusji.

Ten sam model myślenia można przenieść do pracy z niepewnością.

Weźmy na tapet wybranie docelowego rozwiązania.

Podejście dywergentne (rozbieżne):

Na początku nie wiemy czego nie wiemy. Rzucenie się na pierwszy lepszy pomysł sprawi, że pominiemy 90% otaczającej nas rzeczywistości.

Powinniśmy skupić się na wygenerowaniu jak największej liczby informacji na temat problemu. Aby nie odrzucić przedwcześnie wartościowej uwagi, nie oceniamy ich na tym etapie.

Przydatne techniki to:

• Break the Rules -> staramy się odwrócić myślenie o istniejącej sytuacji, poszerzyć spektrum dyskusji.

• Worst possible idea -> szukanie najgorszych pomysłów, by zrozumieć dlaczego są błędne,.

• SCAMPER -> lista pytań pobudzających wyobraźnię (np. jak to uprościć? a jak skomplikować?).

Podejście emergentne (eksploracyjne):

Mamy zbiór informacji na temat problemu - pomysły, rozwiązania, wyzwania, ryzyka. Pojawia się nowy rodzaj niepewności - nie wiemy jeszcze które z nich tworzą spójną całość, jak się uzupełniają i gdzie występują luki w naszym rozumowaniu.

W tym momencie naszym celem jest pogłębiona analiza zebranych pomysłów. Szukamy wzorców, kategoryzujemy, próbujemy znaleźć ukryte powiązania.

Przykładowe techniki:

• Wardley Mapping -> mapujemy rozwiązania, aby zrozumieć ich dojrzałość i bliskość klienta.

• SWOT -> analiza silnych i słabych stron, szans i zagrożeń dla rozwiązań

• Business Model Canvas -> mapujemy pomysły na elementy modelu biznesowego by zobaczyć jak ze sobą współgrają.

Podejście konwergentne (zbieżne):

Na koniec niepewność skupia się dookoła luki zgodności - jak z całego zbioru analizy wybrać właściwe rozwiązanie.

Skupiamy się na technikach, które pozwalają nam zsyntezować informacje. Zawężamy opcje i wybieramy rozwiązanie do dalszej pracy. Skupiamy się na decyzji opartej o wcześniej zebrane dane.

Pomocne techniki:

• Kryteria decyzyjne -> zdefiniowanie kryteriów wyboru i ocena rozwiązań pod ich kątem.

• Ocena zysków Long-Term / Short-Term -> ocena rozwiązań pod kątem wpływu długo i krótkoterminowego na nasz produkt.

• Dot voting -> głosowanie kropkami na najlepsze rozwiązania.

Kluczowe zasady przy wyborze technik:

• Najpierw diverge (otwieramy), potem emerge (analizujemy), na końcu converge (zamykamy).

• Nie mieszamy podejść w jednej technice - większość osób nie potrafi skakać pomiędzy etapami.

• Dopasowujemy technikę do aktualnego typu niepewności.

Podsumowanie

Opisane wzorce nie są ostateczną instrukcją - to dopiero początek systematycznego podejścia do pracy z niepewnością. Wykorzystaj je jako punkt startowy do odkrywania jakie techniki najlepiej sprawdzają się w Twoim zespole.

A Ty, jakie masz podejście do wyboru technik?

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:

1. Wykrywanie nierealnych założeń

   • Było: Problemy wychodzą dopiero podczas implementacji.

   • Jest: Wyłapujemy je na etapie dyskusji i planowania.

2. 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.

3. Alternatywne rozwiązania

   • Było: Programiści dostają gotową specyfikację do implementacji .

   • Jest: Uczestniczą w dyskusji i proponują prostsze podejścia.

4. 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 Boiling Frogs 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.

Ale to nie wystarcza, by szybciej dostarczać wartość klientom.

Build -> Build -> Build

W wielu zespołach panuje przekonanie, że najważniejsze to jak najszybciej dowieźć kod na produkcję. I teoretycznie wszyscy są zadowoleni - przecież dostarczamy! Jednak to podejście ma jeden zasadniczy problem - kompletnie pomijamy kwestię tego, po co w ogóle to robimy.

A to prowadzi do typowych problemów w zespołach produktowych:

• Dostarczamy funkcję, ale nie wiemy co chcemy przez nią osiągnąć - więc nie wiemy czy nam się udało.

• Mierzymy wszystko jak leci, co sprawia, że w zasadzie nie mierzymy niczego konkretnego.

• Nie mamy zdefiniowanego czasu, po jakim oceniamy sukces - przez co zapominamy sprawdzić efekty.

• Nie wiemy jak określić czy funkcja się przyjęła, czy jednak nie.

• Interesariusze kłócą się, czy osiągnięto sukces czy nie.

W efekcie marnujemy czas na funkcje, które nie przynoszą wartości. Stajemy się chomikiem w kołowrotku - więcej funkcji -> więcej funkcji -> więcej funkcji.

Build -> Measure -> Learn

Właściwe podejście powinno być zbliżone do Build -> Measure -> Learn:

• Buduj - Dostarcz określone rozwiązanie.

• Mierz - Sprawdź jak to działa, czy się podoba klientom.

• Ucz się - Podejmuj decyzje w oparciu o faktyczne zachowania twoich użytkowników

Wtedy faktycznie potwierdzamy, że dowieźliśmy wartość dla naszych klientów.

A więc jak tego dokonać?

Cele i miary sukcesu

Wszystkie opisywane elementy znajdziesz na tablicy Miro, którą wykorzystywaliśmy w poprzednim artykule. Będziemy się do niej odwoływać również w kolejnych punktach, więc zachęcam do zerkania na nią podczas czytania:
https://miro.com/app/board/uXjVLF0JQGE=/

Aby dostarczyć wartość, musimy jasno określić czego oczekujemy po naszym rozwiązaniu. Skupiamy się na wpływie naszego rozwiązania na klientów i sposobach mierzenia ich zachowania.

Na tym etapie warto zdefiniować:

• Cel i grupę docelową - co chcemy osiągnąć i dla kogo to robimy.

• Metryki potwierdzające sukces - jasno określone wskaźniki pokazujące, że nam się udało.

• Kryteria sukcesu i porażki - przy jakich wartościach uznamy, że warto kontynuować, lub trzeba się zwijać

• Sygnały ostrzegawcze - jak wykryjemy, że rozwiązanie pogarsza inne funkcje (np. kanibalizacja innych produktów).

• Czas oceny - po jakim okresie sprawdzimy efekty (tydzień? miesiąc? kwartał?).

Zadania już na początku

Za późno myśleć o mierzeniu, gdy już coś wdrożyliśmy. Nie będziemy mieć historycznych danych, nie będziemy wiedzieć jak było "przed". Dlatego kluczowe jest zaplanowanie metryk jeszcze przed rozpoczęciem prac programistycznych.

Rozpocznij od określenia:

• Jakie punkty procesu musimy monitorować.

• Gdzie w kodzie wysyłać zdarzenia analityczne.

• Które metryki techniczne są dla nas istotne.

• Jakie dashboardy musimy przygotować.

• Kto będzie korzystał z tych informacji.

W ramach tego planowania nie możemy zapomnieć o obsłudze niestandardowych scenariuszy:

• Jak wykryjemy problemy z działaniem rozwiązania.

• Co zrobimy, gdy liczby znacząco odbiegną od normy.

• Kogo powiadomić w przypadku wykrycia anomalii.

• Jakie raporty będą wymagane do analizy problemów.

• W jaki sposób cofniemy/naprawimy błędne działanie.

O wadze automatyzacji zbierania danych pisałem w artykule o
[obserwowalności](https://newsletter.radekmaziarka.pl/p/
obserwowalnosc). Im więcej zautomatyzujemy na starcie, tym mniej czasu stracimy na ręczne zbieranie danych. A to przełoży się na szybszą reakcję, gdy coś pójdzie nie tak.

Ocena wdrożonych rozwiązań

Na samym końcu pętli Build->Measure->Learn, jest Learn. Samo uruchomienie rozwiązania nie jest jeszcze sukcesem - to dopiero początek faktycznej weryfikacji. Teraz kluczowe jest sprawdzenie czy nasze założenia się sprawdziły i czy dostarczyliśmy wartość.

Jak uporządkować ocenę rozwiązania? Warto użyć prostej tablicy kanban:

• Waiting - rozwiązania, które "wygrzewają się" na produkcji, czekając na zebranie odpowiedniej ilości danych.

• To Assess - gotowe do oceny, mamy już wystarczająco dużo informacji by podjąć decyzję.

• Success - To Expand - rozwiązania, które spełniły założone kryteria i można planować ich rozwój.

• Failure - To Assess - funkcje, które nie spełniły oczekiwań - do decyzji czy naprawiamy, czy jednak wycofujemy.

Taka wizualizacja pomaga zespołowi aktywnie zarządzać oceną wdrożonych rozwiązań. Nie ma sytuacji, że o czymś zapominamy. Widzimy dokładnie które funkcje wymagają naszej uwagi i jakie decyzje musimy podjąć.

Ogólny proces

Sama tablica i metryki to za mało. Trzeba wprowadzić praktyki w życie zespołu. Aby zmiana się zakorzeniła musimy obudować nasze działania praktykami zespołowymi.

Warto wykorzystać istniejące elementy procesu, zamiast dodawać kolejne spotkania:

• Ocena rozwiązań podczas Sprint Review - przechodzimy przez tablicę i oceniamy wdrożone rozwiązania.

• Pole w Jirze określające datę kolejnej oceny rozwiązania.

• Automatyczne przypomnienia na Slacku/Teams o zbliżającym się terminie oceny.

• Automat przesuwający zadania na tablicy, gdy minie określony czas.

• Cykliczny przegląd dashboardów podczas Daily/Weekly.

W poprzednim newsletterze o Value Stream Mappingu pisałem jak ważne jest, by proces był powtarzalny. Tu działamy podobnie - automatyzujemy co się da, a resztę wpinamy w istniejący sposób pracy. Dzięki temu ocena rozwiązań staje się naturalną częścią pracy zespołu, a nie kolejnym ciężarem.

Podsumowanie

Mam nadzieję, że przekonałem Cie, że warto ustalać cele dla dostarczanych rozwiązań. Chcemy szybciej dostarczać nie tylko rozwiązania, ale wartość dla nas i naszych klientów.

Jeśli interesuje Cię ten temat to zerknij na inne materiały, które mogą Ci pomóc:

• Jak tworzyć produkt, a nie zbiór funkcjonalności -

• Product development - 5 przemyśleń - https://radekmaziarka.pl/2021/02/07/product-development-5-przemyslen/

• Cele -> Możliwości -> Rozwiązania - https://newsletter.radekmaziarka.pl/p/cele-mozliwosci-rozwiazania

• Dla klienta – rozwiązane problemy 

• Dla biznesu - więcej $😃 

Jednak szybsze dostarczanie rozwiązania != szybsze dostarczanie wartości. Powód? Nie wystarczy tylko dostarczyć – trzeba jeszcze uruchomić. A przykłady z życia pokazują, jak odmienne to są procesy.  

W ramach rozszerzenia tego artykułu przygotowałem dla Ciebie tablicę Miro. Może być przez Ciebie traktowana jako wstęp do dyskusji o tym, co wymagane jest by uruchomić daną usługę. Będziemy się do niej odnosić dalej, ale jeśli przyszedłeś tylko po to podsumowanie, to link znajdziesz tutaj:  

https://miro.com/app/board/uXjVLF0JQGE=/  

Dostarczenie to dopiero początek 

W wielu zespołach panuje przekonanie, że najważniejsze to napisać kod i wrzucić go na produkcję. Zapominają jednak, że samo wdrożenie nie generuje jeszcze żadnych przychodów. 

Skupianie się jedynie na rozwiązaniu prowadzi do typowych problemów operacyjnych: 

• Kod jest gotowy, ale czekamy tydzień na tłumaczenia. 

• Nikt nie wie, jak skonfigurować nową funkcję na produkcji. 

• Brakuje kluczy do systemu zewnętrznego, bo nikt o nie nie zapytał. 

• Uruchamiamy testowo i nie wiemy, jak zweryfikować, czy działa, jak powinno. 

• Support nie wie, jak wprowadzić klienta w nowe rozwiązanie. 

Każdy z tych problemów znacząco opóźnia moment, w którym rozwiązanie zacznie faktycznie działać (i zarabiać) 

Szersza perspektywa 

Aby dostarczać realną wartość, musimy zacząć od zmiany podejścia do procesu uruchamiania. Sam development to tylko jeden z etapów na drodze do sukcesu. Po nim następuje jeszcze uruchomienie ze wszystkimi dodatkowymi działaniami.  

W newsletterze "Value-Stream Mapping" opisywałem, jak wykorzystać tę technikę by zidentyfikować wszystkie etapy procesu: 

• Przygotowanie środowiska i konfiguracji 

• Development i weryfikacja jakości 

• Zgody i certyfikaty zewnętrzne 

• Tłumaczenia i treści do publikacji 

• Testy na produkcji z małą grupą klientów 

• Szkolenia dla supportu i dokumentacja 

• Właściwe uruchomienie na podstawie metryk 

Dopiero obserwując cały ten proces, dostrzeżemy prawdziwe koszty pracy. Development to z reguły tylko jego ułamek. Pozostałe działania, takie jak konfiguracja, testy czy szkolenia, nierzadko zajmują nawet więcej czasu i zasobów. Dopiero uwzględniając te wszystkie aspekty, jesteśmy w stanie realnie oszacować czas potrzebny do uruchomienia danej funkcji. 

Warto też zauważyć, że etapy te nie zawsze następują po sobie sekwencyjnie. Wiele rzeczy możemy wykonywać równolegle - na przykład tłumaczenia mogą powstawać w trakcie developmentu. Dzięki takiemu podejściu skracamy całkowity czas dostarczenia wartości.  

Co warto brać pod uwagę od początku 

Aby uniknąć przykrych niespodzianek podczas uruchamiania, warto na starcie przeprowadzić dokładną analizę wymagań. Przygotowałem dla Was tablicę Miro, którą możecie wykorzystać do przeprowadzenia takich warsztatów z zespołem. Poniżej znajdziesz szybką ściągawkę - kluczowe obszary wraz z pytaniami, które warto sobie zadać. 

Konfiguracja i parametryzacja 

• Jakie flagi feature'owe będą potrzebne? 

• Które parametry muszą być konfigurowalne per środowisko? 

• Jak będziemy zarządzać konfiguracją dla różnych rynków? 

• Kto ma mieć dostęp do zmiany konfiguracji? 

Wymagane zgody i certyfikaty 

• Jakie zgody regulacyjne są wymagane? 

• Ile czasu potrzebujemy na uzyskanie certyfikatów? 

• Kto w organizacji może nam pomóc w procesie certyfikacji? 

• Jakie dokumenty musimy przygotować? 

Systemy zewnętrzne 

• Jak uzyskać dostęp do środowisk testowych i produkcyjnych? 

• Jakie są limity API i koszty wykorzystania? 

• Jak przeprowadzić testy integracyjne? 

• Jak monitorować działanie integracji? 

Tłumaczenia i treści 

• Jakie treści marketingowe musimy stworzyć? 

• Jakie treści aplikacyjne wymagają tłumaczenia? 

• Które rynki obsługujemy w pierwszej kolejności? 

• Kto tworzy i zatwierdza tłumaczenia? 

• Czy potrzebujemy nowych assetów graficznych na dany rynek? 

Analityka biznesowa 

• Jakie metryki biznesowe mierzymy? 

• Gdzie w kodzie musimy wysyłać dodatkowe informacje? 

• Jakich dodatkowych raportów potrzebujemy? 

Obserwowalność techniczna 

• Jakie metryki techniczne dodajemy? 

• Które procesy wymagają szczególnego monitoringu? 

• Jakie dodajemy dodatkowe logi ? 

• Jakie alerty konfigurujemy? 

Obsługa klienta i procesy operacyjne 

• Jakich narzędzi potrzebuje support? 

• Jak przebiega proces szkoleń? 

• Gdzie dokumentujemy procesy operacyjne? 

• Jak obsługujemy zgłoszenia błędów? 

• Kto jest pierwszą linią wsparcia? 

Komunikacja z klientem 

• Jakich szablonów wiadomości potrzebujemy? 

• Kiedy wysyłamy powiadomienia? 

• Kto odpowiada za treść komunikatów? 

Testy i walidacja 

• Jak testujemy na produkcji? 

• Która grupa użytkowników testuje jako pierwsza? 

• Jakie są kryteria sukcesu testów? Kiedy mówimy, że nie startujemy? 

• Kiedy podejmujemy decyzję o pełnym rolloucie? 

Czy dzięki temu szybciej dostarczamy wartość? 

Można odpowiedzieć po matematycznemu, że: 

To jest warunek konieczny, ale nie wystarczający, by szybciej dostarczać wartość 

Ponieważ to, że coś szybciej uruchomimy, wcale nie oznacza, że dostarczyliśmy wartość 🤯 

Ale o tym będzie już w kolejnym odcinku. 

Twoja lista uruchamiania 

Powyższy materiał jest w zamyśle podręcznym wstępem do dyskusji, który możesz wykorzystać w swoim obszarze biznesowym. Każdy produkt jest inny i ma inne kryteria uruchomienia. Ale trzeba o nich mówić publicznie, by zacząć je optymalizować. 

Jest coś jeszcze, co sprawdzasz przy uruchomieniu? Daj znać w odpowiedzi / komentarzu 👇