Zespoły Dwóch Pizz: Klucz do Zwinności?

W dzisiejszym dynamicznym świecie biznesu, gdzie zmiany są jedyną stałą, organizacje nieustannie dążą do przyspieszenia innowacji, szybszego wprowadzania nowych pomysłów na rynek oraz efektywniejszego wdrażania zaawansowanych rozwiązań technologicznych. Jednocześnie, nie można zapominać o konieczności budowania bezpiecznych, niezawodnych, zgodnych z przepisami i odpornych na awarie systemów. Brzmi jak proste wyzwanie, prawda? Niestety, nasze dotychczasowe podejście do organizacji i wzmacniania zespołów często staje na drodze do osiągnięcia tych celów. Prawdziwa zwinność nie jest czymś, co można po prostu zamówić lub kupić. Chociaż chmura obliczeniowa, tak jak Amazon Web Services (AWS), z pewnością pomaga w realizacji tych możliwości, sama w sobie nie przyniesie pożądanych korzyści. Co więc przyniesie? Kluczem do sukcesu jest odpowiedzialność i upodmiotowienie zespołów, które są fundamentem wysokowydajnych organizacji zwinnych. W AWS, ten proces zaczyna się od koncepcją, którą nazywamy „zespołami dwóch pizz”. Jako miłośnik i znawca kulinariów, szczególnie w dziedzinie kebabów i pizzy, często zastanawiam się, co sprawia, że niektóre potrawy są idealnie skomponowane, a inne… cóż, potrzebują jeszcze trochę pracy. Okazuje się, że podobne zasady rządzą światem biznesu, zwłaszcza w kontekście organizacji pracy. Dziś zanurkujemy w świat, który na pierwszy rzut oka może wydawać się daleki od kuchni, ale jego nazwa – „zespoły dwóch pizz” – od razu przywołuje smaczne skojarzenia. Koncepcja ta, spopularyzowana przez giganta technologicznego Amazon, nie dotyczy jednak gotowania, a efektywnego zarządzania zespołami, które są na tyle małe, by mogły nakarmić się... dwiema pizzami." + "Czym dokładnie są „zespoły dwóch pizz”? To proste, choć głębokie w swojej istocie pojęcie odnosi się do zespołów, które są na tyle małe, by mogły zostać nakarmione nie więcej niż dwiema pizzami. Zazwyczaj składają się z pięciu do dziesięciu osób. Podobnie jak w dobrze zarządzanej pizzerii, gdzie mały, zgrany zespół kucharzy potrafi przygotować idealne danie od początku do końca, tak i tutaj – kluczem do szybszego działania, bycia bardziej innowacyjnym i efektywnego wykorzystywania nowych, zaawansowanych technologii jest ustanowienie zespołów, które mają jasno określone linie odpowiedzialności za dostarczanie wartości biznesowej i są upoważnione do działania w tym zakresie. To fundamentalna zmiana w sposobie myślenia o strukturze organizacji i zachowaniu, która pozwala firmom osiągnąć prawdziwą zwinność." + "Tradycyjny model organizacyjny, który dominował przez dziesięciolecia, często staje na drodze do realizacji marzeń o zwinności. Wielu menedżerów, w tym ja sam, spędziło niezliczone godziny, próbując udoskonalić model organizacji zdolności IT w dedykowane zespoły oparte na umiejętnościach. Wszystko wydawało się być uporządkowane: wszyscy inżynierowie baz danych razem w jednym zespole, wszyscy inżynierowie jakości w innym, wszyscy inżynierowie oprogramowania w jeszcze innym i tak dalej. Teoretycznie, takie zespoły miały wykorzystywać swoją wiedzę do ustalania standardów i najlepszych praktyk, co miało zapewnić spójność, przewagę techniczną, zmniejszyć ryzyko i obniżyć koszty. I faktycznie, w pewnym stopniu ten model działał – pomógł organizacjom wyeliminować techniczny rozrost i standaryzować określone technologie. Jednakże, nie działa on wystarczająco dobrze dla dzisiejszych wysokowydajnych, zwinnych organizacji. To trochę jakbyśmy w restauracji mieli oddzielny zespół tylko do krojenia cebuli, inny tylko do rozkładania sera, a jeszcze inny do obsługi pieca. Każdy robi swoją część perfekcyjnie, ale czy danie jest gotowe na czas? I czy w ogóle smakuje? Brak wspólnego celu i ciągłego 'podawania sobie składników' tylko spowalnia proces." + "Model organizacyjny oparty na umiejętnościach skupia się na zarządzaniu technologią, zamiast na wykorzystywaniu jej jako katalizatora innowacji i przewagi strategicznej. Innowacje oczywiście się pojawiają, ale mają tendencję do bycia bardziej przypadkowymi, ponieważ zespoły rzadko czują się upoważnione lub oczekuje się od nich innowacyjności. Tradycyjny model oparty na umiejętnościach zmusza przedsiębiorstwa do korzystania z zespołów projektowych, gdzie praca jest rozbijana i rozdzielana między kilka zespołów. Taki model wymaga wielu punktów koordynacji i negocjacji między zespołami w celu ustalenia oczekiwań, priorytetyzacji pracy i synchronizacji dostaw. Jest to niezwykle nieefektywne i podatne na błędy komunikacyjne oraz powolne wykonanie, a zespoły mogą łatwo zostać przeciążone." + "Często nie ma limitu, jak duże mogą stać się te zespoły, niektóre z nich rozrastają się do setek osób. Wyobraź sobie, że próbujesz upiec gigantyczną pizzę, do której przygotowania potrzebujesz setek kucharzy. Każdy dodaje coś od siebie, ale nikt nie widzi całości. Rezultat? Chaos i przypalona skórka, podobnie jak w przypadku ogromnych, niezarządzalnych zespołów IT. Nic dziwnego, że wraz ze wzrostem liczby członków zespołu, istnieje bezpośrednia korelacja ze spadkiem produktywności. Jest to znane jako efekt Ringelmanna, który przypisuje większej wielkości zespołu utratę motywacji i koordynacji. Duże zespoły nakładają duże obciążenie poznawcze na swoich członków. Na przykład, w zespole sześcioosobowym istnieje 15 różnych relacji, które należy utrzymywać. Brzmi jak dużo, prawda? Dla porównania, zespół 25-osobowy ma 300 połączeń, a zespół 50-osobowy ma 1225 połączeń. W moim doświadczeniu, te zespoły oparte na umiejętnościach okazały się suboptymalne. Czy czujesz, że model organizacyjny oparty na umiejętnościach pomaga Ci szybciej budować rozwiązania? Czy poprawia zgodność? Czy pomaga Ci dopasować się do klientów i interesariuszy? Szczerze mówiąc, wątpię w to. Jestem pewien, że trudno jest uniknąć sytuacji, w której zespoły oparte na umiejętnościach stają się wąskim gardłem. Niezwykle trudno jest osiągnąć oszczędności kosztów i standaryzację w takich zespołach, jednocześnie nadążając za tempem reszty organizacji." + "Zespoły oparte na umiejętnościach są nie tylko nieefektywne i trudne do zarządzania. Tworzą również barierę behawioralną dla zwinności. Przy tak dużej wiedzy scentralizowanej w tych zespołach, można by oczekiwać, że sukces jest nieunikniony. Ale w rzeczywistości, staje się praktycznie niemożliwe pociągnięcie kogokolwiek do odpowiedzialności za wyniki. Kto jest odpowiedzialny za to, że pizza trafiła na stół? Kucharz od ciasta? Od sosu? A może kelner? Kiedy każdy ma tylko mały fragment odpowiedzialności, nikt tak naprawdę nie czuje się właścicielem całego dania. W zespołach opartych na umiejętnościach, w jakiś sposób wszyscy są odpowiedzialni za wyniki, a jednocześnie nikt nie wydaje się być odpowiedzialny… cóż, nikt, kto mógłby coś z tym zrobić. W większości przypadków nie ma jednej osoby odpowiedzialnej za dostarczenie, która byłaby również upoważniona do dostarczania. Każdy zespół oparty na umiejętnościach ma wiele zadań, wszystkie konkurujące o ich czas, a jedyna osoba prawdopodobnie skupiona na kompletnym produkcie, kierownik programu lub projektu, często nie może zmienić priorytetów pracy ani zmobilizować zasobów, a zamiast tego po prostu eskaluje problemy." + "Dodatkowo, problem pogłębiają przelotny i fragmentaryczny charakter tych zasobów, ponieważ dzielą swój czas i uwagę, przełączając się z jednego projektu na drugi, co sprawia, że są one prawie zachęcane do nieprzyjmowania długoterminowego podejścia do własności niczego. Widzimy to, gdy odpowiedzialność za inżynierię i operacje spoczywa na dwóch różnych zespołach. Zespoły inżynieryjne budują rozwiązania bez uwzględnienia kosztów lub sposobu, w jaki produkt będzie używany. „To odpowiedzialność Operacji” – mówią. Operacje odpowiadają, budując większą, droższą infrastrukturę, aby „pomieścić słabą inżynierię”. Nikt nie ponosi odpowiedzialności za koszty, każdy robi tylko swoją część. Proces działa zgodnie z projektem, a Ty, jako dyrektor, zostajesz z rachunkiem. Duża wielkość tych zespołów odgrywa rolę w zjawisku psychologicznym zwanym rozproszeniem odpowiedzialności. Im więcej osób jest świadkami zdarzenia, tym mniejsze prawdopodobieństwo, że ktokolwiek podejmie działanie. Ludzie zakładają, że ktoś inny weźmie odpowiedzialność. Dzieje się tak również w tych zespołach; każdy zakłada, że na pewno ktoś inny to naprawi, lub sprawdzi, czy to jest bezpieczne, lub upewni się, że można to wdrożyć do produkcji. Nawet gdy ktoś chce podjąć działanie, jego ograniczone uprawnienia uniemożliwiają mu osiągnięcie znaczącego postępu. Zamiast tego, liderzy tych zespołów są zmuszani do sytuacji, w których decyzje są podejmowane konsensusem lub wymagają ciągłej eskalacji do kogoś upoważnionego do podjęcia działania. To jest bezpośrednie przeciwieństwo upodmiotowienia." + "Aby zarządzać ryzykiem – i zrekompensować rozproszoną odpowiedzialność w zespole opartym na umiejętnościach – czasami tworzymy procesy, które wymagają od zespołów przejścia przez szereg ciężkich ram kontroli opartych na audytach, zatwierdzeń i autoryzacji. Ten proces jest teoretycznie zaprojektowany w celu ustanowienia zaufania i potwierdzenia jakości oraz zgodności projektów poprzez serię list kontrolnych i audytów. Ale w rzeczywistości, jest on zaprojektowany wokół założenia, że deweloper chce pisać niezgodny kod, a celem audytora jest złapanie go. To nieprawda. Zdecydowana większość deweloperów chce pisać dobry kod. Traktowanie ich w ten sposób sprzyja brakowi zaufania między stronami, co pogarsza produktywność. To jakby z góry zakładać, że pizzaiolo chce Ci sprzedać przypaloną pizzę. Taki brak zaufania psuje atmosferę i spowalnia pracę. Ten brak zaufania jest pogłębiany przez brak spójności i wspólnych celów, oraz mentalność „przerzucania przez ścianę” z jednego zespołu do drugiego." + "Struktura organizacyjna oparta na umiejętnościach, z jej fragmentarycznymi liniami komunikacji i wieloma przekazaniami, oddala IT i wzmacnia oddzielenie IT od reszty przedsiębiorstwa. Zespoły są stawiane w sytuacji, w której często prosi się je o dostarczenie czegoś dla klienta, którego nie rozumieją, ani nie rozumieją problemu do rozwiązania. Wyobraź sobie kucharza, który przygotowuje danie, nie wiedząc, dla kogo ono jest i jaki problem ma rozwiązać – czy to ma być szybki lunch, czy elegancka kolacja? Trudno o sukces. Dlaczego tak się dzieje? Przyzwyczailiśmy się do utrzymywania technologii na wyciągnięcie ręki od reszty przedsiębiorstwa. Zaakceptowaliśmy rozproszenie odpowiedzialności i anonimowość zapewnianą przez duże, niejasne projekty, co utrudnia ustanowienie jasnej własności, wspólnych priorytetów i silnego zrozumienia klienta. W próbie przezwyciężenia tego, tworzone są duże biura programów, a do ról pośredników między IT a biznesem zatrudniani są łącznicy ds. technologii biznesowej (lub partnerzy biznesowi). Niestety, te role często nie są w stanie zrobić nic więcej niż przyjmować zamówienia i komunikować status, co prowadzi do większej frustracji i tajemnicy, nad czym pracuje IT. Dodatkowo, inżynierowie są proszeni o robienie trzech rzeczy, których najbardziej nienawidzą: (1) siedzenie na spotkaniach, (2) dostarczanie niekończących się aktualizacji statusu do PMO, oraz (3) komunikowanie się ze sobą. Wszystkie te działania wyciągają informacje od tych, którzy wykonują pracę, zamiast pozwolić im wykonywać pracę." + "Wszystko to sprawia, że praca z IT staje się coraz trudniejsza i często prowadzi do powstania shadow IT (cienia IT). Częściej niż nie, shadow IT pojawia się nie dlatego, że inne działy chcą prowadzić własne IT, ale raczej dlatego, że działy są sfrustrowane opóźnieniami, ograniczoną responsywnością i brakiem przejrzystości ze strony IT, i szukają ścieżki najmniejszego oporu, aby coś zrobić. To jakby klient, zamiast czekać na pizzę z głównej kuchni, sam zaczął sobie ją przygotowywać w biurze, bo tak jest szybciej i bez zbędnych formalności." + "

