Fundament w rozwoju produktów to autonomiczne zespoły dobrych ludzi, których łączy wspólny cel. To jest tak ważne, że nie wiem jakim cudem jeszcze o tym nie napisałem.
Od kilku tygodni opisuję OKR-y, metodę zarządzania celami stosowaną między innymi przez Google. To dość uniwersalna i pojemna technika. Każdy szef może wykorzystać ją w pracy z podwładnymi. Można jej używać prywatnie, opisując cele osobiste (podziwiam ludzi, którzy to potrafią). Jednak w rozwoju produktów chodzi nam przede wszystkim o stawianie celów dla organizacji i działających w niej zespołów.
Trzeba pozbyć się naiwnej wiary, że praca zespołowa to coś łatwego. Nie wystarczy zorganizowanie spotkania, by rozwiązać problem i coś zrobić. Nie wystarczy zebranie grupy ludzi o różnych specjalnościach, by coś powstało. Nawet – uwaga – jeśli to będą najlepsi na świecie ludzie. Co więcej, zespół supergwiazd będzie działał raczej słabo. Typowe podejście tymczasem jest takie, że gdy jest coś do zrobienia, to trzeba zacząć od zebrania ludzi z różnych kawałków organizacji i zamknięcia ich w jednej sali razem z przewodnikiem zwanym szefem projektu albo podobnie. To za mało.
Zespoły zwykle tracą więcej czasu i dają gorsze wyniki niż powinny. Praktyka i badania pokazują, że praca grupowa bardzo rzadko jest efektywna. „Czysty” brainstorming razem z openspacem dawno już powinny być w pudełku z napisem „majaczenia”. Poczytajcie dobre źródła, choćby HBR (niżej tytuły). Jednym z powodów dysfunkcji zespołów jest tak zwane próżniactwo społeczne. Ludzie nie pracują tak ciężko jak mogą, gdy myślą, że mogą liczyć na innych. Gdy dwóch zawodników ciągnie linę, każdy z nich wkłada w to mniej energii niż gdyby ciągnął sam.
Mimo tego praca w zespołach jest nieunikniona. By działała, muszą obowiązywać pewne reguły. Członkowie grupy muszą mieć wspólny cel i odpowiedzialność oraz uzupełniające się kompetencje. Ważna nie tylko w rozwoju produktów zasada dotyczy rozmiaru. Wiadomo, że każdy nowy członek grupy dodaje jej mniej mocy i wprowadza więcej zamieszania niż poprzedni. Dlatego rozmiar powinien być ograniczony i w zasadzie nigdy nie powinien przekraczać 10 osób. W Amazon mają regułę: team powinno dać się nakarmić dwoma pizzami.
Jesteśmy jednostkami zachowującymi się wg ściśle określonych praw. Coraz więcej wiadomo o problemach jakie sprawiamy w grupie. Gdyby ich nie było, project managerowie, konsultanci i tzw. coachowie scruma nie mieliby nic do roboty. Są w grupach różne role i każdy powinien znać swoją. Inni powinni znać jego rolę. Nie powinno być ludzi, których wkład jest niejasny.
Warto wyróżnić dwie, niekoniecznie oczywiste, ale ważne role. Jedną będzie facylitator. Różnie się go nazywa, ale ktoś musi dbać, by zespół nie wypadł z torów. Ten człowiek ma zegarek i kalendarz i nie waha się ich użyć. Upraszczam, bo naprawdę nie chodzi tylko o pilnowanie czasu i agendy. Drugim powinien być dewiant. Dziwne słowo, ale oddaje sens. Nie możecie mieć zespołu złożonego z ludzi, którzy myślą tak samo. Ktoś musi stawiać wyzwania i myśleć inaczej niż reszta. Myślenie grupowe to powszechna zaraza. To jest temat na książkę i jest kilka ksiażek na ten temat.
I teraz: trzeba budować zespoły i inwestować w to jak działają.
Wszyscy – absolutnie wszyscy – którzy coś piszą sensownego o rozwoju produktów to powtarzają. Kris Gale, VP of Engineering w Yammer, mówi, że budowanie zespołów jest ważniejsze od budowania produktu. Nie powinno się skupiać na produkcie, tylko na działaniu organizacji, która skutecznie buduje produkt. Chris Fry z Twittera pisał, że budowanie zespołów powinno być głównym zmartwieniem w organizacji od kiedy przekracza 40 ludzi. Fry radzi, żeby najpierw inwestować w zespoły, potem im przydzielać zadania. Dopiero taka organizacja się skaluje. Lubię jego porównanie do rzymskich legionów, choć skala jest nieco inna.
W Spotify podstawową jednostką rozwojową jest squad. Działa on jak mini startup, jego członkowie siedzą razem (to bardzo ważne, muszą się znać i na sobie polegać). W idealnej sytuacji squad jest całkowicie autonomiczny. Niektórzy wręcz twierdzą, że produkt powinno się budować modularnie na tyle, by mogły go rozwijać niezależne zespoły. Chcesz szybszego rozwoju? Usuń zależności między zespołami. Bezcenna rada? Ograniczaj rozmiar zespołu. Tylko osoby, które coś robią, żadnych menedżerów. Jeszcze raz: żadnych menedżerów.
Aktualizacja 2022: w 2019 napisałem „Dlaczego zwinne zespoły to konieczność„
Lektury z HBR (należy zaznaczyć i googlać):
Why Teams Dont Work
Discipline of Teams
Six Common Misperceptions about Teamwork
Why Group Brainstorming Is a Waste of Time
Yes, You Can Brainstorm Without Groupthink
Bezcenne źródła nt. pracy zespołów:
Twitter Engineering SVP Chris Fry on the Power of Stable Teams
Scaling Agile at Spotify
Five keys to a successful Google team
Why Yammer believes the traditional engineering organizational structure is dead