W dzisiejszym odcinku naszego bloga – szybka porada, a jednocześnie powrót do korzeni i do tego, o co w tej całej zabawie ze zwinnością chodzi. Dziś przypominamy o eksperymentowaniu.
Skomplikowane rozwiązania prostych problemów
W ostatnich miesiącach wielokrotnie miałem okazję uczestniczyć w spotkaniach, na których szerokie grono ważnych i doświadczonych ludzi omawiało wielce skomplikowane i nieprzewidywalne kwestie. Główny powód dyskusji zwykle był ten sam: „chcemy podjąć jak najlepsze decyzje zanim zaczniemy pracę, będąc w sytuacji w której nie mamy pełnych danych i nie potrafimy przewidzieć przyszłości”.
Przy takim postawieniu sprawy widzimy, że jakiekolwiek szczegółowe rozważania i dywagacje nie mają sensu. Cokolwiek nie wymyślimy, to i tak dopiero życie to zweryfikuje. Jednocześnie bardzo ciężko jest podejmować decyzje o poważnych konsekwencjach bez jakiejkolwiek analizy czy głębszego zastanowienia się. Ale to jest punkt, który na razie odłożę, a do którego jeszcze wrócę.
Po prostu zrób i sprawdź
Istnieje bardzo szeroka kategoria problemów, dla których najszybszym, najtańszym i najbardziej skutecznym rozwiązaniem jest po prostu zrobić jakkolwiek i sprawdzić rezultaty. Zamiast spędzając grube miesiące na analizowaniu wszystkich „za” i „przeciw”, czasami wystarczy tydzień wysiłku, żeby przetestować jakąś opcję i zebrać więcej danych.
Absolutnie nie mówię tutaj, że powinniśmy rzucić monetą, zrobić to co wypadło i jeszcze utrzymać to jako rozwiązanie docelowe. Czasami jednak te długie analizy są długie właśnie z tego powodu, że brakuje nam wiedzy i informacji. Innym razem operujemy na wymyślonych założeniach, których nikt nie zweryfikował albo wręcz nie może tanio i szybko zweryfikować.
Tą pułapkę szczególnie widać w korporacjach, gdzie bywa, że tylko praca programisty jest reglamentowana i kosztuje. Z kolei wszystkie rzeczy które się dzieją „dookoła programowania”, traktowane są bezkosztowo. Inaczej mówiąc: są za darmo. Przy takich założeniach wybieramy kilkadziesiąt bądź kilkaset godzin spotkań analityków, menadżerów i dyrektorów zamiast kilkadziesiąt godzin pracy programistów. I jeszcze bezczelnie twierdzimy, że to się opłaca.
Czego uczy nas robienie?
Robienie w odróżnieniu od samego myślenia ma wiele zalet. Nie tylko powstaje produkt – dobry, zły, jakikolwiek – który daje nam coś, co możemy modyfikować i dopracowywać. Po drugie, dostajemy informacje zwrotne – zarówno z jego użytkowania, jak i samego procesu produkcji. To są dwie zupełnie różne kategorie feedbacku, które niestety są mieszane i mylone przez co nie widzimy pełni korzyści z iteracyjnej i przyrostowej pracy.
Samo wytwarzanie czegoś, w odróżnieniu od tylko i wyłącznie teoretyzowania, powoduje że mierzymy się z rzeczywistymi problemami. Dostrzegamy o wiele więcej niż analizując czy projektując. Sęk w tym, żeby wiedzieć kiedy faktycznie robienie opłaca się bardziej od rzeczonego analizowania i projektowania. Ale to jest właśnie ten temat, do którego powiedziałem że jeszcze wrócimy.
Drugim aspektem informacji zwrotnej są informacje płynące z samego użytkowania produktu. I tu znowu muszę troszeczkę ponarzekać na dzisiejsze czasy, bo bardzo wiele organizacji w ogóle nie bada i nie mierzy tego co produkuje. Sukces produktu jest dla tych osób równoważny z sukcesem projektu, a więc zrealizowaniem go mniej więcej w budżecie i terminie przy względnie niezmienionych wymaganiach. A to przecież nie o to chodzi. Zarówno w podejściu zwinnym, jak i podejściu „zrób i sprawdź”.
Samo zrobienie pierwszego lepszego rozwiązania nie wystarczy. Zdarzą się sytuacje, że samo to przyniesie nam odpowiednie rezultaty. Ale najczęściej trzeba jeszcze sprawdzić, co z tego wyszło. „Zrób i sprawdź” to dwa etapy. Trzy, jeśli włączymy w to niezbędne przygotowania.
Przygotuj się, zrób i sprawdź
Nie można dłużej uciekać od tematu przygotowań. Podejście „zróbmy i sprawdźmy” to moim zdaniem kwintesencja zwinności. To także mindset „działaczy”, a nie myślicieli.” Jest to też droga, którą kierują się startupy. Niestety, nie można zawsze wygrywać, więc czasami (często?) okaże się, że wybrana przez nas droga jest niewłaściwa. A to kosztuje. Dlatego ważne, żeby takie działania były przemyślane i realizowane w granicach, na które możemy sobie pozwolić i na które nas stać.
Kiedy konsekwencje naszych decyzji są długotrwałe albo bardzo kosztowne, wypadałoby lepiej się do nich przygotować. Jeśli planujemy lot na księżyc czy budowę kilkunastu kilometrów tunelu, to wiadomo że porażki przy tego typu przedsięwzięciach są ekstremalnie kosztowne. Jednocześnie, „twarda” inżynieria jest o wiele bardziej podatne na precyzyjne przygotowanie. To znaczy, czas włożony w przygotowania zwykle zwraca się z nawiązką na etapie realizacji. Ale nawet w tych okolicach znajdziemy drobne decyzje i proste elementy, które czasami szybciej jest zrobić i sprawdzić, niż bez końca analizować.
Inaczej sprawy się mają w sytuacjach w których pozwalamy sobie na ciągłe zmiany i tak naprawdę w trakcie pracy odkrywamy zarówno potrzeby jak i rozwiązania. Tworzenie oprogramowania to w większości przypadków nieustający koncert życzeń i balansowanie zarówno wymaganiami, jak i rozwiązaniami. Biorąc pod uwagę rosnące koszty pracy wszystkich, nie tylko programistów, zasadne wydaje się stwierdzenie, że w wielu przypadkach powinniśmy skrócić drogę od klienta do osób realizujących wymagania i pozwoli im na szybkie tworzenie prostych rozwiązań – tak, aby móc je sprawdzić w praktyce. Brzmi znajomo?
Powrót do podstaw
Jeżeli dzisiejszy tekst pachnie wam powtórką z rozrywki, czyli kolejnym przykładem na to jak wdrożyć w życie PDCA/Cykl Deminga, to jak najbardziej macie rację!
Problemem wielu osób, które dłużej siedzą w środowisku z winnym, jest proponowanie skomplikowanych techniki i narzędzi bądź świetnych, ale zajmujących czas warsztatów. W wielu przypadkach prosta porada pod tytułem „przygotuj się, po prostu zrób i sprawdź jak wyszło” jest cenniejsza niż najlepsze nawet rady, które nie zostaną wcielone w życie.
A zupełnie przy okazji, mam nadzieję, że na następnym spotkaniu omawiającym tę samą rzecz, przypomni wam się ten tekst i znajdziecie odwagę do tego, żeby powiedzieć „ej, a może po prostu zrobimy i sprawdzimy jak wyszło?”.
