Definiowanie struktury organizacji na potrzeby praktyk agile
W przypadku większości organizacji reorganizacja w celu zwinności jest trudna. Wymaga to fundamentalnej zmiany myślenia i transformacji kulturowej, która kwestionuje wiele istniejących zasad, procesów i struktur władzy w organizacji.
Wyzwanie dotyczące transformacji organizacyjnej
Dobry nadzór w organizacjach, szczególnie dużych przedsiębiorstw, często prowadzi do:
- Sztywne struktury hierarchiczne , które spowalniają podejmowanie decyzji
- Przepływy pracy z dużą liczbą procesów , które priorytetują zgodność z szybkością
- Kultury unikające ryzyka, które zniechęcają do eksperymentowania
- Działy silosowe, które optymalizują lokalnie, a nie globalnie
Chociaż większość dużych organizacji nie została w pełni przeniesiona do struktur agile, większość eksperymentuje z podejściami hybrydowymi, ponieważ:
- Środowiska biznesowe są coraz bardziej niestabilne i złożone
- Tradycyjne systemy zmagają się z wymaganiami dotyczącymi szybkich zmian
- Startupy regularnie zakłócają ustalone branże za pomocą elastycznych podejść
- Oczekiwania klientów wymagają szybszej innowacji i reagowania
Strategie transformacji kulturowej
Z hierarchii do sieci
Tradycyjne podejście: Podejmowanie decyzji odgórnych z wieloma procesami zatwierdzania Podejście Agile: Decyzje rozproszone z wyraźną odpowiedzialnością
Kroki implementacji:
- Identyfikacja punktów decyzyjnych, które można przekazać zespołom
- Ustanowienie jasnych granic dla autonomicznego podejmowania decyzji
- Tworzenie ścieżek eskalacji dla decyzji wykraczających poza uprawnienia zespołu
- Trenowanie menedżerów , aby stać się trenerami, a nie kontrolerami
Od procesu do wyników
Tradycyjne podejście: Realizowanie zdefiniowanych procesów niezależnie od wyników Podejście Agile: Optymalizacja pod kątem wyników przy jednoczesnym dostosowywaniu procesów
Kluczowe zmiany:
- Skoncentrowanie się na dostarczaniu wartości biznesowej zamiast ukończenia zadań
- Mierzenie sukcesu według zadowolenia klientów i metryk biznesowych
- Zwiększanie możliwości zespołów w celu modyfikowania procesów, które nie działają
- Regularne retrospektywne identyfikowanie i implementowanie ulepszeń
Modele struktury zespołu: poziomy i pionowy
Zespoły poziome (tradycyjne)
Struktury zespołów poziomych dzielą zespoły według warstw technicznych lub składników architektury oprogramowania. Zespoły są organizowane przez specjalizację techniczną, a nie możliwości biznesowe.
Przykładowa struktura:
- Zespół interfejsu użytkownika: deweloperzy frontonu, projektanci środowiska użytkownika
- Zespół ds. usług: deweloperzy zaplecza, specjaliści ds. interfejsów API
- Zespół danych: administratorzy baz danych, inżynierowie danych
Wyzwania związane z zespołami poziomymi:
- Obciążenie związane z komunikacją: funkcje wymagają koordynacji między wieloma zespołami
- Przerzucanie winy: Problemy często pojawiają się „na styku” zespołów
- Powolna realizacja: Zależności tworzą zatory i opóźnienia
- Ograniczony kontekst biznesowy: Zespoły koncentrują się na problemach technicznych dotyczących wartości użytkownika
Zespoły pionowe (zalecane)
Pionowe struktury zespołów obejmują cały stos technologii i są dostosowane do możliwości biznesowych lub strumieni wartości klientów.
Przykładowa struktura:
- Zespół poczty e-mail: deweloperzy pełnego stosu, projektant środowiska użytkownika, specjalista ds. danych
- Zespół Voice: deweloperzy full-stack, projektant UX, specjalista ds. infrastruktury
- Zespół telewizyjny: deweloperzy pełnego stosu, projektant środowiska użytkownika, inżynier platformy
Zalety zespołów pionowych:
- Pełna własność: Zespoły mogą niezależnie dostarczać kompletne funkcje
- Szybsze wdrażanie: zmniejszenie zależności i przekazywania funkcji
- Lepsza odpowiedzialność: Jasna własność od pomysłu do produkcji
- Skupienie się na kliencie: Zespoły rozumieją kontekst biznesowy i potrzeby użytkowników
- Ulepszona jakość: zespoły są odpowiedzialne za całe środowisko użytkownika
Skalowanie zespołów pionowych
Zespoły pionowe są skalowane wydajniej, ponieważ można dodawać całe zespoły, zamiast próbować koordynować wiele zespołów poziomych. Zamiast zespołów projektowych należy tworzyć zespoły funkcjonalne z długoterminową odpowiedzialnością.
Zasady skalowania:
- Rozmiar zespołu: zachowaj małe zespoły (5–9 osób) na potrzeby efektywnej komunikacji
- Prawo Conway'a: Twoja architektura oprogramowania będzie odzwierciedlać strukturę zespołu
- Minimalizuj przekazywanie: każdy zespół powinien mieć możliwość niezależnego dostarczania
- Usługi udostępnione: tworzenie zespołów platformy do obsługi zespołów funkcji z typowymi potrzebami
