Dlaczego warto pracować iteracyjnie i przyrostowo?

Wielokrotnie na szkoleniach w trakcie dyskusji, gdy dochodzimy do wątku limitowania pracy w toku i jak najczęstszego wdrażania wartości biznesowej małymi partiami, kolejni uczestnicy odgrzewają dyskusję, że „nie opłaca się” robić małych wdrożeń i że bardziej ekonomiczne jest wdrażać produkt wielkimi wersjami w dużych odstępach czasu. Każdy kto dłużej popracował zwinnie w porządny sposób i każdy kto zna podstawowe teorie, które udowadniają sensowność częstych wdrożeń małymi partiami, wie, że rzekoma opłacalność rzadkich wdrożeń to złudzenie. Widzę jednak, że o wiele trudniej w takiej sytuacji wyjść z perspektywy własnych doświadczeń praktycznych i sformułować logiczny, spójny i przekonujący wywód, który może przekonać wspomnianego wcześniej nieprzekonanego dyskutanta. W tym artykule, bazując na książce Donalda G. Reinertsena „The Principles of Product Development Flow: Second Generation Lean Product Development”, wymienię 10 powodów, dla których warto dostarczać produkt małymi partiami.

Donald Reinertsen formułuje 10 reguł, które sprawiają, że rozwój produktu w sposób iteracyjno-przyrostowy z wczesnymi i częstymi wdrożeniami ma uzasadnienie ekonomiczne (opłaca się finansowo) i jest efektywny (z tych samych środków pozwala uzyskać lepsze rezultaty).

Redukcja wielkości partii obniża czas cyklu

Jeśli dostarczamy produkt (jego kolejną wersję, jego cechy) w rzadkich wdrożeniach, automatycznie wydłużamy łączny czas przetwarzania zadań, które wchodzą w skład kolejnego wdrożenia. Wyobraźmy sobie prostą hipotetyczną sytuację windy w biurowcu, która odjedzie wyłącznie, gdy wsiądzie do niej 8 osób. Czas przejazdu pierwszych kilku osób będzie wyraźnie dłuższy (muszą czekać na dotarcie kolejnych chętnych pasażerów) a czas ostatnich pasażerów będzie niewiele krótszy albo identyczny, co w scenariuszu alternatywnym, w którym winda rusza z piętra jak tylko przestaną wsiadać do niej pasażerowie (nieważne ilu ich przyszło). Średni czas przejazdu dla windy, która jeździ wyłącznie pełna byłby na tyle długi, że być może poza wyjątkami skrajnymi, niektórzy pasażerowie w ogóle zrezygnują z wsiadania do niej 😉 Przenosząc to na realia rozwoju produktu – jeśli rozwijamy nasze wersje rzadkimi wdrożeniami, to średni czas wytworzenia danego kawałka produktu jest długi. Co ważne, ta reguła działa też w drugą stronę – jeśli obecnie nasze produkty są wytwarzane rzadko, to samym zagęszczeniem częstości wdrożeń uzyskamy lepsze czasy przetwarzania poszczególnych składowych produktu bez jakichkolwiek innych zmian w dostępnych mocach przerobowych.

Częste wdrożenia zmniejszają zróżnicowanie płynności pracy

Kolejnym powodem by wdrażać często małymi kawałkami jest możliwość stabilnej pracy, bez znacznych odchyleń na poziomie intensywności działania zespołu zajmującego się rozwojem produktu. Manifest Zwinnego Wytwarzania Oprogramowania wspomina o zachowaniu równomiernego tempa pracy i jest to kolejny powód, by unikać rzadkich i dużych wdrożeń. Organizacja, która poukładana jest wokół wielkich wdrożeń, nieuchronnie spotyka się z męczącą a może nawet wyniszczającą praktyką domykania wdrożenia (w środowisku twórców gier nazywa się to „crunch time”), czyli za wszelką cenę, kosztem nadgodzin, zdrowia, balansu między życiem zawodowym a prywatnym na siłę próbuje się dokończyć planowany wcześniej zakres wdrożenia, często przy okazji kompromitując jakość produktu albo odcinając w ostatniej chwili niedokończone fragmenty. Z drugiej strony pojawić się też mogą dłuższe okresy przestoju na początku projektu, w czasie którego zespół pracuje na „pół gwizdka”, bo nie ma poczucia w organizacji, by potrzebne było pilne realizowanie prac – np. czeka się na zatwierdzenie jakichś kluczowych wytycznych co do kolejnej wersji albo po prostu uwaga firmy skierowana jest na inne sprawy.