Porównanie Tradycyjnych Zespołów a Zespołów Dwóch Pizz

" + "

" + "

" + "

" + "

" + "

" + "

" + "

" + "

" + "

" + "

" + "

" + "

" + "

" + "

" + "

Cecha	Tradycyjne Zespoły (Oparte na Umiejętnościach)	Zespoły Dwóch Pizz (Autonomiczne)
Rozmiar	Duże, często setki osób	Małe (5-10 osób)
Struktura	Silosy, oparte na umiejętnościach (np. wszyscy DBA razem)	Wielofunkcyjne, zorientowane na wartość biznesową
Odpowiedzialność	Rozproszona, „każdy jest odpowiedzialny, nikt nie jest odpowiedzialny”	Jasno określona, zespół odpowiada za całość dostarczanej wartości
Decyzje	Konsensus, eskalacja do góry, biurokracja	Autonomiczne, podejmowane w zespole
Komunikacja	Wiele punktów kontaktu, „przerzucanie przez ścianę”	Bezpośrednia, wewnątrz zespołu, z klientem
Innowacja	Przypadkowa, brak zachęty	Wbudowana, oczekiwana, upodmiotowiona
Relacja z Biznesem	Oddzielenie, pośrednicy, brak zrozumienia klienta	Bezpośredni kontakt, głębokie zrozumienie problemów klienta
Motywacja	Niska (efekt Ringelmanna, brak docenienia)	Wysoka (poczucie własności, widoczne rezultaty)

