Tebe.blog

Wpis techniczny. Pierwszy na nowym miejscu, po Tebe Gada.

By zespoły były rzeczywiście niezależne potrzebne są spore zmiany w organizacji. Trzeba pokonać kilka barier. Część z nich oparta jest na wieloletnich przyzwyczajeniach i starych sposobach robienia rzeczy.

Pisałem już kiedyś o rozmiarze zespołu – nie może być za duży. Przy większych grupach trudniej buduje się zaufanie i nie da się osiągnąć tzw. bezpieczeństwa psychologicznego. Sprawia ono, że każdy zabiera głos i zapadają lepsze decyzje. W Amazon twierdzą, że jeśli na lunch zespół potrzebuje więcej niż dwie pizze, wtedy jest on zbyt duży.

Photo by Ricardo Frantz on Unsplash

Z drugiej strony członkowie zespołu powinni mieć w sumie wszystkie kompetencje niezbędne do działania. W startupie finansowym Transferwise, który zajmuje się międzynarodowymi przelewami, w zespołach zajmujących się ekspansją są bankowiec i prawnik.

Zespoły zaczynają naprawdę przynosić korzyści, gdy ich wysiłek dotyczy tego, co widzą odbiorcy. Nie są to struktury ani procesy, użytkownicy widzą produkty. Dlatego zamiast pionowych układów opartych na hierarchii mamy grupy zajmujące się tym, co tworzy firma.

Trzeba tak określić zakres odpowiedzialności, żeby zespół mógł działać niezależnie – nie czekając na zgody czy pracę innych. Rzeczy, które wymagają koordynacji zawsze trwają dłużej. Planowanie zajmuje czas, współpraca wymaga komunikacji co daje więcej możliwości popełniania błędów. Na dodatek priorytety koordynujących się mogą być różne.

Przy ustalaniu zakresu „własności” wyzwaniem są aspekty technologiczne, zwłaszcza dla firm rozwijających oprogramowanie. Trzeba tak budować systemy, by składały się z części, w których zmiany można wprowadzić niezależnie. Autonomia nie może przy tym prowadzić do sytuacji, w której tylko ludzie z konkretnych zespołów są w stanie zmieniać i naprawiać swoje części aplikacji. W starszych (co może oznaczać „tylko” 10 lat) i złożonych systemach jest to trudniejsze. Czasem ciężko ocenić, czy większym problemem jest technologia czy bariery związane z lękiem bardziej doświadczonych inżynierów. Nie chcą oddawać odpowiedzialności bojąc się o jakość i bezpieczeństwo.

Wcześniej zapewniały to struktury (jeśli zapewniały) co skutkowało jednak wolniejszym działaniem. Nowy podział idzie w poprzek wszystkiego co dotąd obowiązywało. Lider zespołu zwykle nie jest nawet szefem ludzi, z którymi pracuje. Czasem nawet nikt nie jest liderem, a ta rola na pewno nie musi wynikać z funkcji. Zmienia się odpowiedzialność szefów – w szczególności szef produktu może nie podejmować już samodzielnie decyzji o… produkcie. To celowo przerysowany przykład. Teraz jego zadaniem będzie nauczyć specjalistów od produktu tak działać, by dobrze robili swoje współpracując z zespołem. Nadal do nich będzie należało podejmowanie decyzji o priorytetach, jednak muszą to robić angażując zespół.

Kluczowe jest to „dobrze”. Nie zostawiamy ludzi samymi sobie by w jakiś demokratyczny sposób dla własnej satysfakcji robili co im się podoba. Zadaniem tzw. managementu jest zapewnić, by w swojej kompetencji członkowie zespołów osiągnęli pozwalającą na samodzielność sprawność i „fachowość”. To też kluczowy element – mieć w każdym zespole na tyle dobre kompetencje w danym obszarze, by jego przedstawiciel samodzielnie lub choćby w parze mógł reprezentować swoją dziedzinę. Dlatego zespoły się „buduje” a nie po prostu tworzy inaczej niż dotychczas układając ludzi.

Zespół sam decyduje co i jak robi, a kluczowe w ustalania co te rzeczy mają dać są cele. Cele, a nie szczegółowe plany rozwojowe. Cele, które mówią co chcemy osiągnąć i po czym poznamy, że to się udało. Cele zorientowane na poprawę produktu, która może być mierzona np. popularnością czy parametrami świadczącymi o jakości dla odbiorców. Nie da się uniknąć współpracy i koordynacji między zespołami. W tym również pomagają wspólnie określane cele i działający proces podejmowania związanych z nimi decyzji.

