Ujemna prędkość: jak podnieść granicę złożoności

Osiągnięcie granicy złożoności wydaje się nieuniknione, ale istnieją oznaki pozwalające stwierdzić, że zespół zbliża się do niej. Najpierw jednak muszę zaznaczyć, że nie ma bezwzględnego wskaźnika, który pokazuje, ile dzieli Cię od granicy złożoności, jednak opisane poniżej oznaki mogą pomóc Ci w ustaleniu, ile zostało Ci do tej.

Najbardziej oczywistą oznaką, że zespół osiągnął granicę złożoności, jest to, że spędza więcej czasu na poruszaniu się po złożoności organizacyjnej niż na rozwiązywaniu zawiłych problemów, na których powinien się skupić. Przyjrzenie się tendencjom czasu wdrażania zmian (prędkość) i wskaźników błędnych zmian (jakość) wg DORA pozwala zorientować się, czy zespoły zwalniają, czy przyspieszają. Chociaż na te wskaźniki wpływają też inne elementy, są dobrą oznaką efektywności zespołu.

Zadowolenie programistów jest kolejną oznaką tego, po jak dużej złożoności organizacyjnej muszą poruszać się zespoły programistyczne. W porównaniu z innymi rolami w firmie programiści bardziej lubią spędzać czas na rozwiązywaniu zawiłych problemów, a jednocześnie czują większą niechęć do wykonywania niepotrzebnych zadań, które w tym przeszkadzają. Niski poziom zadowolenia programistów jest dobrą oznaką, że złożoność organizacyjna jest problemem w zespole programistycznym.

Kiedy firmy zdają sobie sprawę, że ich zespoły toną w złożoności, często uruchamiają „projekt upraszczania” mający na celu przywrócenie prostoty w organizacji. Upraszczanie jest strategią przegrywania z dwóch powodów: złożoność rośnie szybciej w porównaniu z tempem upraszczania środowiska przez dowolną organizację, a „projekty upraszczania” funkcjonują w złożonym środowisku, które zgodnie z założeniem mają uprościć.

Częstym punktem wyjścia do upraszczania jest zmniejszenie liczby aplikacji poprzez wycofanie lub konsolidację tam, gdzie to możliwe. Wycofanie aplikacji wymaga od zespołu zrozumienia wszystkich zależności w procesach poprzedzających i następczych, określenia, kto korzysta z aplikacji, jak zastąpić funkcjonalność, gdzie i w jaki sposób zostanie przeprowadzona archiwizacja i migracja danych, a także radzenia sobie z wieloma innymi komplikacjami, które pojawiają się przy tego rodzaju pracy. Niestety znaczące nakłady wysiłku zainwestowanego w ten proces nie są nagradzane równie znaczącym zmniejszeniem złożoności. Istnieje granica liczby aplikacji, które firma może wycofać bez wpływu na podstawową działalność lub środowisko użytkownika, ale nie ma ograniczeń co do liczby nowych komponentów oprogramowania, które inżynierowie mogą stworzyć. W ciągu 12 miesięcy potrzebnych do wycofania jednej aplikacji prawdopodobnie powstały setki nowych mikrousług. Ponieważ prawidłowe środowisko technologiczne rozwija się z czasem, utrzymywanie w środowisku stałej liczby aplikacji lub komponentów oprogramowania w celu zmniejszenia złożoności jest niewykonalne.

Projekty upraszczania zazwyczaj obejmują przekształcenie struktury organizacyjnej w celu usunięcia złożoności przepływu komunikacji. Najmniej skomplikowane struktury organizacyjne obejmują duże zespoły hierarchiczne pracujące w jednym miejscu. Najbardziej skomplikowane struktury organizacyjne obejmują małe, rozproszone i autonomiczne zespoły. Prawo Conwaya pokazuje, że duże zespoły hierarchiczne prawdopodobnie będą tworzyć monolityczne aplikacje, natomiast małe zespoły rozproszone prawdopodobnie będą tworzyć aplikacje wykorzystujące architektury modułowe takie jak mikrousługi. Szybkie wytwarzanie wysokiej jakości oprogramowania jest możliwe dzięki modułowym wzorcom architektury, takim jak architektura mikrousług, co oznacza, że bardziej złożona struktura organizacyjna może prowadzić do sukcesu. Chociaż „uproszczenie” struktury organizacyjnej ułatwia jej zrozumienie, uzyskany efekt projektu uproszczenia jest przeciwny do zamierzonego.

Upraszczanie jest ważne i opłacalne, ale najlepiej sprawdza się jako integralna część ciągłego doskonalenia zespołów programistycznych (i współpracujących ze sobą zespołów), a nie jednorazowe działanie. Upraszczanie może opóźnić osiągnięcie granicy złożoności, ale nie przywróci w organizacji szybkości i swobody charakterystycznych dla startupów.

Aby przywrócić efektywność zespołu programistycznego, organizacje muszą podnieść granicę złożoności. Podniesienie granicy złożoności zasadniczo oznacza zwiększenie złożoności organizacyjnej do poziomu, którego przekroczenie negatywnie wpływa na działanie zespołu, zadowolenie z pracy oraz na jakość oprogramowania i szybkość jego dostarczania.

Inżynieria platform jest ważną koncepcją w dążeniu do podniesienia granicy złożoności organizacyjnej. Silne zespoły inżynierów platform koncentrują się na zmniejszaniu obciążenia poznawczego zespołów programistycznych poprzez oddzielenie złożoności organizacyjnej od ich codziennej pracy. Prawidłowo wdrożona inżynieria platform umożliwia zespołom zrównoważenie wielu wysiłków związanych z rozwiązywaniem zawiłych problemów dzięki mniejszej ilości czasu poświęcanego na poruszanie się po złożoności organizacyjnej.