" + "

Często Zadawane Pytania (FAQ)

" + "

P: Czy zespoły dwóch pizz są odpowiednie dla każdej organizacji?
O: Koncepcja ta najlepiej sprawdza się w środowiskach, które dążą do zwinności, innowacji i szybkiego dostarczania wartości. Wymaga jednak zmiany mentalności i kultury organizacyjnej, a nie tylko rozmiaru zespołu. To jak pytanie, czy każdy kucharz powinien być pizzaiolo – nie, ale mały, zgrany zespół zawsze będzie efektywniejszy niż chaotyczna, duża kuchnia.

" + "

P: Jakie są główne wyzwania w przejściu na model zespołów dwóch pizz?
O: Największe wyzwania to zmiana myślenia o odpowiedzialności i upodmiotowieniu, przezwyciężenie oporu wobec decentralizacji władzy oraz budowanie zaufania. Wymaga to również inwestycji w rozwój umiejętności wielofunkcyjnych w zespołach. To trochę jak przekonanie szefa kuchni, że może pozwolić swoim kucharzom na większą swobodę w tworzeniu dań – wymaga to zaufania i wsparcia.

" + "

P: Czy to oznacza koniec specjalistycznych zespołów?
O: Niekoniecznie koniec, ale zmiana ich roli. Zamiast być silosami, mogą stać się centrami wiedzy, które wspierają i doradzają autonomicznym zespołom, zamiast kontrolować ich pracę. Kluczowe jest przeniesienie odpowiedzialności za dostarczanie wartości na małe, wielofunkcyjne zespoły. Możemy mieć wybitnego eksperta od sosów, ale to nie on ma gotować całe danie dla klienta. Jego rola to wspieranie innych, by ich sosy były doskonałe.

