Donald Reinertsen - autor The Principles of Product Development Flow i jeden z najważniejszych myślicieli w historii product developmentu - otwiera swoją książkę od stwierdzenia, które powinno wisieć w ramce w gabinecie każdego CPO i VP of Engineering:
„Dominujący paradygmat zarządzania rozwojem produktów jest błędny. Nie trochę błędny - błędny u samych fundamentów."
A potem tłumaczy dlaczego: niewidzialne i niezarządzane kolejki są główną przyczyną słabej wydajności product developmentu. Nie brak kompetencji. Nie złożoność techniczna. Nie niewystarczająca liczba ludzi. Kolejki - czyli praca, która czeka zamiast płynąć.
Po ponad 20 latach pracy i 60+ organizacjach - od startupów po firmy z setkami inżynierów - mogę powiedzieć jedno: Reinertsen ma rację. I skala problemu jest większa, niż większość liderów sobie wyobraża.
A jeśli myślisz sobie „eee… nieprawda, moi ludzie nie mają przestojów" - to tym bardziej polecam doczytać dalej. Bo zajętość ludzi i przepływ pracy to dwie różne rzeczy. I właśnie ta pierwsza pogłębia problem z drugą.
Rachunek, który zmienia perspektywę
Żeby zrozumieć o czym mówię, zróbmy prosty rachunek. Weźmy typowy feature w typowej organizacji wielozespołowej.
Rzeczywista praca - analiza, design, kodowanie, testowanie, deploy - zajmuje powiedzmy 10 dni roboczych. Ale po drodze ten feature czeka: 5 dni w kolejce do zespołu analizy, 7 dni na research UX-owy, 5 dni na decyzję Product Managera, 5 dni na code review, 4 dni na walidację data analityka, 4 dni na deploy window. Łącznie: 10 dni pracy + 30 dni czekania = 40 dni czasu kalendarzowego. Efektywność przepływu? 25%.
I to jest jeszcze optymistyczny scenariusz. W wielu organizacjach, z którymi pracuję, proporcja jest dużo gorsza - bliżej 15-25% pracy vs. 75-85% czekania. Dwa miesiące kalendarzowe na coś, co wymaga dwóch tygodni realnej pracy.
Ale uwaga - teraz najważniejsze. Gdybyście „przyspieszyli" pracę nad featurem o 20% (z 10 do 8 dni), skrócilibyście całkowity czas realizacji o… 2 dni. Z 40 do 38. Ledwie zauważalna zmiana. Ale gdybyście skrócili czas czekania o połowę (z 30 do 15 dni), całkowity czas realizacji spada z 40 do 25 dni. Prawie 40% szybciej.
Dźwignia nie leży w szybszej pracy. Leży w mniejszym czekaniu.
To jest dokładnie to, co Reinertsen opisuje jako zasadę E5 - Inactivity Principle: nie koncentruj się na przyspieszeniu aktywności, koncentruj się na redukcji przestojów. Większość organizacji robi odwrotnie - szuka sposobów, żeby ludzie pracowali szybciej i więcej, zamiast pytać, dlaczego praca tyle czeka.
I pisze coś jeszcze bardziej niepokojącego: zaledwie 2% organizacji produktowych mierzy swoje kolejki, a tylko 15% zna koszt opóźnienia (Cost of Delay). Skoro prawie nikt nie mierzy tego, co naprawdę spowalnia delivery - nie powinno dziwić, że kolejki rosną niezauważone.
Co mówi na ten temat badawcza literatura
W 2017 roku Todd Sedano, Paul Ralph i Cécile Péraire opublikowali wyniki ponad dwuletniego badania w Pivotal Software - jedno z najciekawszych badań, jakie znam w tej przestrzeni. Przez dwa lata i pięć miesięcy obserwowali osiem projektów, przeprowadzili 33 wywiady z inżynierami, designerami i product managerami, i przeanalizowali rok danych z retrospekcji.
Efektem była pierwsza empiryczna taksonomia marnotrawstwa w software developmencie, opublikowana na IEEE/ACM International Conference on Software Engineering. Zidentyfikowali dziewięć typów marnotrawstwa (waste), a wśród najbardziej destrukcyjnych znalazły się:
- handovers (przekazywanie pracy),
- waiting (czekanie),
- knowledge loss (utrata wiedzy),
- ineffective communication (nieefektywna komunikacja).
To nie są oddzielne problemy. To elementy tego samego systemu.
Poppendieckowie: wiedza, która ginie przy każdym przekazaniu
Mary i Tom Poppendieck w Lean Software Development opisali coś, co każdy z nas intuicyjnie czuje, ale rzadko nazywa: za każdym razem, gdy praca przechodzi od jednej osoby do drugiej - od Product Managera do UX Designera, od UX-a do developera, od developera do data analityka, od analityka z powrotem do PM-a - ginie wiedza ukryta (tacit knowledge).
Dokumenty i specyfikacje mogą przenieść fakty - co trzeba zbudować, jakie są wymagania. Ale olbrzymia część kontekstu - dlaczego podjęto pewne decyzje, jakie alternatywy rozważano, jakie warunki brzegowe trzeba mieć na uwadze, co próbowano i nie zadziałało - ginie przy każdym przekazaniu. To jest jak gra w „głuchy telefon": im więcej ogniw, tym mniej z oryginalnego przekazu dociera na koniec.
Badacze z Pivotal potwierdzili to empirycznie: utrata wiedzy (knowledge loss) to jeden z dziewięciu typów waste, który powtarzał się projekt po projekcie. A koszt nie polega tylko na utracie informacji — polega na koszcie jej odtworzenia, co prowadzi do przeróbek (rework), błędnych założeń i opóźnień.
Zastanawiałeś się może skąd w firmie tyle spotkań "alignmentowych"? Retoryczne pytanie :)
Dlaczego typowa odpowiedź organizacji pogarsza sytuację
OK, więc mamy problem. Delivery jest za wolny. Co robi większość firm?
Dodaje kolejne zasady do procesu wytwarzania. Tworzy więcej spotkań „alignmentowych". Tworzy więcej dokumentacji. Więcej bram jakości. Więcej rytuałów koordynacyjnych. Więcej narzędzi do śledzenia zależności.
A potem zastanawia się, dlaczego jest jeszcze wolniej.
„No ale Krzysiek, przecież nie możemy pozwolić, aby pracownicy siedzieli i czekali. Jeśli jest przestój, to niech biorą się za kolejne zadania."
Słyszę to regularnie u moich klientów. I za każdym razem myślę o Reinertsenowskiej analogii z autostradą: autostrada do 70% obciążenia płynie gładko. Później do 95% - ruch przerywany stop-and-go. Przy 100% - masz parking.
Im bardziej „optymalizujesz" system pod zajętość ludzi (resource efficiency), tym bardziej spowalniasz przepływ pracy (flow efficiency). Masz coraz więcej otwartych tematów (WIP - work in progress) i... coraz bardziej niedostępnych ludzi.
To jest ten sam błąd, o którym pisałem w artykule o grze w szachy warcabami. Organizacje optymalizują złą rzecz - zajętość ludzi zamiast przepływu wartości. Cóż... Russell Ackoff, pionier myślenia systemowego, ujął to celnie: „Im lepiej robimy rzecz niewłaściwą, tym bardziej błądzimy."
Potwierdzenie z programu badawczego DORA
Program badawczy DORA (DevOps Research and Assessment) - wieloletni, obejmujący ponad 32 000 profesjonalistów - daje nam kolejne mocne potwierdzenie. Badania opisane w Accelerate (Forsgren, Humble, Kim) pokazują, że organizacje o najwyższej wydajności (tzw. elite performers) konsekwentnie łączą pewne cechy:
- deployment wiele razy dziennie,
- lead time poniżej jednego dnia,
- niski change failure rate,
- szybki czas naprawy.
Co ciekawe, raport DORA nie mówi: „zatrudnijcie szybszych programistów". Mówi o elementach organizacyjnych odblokowujących przepływ i dopiero na tym bazujących praktykach, tj. zespoły e2e, CI/CD (chodzi o zachowanie developera - kodujesz-integrujesz w krótkich cyklach), trunk-based development (brak branchy), loosely coupled architecture, empowered teams. To wszystko są cechy strukturalne - cechy systemu pracy, nie indywidualnych talentów.
Z mojego doświadczenia, organizacje, które konsekwentnie osiągają takie parametry, mają jedną wspólną cechę: poprzez zmianę konstrukcji systemu organizacyjnego zminimalizowały liczbę przekazywań (handovers), kolejek koordynacyjnych i lokalnych backlogów w swoim systemie pracy. Co spowodowało właśnie bardzo wysoką responsywność, adaptacyjność i zdolność do realizacji najbardziej wartościowych prac (globalnie) w super krótkim Lead-Time. I to wszystko nie dlatego, że ludzie pracują szybciej. Dlatego, że praca mniej czeka.
Modern Waterfall - stary problem w nowym opakowaniu
Ale jest jeszcze jeden problem, który widzę coraz częściej - i jest szczególnie zdradliwy, bo wygląda nowocześnie.
Organizacja tworzy osobny dział Product Managerów. Osobny dział Discovery. Osobny dział UX. Osobny zespół Data Analysts. Każdy z tych działów ma swojego managera, swoje cele, swoje priorytety, swoją kolejkę pracy. Na papierze wygląda to jak „nowoczesna organizacja produktowa". W praktyce jest to waterfall z nowymi nazwami stanowisk.
Bo mechanizm jest dokładnie ten sam: praca przechodzi sekwencyjnie od jednego silosu do drugiego. Discovery „przekazuje" wyniki do UX-u. UX „przekazuje" projekty do developmentu. Development „przekazuje" do QA. Data Analysts czekają na swoją kolej, żeby zwalidować to, co już dawno powinno było trafić do użytkowników.
Na każdym przekazaniu - kolejka. Na każdej kolejce - utrata kontekstu. Na każdej utracie kontekstu - rework.
Reinertsen opisuje to precyzyjnie: to nie jest problem ludzi ani ich kompetencji. To jest problem struktury systemu organizacyjnego, a w nim przepływu pracy. Kiedy organizujesz ludzi w funkcjonalne silosy, w grupy "ekspertów" - nieważne jak nowoczesne nazwy im nadasz - tworzysz kolejki. A kolejki dominują nad czasem cyklu (Cycle-Time). Zawsze.
Co naprawdę działa: eliminacja handoverów, nie ich optymalizacja
Odpowiedzią na problem koordynacyjny nie jest menedżer ds. koordynacji, ani lepsze praktyki koordynacji. Odpowiedzią jest eliminacja potrzeby koordynacji.
Jak? Przez zmianę systemu, w ktorym praca przepływa między ludźmi.
1. Zespoły cross-funkcjonalne i cross-komponentowe (czyli e2e)
Zamiast przekazywać pracę między działem discovery, działem UX, działem rozwoju, działem data analytics i działem operacji - połącz te kompetencje w jednym zespole, pracującym na jednym produkcie. To nie jest nowy pomysł - to fundament Lean Software Development i ruchu DevOps. Ale zaskakująco mało organizacji faktycznie to robi - nawet te, które twierdzą, że działają „produktowo". Często widzę UX, Data Analityków, DevOps na zewnątrz zespołów, a ten „okrojony z kluczowych kompetencji" zespół organizacje nazywają cross-funkcyjnym. Przestańmy się oszukiwać.
Kiedy Product Manager, UX Designer, developer i data analityk pracują razem nad tym samym problemem od discovery po delivery - handover nie istnieje. Nie trzeba pisać obszernego briefu discovery, bo developer uczestniczył w rozmowach z użytkownikami. Nie trzeba pisać osobnej specyfikacji UX, bo designer siedzi z zespołem i iteruje w czasie rzeczywistym. Nie trzeba czekać w kolejce do data analityka, bo analityk jest częścią zespołu i waliduje hipotezy na bieżąco. Zresztą… to nie role, ale kompetencje. Cały, szeroko kompetencyjnie zespół dokonuje samodzielnie wszystkich czynności ciągłego Discovery & Delivery - szybko i sprawnie ucząc się wartości produktu i podejmując decyzje dotyczące rozwoju produktu boostujące wskaźniki biznesowe.
Ponadto każdy zespół jest zespołem cross-komponentowym, czyli może dokonać zmiany w każdym technicznym komponencie, który musi być zmieniony, aby dany feature się wydarzył - bez zlecania „ticketu" do zespołu będącego właścicielem komponentu. Dlaczego? Po raz kolejny - kolejki/czekanie. A jeśli właśnie w Twojej głowie pojawiła się wątpliwość „Krzysiek, jak każdy będzie grzebał wszędzie, to dopiero będzie chaos!", to rzuć okiem jak to się robi w open-source. W firmie chcemy mieć właśnie wewnętrzny „open-source" - kod dostępny dla każdego developera.
To jest podejście, które w branży znamy jako concurrent development: discovery, design, kodowanie, testowanie i walidacja danych dzieją się równolegle, nie sekwencyjnie. Feature, który w modelu Modern Waterfall zajmował dwa miesiące (nie dlatego, że tyle trwała praca, ale dlatego, że tyle trwało czekanie w kolejkach między silosami) - może być dostarczony w ciągu dwóch tygodni.
Ci sami ludzie. Te same kompetencje. Radykalnie inny sposób przepływu pracy.
2. Mniej pracy w toku, szybszy feedback
Reinertsen wykazał w swoich pracach, że zmniejszenie wielkości paczek pracy (batch size) jest jednym z najskuteczniejszych sposobów na poprawę przepływu. Małe partie pracy → szybszy feedback → mniejsze ryzyko → mniej przeróbek → więcej wartości szybciej. Czy teraz już wiesz, dlaczego chcemy dzielić te „Historyjki użytkownika"? Duża paczka pracy (duży Feature/Epic) to także ukryta kolejka, która przez długi czas trzyma w zajętości (i niskiej dostępności) osoby, które tą pracą się zajmują. A jak ktoś inny teraz czeka na tych, co są aktualnie zajęci, to co robi? No tak… zaczyna kolejne zadanie. WIP rośnie dramatycznie.
Ograniczenie pracy w toku (WIP) to uzupełnienie w/w strategii. Kiedy zespół pracuje nad jedną/dwiema rzeczami jednocześnie zamiast dziesięcioma - focus rośnie, a praca faktycznie przepływa zamiast stać w kolejkach. Badania Rubinsteina, Meyera i Evansa z University of Michigan (2001), publikowane w Journal of Experimental Psychology, wykazały mierzalne koszty cognitive switching - APA (American Psychological Association) szacuje, powołując się na te badania, że przełączanie się między zadaniami może kosztować do 40% produktywnego czasu. Nawet jeśli ta liczba jest górną granicą - implikacja jest jasna:
Multitasking i wysoki WIP to iluzja produktywności.
3. Continuous Delivery zamiast dużych release'ów
Program DORA jednoznacznie pokazał: organizacje, które deployują często (wiele razy dziennie), mają jednocześnie szybszy delivery i wyższą stabilność (mniej błędów!). To nie jest kompromis - prędkość vs. jakość. Elite performerzy osiągają jedno i drugie, bo małe, częste zmiany są łatwiejsze do zrozumienia, łatwiejsze do testowania i łatwiejsze do naprawienia, gdy coś pójdzie nie tak.
Duże, rzadkie release'y to batchowanie marnotrawstwa. Każdy duży release to ogromna kolejka zmian czekających na deploy, ogromne ryzyko integracyjne i ogromny koszt naprawy, gdy coś się zepsuje. Reinertsen poświęca temu zagadnieniu dużo miejsca w swojej książce - i trudno się z nim nie zgodzić.
Na koniec
Zadaj sobie pytanie:
Jaki procent czasu Twoich zespołów jest poświęcony na czekanie na kogoś innego?
Jeśli nie znasz odpowiedzi - to jest Twój pierwszy problem do rozwiązania. Kolejki są główną przyczyną problemów z delivery.
Zmierz. Zrozum. Zmień system.
Jeśli chcesz porozmawiać o tym, jak mogłaby wyglądać eliminacja marnotrawstwa koordynacyjnego w Twojej organizacji - zapraszam na bezpłatną konsultację. Bez zobowiązań, z konkretem.
Źródła
- Reinertsen, D.G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.
- Sedano, T., Ralph, P., Péraire, C. (2017). Software Development Waste. IEEE/ACM 39th International Conference on Software Engineering (ICSE).
- Poppendieck, M., Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley.
- Forsgren, N., Humble, J., Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
- Rubinstein, J.S., Meyer, D.E., Evans, J.E. (2001). Executive Control of Cognitive Processes in Task Switching. Journal of Experimental Psychology: Human Perception and Performance, 27(4), 763–797.
- DORA / Google Cloud - Accelerate State of DevOps Report 2024. dora.dev.
- Kim, G., Humble, J., Debois, P., Willis, J., Forsgren, N. (2021). The DevOps Handbook: Second Edition. IT Revolution Press.
Krzysztof Niewiński - Transformation Manager & Product Coach, ProductOrg.com Pomagam firmom budować wielozespołowy Model Produktowy, który skraca czas od pomysłu do wartości.