Autonomia vs. zewnętrzne sterowanie

Niemal każda duża firma technologiczna wskoczyła już do pociągu autonomicznych, zaangażowanych/trwałych, wielofunkcyjnych i dobrze współpracujących zespołów produktowych i uważam, że słusznie. Coraz rzadziej widzi się firmy, które nadal używają starych modeli (głównie modelu puli). Jednak wciąż nie zawsze łatwo jest znaleźć właściwą mieszankę autonomii i zewnętrznego sterowania.

Wyniki mówią same za siebie, jednak większość korzyści przypisuję zwiększonej motywacji i prawdziwemu poczuciu ownershipa, które powstaje, gdy zespoły czują, że mogą same decydować o swojej pracy.

Ale nawet jeśli liderzy zespołów zazwyczaj mówią mi, że ich zespoły są samodzielne i niezależne, od wielu członków zespołów słyszy się, że często postrzegają to inaczej. Gdy tak jest, staram się ustalić, czego dokładnie zespół nie może sam decydować lub w czym czuje się ograniczony.

Gdzie przebiega granica między autonomią a zewnętrznym sterowaniem?

Najczęściej sprowadza się to do jednej z dwóch odpowiedzi:

Albo zespół nie cieszy się jeszcze w pełni zaufaniem kierownictwa i dlatego management nie chce naprawdę dawać członkom zespołu wolnej ręki.

Albo zespół chce zmienić coś, co management traktuje jako element wspólnych podstaw.

Zasadniczo większość zespołów zgodziłaby się, że istnieją zarówno pewne rzeczy, które mogą całkowicie swobodnie decydować samodzielnie, jak i inne obszary, które są częścią wspólnych wymagań wstępnych dla wszystkich zespołów.

Przykład

W tym ostatnim przypadku byłoby na przykład bardzo niezwykłe, gdyby każdy zespół wybierał własne narzędzie do wersjonowania. Jeśli zespół programistyczny na przykład ustanowił GitHub jako standard, jest to zwykle traktowane jako część podstawowych wymagań. Nawet jeśli jakiś zespół miałby silną preferencję dla innego narzędzia, koszty znacznie przewyższyłyby korzyści dla firmy.

Ten przykład jest dość jednoznaczny, ale jest też wiele innych, gdzie nie jest to tak oczywiste.

Czy na przykład każdy zespół powinien móc podchodzić do automatyzacji testów po swojemu? Czy zespoły powinny móc indywidualnie wybierać język programowania? Co z frameworkiem interfejsu użytkownika? Co z kompatybilnością przeglądarek? Co z kosztownymi funkcjami jak „obsługa offline"? Czy powinny same decydować, jak bardzo „zwinnie" pracują? I czy każdy zespół naprawdę musi być zaangażowany w kilka inicjatyw produktowych w firmie?

Jak często bywa w przypadku produktów, ostatecznie sprowadza się to do kompromisu – w tym przypadku jest to kompromis między samodzielnością a przestrzeganiem ustalonych podstaw.

Chociaż generalnie bardzo popieram zasadę autonomicznych i niezależnych zespołów, przyznam, że jestem też wielkim zwolennikiem inwestowania w dobre fundamenty. Dzięki solidnym wspólnym podstawom zespoły mogą bowiem znacznie szybciej tworzyć świetne produkty i doświadczenia.

Chciałbym nieco bliżej omówić ten kompromis. Chcę jednak również podkreślić, że nie twierdzę, że istnieje tylko jedna odpowiedź na to pytanie – może być inaczej w każdej firmie i każdym zespole. Wszystko zależy od różnych czynników, które tutaj omówię:

Punkty, które należy wziąć pod uwagę:

– Kompetencje zespołu:

Ogólnie rzecz biorąc, istnieją trzy różne sytuacje:

Zespół A – doświadczony zespół ze sprytymi i kreatywnymi osobami, któremu można w pełni ufać, że będzie podejmował dobre decyzje.

Zespół B – te osoby mają właściwe intencje, ale w wielu przypadkach nie mają jeszcze wystarczającego doświadczenia, aby podejmować dobre decyzje, dlatego potrzebują jeszcze trochę wsparcia.

Zespół C – junior team, który może nawet nie wiedzieć, czego nie wie. Bez intensywnej opieki te zespoły mogą nieumyślnie powodować poważne trudności.

– Szybkość:

