Autonomia vs. Zlecenie

W moim ostatnim artykule pisałem o kompromisach między różnymi celami autonomii a zewnętrznym sterowaniem w zespołach. Otrzymałem kilka wiadomości, w których pisano, że jest to duży temat w firmach, i niektóre osoby chciały dowiedzieć się czegoś więcej na ten temat – ale raczej z perspektywy produktu i designu niż z perspektywy rozwoju. Temat jest bardzo różnorodny i dlatego uznałem, że warto go rozwinąć.

Oto kilka kwestii, które chciałbym poruszyć:

• Co jeśli zespół widzi lepszą okazję i decyduje się skupić na innym typie klienta?
• Co jeśli zespół nie chce wykonywać pracy mającej wspierać dużą inicjatywę firmową (np. internacjonalizację produktu)?
• Co jeśli zespół jest przekonany, że musi zmienić kurs, aby wykorzystać szanse na rynku mobilnym, choć jest odpowiedzialny tylko za część całości?
• Co jeśli zespół jest przekonany, że musi przejść na inny design UX, choć różniłby się wtedy od designu innych zespołów?

W każdym z tych przypadków zespół i management mają zapewne zupełnie różne perspektywy. Wiele zespołów twierdzi, że jeśli naprawdę mogą pracować autonomicznie, mogą podejmować takie decyzje.

Problem

W zdrowych zespołach i organizacjach zazwyczaj dochodzi do kompromisu między tymi dwoma podejściami, poprzez przyznanie kierownictwu kontroli nad dwoma kluczowymi punktami w procesie decyzyjnym. Pierwszym jest ogólna wizja produktu, a drugim są konkretne cele biznesowe wyznaczone każdemu zespołowi.

Mogą jednak pojawić się problemy, gdy management nie formułuje jasno tych dwóch kluczowych punktów, gdyż wtedy powstaje szara strefa i nie jest już jasne, co zespół może sam decydować, a co nie.

Wizja produktu opisuje ogólny obraz docelowych klientów i usług, które chce się świadczyć każdemu typowi klienta. Ta wizja produktu ma wspierać strategię biznesową firmy. Jeśli na przykład masz strategię biznesową opartą na modelu sprzedaży low-touch (mały osobisty kontakt z klientem), sprzyja to bardzo konkretnemu rodzajowi wizji produktu. Jeśli zespół chce teraz opracować produkt odbiegający od tej wizji i modelu, będzie bardzo trudno go sprzedać.

Konkretne cele biznesowe są przekazywane zespołom albo w formie priorytetowych KPI (Key Performance Indicators – wskaźniki efektywności) – zwanych też Product Scorecards – albo w formie OKR (Objectives and Key Results), które też prowadzą do różnych KPI. Jeśli celem biznesowym jest na przykład znaczne zmniejszenie wskaźnika odejść klientów, to jest to zlecenie dla zespołu.

Zespoły otrzymują wprawdzie wizję produktu i KPI od kierownictwa, ale nie mówi się im, jak je realizować. To jest punkt, w którym zespół może pracować autonomicznie i elastycznie. Lubię opisywać silne zespoły produktowe jako wspólnoty robocze do rozwiązywania trudnych problemów. Zmniejszenie wskaźnika odejść może być naprawdę dużym wyzwaniem i prawdopodobnie istnieje niezliczona liczba sposobów osiągnięcia tego celu. To samo dotyczy zwiększenia „Customer Lifetime Value" (wartości, jaką klient przynosi firmie przez cały czas trwania relacji biznesowej) lub obniżenia kosztów pozyskania klienta itp.

Wyznaczenie wizji produktu i KPI, różnica między autonomicznymi zespołami a pozostałymi polega na tym, czy firma ma roadmapę czy nie. Jeśli management lub stakeholderzy przedstawiają zespołowi listę wiążących funkcjonalności, na które klienci i stakeholderzy już liczą, zespół ma niewiele przestrzeni do znalezienia najlepszego rozwiązania dla leżących u podstaw pytań biznesowych (nie wspominając o naprawdę fundamentalnych kwestiach).

