Tebe.blog

Teoria mówi, że powinniśmy mierzyć wartość a nie liczbę zrealizowanych rzeczy. Dziś scrum i inne metodyki rozwoju produktów kładą nacisk na dostarczanie działającego oprogramowania. W efekcie zespoły rozwojowe stają się fabrykami funkcjonalności. Zmiana nie jest jednak taka prosta. Trzeba zacząć od liczenia i często okazuje się, że niekoniecznie ma to sens.

Propagatorzy OKR, tacy jak Felipe Castro czy Christina Wodtke twierdzą, że stosowane w nich miary, KRy, powinny opisywać efekt podejmowanych działań, a nie postęp na drodze do celu. Popiera to m.in. Marty Cagan, znany z książki „Inspired”, fundamentalnej w temacie rozwoju produktów. Postanowiłem wskoczyć do tego pociągu, ponieważ jedzie w dobrą stronę. Inna sprawa, że łatwiej nim jechać niż dotrzeć do celu.

OKRy to Objectives and Key Results, metoda zarządzania celami, o której dużo piszę. Praktyczne materiały znajdziecie na stronie OKRy.pl.

OKRów można używać wszędzie tam, gdzie wprowadzana jest zmiana, gdzie są jakieś nowe wyzwania i cele do osiągnięcia. Metoda wywodzi się z organizacji rozwijających produkty, w szczególności innowacyjne i budowane z udziałem nowych technologii. Tu obowiązującym podejściem są dziś metodyki zwinne, takie jak scrum. Felipe w swoich artykułach zwraca uwagę, że nie ma w scrumie ani jednej ceremonii, która zajmowałaby się mierzeniem dostarczonej wartości. Cieszą mnie takie opinie, pamiętam niejedną trudną rozmowę ze scrummasterami zaczynającą się od pytania „a skąd będziemy wiedzieli, że nam się udało”. Rozkładali ręce ponieważ tak, ich dziedzina się tym nie zajmowała.

Problemy z mierzeniem są niezależne od tego, jaką metodą pracuje zespół. Mamy je również tam, gdzie działa waterfall, kanban, scrumban czy but scrum. Stosując z wszelakimi metodykami OKRy warto przede wszystkim pamiętać, że KRy nie powinny być listą zadań do zrobienia. Stoją poziom wyżej od backlogu, stanowią raczej dla niego ramy. Oraz obowiązują w dłuższym niż sprint terminie.

W stosunku do wcześniej stosowanych metod agile poprawia skuteczność uczenia się i dostarczania funkcjonalności. Dostarczanie wartości biznesowej pozostaje tu jednak problemem produkt ownera. W połączeniu z dyktaturą zespołu i metody może się okazać, że w efekcie nie powstaje żadna wartość poza działającym oprogramowaniem.

Na wielu stronach o OKRach znajdziecie przykłady, w których jako miary występuje lista „dokonań” i zrobionych rzeczy.

Weźmy przykład kanonicznej prezentacji Johna Doerra, który wprowadził OKRy do Google. Pokazuje on historię z 1979 roku i miary dla celu „Establish the 8086 as the highest performance 16-bit microprocessor family”, który w tym czasie był głównym wyzwaniem Intela. KRy, miary zastosowane w Q2 dla tego celu nie są ściśle nastawione na wynik, ale bardzo precyzynie pokazują postęp. Ta prezentacja nie jest biblią OKRów (to jest framework, nie ma dla niego czegoś takiego jak biblia), ale dobrze pokazuje, że w tym podejściu można i trzeba być elastycznym. Slajd możecie znaleźć w notce Jak rozliczac OKRy.

To nie jest takie złe na starcie, powinno się jednak dążyć do czegoś więcej. Jak duże może to być wyzwanie?

W artykule „You Need to Manage Digital Projects for Outcomes, Not Outputs”, opublikowanym w HBR, autorzy opisują jak to z klientem ustalili, że za cel zmian na stronach uznają liczby związane z zaangażowaniem użytkowników, co zakończyło się sukcesem. Popieram to podejście, ale ten przykład jest banalny, nawet jeśli rzadko gdzie ludzie tak pracują. W większości praktycznych sytuacji nie ma łatwych miar do złapania. Doprowadzając to do absurdu – w ramach sprintu nie da się wytworzyć zysku. Wartość powstaje w dłuższym czasie. Trzeba znaleźć miary pośrednie.

