Tebe.blog

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.

Nie ma zbyt wielu dobrych scrum masterów. Jeszcze mniej jest ludzi, którzy są w stanie takich wykształcić. Proponuję nie zapominać o rzeczach najprostszych: dać im coś konkretnego do roboty i sprawdzić jak poszło. To zresztą nie dotyczy tylko scrum masterów.

Scrum master nic nie wytwarza. Produkt jego pracy to lepsza praca zespołu, osiągana m.in. dzięki stosowaniu metodyki. Wkład naszego bohatera jest ulotny – na ile skuteczność zależy od niego, na ile od jakości zespołu? Ile spawia świetny właściciel produktu albo lider techniczny? Jak scrum master poradziłby sobie z dysfunkcyjnym zespołem?

Na jednej z list zadań znajdziecie stwierdzenie, że scrum master powinien nauczyć produkt ownera jak komunikować wizję produktu, cele, wartości. To jest grube. Niewielu spotkałem produkt ownerów, którzy wiedzą jak to robić. Generalnie niezbyt często w przyrodzie występuje sytuacja, w której znana jest wizja, cele i wartości.

Pisałem już, że scrum master może nie rozumieć tego co jest budowane i robić dobrze to, co powinien. Wg źródeł jest służącym-przywódcą zespołu. By jednak facylitować pracę ludzi nie wystarczy zadawanie pytań typu „jakie zadania wykonałeś” i „co utrudnia Ci wykonywanie pracy”. Ważne jest pogłębianie odpowiedzi i dążenie do źródeł problemów. To wyzwanie. Wymaga asertywności, trzeba mieć pojęcie o psychologii, rozumieć dynamikę grupy, umieć zbudować sobie autorytet. Rozmawiałem z menedżerami, którzy brali na siebie tę rolę. To sensowne, bardzo pomaga doświadczenie w pracy z ludźmi. Z drugiej strony z menedżerami wiąże się często autorytet narzucony przez herarchię… co jest sprzeczne z fundamentami.

Mierzenie wyników pracy scrum mastera nie jest łatwe. Gdybym był tu juniorem, zadbałbym o to jak mi idzie i z uwagą przeczytał to co zebrał Vasco Duarte. Z rad jakich udziela można wybierać rzeczy, które pozwolą poprawić sposób pracy i myślenie o nim. Mierzenie tempa dostarczanego działającego oprogramowania jest najprostszym z kryteriów. Lepszym, ale trudniejszym – mierzenie dostarczanej wartości. Warte grzechu jest weryfikowanie czy zespół jest dumny z tego co osiągnął oraz ustalanie, jakie najważniejsze problemy rozwiązał.

Świetna jest też sugestia Matta Dominici – zostawić raz na jakiś czas zespół i sprawdzić czy rzeczywiście poczuł się odpowiedzialny. Taki test pokazuje rzeczywistą zmianę. Zespoły czasem chwalą scrummasterów ponieważ im wygodnie. To może oznaczać tylko, że cała logistyka spotkań jest sprawnie prowadzona i np. kolega robi za nich wszystkie notatki. No i kawa jest. Pisałem już o tym paradoksie. Tak naprawdę nic się nie poprawia, nikt nie znalazł się na moment poza strefą komfortu. Nawet nie pomyślał o tym, że można lepiej…

Z menedżerami projektów było łatwiej. Mieli ogarniać i sprawiać. Potknięcia szybciej były widoczne. By rozwijać scrum mastera, warto przy nim być, obserwować przy pracy. Dlatego dobrze mieć minimum jednego dobrego, naprawdę doświadczonego SM-coacha.

Oraz dawać scrum masterom coś do roboty.

Co to znaczy? W uproszczeniu wyznaczać zadania. Sprawiać, że wezmą na siebie rzeczy, których postęp zależy wyłącznie od nich. Będzie widoczna ich praca, niezależna od wkładu zespołu. Jakie? Mogą dotyczyć choćby wszystkiego co powstaje wokół zmian w organizacji. Np. zatroszczenie się o tablicę z listą zespołów i aktutalnych projektów. Pozornie nic istotnego, ale sprawić, by pełniła swoją funkcję oraz by była aktualna nie jest bardzo łatwo. Możecie się zdziwić ile daje taka wizualizacja, ilu rzeczy ludzie bez niej nie wiedzą. To zadanie na początek, z czasem powinno robić się trudniej.

Gdy będziesz widział jak SM robi rzeczy, będzie okazja to poprawiać. Sam zawodnik będzie mógł się rozwijać i czuć, że coś zrobił. Będzie widzieć postęp i rzeczy, których dokonał. To zawsze przynosi satysfakcję. Będzie też mu łatwiej się odnaleźć, gdy minie moda na Scrum… To zresztą nie dotyczy tylko scrum masterów, tak warto pracować z każdym. Dlaczego? W zespole warto mieć tzw. doerów – ludzi, którzy dowożą i są w stanie pomóc, gdy pojawią się duże wyzwania. A one przyjdą.

Nie możesz wtedy zostać z ludźmi, którym strach powierzyć cokolwiek trudnego.