I właśnie dlatego tak bardzo cieszę się z odrodzenia OKR. Gdy są właściwie stosowane, pomagają bowiem przekierować tę sytuację od outputu (funkcjonalności na roadmapach) do outcome (wyników biznesowych).

2 przypadki specjalne

Istnieją dwa przypadki specjalne, które warto wspomnieć, bo bardzo często powodują napięcia w firmie.

Pierwszy przypadek specjalny dotyczy designu. Nie ma wątpliwości, że posiadanie projektanta w każdym zespole (odpowiedzialnego za funkcje zorientowane na klienta) jest dużą korzyścią dla zespołu i klientów. Ci projektanci tworzą naprawdę ścisłą więź ze swoim produktem i deweloperami i są pełnoprawnymi członkami zespołu. Nie próbują też pracować według modelu przypominającego wewnętrzną agencję designu. Jak jednak można zadbać o to, żeby projektanci chcieli poprawić doświadczenie dla wszystkich użytkowników, a nie tylko dla celów własnego zespołu? Użytkownicy nie dbają o strukturę Twoich zespołów. Jak więc promować samodzielność i jednocześnie zapewniać spójność?

Istnieją różne metody – od wyznaczenia „Design Managera" (lub starszego projektanta), który przegląda i zatwierdza pracę wszystkich projektantów, po jak największą automatyzację za pomocą „Pattern Libraries", „Style Guides" i „Stylesheets".

Mając na uwadze samodzielność i szybkość, preferuję automatyzację, bo dzięki niej zespół stosunkowo łatwo i dobrze radzi sobie z designem (interakcja i wygląd wizualny). Oczywiście od czasu do czasu pojawia się też „Design Debt", tzn. stwierdzamy, że design wymaga przeglądu, i robi się to, gdy tylko problem zostanie zauważony. Lubię to podejście, bo Design Manager co prawda nadal zbiera grupę dobrych projektantów, ale nie musi już uczestniczyć w każdym drobnym przeglądzie (to wszystko spowalnia i podważa autonomię).

Drugi przypadek specjalny to inicjatywy firmowe. To są projekty, które zawsze angażują wiele zespołów. Dość częstym przypadkiem jest internacjonalizacja. Innym jest tzw. „Responsive Design". Jeszcze innym jest poważne traktowanie rynku mobilnego. Myślę, że rozumiesz, o co mi chodzi. W najlepszym przypadku te inicjatywy dobrze wpisują się w priorytetowe KPI każdego zespołu i często istnieje konkretny cel OKR dla tej inicjatywy. Należy jednak być świadomym, że ważna inicjatywa nie zawsze jest wyraźną korzyścią dla każdego pojedynczego zespołu. Mimo to każdy zespół musi wykonać swoje zadanie, bo inaczej inicjatywa się nie powiedzie. Mówię wtedy zespołom, że czasem po prostu trzeba wykonać swoje zadanie jako część całości. Dobra strona jest taka, że te inicjatywy są naprawdę wspaniałe dla produktu i klienta, więc możemy być z tego przynajmniej zadowoleni.

Podsumowanie: Autonomia vs. Zlecenie

Jeśli więc Twoje zespoły nie czują, że mają wystarczającą autonomię, musisz dać każdemu zespołowi jasną wizję produktu i jednoznaczne, spriorytetowane cele biznesowe. Zawarty w tym kontekst jest zleceniem zespołu. Upewnij się, że zespoły rozumieją to zlecenie i daj im jak najwięcej swobody do jego realizacji.

Ten tekst pochodzi z bloga Marty'ego Cagana i został przez nas przetłumaczony na język polski.

Tworzenie wizji produktu

=> Product Vision Canvas - Instrukcja do wizji produktu.

Szkolenie Scrum Master

=> Zostań certyfikowanym Scrum Masterem w Agile Academy!

Właściwe wykorzystanie metryk zwinnych

=> Jakie wskaźniki powinieneś znać jako Scrum Master?