Autonomia vs. Inicjatywa

Aby kontynuować serię na temat autonomii zespołów, chciałbym po Autonomia vs. Zlecenie dodać jeszcze ten ważny aspekt do tematu. Dotyczy on tego, jakie skutki mają w praktyce duże inicjatywy angażujące wiele zespołów.

Czym jest inicjatywa?

Kiedy mówię "inicjatywa", mam na myśli nakład pracy nad produktem, w którym zaangażowanych jest wiele zespołów. Może to być na przykład: przeprojektowanie interfejsu użytkownika strony internetowej, przejście na responsywny design, internacjonalizacja lub wejście na istotne nowe rynki, jak np. Chiny. To wszystko są zasadniczo dość ważne rzeczy, które jednak zazwyczaj wymagają wspólnego wysiłku kilku – jeśli nie wszystkich – zespołów produktowych.

Zasadniczo przebudowa platformy ze względu na lepszą skalowalność lub wydajność – na przykład nowa architektura lub nowe podstawy technologiczne – to także rodzaj inicjatywy. Jednak z tym długiem technicznym postępuje się inaczej i dlatego nie będę go omawiać w tym artykule.

Pomińmy na chwilę kwestię, czy przeprowadzenie danej inicjatywy jest co do zasady dobrym czy złym pomysłem. Ten temat omówiłem już w innym artykule. Przyjmijmy tutaj po prostu, że inicjatywa jest czymś dobrym i ważnym. Chciałbym omówić trzy sposoby, w jakie zespoły mogą radzić sobie z tymi dużymi i złożonymi inicjatywami.

Chodzi o to: z definicji mamy złożony projekt, którym musimy się zająć i w który zaangażowanych jest wiele zespołów. Każdy zespół ma własne szczegóły do wyjaśnienia, ale pytanie brzmi, kto tym wszystkim kieruje i w jaki sposób. Jeśli inicjatywa polega na dostosowaniu oferty produktowej do rynku chińskiego, czy wysyłamy każdy pojedynczy zespół do Chin, żeby dowiedzieć się, co trzeba zrobić? To nie byłoby zbyt sensowne i najprawdopodobniej każdy zespół znalazłby inne rozwiązanie.

Strategia 1: Zespół wiodący

W większości przypadków wybiera się jeden z zespołów, który przejmuje główną rolę i kieruje inicjatywą, czyli przejmuje prowadzenie discovery i delivery. Oczywiście ten zespół jest uzależniony od pracy innych zespołów, ale także kieruje i koordynuje te prace. Na przykład zidentyfikowałby grupę klientów, by następnie z nimi ustalić niezbędne zmiany w produkcie, a potem pomóc w podziale i podjęciu niezbędnych prac (discovery i delivery).

Zaletą tego podejścia jest jasny zakres odpowiedzialności i ownership. Oczywiście należy starać się wybrać zespół wiodący, na który ta praca ma duży wpływ.

Jest jednak też wada tego podejścia. Jeśli bowiem zespół wiodący nie informuje na bieżąco pozostałych zespołów o nowych odkryciach i decyzjach, nie będą one w stanie ich zrozumieć lub będą im się sprzeciwiać w momencie, gdy przyjdzie do podziału pracy. I w tym punkcie autonomia staje się naprawdę wyzwaniem.

Strategia 2: Zespół tymczasowy

W tym podejściu żaden z istniejących zespołów nie jest wyznaczany do prowadzenia inicjatywy. Zamiast tego tworzony jest specjalnie (na czas trwania tej inicjatywy) tymczasowy zespół discovery, który zajmuje się przynajmniej pracami discovery. Zazwyczaj taki zespół składa się z Product Ownera, wiodącego projektanta UX i co najmniej jednego wiodącego dewelopera. Gdy ta grupa zidentyfikuje niezbędne prace delivery i stworzy Backlog Items, członkowie tego tymczasowego zespołu wracają do swoich właściwych zespołów.

Zaletą jest to, że mamy silny zespół z zaangażowanymi ludźmi, którzy mogą skupić się na tej pracy. Wadą jest to, że ci ludzie stosunkowo szybko wracają do swoich własnych zespołów. To właściwie coś dobrego, bo mogą wtedy przekazać swoim zespołom, czego się dowiedzieli i co zdecydowali. Jednak nie ma wtedy już jasnych zakresów odpowiedzialności ani ownershipa. I tutaj również pojawia się ryzyko, że inne zespoły nie rozumieją lub nie zgadzają się z tym, co jest im przekazywane. Kolejną wadą jest to, że wyciągając ludzi z ich zespołów, podważa się cel trwałości zespołów.

Strategia 3: Zjednoczony zespół

Trzecia możliwość podejścia do tych inicjatyw to coś, czego zazwyczaj nie polecam. Muszę to jednak wspomnieć, bo od czasu do czasu się zdarza. W tym podejściu kilka zespołów (niekoniecznie wszystkie) łączy się, aby wspólnie przeprowadzić prace discovery.

Główną zaletą jest to, że wszystkie nowe informacje są udostępniane i ma to bardzo dużą wartość.

Największą wadą jest jednak to, że w podejmowanie decyzji zaangażowanych jest wiele osób, a zbyt wielu kucharzy psuje zupę.

Podsumowanie: Autonomia vs. Inicjatywa

Niezależnie od tego, co wybierzesz, musisz znaleźć rozwiązanie dla inicjatywy i je wdrożyć. To są trzy sposoby, w jakie zespoły mogą sobie z tym radzić. Trudno powiedzieć, że jedno z nich jest lepsze pod względem autonomii od pozostałych, bo inicjatywa polega przecież na robieniu czegoś dobrego dla organizacji, a niekoniecznie na tym, jaką swobodę decyzyjną mają poszczególne zespoły. Być może trafniej jest powiedzieć, że można wybrać jedno z tych podejść, aby zminimalizować poczucie utraty autonomii.

Pamietaj, że te inicjatywy są często niezwykle wartościowe dla naszych klientów i naszej firmy, więc jest z czego być naprawdę dumnym, gdy pomyślnie zakończysz tę inicjatywę.

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