Załóżmy np. że chcemy za pomocą działań marketingowych zwiększyć świadomość produktu. Przy takim celu proponuje się często KR typu „opublikować informacje prasowe w 10 mediach”. Samo opublikowanie notek – choć łatwo stwierdzić, że nastąpiło – nie będzie oznaczało wzrostu świadomości produktu. Ten należałoby próbować łapać raczej efektem, które spowodowały publikacje. Pokażcie mi dział marketingu, który to robi. Które wejścia na stronę wynikają bezpośrednio z tego, że ktoś przeczytał notatkę? Da się to ustalić, ale wtedy samo mierzenie wymaga dodatkowego wysiłku. Nie twierdzę, że nie jest on wart zachodu…

Do sukcesu nie wystarczy, że coś zostało zrobione. Dana rzecz musi jeszcze przynieść korzyść – w ostateczności wpływając na zwiększenie przychodów lub zmniejszając koszty. To niby oczywiste. By zadziałało niezbędne jest znalezienie i wdrożenie dobrych wskaźników, którze pokażą wpływ zmian w produkcie na biznes. Trzeba też spowodować, że cała organizacja będzie się nimi posługiwać. To nie jest łatwa zmiana. Często w organizacjach i startupach nawet podstawowe rzeczy nie są mierzone. Nie ma kiedy ładować taczek, co tu mówić o sytuacji, w której przewozimy w danym momencie najbardziej potrzebne rzeczy.

OKRy mogą te rzeczy pomóc uporządkować. Nie jest to jednak poziom przedszkola. Należy do tego dążyć, niekoniecznie od tego zaczynać wdrażanie metody.

Wybrałem się do Amsterdamu na Lean Startup Summit. Lubię to miasto i Holandię (sery, kanały, śledzie i różne inne), chciałem też zobaczyć co w temacie dziś się dzieje. Wygląda na to, że zamiast robić lepsze produkty bardziej opłaca się wymęczać innowację w korporacjach.

„The Lean Startup” jest jedną z najważniejszych książek biznesowych ostatniej dekady. Ericowi Riesowi udało się wyciągnąć wnioski z problemów jakie sprawia rozwój produktów i w spójny sposób zaproponować jak sobie z nimi radzić. Jego książkę czytaliśmy w Gazeta.pl w 2012, dość świeżo po wydaniu, dziś do niej wracam i uważam, że nie straciła wagi. Teraz autor napisał hmmm… sequel, który zwie się „The Startup Way”.

W jednym z tzw. „blurbów” nowej książki Robert Sutton, profesor zarządzania ze Stanforda, napisał, że autor może być nowym Peterem Druckerem. Z całym należnym szacunkiem, wydaje się to być nadużycie. Poczekajmy trochę z takimi ocenami, tym bardziej, że o tym jak Drucker wyprzedził epokę widzimy dopiero po ponad 50 latach.

Tych notek od znanych postaci Ries zresztą nagromadził prawie 30. Bardziej przemawia do mnie to co napisał Tom Peters. Jak na niego zaskakująco zresztą jest to wyważone (Peters częściej przegina niż Sutton). „Korporacje borykają się z kłopotami większymi niż kiedykolwiek”. Tym teraz zajmuje się „ruch Lean Startup”. Czy dlatego, że w startupach szybciej się uczą i mają mniej czasu i pieniędzy na konsultantów?

Udział w konferencjach to zawsze dobra okazja do poznania ludzi i wymiany doświadczeń. Same prezentacje są ciekawe, ale jeśli ktoś chce pogłębić wiedzę na jakiś temat, znajdzie masę świetnych wykładów na YouTube. Lepszy jest udział w warsztatach, ale najważniejsza jest praktyka. Musi zaboleć, żebyśmy zrozumieli jak coś robić. To zresztą jeden z ciekawszych wniosków z Amsterdamu: innnowacja to pasmo porażek. Sukcesy są nieliczne i ciężką pracą okupione.

Było to słychać w bardzo dobrym wystąpieniu Benoît Legranda, który pracuje jako Chief Innovation Officer w ING Banku. Był szczery, otwarty, mówił bardzo ciekawie. W czasie sesji pytań przyznał, że stosunek sukcesów do porażek w innowacyjnych przedsięwzięciach to mniej więcej jeden do trzydziestu. Potrzebna jest cierpliwość, wytrwałość i dobre przywództwo, by zniesc ten koszt.