Mniejsze wdrożenia przyspieszają informację zwrotną

W rozwoju produktu ceni się często wizjonerów – osoby, które doskonale wiedzą, co się sprawdzi, mają swój pomysł i uparcie realizują go, wdrażając swoje idee w życie. Pierwsi realni klienci uwielbiają rozczarowywać takich wizjonerów, w najbardziej optymistycznym scenariuszu dając podpowiedzi jak ten produkt mógłby wyglądać lepiej, w najbardziej pesymistycznym po prostu nie kupując tych rozwiązań, które w pocie czoła pod kierownictwem wizjonera zostały wypracowane. Z czysto ekonomicznego punktu widzenia, niezależnie od tego jak przekonani o doskonałości swoich idei produktowych jesteśmy, opłaca się doprowadzać do jak najszybszego walidowania naszych założeń biznesowych i na tej bazie ulepszać kolejne wersje. Rozważmy dwa alternatywne scenariusze, w których osoba odpowiedzialna za produkt przyjęła błędne założenie biznesowe. Jeśli wdrażamy małymi partiami i stosujemy na przykład technikę MVP, to błędna decyzja zostanie szybko wykryta i poprawiona (albo porzucimy rozwój tego produktu kompletnie). Jeśli wdrażamy rzadko, dana błędna decyzja będzie fundamentem do szeregu kolejnych decyzji produktowych, które będą podjęte bez konfrontacji z realiami rynkowymi (co samo w sobie bardzo utrudni wyseparowanie założeń biznesowych błędnych od tych poprawnych, bo będą na siebie wzajemnie oddziaływać). Poniesiemy wyższe koszty rozwoju produktu w błędnym kierunku, a jeśli nie zmienimy częstości wdrażania – to nawet jeśli odkryjemy jak produkt poprawić, to jego lepsza wersja również na rynku będzie bardzo późno. Świetne przykłady z realnego świata biznesu jak można budować MVP i tego, jak bardzo twórcy nawet najbardziej popularnych produktów byli na początku swojej drogi w błędzie opisała jakiś czas temu Iza.

Częste wdrożenia obniżają ryzyko

Powód bardzo powiązany z wywodem z poprzedniego akapitu – jeśli dostaniemy szybko informację zwrotną i na jej bazie dokonamy odpowiednich korekt, zmniejszają się nam ryzyka powiązane z rozwojem produktu (zarówno ryzyka błędnych decyzji jak i ryzyka procesu rozwoju). Dodatkowo ewentualne działania naprawcze również realizowane są szybciej a praca w mniejszych partiach generuje mniej ryzyk związanych z błędnym zarządzaniem, kłopotami z integracją czy nieporozumieniami komunikacyjnymi w zespole produktowym.

Małe wdrożenia to mały narzut organizacyjny

