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ę.