Miłosz KarolczykTeoria Ograniczeń (Theory of Constraints) została opracowana przez dr. Eliyahu Goldratta w latach 80. XX wieku i od tego czasu zdobyła szerokie uznanie jako podejście do zarządzania i identyfikacji kluczowych czynników ograniczających wydajność organizacji. Proces Ongoing Improvement (POOGI) jest kluczowym elementem TOC, który pomaga organizacjom w sposób systematyczny i ciągły eliminować ograniczenia i doskonalić swoje procesy.
Pierwszym krokiem wdrożenia TOC jest zidentyfikowanie ograniczeń, czyli czynników wpływających na wydajność zespołu programistycznego. Ograniczenia mogą być związane z ludźmi, procesami, technologiami lub zasobami. Przykłady ograniczeń to: niewystarczające umiejętności, brak komunikacji między zespołami, problemy z jakością kodu oraz szybkością dostarczania. Właśnie w tym kontekście, POOGI odgrywa ważną rolę, umożliwiając organizacjom skuteczne rozwiązanie wyzwań związanych z ograniczeniami i poprawę wydajności.
POOGI (Process of Ongoing Improvement)
Proces POOGI (Process of Ongoing Improvement) stanowi rdzeń Teorii Ograniczeń (TOC) i zakłada ciągłe doskonalenie procesów w celu zwiększenia efektywności i wydajności organizacji.
5 kroków POOGI:
-
Identyfikacja ograniczenia
W pierwszym kroku kluczowe ograniczenie wpływające na wydajność i efektywność jest identyfikowane. Ograniczenie może być związane z zasobami, przepustowością lub współzależnościami między zadaniami. -
Eksploatacja ograniczenia
Następnie analizuje się wydajność ograniczenia, dążąc do jego maksymalnego wykorzystania, co pozwala na jak najlepsze wykorzystanie dostępnych zasobów i możliwości. -
Podporządkowanie pozostałych procesów
W tym kroku podejmuje się decyzje dotyczące pozostałych procesów i zasobów, tak aby wspierały wydajność zidentyfikowanego ograniczenia. Celem jest optymalizacja pracy w całej organizacji przez dostosowanie się do ograniczenia. -
Podniesienie wydajności ograniczenia
Po optymalizacji procesów dąży się do zwiększenia wydajności ograniczenia, eliminując lub redukując jego wpływ na organizację. -
Powrót do pierwszego kroku
Po usunięciu lub zminimalizowaniu ograniczenia, proces zaczyna się od początku — kolejne ograniczenie jest identyfikowane i cykl doskonalenia jest stosowany. Proces POOGI (Process Of On-Going Improvement) jest kontynuowany w sposób ciągły, aż osiągnięte zostaną optymalne rezultaty.
Co jest istotne w eliminacji wąskich gardeł?
W przeciwieństwie do tradycyjnego podejścia, które skupia się na lokalnych optymalizacjach poszczególnych elementów systemu, teoria ograniczeń skupia się na holistycznym i interdyscyplinarnym podejściu do rozwiązywania problemów.
Optymalizacja wszystkiego na raz może być pokusą dla wielu zespołów programistycznych, jednak taka strategia zazwyczaj prowadzi do rozmycia uwagi, a tym samym do mniejszej efektywności. Skupienie się na najważniejszym wąskim gardle pozwala zespołowi na lepsze zrozumienie istoty problemu, osiągnięcie szybszych rezultatów oraz na efektywniejsze zarządzanie zasobami.
Lokalne optymalizacje, takie jak usprawnianie pojedynczych procesów lub elementów systemu, często prowadzą do powstawania nowych „wąskich gardeł”, czyli ograniczeń, które blokują osiągnięcie pełnej wydajności całego systemu. Teoria ograniczeń zakłada, że aby uzyskać maksymalną wydajność systemu, należy identyfikować i rozwiązywać główne ograniczenia, które blokują jego pełne działanie.
Gdy wąskie gardło zostaje zidentyfikowane i zlikwidowane, zespół może przejść do kolejnego najważniejszego ograniczenia, wprowadzając stopniowe usprawnienia w procesie. Dzięki temu możliwe jest ciągłe doskonalenie i optymalizacja efektywności pracy zespołu, a także unikanie powstawania nowych wąskich gardeł w przyszłości.
W ten sposób teoria ograniczeń wpisuje się w myślenie systemowe, które zakłada, że wszystkie elementy systemu są ze sobą powiązane i wpływają na siebie nawzajem i że optymalne rozwiązanie problemów wymaga uwzględnienia całego systemu, a nie tylko jego poszczególnych części.
Złożoność esencjonalna vs złożoność przypadkowa
Zrozumienie różnicy pomiędzy złożonością esencjonalną i złożonością przypadkową jest kluczowe dla identyfikacji źródeł wąskich gardeł podczas tworzenia oprogramowania.
Złożoność esencjonalna – wynika z samej natury problemu, który próbujemy rozwiązać, i nie można jej uniknąć. Jest to związane z niezbędnymi trudnościami i wyzwaniami, które muszą zostać pokonane, aby osiągnąć żądane rezultaty. Dążenie do minimalizowania złożoności esencjonalnej prowadzi do prostszego, bardziej zrozumiałego i elastycznego kodu.
Złożoność przypadkowa – wynika z nieoptymalnych lub niepotrzebnych rozwiązań, złego projektowania, błędnych założeń czy narzędzi. Jest to złożoność, którą można zredukować lub zlikwidować poprzez refaktoryzację, uproszczenie lub usunięcie niepotrzebnych elementów.
Gdzie najczęściej występują wąskie gardła i jak je eliminować?
Brak kompetencji – szkolenia i rozwój kompetencji
Wspieraj rozwój umiejętności zespołu poprzez szkolenia, warsztaty, mentoring czy naukę samodzielnie. Inwestowanie w rozwój kompetencji zespołu może pomóc w eliminacji ograniczeń związanych z niedostatecznymi umiejętnościami.
Zła struktura organizacyjna – przełamywanie barier organizacyjnych
Często ograniczenia wydajności zespołów programistycznych wynikają z barier organizacyjnych i strukturalnych. Aby efektywnie wdrażać Teorię Ograniczeń w praktyce IT, konieczne jest przełamywanie tych barier poprzez zmiany w strukturze organizacji, komunikacji i procesów zarządzania. Dążenie do większej autonomii zespołów, usprawnienie współpracy między zespołami oraz zmniejszenie biurokracji może pomóc w osiągnięciu lepszych wyników.
Słaba komunikacja – poprawa komunikacji
Wprowadź regularne spotkania zespołu, takie jak codzienne stand-upy, aby ułatwić komunikację i rozwiązywanie problemów. Wspieraj również komunikację między zespołami, aby zapewnić spójność i efektywność organizacji.
Brak wiedzy o tym jaki problem rozwiązujemy – Event Storming (i inne techniki warsztatowe)
Event Storming to warsztatowy proces odkrywania i modelowania domeny, który pomaga w identyfikacji kluczowych zdarzeń, procesów i aktorów w systemie. Podczas Event Stormingu, uczestnicy (programiści, analitycy, eksperci domeny) wspólnie analizują i modelują system, używając prostych narzędzi, takich jak kolorowe karteczki i markery. Event Storming wspiera zarówno Domain Driven Design, jak i Teorię Ograniczeń, ponieważ pozwala na szybkie zrozumienie domeny, wykrycie wąskich gardeł i potencjalnych problemów oraz usprawnienie komunikacji między zespołem a interesariuszami.
Jako technika wspierająca bardzo dobrze sprawdzają się specyfikacje na przykładach (Specification by example, BDD).
Brak zrozumienia domeny biznesowej i kontekstów – Domain Driven Design
Domain Driven Design (DDD) to podejście do projektowania oprogramowania, które koncentruje się na tworzeniu modeli biznesowych opartych na rzeczywistych problemach domeny. W DDD, zespół pracuje ściśle z ekspertami domeny, aby lepiej zrozumieć potrzeby i wymagania systemu. DDD wspiera Teorię Ograniczeń, umożliwiając zespołowi skupienie się na kluczowych aspektach domeny i eliminowanie ograniczeń wynikających z niezrozumienia biznesu i granic kontekstów.
Znamy konteksty, ale w naszym systemie są splątane – modularyzacja
Modularyzacja polega na podziale systemu na mniejsze, niezależne moduły, które są odpowiedzialne za określone funkcje i odpowiadają na konkretne pytania biznesowe. Modularyzacja wpływa na wydajność zespołu programistycznego, ponieważ ułatwia zarządzanie kodem źródłowym, zwiększa skalowalność systemu oraz pozwala na równoczesne rozwijanie różnych funkcji.
W kontekście Teorii Ograniczeń, modularyzacja pomaga w eliminacji ograniczeń wynikających z złożoności systemu, tworzenia silnych zależności między komponentami czy trudności w zarządzaniu kodem. Dzięki modularyzacji, zespół programistyczny może skupić się na optymalizacji poszczególnych modułów, co przekłada się na większą efektywność i wydajność.
Skupiamy się na „walce z technologią”, a nie na rozwiązywaniu prawdziwych problemów biznesowych – minimalizm technologiczny
Minimalizm technologiczny polega na ograniczeniu liczby technologii, frameworków i zależności w projekcie, co pozwala na prostsze zarządzanie i eliminację potencjalnych wąskich gardeł. Im mniej skomplikowane jest środowisko technologiczne, tym łatwiej utrzymać wysoką jakość kodu, szybkość dostarczania oraz lepsze zrozumienie systemu przez zespół. Członkowie zespołu mogą skupić się na prawdziwych problemach biznesowych, zamiast rozwiązywać coraz bardziej skomplikowane problemy techniczne.
Mamy problemy z regresja – testy automatyczne
Testy automatyczne są niezbędne dla utrzymania wysokiej jakości oprogramowania i szybkiego wykrywania błędów. Poprzez automatyzację testów jednostkowych, integracyjnych i funkcjonalnych, zespół może skupić się na rozwoju nowych funkcjonalności, jednocześnie mając pewność, że istniejące nie zostały naruszone. Testy automatyczne przyczyniają się do eliminacji ograniczeń związanych z jakością kodu i czasem potrzebnym na jego weryfikację.
Kod aplikacji przestaje być czytelny i trudno go rozwijać – ciągła refaktoryzacja
Refaktoryzacja to proces systematycznego ulepszania struktury kodu źródłowego, mający na celu zwiększenie jego czytelności i utrzymania, przy jednoczesnym zachowaniu istniejącej funkcjonalności. Regularna refaktoryzacja kodu jest ważnym elementem zarządzania zespołami programistycznymi, gdyż pozwala na eliminację niepotrzebnych zależności, uproszczenie architektury oraz usunięcie złożoności przypadkowej.
Mamy problem ze scalaniem kodu i mnóstwo konfliktów – trunk based development
Trunk Based Development (TBD) to strategia zarządzania wersjami kodu, która polega na ciągłym łączeniu zmian we wspólnym gałęzi (trunk). Dzięki temu podejściu zespoły unikają problemów związanych z długotrwałymi gałęziami, które mogą prowadzić do konfliktów, trudności w scalaniu kodu i opóźnień w dostarczaniu wartości. Wdrożenie TBD pozwala na szybsze wykrywanie i rozwiązywanie problemów, co przekłada się na wyższą wydajność zespołu.
Wdrożenia są skomplikowane i trwają dług – ciągła integracja (CI/CD)
CI/CD to praktyki, które pozwalają na automatyzację procesu tworzenia, testowania i wdrażania oprogramowania. Wdrożenie CI/CD może pomóc w eliminacji wąskich gardeł związanych z cyklem życia oprogramowania, poprawiając tym samym wydajność zespołu.
Mama problem z zarządzaniem nowymi funkcjonalnościami i zmianami – feature flags
Feature flags, znane również jako feature toggles, są jednym z narzędzi, które mogą przyczynić się do redukcji wąskich gardeł w procesie tworzenia oprogramowania. Pozwalają one na dynamiczne włączanie i wyłączanie funkcji aplikacji, umożliwiając ich łatwe testowanie oraz zarządzanie różnymi wersjami oprogramowania.
Dają także możliwość stopniowego wdrażania nowych funkcji, minimalizując ryzyko negatywnego wpływu na użytkowników. W przypadku problemów z nową funkcją można ją szybko wyłączyć, bez konieczności cofania całego wdrożenia.
Feature flags pomagają w skoordynowaniu równoczesnych prac nad różnymi funkcjami przez różne osoby lub zespoły, co sprawia, że są one mniej zależne od siebie. Dzięki temu wąskie gardła związane z koordynacją mogą zostać zredukowane.
Robimy wiele rzeczy na raz, ale niewiele z nich kończymy – Kanban (i inne zwinne metodyki wytwarzania oprogramowania)
Kanban to metoda zarządzania pracą, która ma na celu zwiększenie wydajności zespołu poprzez wizualizację procesów, identyfikację wąskich gardeł i ciągłe doskonalenie. W kontekście Teorii Ograniczeń, Kanban wspiera identyfikację i optymalizację ograniczeń, dostarczając narzędzi do monitorowania postępów, zarządzania przepływem pracy i równoważenia obciążenia zespołu.
Oto jak Kanban może wspomóc Teorię Ograniczeń:
a. Wizualizacja pracy: Kanban Board pozwala na wizualizację wszystkich zadań w procesie, co ułatwia identyfikację wąskich gardeł oraz monitorowanie postępów. Przez wizualizację, zespół jest bardziej świadomy stanu poszczególnych zadań i może łatwiej dostosować priorytety.
b. Zarządzanie przepływem: Kanban opiera się na zarządzaniu przepływem pracy, co oznacza, że zespół dąży do utrzymania stałego tempa pracy i unikania przeciążenia. Ograniczenia pracy w toku (Work in Progress – WIP) pomagają zespołowi skupić się na bieżących zadaniach i szybciej je realizować, co przekłada się na wyższą wydajność.
„Przestań zaczynać, zacznij kończyć!”
Nie wiemy co się dzieje na produkcji – observability
Observability odnosi się do zdolności monitorowania i analizowania działania systemu, pozwalając na szybkie wykrywanie i diagnozowanie problemów, a także dostarczanie informacji na temat jego wydajności. W kontekście Teorii Ograniczeń, observability jest kluczowa dla identyfikacji wąskich gardeł oraz monitorowania postępów po ich optymalizacji. Można to osiągnąć poprzez wdrożenie strategii monitorowania, takich jak logowanie, metryki oraz śledzenie rozproszonych transakcji (distributed tracing).
Wdrażając observability, zespół programistyczny będzie mógł szybciej reagować na problemy, zwiększając tym samym wydajność i niezawodność systemu. Ponadto, lepsze zrozumienie działania systemu ułatwi optymalizację i eliminację ograniczeń.
Nie wyciągamy wniosków z przeszłości – retrospekcje
Retrospekcje są kluczowym elementem w zarządzaniu zespołami programistycznymi, umożliwiającym regularną analizę osiągnięć, wyzwań i obszarów do poprawy. W kontekście Teorii Ograniczeń retrospekcje pomagają w identyfikacji wąskich gardeł i wprowadzaniu zmian w celu ich eliminacji. Zachęcaj zespół do uczciwej i otwartej wymiany opinii oraz konstruktywnej krytyki, aby każda retrospekcja była efektywna i przynosiła konkretne wyniki.
Cztery filary
W 2011 roku Goldratt przedstawił istotę fundamentów TOC w ramach tzw. „4 filarów Teorii Ograniczeń” podczas konferencji TOCICO w Nowym Jorku:
1. Rzeczywistość jest prosta i spójna wewnętrznie
Trzeba odrzucić powszechne przekonanie, że rzeczywistość jest złożona. Nauki ścisłe uczą nas, że wszystko w końcu jest spójne i stosunkowo proste. Goldratt przekonywał, że zasada ta dotyczy również rzeczywistości gospodarczej, a na odkryciu tej „prostoty” opierają się wszystkie stworzone przez niego rewolucyjne strategie.
2. Każdy konflikt można rozwiązać
Nie należy akceptować konfliktów jako części rzeczywistości. W przyrodzie nie występują konflikty, a zdaniem Goldratta podobnie jest w rzeczywistości gospodarczej. Większość firm jest nasycona nierozwiązanymi konfliktami, które uniemożliwiają istotną poprawę. Gdy zrozumiemy konflikt, można go rozwiązać.
3. Ludzie są dobrzy
Nie należy obwiniać innych. Ludzie z natury są dobrzy i jeśli postępują w określony sposób, istnieje na to jakiś powód. Jeśli zrozumiemy prawdziwe potrzeby drugiej strony, zawsze znajdziemy rozwiązanie typu WIN-WIN, które zaspokoi potrzeby obu stron.
4. Nigdy nie mów „Ja wiem”
Nigdy nie należy zadowalać się istniejącą sytuacją jako zadowalającą, nawet jeśli osiągnięto już wiele. W momencie, gdy wydaje się, że możemy powiedzieć „Już wiem”, stajemy się ślepi na nowe możliwości i dlatego powinniśmy mówić „Jednak nie wiem”. Goldratt dowodził, że prawo malejących korzyści nie musi obowiązywać i utrzymywał, że im lepsza jest sytuacja wyjściowa, tym większy potencjał do poprawy. Według Goldratta właśnie ten filar wymaga największej uwagi i doskonalenia.
Podsumowanie
W życiu i pracy czasem napotykamy na przeszkody, które wydają się niemożliwe do pokonania. Teoria Ograniczeń uczy nas, że kluczem do sukcesu jest skupienie się na tym jednym, najważniejszym ograniczeniu, które hamuje nasz postęp.
Podobnie jak w przypadku diety, TOC ważna jest konsekwencja, zaangażowanie oraz systemowe podejście do eliminacji ograniczeń.
Warto przeczytać:
– „Cel 1. Doskonałość w produkcji” – Eliyahu M. Goldratt
– „Cel 2: To nie przypadek” – Eliyahu M. Goldratt
– „Łańcuch krytyczny” – Eliyahu M. Goldratt
– „Projekt Feniks. Powieść o IT, modelu DevOps i o tym, jak pomóc firmie w odniesieniu sukcesu” – Gene Kim, Kevin Behr i George Spafford
– „DevOps. Światowej klasy zwinność, niezawodność i bezpieczeństwo w Twojej organizacji” – Gene Kim, Patrick Debois, John Willis, Jez Humble iJohn Allspaw
– „Domain-Driven Design. Zapanuj nad złożonym systemem informatycznym” – Eric Evans
– „Event Storming” – Alberto Brandolini
– „Team Topologies: Organizing Business and Technology Teams for Fast Flow” – Matthew Skelton i Manuel Pais