" + "

P: Jak mierzyć sukces zespołów dwóch pizz?
O: Sukces mierzy się nie tylko przez dostarczone funkcjonalności, ale przede wszystkim przez wartość biznesową, jaką generują, szybkość iteracji, jakość rozwiązań, zadowolenie klienta oraz zaangażowanie i autonomię członków zespołu. Podobnie jak w restauracji, sukces nie mierzy się tylko liczbą wydanych dań, ale przede wszystkim zadowoleniem gości i tym, czy wracają po więcej.

" + "Wszystko to, co zostało opisane, rozprasza odpowiedzialność i demotywuje członków zespołu, ponieważ często nie ma bezpośredniego związku między wynikami a uznaniem. Wkład pozostaje niedoceniony, nagrody są źle przyznawane, a konsekwencje są łagodzone lub nigdy się nie pojawiają. Potrzebujemy lepszego podejścia. Zadaj sobie następujące pytania:" + "

" + "
• Jakie decyzje podejmujesz jako lider? Czy znajdujesz się wplątany w szczegóły projektu?

" + "

• Czy zespoły działają w tajemnicy przed Tobą, resztą organizacji lub sobą nawzajem?

" + "

• Jeśli Twój projekt jest opóźniony lub system jest wyłączony, czy potrzeba kilku liderów i zespołów, aby to rozwiązać?