Tak po prostu jest, pytanie dlaczego spodziewamy się czegoś innego. Może dlatego, że patrzymy na innowacje z perspektywy sukcesów. Oczywistość gotowego produktu jest źródłem jednego z największych mitów związanych z rozwojem. Nie widać przegranych, nie widać włożonej pracy. Widzimy np. świetne suszarki do rąk Dysona (szybko skopiowane przez innych producentów), widzimy wyjątkowy odkurzacz. Nie pamiętamy, że aby ten odkurzacz zbudować Dyson zrobił około 5 tysięcy prototypów. Potem musiał założyć firmę, gdyż żaden z producentów nie chciał wprowadzić produktu na rynek.

Ciekawe jak niewiele osób to rozumie. Dlaczego powstaje tak wiele produktów i usług dla nikogo. Z drugiej strony, jak to się dzieje, że mimo eksplozji popularności projektowania, która miała miejsce ponad 10 lat temu nadal tak wiele popularnych produktów jest źle zaprojektowanych…

Napisałem też zainspirowaną konferencją historię Lean Startup anventures in corporate world (Medium). Tam nieco inna perspektywa.

Tytuł sugeruje, że Captain Obvious powraca, ale czy to dla wszystkich jest oczywistość? Mamy receptę, punkty, których spełnienie jest niezbędne do zbudowania dobrego działu rozwoju. Wystarczy?

Nie, tak naprawdę liczy się tylko to, jak pracujesz z ludźmi.

Jak pisałem, kiedyś w Gazeta.pl ustaliliśmy, że dobre działy rozwojowe (technologia + produkt + design) mają 4 cechy wspólne. Pracują zwinnie, podzielone są na autonomiczne zespoły produktowe, dbają o motywację ludzi oraz klarownie komunikują cele.

Dlatego m.in. zdecydowaliśmy się zastosować OKRy. Warto iśc tym tropem, ale to za mało. Po zeszłym roku, kiedy prowadziłem dział programistów, mam takie przemyślenia:

1. Elementy, które ustaliliśmy są ważne, ale można je wdrożyć dowolnie źle.

2. Podział na autonomiczne zespoły produktowe to jedno z największych wyzwań związanych z technologią.

Gdy coś budujesz od zera, uważaj. Przy skali powyżej 30 osób zapewnienie dobrej architektury technicznej i ludzkiej oraz minimalizacja zależności między elementami systemu to twoje główne zadanie. Jest już całkiem dużo wiedzy na ten temat. Można też znaleźć ludzi, którzy chętnie dzielą się swoim doświadczeniem w tym obszarze.

Przy dużych, rozwiniętych systemach, taki podział to mega wyzwanie. Dlatego z rezerwą słucham opowieści o zwinności wielkich firm, zwłaszcza banków. Doprowadzić tam do sytuacji, w której rzeczywiście występuje autonomia i poczucie własności to proces długi i mozolny. Żeby nie powiedzieć Mission Impossible (ten kawałek w Dubaju zwłaszcza).

3. Nie jest to jednak nie do zrobienia. Nie uda się na pewno, o ile od początku nie wciągnesz w temat swoich najlepszych inżynierów. Trzeba doprowadzić do sytuacji, w której każdy z nich rozumie i podziela wspólny cel. Bez tego nici ze zmiany.

Wciągnięcie i zaangażowanie jest potrzebne by wzmocnić ich poczucie własności. Nie warto próbować kontrolować wszystkiego. Wierzę w jednostki, ale tu problemy są tak złożone, że tylko działające w zgodzie grupy są w stanie z nimi sobie poradzić. Dlatego programiści muszą czuć, że kod i system należy do nich.

4. Z inżynierami warto rozmawiać i dobrze się z nimi rozmawia. To mit, że programiści to zamknięte w sobie typy, które widzą tylko kod. Nie zawsze łatwo zacząć, ale tak jest z każdym. Lody łamią rózne tematy, trzeba się dostroić do osoby, ale po zbudowaniu zaufania jest coraz lepiej.

