The Principles of Product Development FLOW – cz.2

Momentów aha! z tego warsztatu było na tyle dużo, że postanowiłem rozbić je na dwa wpisy. Poniżej druga część moich notatek rozszerzających zawartość warsztatu i książki Dona Reinertsena Lean Product Development „Flow”.

  • Obniżanie transaction cost – jeśli zaczniemy analizować pod kątem ekonomicznym kwestie wielkości batcha w product developmencie, zauważymy, że koszty transakcyjne (koszty każdego batcha – na przykład koszty testów albo wdrożenia każdej paczki oddzielnie) mogą być obniżane co automatycznie przekłada się na zmniejszenie całości kosztów i przesuwa punkt minimum tych kosztów bardziej w stronę mniejszych wielkości batchy. By to uzasadnić będziemy potrzebowali znać Cost of Delay (bez Cost of Delay najbardziej racjonalne z perspektywy finansowej wydaje się pracowanie w dużych batchach i na 100% utylizacji – czyli minimalizowanie kosztów niewykorzystanych „zasobów”)

Duże batche są jak króliki w Australii – nie mają naturalnych drapieżników, więc mnożą się bez przeszkód.

  • Metafora z obstawianiem wyścigów – waterfall jest jak klasyczne zakłady na wyścigach konnych – przed rozpoczęciem wyścigu musisz obstawić pieniądze a potem możesz tylko obserwować jak rozwija się bieg, po sygnale startu nie możesz już nic zmienić; agile product development daje Ci możliwość obstawiania oraz wycofywania zakładów przez cały czas trwania wyścigu.
  • Współdzielone specjalizacje – jeśli zespoły interdyscyplinarne współpracują z jakimiś rzadkimi specjalistami (security, grafik, UX, … agile coach?), zamiast mierzenia tych rzadkich specjalistów kosztami, lepiej analizować cycle time i czas reakcji. Te czasy powinny być minimalizowane, by obniżać wpływ na wydłużanie czasów całego zespołu – ślepą uliczką byłoby kazać tym specjalizacjom skupiać się na obniżaniu kosztów, bo to automatycznie zepchnie ich do świata bardzo długich czasów oczekiwania (bo każdy specjalista będzie obciążony na 100%).
  • Zmniejszanie stuprocentowej utylizacji – Reinertsen nie radzi przekonywać zarządzających do tego, by zaakceptowali decyzję żeby „zasoby” były obciążane na mniejszy procent czasu. Efekt zmniejszenia obciążenia uzyskamy również wtedy, gdy będziemy realizować skrócenie cycle time przez limitowanie pracy w toku – a szybsze czasy dostarczenia będą bardzo łatwe do przełknięcia dla zarządzających
  • Backlog to waste – czas przebywania pomysłu do realizacji wlicza się do lead time, więc backlog powinien być tak krótki jak to możliwe i w szczególności należy go przeczyszczać ze śmieci, starych pomysłów itd. Reinertsen jest propagatorem podejścia YAGNI (You Aint Gonna Need It) i regularnego kasowania wszystkiego, co przesiedziało w backlogu jakiś czas i nikt się o ten pomysł nie upomniał. Zamiast realizować stare pomysły po kilku miesiącach/latach, lepiej je skasować i wprowadzić do backloga od nowa gdyby jednak pomysł wrócił jako ponownie istotny
  • Mierz długość kolejki a nie cycle time – Don zwrócił uwagę, że cycle time jest typem lagging indicator – miernikiem, który pokaże nam, że w naszym procesie dzieje się źle dopiero gdy jest już późno albo za późno na reakcję. Lepszym miernikiem jakości naszego procesu i jego przepustowości jest długość kolejki – jeśli zauważymy, że ilość chętnych w naszym procesie się zwiększa (a większa ilość chętnych bez zmiany w procesie bez wątpienia będzie obsługiwana dłużej niż dotychczasowe wskaźniki by podpowiadały), możemy zareagować od razu i wprowadzić potrzebne korekty.
  • WSJF – jeśli przy priorytetyzacji inicjatyw stosujemy podejście Weighted Shortest Job First, racjonalnym rezultatem jest dbanie przez autorów inicjatyw o to, by ich długość trwania była jak najmniejsza, bo dzięki temu można sobie podbić współczynnik wagi. W związku z tym każdy inicjator pomysłu ma potrzebę, by jego inicjatywa była realizowana jak najintensywniej i nie zawierała żadnego zbędnego elementu zakresu, który dodaje relatywnie mniejszą wartość w porównaniu do czasochłonności. Jest to dokładnie odwrotna tendencja do popularnego w świecie dużych organizacji zjawiska puchnięcia i wleczenia się dużych projektów, które są „za duże by je zatrzymać”.
  • Koszulkowe podejście do Cost of Delay – podobnie jak z szacowaniem wielkości user stories i business value, CoD i Duration potrzebne do ustalenia współczynnika WSJF można ustalić metodą relatywną, ustawiając Cost of Delay i Duration w macierzy 3×3 (Low, Medium, High). Całe podejście zostało spisane na stronie Black Swan Farming . To ma swoje wady, ale może być szybkim startem dla organizacji, które nie mają odpowiednie usystematyzowanego podejścia do policzenia kosztów i korzyści z danej inicjatywy/produktu/projektu.

 

Dodaj komentarz

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

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.