Jednym z głównych argumentów za stałymi wytycznymi jest szybkość. Logika za tym stoi taka, że zespoły powinny być w stanie budować na pracy swoich kolegów, aby nie tracić czasu na wynajdowanie koła od nowa. Jednak w niektórych przypadkach jest ogólnie akceptowane i zwyczajowe, żeby pozwolić zespołom na nieco wolniejsze tempo i ewentualne dublowanie pracy, jeśli sprzyja to samodzielności. Czasem jednak przestrzeganie wytycznych jest niezbędne dla biznesu.

– Znaczenie integracji:

W niektórych firmach portfolio składa się z powiązanych, ale w większości niezależnych produktów, gdzie integracja i wytyczne nie są szczególnie ważne. W innych firmach portfolio obejmuje silnie zintegrowane produkty, gdzie pewne wspólne wytyczne są nieodzowne. Ostatecznie chodzi o to, czy zespół powinien skupić się na jednym konkretnym rozwiązaniu, czy też znaleźć optymalne rozwiązanie dla całej firmy.

– Źródło innowacji:

Jeśli główne źródła przyszłych innowacji leżą już w podstawach, zespoły powinny mieć więcej swobody w przemyśleniu tych podstawowych elementów. Jeśli jednak źródła innowacji leżą na poziomie rozwiązań, zespół powinien mniej skupiać się na podstawach, a bardziej na kreatywnych innowacjach na poziomie aplikacji.

– Wielkość firmy i lokalizacje:

Autonomia często staje się trudna, gdy pojawiają się problemy ze skalowaniem. Gdy firmy rosną i ich zespoły są rozmieszczone w różnych miejscach, ustalenie pewnych podstawowych wytycznych staje się trudniejsze, ale też ważniejsze. Niektóre firmy próbują rozwiązać ten problem koncepcją „Center of Excellence" (centrum kompetencji), grupując w jednym miejscu zespół pracujący wspólnie nad zadaniem. Inne próbują za pomocą bardziej całościowych ról. Jeszcze inne dodają procesy.

– Kultura organizacyjna:

Stosunek autonomii do zewnętrznego sterowania odgrywa ważną rolę również w kulturze zespołu. Im więcej wytycznych narzuca firma, tym bardziej zespoły czują się ograniczone w swojej samodzielności. Dla zespołów B i C może to być jeszcze akceptowalne, ale dla zespołów A jest już nieco problematyczne.

– Dojrzałość technologii:

Zbyt wczesne narzucanie jednolitych podstaw dla wszystkich to częsty problem. Jeśli bowiem fundamenty nie są jeszcze dojrzałe, nie mogą zapewnić wsparcia, do jakiego były przeznaczone. Zbyt duże naciski na wdrożenie wytycznych, zanim podstawy są naprawdę gotowe, mogą naprawdę zaszkodzić zespołom, które muszą się na tych podstawach opierać. To tak, jakby chcieć zbudować coś na chwiejnym domku z kart.

– Znaczenie biznesowe:

Zakładając, że fundament jest solidny, istnieje większe ryzyko dla zespołu, który tych podstaw nie wykorzystuje. W niektórych przypadkach może to nie być wielkim problemem. Gdy jednak chodzi o produkty lub inicjatywy kluczowe dla biznesu, trzeba dobrze przemyśleć, na czym należy się skupić.

– Stopień odpowiedzialności:

Kolejnym czynnikiem jest stopień odpowiedzialności, jaki towarzyszy samodzielności i niezależności. Jeśli zespoły nie mają własnej odpowiedzialności – a szczególnie gdy nie ma silnych zespołów A – nie mają też prawdziwego powodu, aby przywiązywać wagę do tego kompromisu. Chcemy jednak, żeby zespoły zastanawiały się nad tym kompromisem. Jeśli wiem, że zespół jest silny i w pełni zdaje sobie sprawę z ryzyk i konsekwencji, a mimo to chce zignorować lub zastąpić istotny element podstaw, wsperam go w tej decyzji.

Podsumowanie

Jak widać, jest wiele kwestii, które należy wziąć pod uwagę. Moim zdaniem jednak większość zespołów jest bardzo rozsądna, gdy te tematy są omawiane otwarcie. Czasem kilka podstawowych pytań dotyczących skutków wystarczy, aby pomóc zespołowi w podejmowaniu lepszych decyzji w odniesieniu do tego kompromisu.

Jeśli jednak zespoły stale podejmują złe decyzje w tym zakresie, warto ponownie przemyśleć stopień doświadczenia w zespole i być może zainwestować więcej czasu, aby upewnić się, że wszyscy członkowie naprawdę rozumieją wszystkie powiązania biznesowe.

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