Łatwo powiedzieć „inwestujcie w zespoły”. To jedno z większych wyzwań przed zmieniającymi się firmami: jak ułożyć organizację, by współpraca ludzi o różnych specjalnościach dawała szybko efekty dobre dla klientów i biznesu.

Pisałem już o tym dwa lata temu. Jednak gdy o tym opowiadam w kontekście pracy z celami, dla wielu jest to całkowicie nowy temat. Zespoły zamiast działów? Ale jak to?

Na początek trochę propagandy – „najlepsi już tak robią”. Skuteczne firmy produktowe – Amazon, Netflix czy Spotify organizują ludzi w zespoły produktowe. Zwłaszcza „model Spotify” jest szeroko opisany. Wg badań Deloitte autonomiczne zespoły wielofunkcyjne („cross-functional” – rzadziej przekrojowe lub interdyscyplinarne) to pierwsza z pięciu kluczowych praktyk stosowanych przez dojrzałe firmy po cyfrowej transformacji. Tam działają „zwinne zespoły”.

Team of teams – ilustracja z książki gen Stanley’a McCristala

To co firmy dają klientom i użytkownikom rzadko jest odbiciem struktury organizacyjnej a niemal nigdy nie jest wytworem ludzi jednej specjalizacji. Przykładowy „dział UX” w zasadzie nic nie wytwarza – wartość powstanie dopiero, gdy projekty zostaną wdrożone przez zespół deweloperski. Najlepiej to działa, gdy projektant jest po prostu częścią tego zespołu. To pierwszy powód – dopiero zespół jest w stanie przynieść wartość.

Zwykle taki sposób działania wiąże się z rozwojem oprogramowania, ale nie musi. Polski dystrybutor sprzętu elektronicznego, z którym pracowałem, zdecydował, że w dziale marketingu zorganizuje się w kilka wirtualnych teamów. Jeden z nich może np. odpowiadać za aktywność w social media. Pracownik może być członkiem dwóch teamów. Np. grafik, czy redaktor treści może działać w zespole „socialowym” oraz zajmującym się rozwojem stron WWW z ofertą.

To ilu ludzi mamy do dyspozycji ma mniejsze znaczenie niż szybkość i skuteczność ich współpracy. Lepiej zorganizowany 30 osobowy team może być skuteczniejszy niż dwa razy większy. Zasoby zawsze są ograniczone – nawet na poziomie małej grupy trzeba wybierać w jakiej kolejności realizowane są zmiany. Na szybkość wpływa kilka rzeczy np. to jak ludzie współpracują i czy zespół ma wszystkie niezbędne do wprowadzania zmian kompetencje. Jeśli musi czekać na projekt albo decyzje projektantów, będzie wolniejszy i mniej zaangażowany. Szybkość to powód drugi.

To jak klienci odbierają usługi najlepiej widzą pracownicy na pierwszej linii – pracujący z użytkownikami lub mający dostęp do ich reakcji. Powinni oni móc podejmować decyzje o tym, jak ma działać produkt. Rzadko kiedy lepiej zdecyduje o tym zarząd. Zespół najszybciej lepiej poradzi sobie, gdy nie będzie musiał czekać na zgody z „góry”, która ani nie ma tylu informacji, ani nie będzie w stanie podejmować tylu decyzji. Więcej dobrych decyzji to trzeci powód.

Trzeba podkreślić: nie są to organizowane ad hoc zespoły projektowe, bo logika „zaplanowany efekt + budżet = projekt” oparta jest na fałszywym założeniu, że wszystko przypomina budowanie mostów czy domów. Tu można przewidzieć co się stanie, bo to powtarzalna działalność. Tymczasem często, nie tylko w rozwoju produktów, nie ma takich zależności. Niespodzianki są stałym fragmentem gry, zwłaszcza w czasach technologii.