Pierwszy z powodów, który jest argumentem za pracą mniejszymi partiami, ale bywa wyciągany intuicyjnie jako zarzut przeciwko takiemu stylowi, to sugestia „jak będziemy robić dużo (wdrożeń / wersji / małych przyrostów), to się dodatkowo napracujemy przy biurokracji powiązanej z projektami i procesami rozwojowymi w firmie”. Faktycznie nie da się nie zauważyć, że na przykład częstsze wdrożenia mogą oznaczać wykonanie dodatkowych czynności przygotowawczych (kolejne stawianie środowisk, odświeżenia wersji, integracje, testy, prace powdrożeniowe) – nie dostrzegamy jednak, że w rzadkich wdrożeniach masa dodatkowego narzutu organizacyjnego wynika tylko i wyłącznie z faktu ich wielkości. Są to najczęściej dodatkowe spotkania synchronizacyjne, dodatkowe role w organizacji (koordynatorzy, menedżerowie procesu), seria dodatkowych czynności i osobnych kroków by uniknąć ryzyk błędów integracji. Jeśli w organizacji istnieje narzut, który zniechęca do częstych wdrożeń, jest to mocny kandydat do usprawnień i automatyzacji (uzasadnienie biznesowe to zauważalne przyspieszenie realizacji kolejnych inicjatyw produktowych), a nie wymówka, by nie uzyskiwać korzyści z częstych małych wdrożeń.

Rzadkie wdrożenia obniżają wydajność

Kolejny nieintuicyjny argument to rozważania na temat wydajności pracy. Łatwo sobie wyobrazić, że dzięki dłuższym fragmentom nieprzerwanej pracy uzyskujemy w zespole produktowym większe skupienie i dzięki temu wyższą średnią wydajność z każdej przepracowanej jednostki czasu. Pojawia się to na przykład argument typu „jak pracujemy w dwutygodniowych sprintach, to nie mamy na nic czasu, jakbyśmy pracowali w miesięcznych cyklach, zrobilibyśmy więcej!”. Nie uwzględniając już poprzednich argumentów o ryzykach czy korzyściach z szybkiej informacji zwrotnej na temat produktu, zwróćmy uwagę, że nieprzerwana praca długimi okresami czasu to utopia. Realna praca przy rozwoju produktu wymaga interakcji pomiędzy członkami zespołu i częstego podejmowania decyzji ale także współpracy nad zmianą tych decyzji (korekty błędnych decyzji na temat rozwiązania, poprawa jakości, usprawnienie architektury i użyteczności produktu). Podążanie za ideą rzadkiego wdrażania, źle zrozumianej maksymalizacji efektywności każdego członka zespołu i tym samym długich okresów nieprzerwanej pracy może doprowadzić do tego, że zdecydowanie zbyt późno odkrywamy takie błędne decyzje i musimy poprawiać pracę z o wiele dłuższego okresu, wychodzić z bardzo długich ślepych uliczek.

Rzadkie wdrożenia obniżają motywację i poczucie pilności

Temat powiązany z płynnością pracy – w rzadkich, dużych wdrożeniach łatwo o demotywację. Donald Reinertsen zwraca uwagę w książce na dwa rodzaje przyczyn takiej demotywacji. Pierwsza z nich to rozmycie odpowiedzialności – na efekty dużego wdrożenia składa się wiele elementów realizowanych przez wielu ludzi, często rozłożone w czasie. Po kilku miesiącach można zapomnieć kto dokładnie przygotowywał jakiś fragment albo jest on już ściśle połączony z efektami pracy innych osób. Drugi demotywator to odroczenie informacji zwrotnej. Członek zespołu odpowiedzialny za swój kawałek produktu nie wie, czy wykonał dobrą pracę (na każdym możliwym poziomie – jakościowo i biznesowo), bo realne efekty dla klienta i dla firmy będą widoczne bardzo późno. W alternatywnych scenariuszach o wiele prościej o zaangażowanie, jeśli widzimy, że z efektów naszej pracy z ostatniego tygodnia korzystają już klienci i mają pierwsze obserwacje na temat tego co im się podoba i co by jeszcze poprawili. Nawet jeśli uwagi klientów są negatywne, zespół ma doping, by jak najszybciej dokonać korekty i wie, że ewentualne poczucie wstydu zniknie już przy okazji najbliższego wdrożenia.

Rzadkie wdrożenia prowadzą do przekroczenia budżetu i terminu

