Kiedy ostatnio udało się Wam zrobić coś idealnie przy pierwszym podejściu? Dawno? Nigdy? Mi osobiście nigdy się to nie udało. Jestem wyznawcą zupełnie innego podejścia. W tytule użyłem 4 kroków cyklu Deminga. Ale możecie znać to podejście także jako “Build, Measure, Learn” z “The Lean Startup”. Dziś opisuję moje zastosowanie tych podejść.
Usystematyzowanie pojęć
We wstępie użyłem kilku pojęć. Zanim opiszę, jak z nich korzystam, to krótko je scharakteryzuję.
Cykl Deminga
Cykle Deminga to schemat ilustrujący zasadę ciągłego ulepszania. W wersji zaproponowanej przez jego twórcę, Wiliama Edwardsa Deminga składa się z następujących kroków:
- Zaplanuj – planuj z wyprzedzeniem
- Wykonaj – pilotażowe wdrożenie
- Zbadaj – przeanalizuj rezultaty
- Zastosuj – podejmij najlepsze działania, korzystając z wiedzy z analizy rezultatów
Podejście to jest szczególnie popularne w zarządzaniu przez jakość.
Build, Measure, Learn
Build, Measure, Learn to kroki metody rozwoju biznesu i produktów zwanej “Lean startup”. Dosłownie znaczy to „szczupły start”.
Ries, claims that startups can shorten their product development cycles by adopting a combination of business-hypothesis-driven experimentation, iterative product releases, and what he calls validated learning.
Co można przetłumaczyć:
Ries [twórca metody], twierdzi, że startupy mogą skrócić cykl tworzenia produktu, wykorzystując podejście składające się z kombinacji eksperymentów opartych na hipotezach, iteracyjnego podejścia do wypuszczania nowych wersji produktów oraz potwierdzonego uczenia się.
Co to znaczy w praktyce? Budowanie nowego produktu lub usługi powinno polegać na:
- zbudowaniu podstawowej wersji produktu/usługi, który spełnia podstawowe wymagania klienta,
- zbadaniu, jak ten produkt/usługa została przyjęta i jak jest używana,
- nauczeniu się na tej podstawie, co działało dobrze, co można poprawić,
- wykorzystaniu tego, czego się nauczono, w następnej wersji produktu/usługi.
Oczywiście podejście to zawiera jeszcze wiele dodatkowych czynników, ale w najprostszym ujęciu o to w nim chodzi. Stawiamy hipotezę, budujemy pierwszą, prostą wersję, sprawdzamy, jak jest używana, poprawiamy itd.
Jak skorzystać z tej wiedzy w praktyce?
Obydwie przytoczone przeze mnie metody mają wspólne cechy. W obydwóch chodzi o to, żeby nie czekać z realizacją pomysłu aż będzie idealnie opracowany, ale aby zacząć od małej rzeczy, mierzyć (badać) rezultaty, uczyć się na nich i wykorzystywać tę wiedzę przy następnej wersji produkty/usługi lub w zupełnie innych obszarach.
Jak można wykorzystać to w praktyce? Opiszę Wam parę przykładów z mojego doświadczenia.
Wprowadzanie nowych inicjatyw w zespole
W jednym z zespołów z którym pracowałem przez długi czas, zdecydowaliśmy wspólnie, że jest potrzeba wprowadzenia zmian w sposobie naszej pracy. Wybraliśmy kilkanaście obszarów, które spriorytetyzowaliśmy, a potem zaczęliśmy nad nimi pracować. Za namową jednego z kolegów pracowaliśmy nad nimi za pomocą metody “Build, Measure, Learn”. Na czym polegała ta praca? Zaczęliśmy od opisania inicjatywy za pomocą kilku parametrów:
- Tło – kilka zdań na temat dlaczego chcemy zajmować się daną inicjatywą.
- Ludzie – jacy są właściciele i uczestnicy danej inicjatywy (Stakeholders).
- Wartości, które chcemy osiągnąć
- Wymagania, jakie dana inicjatywa musi spełniać. Tutaj zwykle korzystaliśmy z metody MoSCoW. Określaliśmy, co nasza inicjatywa musi zawierać (Must), co powinna zawierać (Should), co może obejmować (Could) i czego nie będzie uwzględniać (Won’t).
- Metryki – jak będziemy mierzyć, czy udało nam się wprowadzić inicjatywę.
Build
Mając opisane te parametry, proponowaliśmy, jak taką inicjatywę będziemy wprowadzać, na czym będzie ona polegała, jakie konkretnie akcje podejmiemy, jak długo będą trwały itd.
Measure
Po pewnym czasie (określonym w metrykach i w fazie Build) sprawdzaliśmy rezultaty wprowadzenia inicjatywy/zmiany. Zapisywaliśmy wyniki i porównywaliśmy z metrykami.
Learn
Na koniec sprawdzaliśmy, czego się nauczyliśmy. Rozmawialiśmy z uczestnikami inicjatywy/zmiany o rezultatach. Analizowaliśmy wyniki z fazy Measure. I na tej podstawie proponowaliśmy, co zrobić w następnej iteracji, o ile nie uznaliśmy, że już jesteśmy zadowoleni z wyników wprowadzenia zmian.
Podsumowanie przykładu
Pracując w ten sposób, wprowadziliśmy wiele zmian, większych i mniejszych. Z mojej perspektywy ta metoda okazała się bardzo skuteczna. Wszyscy wiedzieli, co robimy, jak, jakie są następne kroki. Każdy mógł się wypowiedzieć na temat rezultatów. To połączenie dobrze opisanej metody z zaangażowaniem zespołu przyniosło naprawdę dobre rezultaty.
Praca nad moim systemem produktywności
Bardzo podobne podejście, jak w przypadku przykładu z inicjatywami wprowadzanymi w zespole, mam do budowy mojego systemu produktywności. Buduję go już prawie 6 lat. I wciąż ewoluuje. Jak to robię? Ważne w tym procesie jest kilka czynników:
- Dużo czytam i inspiruję się – praktycznie codziennie czytam artykuły, książki, oglądam prezentacje i inne materiały o tym, jak można pracować bardziej produktywnie. Informacje, które uzyskuje w ten sposób, służą mi na dwa sposoby. Z jednej strony widzę, co mógłbym sam u siebie spróbować. Widzę też, co mógłbym zaproponować moim klientom, którym pomagam przygotować ich system produktywności. Warto się inspirować! Ciekawe pomysły zapisuję w Todoist. W odpowiednim czasie sprawdzam je dokładniej. Jeżeli są interesujące, to zapisuję więcej informacji o nich w OneNote.
- Tygodniowe przeglądy – co tydzień mam przegląd tygodniowy. Pomysł zaczerpnąłem z GTD Davida Allena. Jednym z punktów, który wtedy sprawdzam, jest to, czy dany sposób pracy działa czy nie. Jeżeli coś nie działa któryś już tydzień z rzędu, to zaczynam zastanawiać się, jak to zmienić.
- Przeglądy co 12 tygodni i roczne – co 12 tygodni poświęcam cały dzień na analizę tego, co zrobiłem przez ten czas, ale też oceniam, co działało dobrze, a co nie do końca. To samo robię w czasie rocznych przeglądów.
W czasie tych przeglądów korzystam (pośrednio) z powyżej opisanych metod. Mam już jakiś system, który działa. Sprawdzam, jak on działa np. poprzez ocenę, czy korzystając z tego systemu, udało mi się osiągnąć to, co zamierzałem. Wyciągam wnioski, które części działały dobrze, a które nie. I poprawiam.
Podsumowanie
Jak widzicie na podstwaie przykładów, które przytoczyłem, teoretyczne modele dobrze sprawdzają się także w praktyce. I tak naprawdę takie podejście sprawdza się w wielu sytuacjach. Jeżeli nad czymś pracujecie, wymyślacie coś nowego, ulepszacie, to takie podejście da Wam świetne rezultaty.
Pytanie: czy znacie jeszcze inne modele, podobne do tych opisanych przeze mnie?
