Nierówna walka

Discovery i delivery w kontekście IT to zbyt często rozłączne procesy. Dojrzałe zespoły łączą je w Dual‑Track Agile: równoległe tory discovery (hipotezy, badania, testy) i delivery (implementacja zweryfikowanych rozwiązań) w jednym nurcie.

W zależności od dojrzałości organizacji planujemy kwartał, rok lub tydzień i realizujemy. Przez lata w wielu korporacjach dominowało podejście, planuj i działaj, ale równolegle – już od lat 90. – rozwijały się metody iteracyjne i zwinne (Scrum, XP, RUP). Dzisiejsze praktyki to efekt stopniowej ewolucji, nie nagłej rewolucji.

Nikogo nie zdziwi, że “klasyczny waterfall” był szeroko stosowany:

• budujemy plan strategiczny, często oparty o biznesplan
• analitycy przygotowują analizy i specyfikacje
• plan trafia do zespołów technicznych
• najpierw design, potem backend, frontend
• na koniec testy

Lub alternatywnie w mniejszych firmach:

• Szef mówi, co chce zbudować
• Menedżerowie rozpisują zadania
• Programiści realizują
• Mija kolejny miesiąc
• “Projekt został wykonany”

Oba podejścia zakładają, że plan nie ma luk lub że luki nie wpłyną na termin i wartość.

No i kiedy to zadziała? A kiedy nie do końca?

Menedżerowie i eksperci - w IT i w produkcji - zauważyli, że brak pętli zwrotnych generuje koszty.
Przykładowo, normy wydajności maszyn zmieniają się, gdy uwzględnimy przeglądy i naprawy, tak samo gdy ilość wyprodukowanego kodu maleje gdy kod nie przejdzie finalnych testów.

W IT na początku lat 2000 upowszechniło się Agile, a około 2010 – praktyki, które dziś nazywamy DevOps. Warto doprecyzować: Trzy Drogi (Flow, Feedback, Continuous Learning) zostały spopularyzowane w The DevOps Handbook.

Na rynku oprogramowania założenia środowisk i rynku szybko się zmieniają. Jeśli wydajemy coś po paru miesiącach pisania kodu i to coś jest oparte na starych założeniach, rynek mógł już odjechać – i produkt automatycznie traci sens.

Jak poszliśmy krok dalej? Agile i kultura DevOps

Zeszliśmy z rocznych cykli na miesięczne, tygodniowe, a nawet dzienne integracje. Ale trup w szafie wielu organizacji to discovery – pozostaje kwartalnym wydarzeniem albo nie istnieje w praktyce.

3 filary DevOps

• Pierwsza Droga: Flow – myślenie systemowe i przyspieszanie przepływu od stworzonego zadania przez pisanie kodu, aż do wartości dla klienta
• Druga Droga: Feedback – skracanie i wzmacnianie pętli zwrotnych (Code Review, Pair Programming)
• Trzecia Droga: Continuous Learning and Experimentation – kultura eksperymentów i nauki

Agile oraz wdrożenie praktyk takich jak CI/CD, trunk‑based development pomaga w Flow i Feedback, ale to nie wystarczy.
Pełna realizacja wymaga też praktyk produktowych i przejrzystego ładu decyzyjnego. Najtrudniejsze bywa wpięcie eksperymentowania w rytm pracy, zamiast ad hoc “kwartalnych narad”, które można określić jako top-down.

Zamiast top‑down, czyli zrzucania wielkich inicjatyw pod szyldem OKR, lepiej przenieść decydowanie bliżej problemu.
Jak pisał Marty Cagan:

If you’re using your developers for only coding, you’re only getting about half their value.

W praktyce znaczy to tyle, że to deweloperzy razem z produktowcami i designerami mają prowadzić ciągłe eksperymenty, tydzień w tydzień.

Ciągłe sesje discovery

Na początku discovery ma właściciela (PM/lead). Docelowo staje się elementem kultury samozarządzającego się zespołu.

Zamiast angażować 20 osób naraz i ulegać HiPPO (Highest Paid Person’s Opinion), pracujmy w małych zespołach discovery.

Metody i kiedy je stosować:

• Opportunity Solution Tree – gdy rezultat jest jasny, a sposobów na osiągnięcie ich jest wiele, porządkuje hipotezy i eksperymenty
• User Story Mapping – dobry wstęp do konwersacji o problemach biznesowych, pomaga w ułożeniu problemów klientów
• Domain Storytelling (lub Event Storming)  – gdy domena jest złożona i trzeba wykonać transfer wiedzy od interesariuszy do zespołu

Mały zespół (3–5 osób) składający się z produktowca, menedżera, programistów i designerów, prowadzi wywiady i testy, a następnie raportuje reszcie zespołu w formie:

• wyniki wywiadów
• hipotezy do testów wynikające z Opportunity Solution Tree
• zmapowane historyjki i przepływy

Postaraj się ograniczyć WIP i przeglądać artefakty co 1–2 tygodnie.

Na retro analizujemy, gdzie discovery nie zadziałało; rotujemy ludzi w pod-zespole discovery co 2–4 tygodnie.

Eksperymenty oparte na testach założeń

Lean Startup, BMC, OST i Customer Journey Mapping pomagają wnieść testowanie hipotez do codziennej pracy. Projektujemy testy pod decyzję i z guardrails.

Przykład
Chcemy sprawdzić, czy ludzie nadal chcą kupować ręcznie robione meble. Zamiast budować cały e‑commerce i logistykę, w 2 tygodnie i za 2 000 PLN weryfikujemy:

