The Principles of Product Development FLOW – cz.1

Pod koniec zeszłego tygodnia zrealizowałem jeden ze swoich celów rozwojowych – wziąłem udział w warsztacie prowadzonym przez Donalda Reinertsena. Bardzo chciałem wziąć udział w takim warsztacie od momentu, gdy po przeczytaniu jego książki poczułem się zmiażdżony ogromem wiedzy i konkretnych teorii, które potwierdzają przyczyny działania agile jako podejścia. Pewną barierą zawsze była kwestia finansowa – Don do Europy przyjeżdża bardzo rzadko, a jego warsztaty są relatywnie drogie i daleko od Polski (normalna cena zaczyna się od 2.000 euro, najczęściej w Paryżu, Londynie albo Skandynawii). Na szczęście okazało się, że jest pewien powód, dla którego dla społeczności czeskiej i słowackiej Don zrobił wyjątek i poprowadził warsztat na preferencyjnych warunkach. Ten wpis przytoczy kilka największych momentów aha!, które odnotowywałem sobie na marginesach materiałów.

  • Dlaczego Lean zarabia – Zdaniem Reinertsena clue Toyota Product System to „small batches” – owszem klasyczny obrazek systemu pokazuje cały domek z daszkiem, filarami i fundamentami, ale w jego praktyce 95% efektu pochodzi z tego, że w fabryce zaczynamy zwracać uwagę na to, by doprowadzić do zmniejszenia kolejek poprzez stosowanie małych batchy.
  • Cost of Delay – na studiach ekonomicznych uczyłem się takich koncepcji pod hasłem analizy wrażliwości. Tworzymy model ekonomiczny danego zjawiska (przychodowości projektów, sukcesu rynkowego naszego produktu) i sprawdzamy jak na wynik ostateczny ($$$) wpływa zmienianie każdego czynnika oddzielnie. I oczywiście jest to miejsce na pełno przybliżeń, uproszczeń, założeń – ale zamieniamy rozmowę z „wydaje mi się” na „zakładam że”, co pozwala na bardziej cywilizowane argumentowanie. A ponieważ przy okazji wszystko sprowadzamy do wymiaru finansowego – do poprawnego porównywania teoretycznie nieporównywalnych wcześniej kwestii (szybkość dostarczenia projektu, nakłady poniesione na skracanie cycle time, zwiększone koszty realizacji projektu i przychodowość uzyskana dzięki wcześniejszemu albo późniejszemu wdrożeniu).
  • Ryzyka produktowe – w klasycznym project managerskim zarządzaniu ryzykiem dużo mówi się o ryzykach procesowych – ryzyka wpływające na koszty wszelkiego typu, proces pracy (narzędzia, technologia, ludzie),  opóźnienia realizacji zadań i całego projektu. Jeśli uświadomimy sobie, że zdaniem Reinertsena naprawdę duże ryzyko rozwoju produktów leży tylko w temacie wartości produktu (wartość dostarczona przez produktu może mieć 10krotny rozrzut w zależności od materializowania się lub niematerializowania określonych ryzyk produktowych), natychmiast bardzo racjonalnym wydaje się stosowanie modelu iteracyjno-przyrostowego, częstych wdrożeń małych fragmentów produktu, dodatkowe inwestowanie w poznawanie potrzeb klienta w trakcie rozwoju produktu itd. itp.
  • Model ekonomiczny – Reinertsen przytoczył model decyzyjny stosowany przy konstruowaniu Boeinga 777, który pozwalał każdemu inżynierowi na wydatek 300$ na każdy obniżony funt wagi samolotu (~0,45kg). Samolot musi być lekki, więc w każdym pojedynczym przypadku warto inwestować w zmniejszenie jego wagi – ale nie za wszelką cenę, bo od któregoś momentu taka inwestycja (choć przyniesie obniżenie wagi) stanie się nieekonomiczna (bo koszt samolotu wzrośnie zbyt znacznie i firma nie będzie mieć zysków z jego sprzedaży). Decyzje tego typu można by zcentralizować i oczekiwać zgłaszania każdego pomysłu (bo przecież decydujemy o zyskowności bardzo zaawansowanej konstrukcji), ale zamiast tego Boeing propagował prostą zasadę – jeśli masz pomysł jak obniżyć wagę elementu samolotu, który projektujesz i ten pomysł nie zwiększy kosztów jednostkowych o ponad 300$ – możesz to zrobić bez pytania kogokolwiek o zgodę. Jeśli masz pomysł za koszt do 600$ – skonsultuj to ze swoim przełożonym, a jeśli widzisz jakiś potencjał na koszt do 2500$ – z zarządzającym całym projektem. Fajnie byłoby zobaczyć taki model przy pracy z długiem technologicznym w systemach legacy – istnieje gdzieś granica rozsądku, gdzie natychmiastowe usunięcie długu bez pytania kogokolwiek o zgodę powinna być automatyzmem, jest też pewnie obszar, którego poprawianie już nie daje tak wielkiego sensu (negatywne odpowiedzi na pytania w stylu – „jak często będziemy rozwijać ten kawałek systemu”, „czy dużo użytkowników korzysta z tego kawałka systemu”)
  • Krytyka ROI – Reinertsen bardzo fajnie zwrócił uwagę na to, że ROI jest zbyt upraszczającą miarą. Wartość wygenerowana przez produkt bardzo zależy od daty pojawienia się produktu na rynku (zazwyczaj wcześniej pojawiający się produkt jest bardziej zyskowny niż ten, który dociera, gdy rynek jest już pełen konkurencji). Zamiast czystego ROI Don zachęcił do sprawdzania Cost of Delay, zwymiarowania tego, ile stracimy, jeśli dany produkt/projekt/feature będzie zrealizowany z opóźnieniem. A na chłopski rozum – odpowiedzenie sobie na pytanie „co z tego, co mamy do zrobienia, może poczekać?”
  • Planowanie biznesowe – do rozpoznawania danego zespołu koniecznie trzeba dodać krok w stylu „jak w tej chwili generowane i wybierane są inicjatywy do realizacji”. Sama faza rozwoju kryje w sobie niewielkie usprawnianie w porównaniu do tego, co możemy zyskać jeśli usprawnimy aspekt robienia właściwych rzeczy.
  • Inwestycje w skracanie cycle time – Reinertsen przytoczył życiowy paradoks, że w wielu projektach prace i inwestycje intensyfikują się pod koniec projektu, gdy trzeba go „ratować”. Decydenci są skłonni zaakceptować znacznie wyższe wydatki na uratowanie terminu, gdy są już bardzo blisko końca. Gdyby w takiej organizacji funkcjonował model ekonomiczny i znany byłby Cost of Delay – wszystkie te inwestycje i wysiłki, które są robione w nerwowych końcówkach, byłyby oczywistością do zaimplementowania zaraz na samym początku, zwłaszcza gdy różnego rodzaju koszty skracania cycle time są mniejsze gdy mamy więcej czasu (np. spokojne rozwijanie platformy do Continuous Integration przez cały czas trwania projektu zamiast szukania na ostatnią chwilę tabunów testerów manualnych by „przyspieszyć” fazę testowania).
  • Potrzeby klientów – typowo w rozwoju produktu zadawane jest pytanie „Czego klient chce”. Jest to zdaniem Dona mało istotne pytanie, bo klient nie wie czego chce… 😉 Oprócz tego pytania warto więc poszukać odpowiedzi na pytanie „Dlaczego klient tego chce?” (co się bardzo łączy z klasycznym templatem user stories „tak aby…”) oraz na pytanie „Po czym klient pozna, że tą potrzebę będzie miał zrealizowaną?”. Klient nie tylko nie wie, czego chce, ale oprócz tego ocenia czy produkt ma jakieś cechy na podstawie nieracjonalnych przesłanek – na przykład aplikacja oceniana jest jako szybsza, jeśli bombarduje klienta informacją na temat postępu ładowania (nawet jeśli realny czas wcale nie jest taki szybki, klient widzi, że coś się dzieje).
  • Dlaczego warto obniżać wielkość batcha (partii przetwarzanego materiału) – wszystkie reguły wypisane w książce stanowią świetną checklistę do podsumowania ćwiczenia z zamkami albo obracaniem klocków, jakie stosuję w swoich warsztatach. 😀 Krótszy czas przetwarzania, mniej otwartych błędów i mniejsze zmiany prowadzą do:
    • wczesnego feedbacku
    • szybszego uczenia się
    • niższych kosztów zmiany
    • lepszego kodu(/produktu)
    • niższych kosztów poprawki
    • mniejszej ilości zmian wymagań
    • mniejszej potrzeby dla raportowania statusu prac
    • zmniejszenia ilości działań niedodających wartości do produktu
    • lepszego uptime produktu
    • tańszego testowania
    • łatwiejszego poprawiania błędów
    • tańszego poprawiania błędów
    • lepszej wydajności całego procesu

Druga część materiału zaplanowana na najbliższy czwartek – wpis wyszedł za długi (co dobrze świadczy o wartości warsztatu).

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.