5. Zaufania? Tak, olbrzymie znaczenie mają w zarządzaniu technologią rzeczy miękkie. Wprowadzenie One-On-One było jedną z lepszych rzeczy jakie zrobiliśmy z liderami technologii. W tematach miękkich w działach IT rzadko kto wie o co chodzi, niewielu to robi a prawie nikt dobrze. I trudniej to się robi w starych firmach, niż młodych, których założyciele od początku wspierają budowanie kultury. Często dlatego, że sami wywodzą się z technologii.

I na koniec – naprawdę wszystko warto liczyć i mierzyć. Od dawna wiadomo, że jeśli się chce czymś zarządzać, trzeba to mierzyć. Liczenie wszystkiego i posługiwanie się metrykami przy podejmowaniu decyzji – od tego nie ma odwrotu. Powiedzmy, że chodzi o hasło „wymiarowanie” – jeszcze do tematu wrócę.

Nie ma przepisów na sukces osobisty ani powodzenie firmy. Nie wystarczy odtwarzanie tego, co zrobili inni. Warto jednak wiedzieć, co im pomogło. Stąd pytanie: jakie rzeczy robią firmy technologiczne, którym się udaje?

Dziś po inspiracje rodem ze startupów sięgają nawet banki. Pytania co robić z technologią by działała, jak pracować z programistami by rozwój szedł zgodnie z planem i wzmacniał biznes dotyczą coraz większej liczby organizacji.

Internet jest fantastyczny. Chcę przyrządzić żeberka – pół dnia mogę spędzić poznając przepisy i oglądając jak je robią na YT. Chcę by moja organizacja działała lepiej – mogę czytać produkcyjniaki, o tym jak urosło imperium braci Samwerów (slajd 19 zwłaszcza), jak rozwijają Trello czy Spofity ale też w jaki sposób pracuje polskie Netguru.

Przez lata w Gazeta.pl czytaliśmy takie rzeczy, starając się pracować coraz lepiej. W 2015 roku postanowiliśmy pójść krok dalej i zrobiliśmy badania terenowe. Ówczesny szef programistów spotkał się z siedmioma polskimi firmami, by posłuchać, co im pomaga. Rozmawiał choćby ze wspomnianym Netguru, ale też firmami, które mają własne produkty, poza rynkiem mediowym. Ustaliliśmy, że robią cztery rzeczy.

Wracam do tematu, ponieważ ostatnio dosyć często opowiadam ludziom o OKRach. Zaczynam od tego, po co po nie sięgnęliśmy. Wspominam o tych badaniach mówiąc, że był to jeden z czterech elementów, które, jak ustaliliśmy, są kluczowe. W tym momencie każdy pyta „a jakie były pozostałe?”. Komplet jest taki:

1. Wszyscy pracują w metodykach zwinnych (wiadomo, agile i lean)
2. Mają małe, produktowe, autonomiczne zespoły
3. Zajmują się motywacją programistów i rynkiem pracy IT
4. Mają ustalone wartości i wykorzystują metody służące do zarządzania celami w całej organizacji (jak OKRy czy V2MoMy)

Agile ćwiczyliśmy od dawna, to zwykle zaczyna się w technologii. Byliśmy też podzieleni na zespoły produktowe – to naturalny krok po przejściu na metodyki zwinne. Pierwszy pilotaż Lean Startup robilismy w 2011. Dodam, że od pilotaży do przestawienia całej organizacji droga jednak jest daleka.

Obszar motywowania programistów to temat rzeka. Nie da się uniknąć jakiegoś udziału w licytacji. Nie można jednak zajmować się tylko tym, warto zwracać na pozafinansowe motywacje. I nie chodzi o konsole do gier, czy ładne biura, ale o kulturę, cel i sens pracy. Swoją drogą to, że ludzie do pracy nie przychodzą tylko po pieniądze okazuje się być jakimś odkrywczym tematem nad Wisłą. I tu wchodzą wartości i cele. Do tych ostatnich własnie postanowiliśmy zastosować OKRy.

Powyższe zalecenia to tylko nuty (czy też informacja o tym jakie nuty trzeba mieć). Jeszcze trzeba sprawić, żeby orkiestra zagrała, tymczasem dyrygent często nie wie co robić z batutą. To nie jest droga, która kiedyś się kończy. W jej trakcie ciągle się przekonujemy, że teoria od praktyki bardziej się różni w praktyce niż w teorii.

Jak bardzo – o tym w drugiej części wpisu: W technologii najważniejsi są ludzie.