Tragedia wspólnego pastwiska w IT

Wyobraźcie sobie jedno pole, kilka grup pasterzy i ich stada. Pole jest wspólne, więc każdy pasterz chce, żeby jego owce najadły się jak najwięcej. Nikt nie odpowiada za trawę.

Po kilku sezonach pole zamienia się w klepisko.

Czym jest tragedia wspólnego pastwiska?

To sytuacja, w której wspólny zasób niszczeje, bo każdy korzysta z niego racjonalnie z własnego punktu widzenia. Garrett Hardin opisał ją w 1968 roku w „Science”. Każdy pasterz, który dokłada jedną owcę, ma z niej cały zysk, a kosztem zniszczonej trawy dzieli się ze wszystkimi. Więc każdy dokłada.

Każdy działa w dobrej wierze i robi to, za co jest rozliczany.

Jak wygląda wspólne pastwisko w IT?

Pastwiskiem jest zespół developerski i jego czas. Pasterzami są interesariusze:

Biznes chce jak najszybciej wejść na rynek. Liczy się Time-to-Market.
Customer Success chce stabilności i szybkich poprawek dla klientów.
Produkt chce nowych funkcji, które wyróżnią ofertę.

Każdy ma swój KPI i każdy ma rację. Tylko że żaden z tych wskaźników nie mówi nic o zdrowiu kodu, architektury i ludzi, którzy to wszystko budują. Wspólny zasób nie ma właściciela, więc nikt go nie broni.

Co dzieje się z pastwiskiem, którego nikt nie pilnuje?

Najpierw rośnie dług techniczny. To erozja gleby: każda szybka łatka, każdy skrót „na teraz” i każdy odłożony refaktoring zabiera trochę urodzajnej warstwy. Przez długi czas tego nie widać. Pole wciąż daje trawę, tylko coraz mniej. Pisałem o tym we wpisie o entropii oprogramowania: system psuje się także wtedy, gdy nikt go nie dotyka.

Potem zespół wchodzi w ciągły tryb kryzysowy. Każdy interesariusz ma pilną sprawę, a wszystkie są „na wczoraj”. Zespół skacze między zadaniami i gasi pożary.

Na końcu przychodzi wypalenie i rotacja. Odchodzą najczęściej ci, którzy najlepiej znali system. Z nimi odchodzi wiedza, a praca zwalnia jeszcze bardziej. Interesariusze widzą spowolnienie i naciskają mocniej. Pętla się zamyka.

Jak zarządzać wspólnym pastwiskiem?

Trzeba dać mu zasady, które obejmują wszystkich pasterzy. Elinor Ostrom, która dostała za badania nad wspólnymi zasobami Nagrodę Nobla z ekonomii, pokazała, że społeczności potrafią dbać o wspólne pastwiska bez prywatyzacji i bez odgórnego nakazu. Warunkiem są wspólnie ustalone reguły, widoczność tego, jak zasób jest używany, i miejsce, w którym rozstrzyga się spory.

W IT przekłada się to na kilka praktyk:

Wspólna strategia. Wszyscy interesariusze wiedzą, dokąd zmierza produkt, i mierzą swoje prośby tą miarą.
Przejrzysty backlog. Jedna lista, którą widzą wszyscy. Każdy wie, co jest przed jego sprawą i dlaczego.
Wspólne KPI. Obok wskaźników każdego działu jest wskaźnik zdrowia całego systemu, na przykład czas od zmiany w kodzie do wdrożenia (lead time for changes) z badań DORA.
Proces priorytetyzacji. Jedno miejsce, w którym interesariusze ustalają kolejność razem, zamiast przekonywać zespół każdy osobno.
Ochrona czasu zespołu. Stała część pojemności idzie na utrzymanie, refaktoring i naukę. Tej trawy nie wypasa nikt.

Interesariusz, który rozumie tę logikę, staje się partnerem w ryzyku, który współodpowiada za stan pola.

Kto ma ostatnie słowo?

To pytanie warto zadać w każdej organizacji. Jeśli priorytet wygrywa ten, kto głośniej krzyczy albo ma wyżej w hierarchii, pastwisko i tak się wyjałowi. Ktoś musi mieć mandat, żeby powiedzieć „nie” także najważniejszemu pasterzowi, i odpowiadać za to, żeby pole dawało trawę za rok.

A u Was kto ma ostatnie słowo, gdy wszyscy chcą wypasać swoje stada na tym samym polu?

Bibliografia

Hardin, G. (1968). The Tragedy of the Commons. Science, 162(3859), 1243–1248.
Ostrom, E. (1990). Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge University Press.
Forsgren, N., Humble, J., Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.

💬 Dołącz do dyskusji na LinkedIn → Komentuj i podziel się swoim podejściem

Ten o wspólnym pastwisku