1. Hipoteza rynkowa: “Jest popyt w naszym regionie”

   • Test: landing zapisami do newsletter’a
   • Reguła: go, jeśli zarejestrowało się conajmniej 200 osób
   • Metryki decyzyjne: ilość zapisanych do newsletter

2. Hipoteza wartości/ceny: “Klienci zapłacą premium”

   • Test: pre‑order mebli
   • Reguła: go, jeśli osiągneliśmy co najmniej 10 zamówień pre-order
   • Metryki: intent‑to‑pay

3. Hipoteza kanału: “Kanał X jest efektywny”

   • Test: mini‑kampanie w 2–3 kanałach (social, marketplace, lokalny event)
   • Reguła: wybieramy kanał w którym koszt akwizycji klienta nie będzie przekraczał 10 zł
   • Metryki: Kosz pozyskania klienta

4. Hipoteza podaży: “Dowieziemy jakość i termin”

   • Test: 5 próbnych realizacji; mierz time‑to‑fulfill i scrap rate
   • Pre‑mortem: opóźnienia, zwroty, kontrola jakości

Guardrails: limit WIP eksperymentów, standardy etyczne i prywatności, minimalne próby, log decyzji (go/kill/pivot lub ADR). Unikamy metryk próżności (np. “czas na stronie”) jako podstawy decyzji.

Zaczynajmy od wyniku

W podejściu Discovery + Delivery startujemy od jasno zdefiniowanego wyniku, nie funkcjonalności.

Hierarchia rezultatów:

• North Star Metric – główny rezultat
• Sub‑outcomes – np. retencja, aktywacja, konwersja
• Wskaźniki wspierające – np. liczba zgłoszeń do supportu

Dla każdego outcome’u określ baseline, target i horyzont czasu.
Outcome powinien odzwierciedlać wartość dla klienta i prowadzić do wyniku biznesowego. Następnie identyfikujemy problemy/szanse i generujemy rozwiązania jako hipotezy do weryfikacji, np. “Milenialsi chcą kupować ręcznie tworzone meble.”

Co możemy z tego wynieść?

Integracja discovery z delivery w Dual-Track nie jest opcjonalna – w dzisiejszym tempie zmian to konieczność.

Kluczowe zasady do wdrożenia:

1. Nie bazuj tylko na pionie produktowym – zintegruj członków zespołu i interesariuszy we wspólnym discovery
2. Małe, ciągłe eksperymenty – cotygodniowe testy hipotez zamiast wyłącznie wielkich inicjatyw kwartalnych
3. Wyniki nad funkcjonalnościami – każda praca dev musi mieć powiązanie z mierzalnym outcome’em
4. Krótkie pętle zwrotne – minimalnie tygodniowy kontakt z użytkownikami; dąż do mikro‑testów
5. Kultura eksperymentowania – porażki traktuj jako naukę, nie coś do ukrywania
6. Integracja w sprintach – stały bufor 10–20% pojemności na discovery, osobny tor na tablicy, redukcja długu poznawczego planowana jak technicznego
7. Governance i skala – portfolio kanban, comiesięczny przegląd ryzyk, ADR dla kluczowych decyzji architektonicznych, bramka ethics/compliance przed testami na użytkownikach

Pamiętaj: speed of learning beats speed of building – ale uczenie też kosztuje uwagę, budżet i ryzyko reputacyjne. Minimalizuj koszt wybierając testowanie hipotez zamiast budowania pełnych produktów.

Organizacje, które opanowały tę sztukę, wdrażają kod często, aby skracać pętle informacji zwrotnej – to środek do celu, nie cel sam w sobie.
W domenach regulowanych kadencja będzie inna, ale zasada skracania cykli uczenia pozostaje.

Dla korpo: Jak raportować leadershipowi – 1 slajd miesięcznie:

• Cele: North Star + sub‑outcomes (trend vs target)
• Top 3 hipotezy i decyzje (go/kill/pivot) z krótkim uzasadnieniem
• Wpływ na roadmapę: co wchodzi/wychodzi i dlaczego
• Ryzyka i mitigacje: 1–2 kluczowe, właściciele, terminy

To nie magia – to systematyczne stosowanie zasad “Trzech Dróg” z naciskiem na ciągłe uczenie, eksperymentowanie oraz myślenie produktowe, osadzone w praktykach inżynierskich i lekkim governance.

Lektury uzupełniające

• Marty Cagan — Inspired; Empowered (rozwój produktu, rola zespołów empowered; cytowana teza o wykorzystaniu deweloperów)
• Teresa Torres — Continuous Discovery Habits (ciągłe discovery, Opportunity Solution Tree, rytuały zespołowe)
• David J. Bland, Alexander Osterwalder — Testing Business Ideas (katalog testów hipotez, guardrails, decyzje go/kill/pivot)
• Steve Blank, Bob Dorf — The Four Steps to the Epiphany; The Startup Owner’s Manual (customer development, pętle uczenia)
• Eric Ries — The Lean Startup (MVP, metryki próżności vs metryki decyzyjne)
• John Doerr — Measure What Matters (OKR)
• Gene Kim, Jez Humble, Patrick Debois, John Willis — The DevOps Handbook (Trzy Drogi: Flow, Feedback, Continuous Learning)
• Gene Kim, Kevin Behr, George Spafford — The Phoenix Project (narracyjnie o przepływie i ograniczeniach)
• Jez Humble, David Farley — Continuous Delivery (CI/CD jako narzędzie skracania pętli)
• Nicole Forsgren, Jez Humble, Gene Kim — Accelerate (DORA metrics, naukowe podstawy high‑performing orgs)