Ta reguła staje się już – mam nadzieję – wiedzą powszechną: zgodnie z wieloletnimi badaniami takimi, jak CHAOS Report Grupy Standish, rok w rok udaje się udowodnić, że im większy projekt, tym większe prawdopodobieństwo porażki albo opóźnień i przekroczenia kosztów. Podobna reguła funkcjonuje przy rzadkich wdrożeniach – o wiele większe zagrożenie opóźnienia wkrada się do dużych zakresów, choćby z powodu trudności w oszacowaniu większych złożonych zmian. „Ratowanie” rzadkiego wdrożenia często odbywa się kosztem nadgodzin albo dodatkowych zatrudnień a obniżona jakość spłacana jest z wielkimi odsetkami, obniżając tempo pracy nad kolejnymi elementami w Backlogu Produktu.

Wielkie wdrożenia prowadzą do jeszcze większych wdrożeń

Chwytliwy nagłówek niestety jest smutną rzeczywistością wielu organizacji. Jeśli kiepsko sobie radzimy z rzadkimi wdrożeniami, albo opóźnienia powodują niedotrzymanie pierwotnego planowanego terminu, termin wdrożenia jest odsuwany, zakres produktu na który tak długo czekamy odczuwa coraz większą presję dodania kolejnych drobnych zmian a wszyscy w organizacji łatwo wybaczają sobie i racjonalizują to, że „w sumie nic się nie stało” i że „wdrożenie produktu raz na rok też jest OK”. Z psychologicznego punktu widzenia bardzo trudno przerwać taką pułapkę myślową, za wszelką cenę wszyscy odpowiedzialni za zarządzanie chcą podtrzymać słuszność swoich poprzednich decyzji i trudno znaleźć odważnego lidera, który przerwie takie szaleństwo. Jeśli w dodatku pracujemy w organizacji ustawionej projektowo, taki niekończący się cykl wdrożeniowy natychmiast obrasta w dodatkowe moduły, rzekomo niezbędne dodatki i wymagania typu „przy-okazji-jak-już-zmieniacie-to-dodajcie-też”. Gdyby praca nad dokładnie tym samym produktem przebiegała w serii małych wdrożeń, można byłoby priorytetyzować rzeczy istotne i je realizować w pierwszej kolejności, a ewentualne zachcianki interesariuszy realizować w późniejszych wdrożeniach.

Całe wdrożenie jest limitowane przez jego najgorszy element

Ostatni argument, moim zdaniem najtrudniejszy, to uzmysłowienie sobie, że jeśli wdrażamy duże fragmenty zakresu rzadko (i słabo podzielnymi) wersjami, automatycznie uzależniamy się od tego, że całość zakresu musi być zrealizowana jednocześnie. To może prowadzić do tego, że jeśli dany element zakresu ma jakieś specyficzne wymagania, cała paczka może odziedziczyć te wymogi – np. jeśli wpływamy na kluczowe aspekty bezpieczeństwa, musimy zrobić kompletne testy bezpieczeństwa całej paczki wdrożeniowej (i opóźnić albo wydłużyć czas wdrożenia), nawet jeśli inne zmiany nie były krytyczne pod tym względem. Jeśli z wybranym elementem produktu mamy problem jakościowy (zbyt duża ilość błędów w tym fragmencie) albo biznesowy (np. wątpliwości prawne co do rozwiązań w produkcie), całe wdrożenie musi czekać, co w ogóle nie nastąpiło by w scenariuszu małych wdrożeń, gdzie każdy osobny fragment produktu może być wypuszczany na rynek niezależnie.

Czy przychodzą Wam do głowy jeszcze jakieś powody, dla których „opłaca się” pracować małymi i częstymi wdrożeniami nad rozwojem produktu? Napiszcie w komentarzu.

PS. Jeśli taka tematyka, jaką zawarłem w tym artykule, się Tobie podoba, zapraszam na warsztat, który organizuję wspólnie z Jackiem Wieczorkiem pod tytułem Porządny Agile 7-8 listopada w Poznaniu. Pogłębimy temat zwinności na zaawansowanym poziomie, szczegółowy program na stronie.

Zdjęcie „Triple Chocolate Mousse Cake” autorstwa jshj na licencji CC BY-NC 2.0

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x
X