Kategoria: PL

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.

Gdzie kończy się wsparcie a zaczyna kontrola? Problem z ustaleniem granicy mają nie tylko młodzi menedżerowie. Nawet doświadczeni za często starają się sprawdzać wszystko co tworzą podlegli im ludzie. W ten sposób zmniejszają ich zaangażowanie i spowalniają rozwój.

Co mam zrobić, wszystko gotowe, czekam na zatwierdzenie szefa? To pytanie kierownika zespołu, którego goni termin. Pracujemy nad OKR-ami, swój zestaw ma zamknąć do wtorku, jest poniedziałek wieczorem. Kierownik rozmawiał wcześniej ze swoim szefem, ten przekazał mu uwagi ale umówili się na ostateczne sprawdzenie. Szef ma takich zespołów kilka, z każdym tak robi więc całość się opóźnia.

OKRy to tutaj tylko przykład. Może to być praca nad prezentacją, raportem, projektem, cokolwiek. Sytuacja jest typowa i popularna. Widziałem to w akcji, pytania jak sobie z tym radzić często pojawiają się, gdy opowiadam ludziom o pracy z OKR. Jest kilka sposobów. Brutalny – wysłać bez akceptacji. Można też przewidzieć problem i z góry umówić się, że akceptacja nie będzie potrzebna. Dobrze będzie, jeśli inicjatywa wyjdzie od podwładnego, który powie „słuchaj, uwzględnimy wszystko, będzie ok”. I sam weźmie odpowiedzialność.

Najsensowniej jest jednak, gdy szef pracując z ludźmi daje im odpowiedzialność, za to, co wnoszą.

Ustalanie celów w OKRach to nie tylko format zapisu. Metoda może też wpływać na podejście do pracy z ludźmi. Dobrze wprowadzona zmienia organizację i kulturę. Kluczowe jest tu założenie, że cele w 60 proc. proponowane są oddolnie a swoje zestawy zespoły piszą własnym językiem, dla siebie i odpowiadają za nie. Ten element procesu to jeden z istotnych trybików w maszynie. Inwestujemy w poczucie własności i odpowiedzialność.

Zresztą źródłem problemu jest poczucie odpowiedzialności. W tym przypadku – odpowiedzialności szefa za to co wychodzi od jego ludzi. On chce tylko dobrze, naprawdę. Co więcej, najczęściej intencją jest pomoc, nie kontrola. Niestety w efekcie od ludzi nie wychodzą lepsze rzeczy. Przeciwnie, kontrola opóźnia ich rozwój. Kierownik, który troszczy się o jakość sprawdzając wszystko staje się wąskim gardłem i spowalnia proces. Jego zespoły tak naprawdę nie starają się. Wiedzą, że będą poprawki. Nie wierzą, że są w stanie sprostać i w związku z tym zależy im mniej.

Gdy ludziom nie zależy, strata jest olbrzymia. Trudno też ocenić jaki rzeczywiście jest ich wkład i co by mogli zrobić, gdyby naprawdę poczuli się odpowiedzialni. Tego po prostu nie widać. Jest anegdota o tym jak Eisenhower odsyłał dwukrotnie swoim ludziom pewien raport. Domagał się lepszej jakości. Gdy za trzecim razem napisali, że dali z siebie wszystko, odpowiedział, że teraz może to w końcu przeczytać. W takim podejściu jest większy sens niż w poprawianiu słowa po słowie.

Chodzi o to, żeby dawać odpowiedzialność i oczekiwać pracy najlepszej z możliwych. Oraz pomagać i motywować a nie poprawiać i kryć swoich ludzi za własnymi poprawkami.

Dlaczego szef kryje swoich ludzi? Ponieważ ma w głowie, że to są „jego” ludzie. Sama ta nazwa budzi skojarzenia i zobowiązania. Być może trzeba sobie zadać pytanie, czy naprawdę odpowiadamy za pracę swoich ludzi? Może rolą menedżerów jest przede wszystkim pomagać i stawiać oczekiwania. Natomiast każdy z ludzi jest niezależny i odpowiada za siebie, za to co robi.

Tak powinno się pracować z ludźmi wolnymi.

Pomyślcie o tym.

Przedostatnie zdanie, w tym kontekście, jest zainspirowane tym co kiedyś przeczytałem – jak zwykle – u P. Druckera: [menedżer] „działa nie dlatego, że ktoś tego chce, ale dlatego, że on sam decyduje o tym co musi zrobić – innymi słowy, że działa jak człowiek wolny”. (str 179 „Praktyka Zarządzania” wyd. MT Biznes)