Dobrze zbudowany, zrównoważony zespół, jest w stanie działać bez nadzoru. Gdy któryś z członków odejdzie pozostała grupa często jest w stanie zapełnić braki. Gdy taki człowiek byłby jedynym „decydentem”, menedżerem czy innego rodzaju „alfą i omegą” – tak często kończymy stawiając na „geniuszy” – to gdy go zabraknie dziura jest trudniejsza do załatania. Ułożenie współpracy w większym stopniu wpływa na skuteczność niż zatrudnianie wybitnych. Geniuszy jest niewielu, wystarczająco dobrych – cała masa. Nie wiem jeszcze jak nazwać ten powód, wygląda na to, że jest czwarty i piąty.

Amerykańscy szpiedzy w czasie Drugiej Wojny zaobserwowali, że 22 letni niemieccy porucznicy byli w stanie skutecznie dowodzić oddziałami, gdy ich dowódcy ginęli. Nie było to możliwe w siłach aliantów. Wynikało z modelu szkoleń i zastosowania taktyki zadaniowej u Niemców, w której definiuje się cele, środki zostawiając w kompetencjach realizujących. Tak właśnie trzeba podchodzić do zespołów – przekazując im odpowiedzialność a nie wyznaczając zadania. O tym wkrótce.

Jest takie powiedzenie, że człowiekowi z młotkiem wszystko przypomina gwóźdź. Ja na koniec mijającego roku wszędzie widzę cele i ich zastosowania. Określanie intencji, precyzowanie celu, mierzenie postępu zmian. Cele w rozwoju produktu mogą stać się uniwersalnym narzędziem.

Projektant zapyta „jakie mamy cele”. Będzie chciał wiedzieć, co chcemy uzyskać zmieniając wygląd strony lub usługę. Powinniśmy to ustalić na początku. Tylko jak to dobrze zapisać?

Można podejść tak: „po czym poznamy, że nam się udało”. To pytanie pomaga w ustaleniu czy zmiany dały efekt. Czy wpłynęły na dające się zmierzyć zachowania użytkowników lub spowodowały wymierne korzyści dla właścicieli. I znowu – jakie wybrać parametry i jak to zapisać? Rozmowa prowadzi nas w kierunku pomiaru.

Pomiar jest ważny, ponieważ nie da się dobrze zdefiniować celu jeśli nie będziemy mieli sposobu jednoznacznego ustalenia, czy został osiągnięty. Należy porzucić subiektywne oceny i zacząć stosować dobrze dobrane miary.

W tym roku cele to dla mnie OKRy – Objectives and Key Results. Skupiłem się na tej metodzie i udało mi się pogłębić ją w różnych kierunkach pracując z zespołami na szkoleniach i warsztatach. Jeśli już coś poznam dobrze, zaczyna mnie ciekawić wszystko co jeszcze może się z tym wiązać.

Znajduję następne – co najmniej dwa – obszary i metody, w których wiedza związana z OKR, celami i pomiarem ich realizacji się przydaje. Pierwszy to priorytetowanie projektów z wykorzystaniem Impact Estimation Table, drugi to metoda opisu potrzeb użytkownika – Jobs To Be Done.

IET opisał w swoich książkach i pracach Tom Gilb, który mówi o sobie, że jest „dziadkiem agile”. Podejście pozwala wybrać zmiany, którymi w pierwszej kolejności warto się zająć. Definiuje się jakie jakości systemu są ważne dla interesariuszy i jak ustalić czy osiągnęły pożądany poziom. Metoda zakłada, że zmierzyć oraz „zkwantyfikować” można wszystko. Gdy np. mówimy o użyteczności to najlepiej znaleźć dla niej konkretny sposób pomiaru – np. czas potrzebny użytkownikowi do zrealizowania zadania.

Ilustracja z przewodnika Intercom.io – przewaga JTBD nad personami

JTBD to podejście opisane przez jednego z mądrzejszych ludzi na planecie – Claytona Christensena. Chodzi o to, by na produkt patrzeć z perspektywy celów użytkowników. Ludzie „zatrudniają” produkty ponieważ w czymś im one pomagają. Format zapisu „Joba” mówi o sytuacji, potrzebie i oczekiwanymi wyniku działania – tak więc o celu użytkownika. To bardziej konkretne niż wykorzystanie opartej na demografii „persony”.

Kolejność taka: ustalamy w czym pomagamy i od czego zależy, czy robimy to dobrze (JTBD), potem oceniamy, które z propozycji rozwiązań wspierają to w największym stopniu (IET).