" + "

• Czy równie wiele zespołów musi współpracować, aby wydać nową funkcjonalność?

" + "

• Czy w Twojej organizacji powszechne jest zjawisko „shadow IT”?

" + "

" + "Jeśli odpowiedziałeś „tak” na którekolwiek z tych pytań, prawdopodobnie musisz przemyśleć, jak strukturyzujesz swoje zespoły. Jest prawdopodobne, że Twoi deweloperzy nie są upoważnieni do podejmowania własnych decyzji i nie są zachęcani do ponoszenia odpowiedzialności za swoją pracę." + "Dobra wiadomość jest taka, że nie musi tak być. Być może już rozumiesz krytyczne znaczenie odpowiedzialności, własności i upodmiotowienia. A może dopiero zaczynasz zdawać sobie sprawę, że Twoja organizacja boryka się z tymi wyzwaniami. Zidentyfikowanie problemu to połowa sukcesu: nadszedł czas, aby pomyśleć, jak go naprawić. Właśnie dlatego koncepcja zespołów dwóch pizz jest tak potężna – oferuje ona praktyczne sposoby na wbudowanie odpowiedzialności i upodmiotowienia w strukturę zespołu i przekształcenie się w wysokowydajną, zwinną organizację. Przejście na ten model to inwestycja w przyszłość firmy, która pozwoli nie tylko przyspieszyć rozwój, ale także zbudować silniejszą, bardziej zaangażowaną kulturę organizacyjną. Podobnie jak w kuchni, gdzie mały, zgrany zespół potrafi stworzyć kulinarne arcydzieło, tak w biznesie, małe, autonomiczne zespoły są przepisem na sukces. Czas zrezygnować z 'gigantycznych kuchni' pełnych chaosu i postawić na 'kameralne pizzerie', gdzie każdy wie, co robi i czuje się odpowiedzialny za smak końcowego produktu, czyli za dostarczoną wartość biznesową.

Zainteresował Cię artykuł Zespoły Dwóch Pizz: Klucz do Zwinności?? Zajrzyj też do kategorii Gastronomia, znajdziesz tam więcej podobnych treści!