Lokalne optymalizacje

Na każdą organizację można spojrzeć jako na system, który przetwarza pewne sygnały wejściowe na jakieś produkty wyjściowe. W tym sensie organizacja jest zbiorem procesów, mniej lub bardziej powtarzalnych, w których przepływają pewne zlecenia. W przemyśle mają one charakter materialny, namacalny. W pracy intelektualnej (mylonej czasem z biurową) są najczęściej tylko pojęciami takimi jak pojedyncza sprawa, zlecenie, „ficzer” itp. Umownie możemy je nazwać „jednostkami pracy”.

Tak patrząc na dowolną firmę o jej sprawności świadczą dwa najważniejsze parametry: przepustowość (liczba jednostek pracy w jednostce czasu, które firma przetwarza) oraz średni czas przetwarzania (czyli średni czas jaki upływa od rozpoczęcia do zakończenia pracy nad jednostką pracy – oczywiście patrząc z perspektywy odbiorcy). Efektywność to funkcja kosztu – innymi słowy ile kosztuje przetworzenie jednostki pracy – ale z pewnością ma ona związek ze średnim czasem przetwarzania, przeciętnie im szybciej coś jest przetwarzane tym to przetwarzanie powinno być tańsze.

Teoretycznie kierujący organizacją powinni tak działać, by organizacja tak szybko jak to w danej domenie działalności jest możliwe przetwarzała jednostki pracy od wejścia do ukończenia.

Wyobraźmy sobie teraz organizację jako proces składający się z wyróżnialnych kroków wykonywanych przez konkretnych ludzi i z użyciem konkretnych zasobów. Każdy z tych kroków działa sobie jakoś, w swoim tempie, a średni czas przetwarzania całości wynosi X. Co stanie się, jeśli krok C raptownie przyspieszy, a więc stanie się dużo bardziej wydajny od innych? Czy sumaryczny czas przetwarzania wzrośnie czy spadnie?

Wbrew pozorom średni czas przetwarzania wzrośnie. Dlaczego? Bo wyniki pracy kroku C zaczną się odkładać w coraz bardziej rosnącej kolejce przed krokiem D, który nie przyspieszył. Co się podzieje z przepustowością? Pozostanie taka sama, ograniczona możliwościami kroku D.

Taki scenariusz to właśnie lokalna optymalizacja – tylko część całego łańcucha albo procesu usprawniła się bez zmiany w pozostałych. Stan całości organizacji nie uległ poprawie, ale przeciwnie, pogorszeniu.

Jakie to ma przełożenie na nasz świat? Takie mianowicie, że w bardzo wielu miejscach Scrum (czy Kanban) zastosowany w zespołach jest właśnie taką lokalną optymalizacją. Reszta organizacji się nie zmienia, nie zmieniają się zwłaszcza te procesy, które zajmują się wprowadzaniem zmian do użytku. W efekcie co prawda zespoły wytwarzają często wydawalny produkt, działają szybciej, efektywniej – ale korzyści nie widać, bo wydania nadal są tylko trzy razy do roku (i jest na to mnóstwo wspaniałych uzasadnień).

Przy tym lokalna optymalizacja w wytarzaniu oprogramowania jest bardziej zdradliwa niż w fabryce. W przetwarzaniu fizycznych elementów jest ona bowiem widoczna namacalnie. Po pierwsze kolejki wytworzone przez krok, który nagle przyspieszył mają charakter widocznego stosu elementów czy półproduktów, których przechowywanie dodatkowo kosztuje. Po drugie jednak widać wyraźnie, że poprzednie kroki nie nadążają co prowadzi do przestojów na etapie, który przyspieszył, bo zaczyna mu brakować elementów na wejściu (z kroków A i B).

Tymczasem w naszej dziedzinie ten drugi efekt jest rzadziej widoczny, bo zawsze jest pełno pomysłów na ficzery i zmiany, które można wprowadzić do prodktu. Co więcej, jeśli zmiany naprawdę najbardziej wartościowe zostaną załatwione można na lata utonąć w mało wartościowych pomysłach, co jest niestety odruchem w wielu organizacjach zamiast otwartego przyznania, że to, co najważniejsze jest już zrobione i w sumie nie ma uzasadnienia dla utrzymywania dużych zespołów developerskich. Mogłoby to się stać widoczne, gdyby śledzono wartość dostarczaną w funkcji czasu starając się ją jakoś obiektywnie mierzyć, ale z mojej praktyki wynika, że jest to niezmiernie rzadkie.

Podsumowując: przyspieszanie i usprawnianie działania samych zespołów – w czym wiele organizacji celuje w ramach tzw. „wdrożeń Scrum” – poprawia wskaźniki w IT, ale nie przynosi spodziewanych korzyści dopóki pozostaje lokalną optymalizacją a reszta organizacji pozostanie bez zmian. Niestety, nie jest to widoczne bo zawsze jest pełno czekających na jakąś zmianę w produkcie i powstaje złudzenie, że to wciąż za mało tempa i pojemności w developmencie.