Czy zastanawialiście się kiedyś, dlaczego niektóre zespoły IT są efektywne, a inne borykają się z ciągłym chaosem w pracy?

-
Każdy zespół lepiej czy gorzej ustrukturyzowany czasem boryka się z problemami chaosu i częstej zmiany priorytetów zadań. Przyczyna leży w wielu miejscach, lecz dla większości przypadków rozwiązaniem tego problemu jest zastosowanie odpowiedniej metody komunikacji z interesariuszami wewnętrznymi i zewnętrznymi co przełoży się na możliwość kategoryzacji typów pracy i dobrania do każdego z nich odpowiednich przepływów. 

Kategoryzowanie typów pracy co do zasady daje nam następujące podstawowe korzyści:
  • Zrozumienie charakteru i przepływu pracy.
  • Poprawa sposobu wykonywania pracy
  • Możliwość eliminacji pracy, która nie generuje wartości dodanej
  • Odpowiednie nadawanie priorytetów dla zadań
  • Zarządzanie zasobami przydzielonymi do poszczególnych zadań
  • Poprawa widoczności aktualnie realizowanych tematów co przekłada się na lepszą komunikacją z interesariuszami
  • Możliwość realnego planowania pracy i przedstawiania terminów biorąc pod uwagę obciążenie na kolejne okresy
  • Możliwość eliminacji wąskich gardeł procesu i miejsc powstawania kolejek

Krótka charakterystyka 4 typów pracy

Poniższa definicja została wprowadzona książce "The Phoenix Project (Gene Kim, Kevin Behr, Gorge Spafford) i miała na celu lepsze odwzorowanie typowych zadań realizowanych w IT. Całość oparta jest o dobre praktyki Lean i Kanban. 
  1. Projekty biznesowe  - praca planowana
  2. Wewnętrzne projekt IT - praca planowana
  3. Wszelkiego typu zmiany lub zadania rutynowe, zlecania ad-hoc - praca nieplanowana lub operacyjna
  4. Zadania niezaplanowane, naprawy, przywrócenia stanu środowiska - praca nieplanowana lub operacyjna
Wspomniane typu pracy zostały podzielone na dwie kategorie: praca planowana i praca nieplanowana/operacyjna. Podział ten ma na celu wprowadzenie lepszego zrozumienia genezy powstawania poszczególnych typów i ich oddziaływania pomiędzy sobą. Dlatego też praca planowana to taka, którą wspólnie można wstawić do jednej kolejki i która to realizowana będzie zgodnie z dostępnymi zasobami, priorytetami i terminami. Praca nieplanowana lub operacyjna to tego typu zadania, które są konieczne do wykonania, ponieważ bez nich cała działalność podstawowa mogłaby zostać zagrożona. Ze względu na ich charakter niemożliwe byłoby wprowadzenie ich do wspólnej kolejki z pozostałymi typami. Często zadania niezaplanowane wywłaszczają zasoby, wpływając bezpośrednio na terminowość lub jakość pozostałych typów pracy.

Typy 1,2 i 4 są względnie jasne i nie wymagają dodatkowej charakterystyki, natomiast typ 3 dla wielu organizacji oznacza różne wyzwania w szczególności związane z operacyjnym aspektem działalności. Zadania rutynowe lub zlecane ad-hoc bardzo często są świetnie zdefiniowane pod kątem czynności koniecznych do wykonania, lecz przysparzają one dodatkowych problemów związanych z błędną interpretacją, niezrozumieniem celu realizacji lub też chęcią przemycenia w nich zadań, które powinny zostać wprowadzone do kategorii 1 lub 2 jako planowane. Zdarza się tak, że natłok prac w typie 3 doprowadza do paraliżu pozostałych wątków poprzez wywłaszczenie kluczowych osób. 

Dla przykładu zadania, które często trafiają do typu 3, a powinny do 1 lub 2 to:
  • opracowanie nowego raportu (np finansowego)
  • zadania w obszarze zamykania projektu i transferu otwartych zgłoszeń do innego działu
  • upgrade systemu lub platformy
Przytoczone cztery typu pracy można także scharakteryzować pod kątem złożoności zadań i tak typ 1 i 2 to złożone przedsięwzięcia, które w swoje naturze będą angażowały wiele osób z jednoczesnym występowaniem wewnętrznych zależności. Zadania o typie 3 i 4 to raczej proste jedno lub kilkuosobowe zestawy czynności, które stanowią bezpośrednie wsparcie dla prac sklasyfikowanych w typach 1 i 2 a czasem są one ich częścią.

Czym może skutkować brak planu i chaos w IT?

Sytuacja, w której  zespoły zmieniają często swoje priorytety, przełączając się pomiędzy zadaniami, skutkuje wydłużeniem czasu dostawy i materializacją ryzyka zmiany wymagań. Chaos i ciągła zmiana priorytetów powiązana z ciśnieniem generowanym przez kluczowych interesariuszy doprowadza do paraliżu i dramatycznego zmniejszenia wydajności pracy. Środowisko takie przyczyniać się może do powstawania konfliktów i pogarszając atmosferę w pracy, co jest już tylko małym krokiem do drastycznych decyzji członków lub liderów.

Dlatego też ważne jest odpowiednie ustawienie przepływów i identyfikacja zadań, tak aby całość organizacji osiągnęła stabilny balans. Brak wdrożenia optymalnych procesów i modelu świadczenia usług może skutkować twardymi decyzjami biznesowymi - nawet zmierzającymi do outsourcingu IT w celu poszukiwania lepszego partnera strategicznego dla działów biznesowych.

Jaką strategię przyjąć, aby doprowadzić do likwidacji chaosu w pracy?

Powyżej zdefiniowane typy mają jedną wspólną wadę - prawo Parkinsona, które prawdopodobnie zagwarantuje, że odpowiednio wymiarowane zespoły do zadań nieplanowanych (typ 3 i 4) nigdy nie będą narzekały na nudę. Prawo to pokazuje także, że przyrost czynności nieplanowanych mógłby skłonić do podjęcia decyzji o chwilowym zwiększeniu pojemności poprzez transfer osób z zespołów projektowych. Działanie takie może okazać się trudne do odwrócenia, ponieważ ilość zadań operacyjnych charakteryzuje się innym rozkładem niż zadania projektowe, co za każdym razem będzie generować konieczność zaangażowania dodatkowych osób w ich rozwiązywanie. Rekomendowanym jest rozważne wymiarowanie zespołów i racjonalne podejmowanie decyzji o zwiększaniu lub zmniejszaniu ich pojemności, iluzoryczne szybsze rozwiązanie problemów operacyjnych może skutkować ich zwiększeniem w wyniku realizacji pracy pod presją czasu lub poprzez osoby nieodpowiednio przygotowane. 

Rozwiązaniem tego problemu mogą być stosunkowo proste działania, które mają na celu wdrożenie modelu DevOps przy jednoczesnym braku ingerowania w sposób wytwarzania/dostarczania poszczególnych projektów. Celem poniższych rekomendacji nie jest wyparcie metodyk zwinnych czy tradycyjnych a jedynie wdrożenie modelu, który będzie integrować te działania na poziomie portfela czynności. 

 W zakresie ryzyka wywłaszczenia zasobów i spowolnienia realizacji pracy planowanej (typ 1 i 2) rekomendowane jest przeprowadzenie poniższych zmian:
  1. Utworzenie wewnętrznie w IT zespołu lub zespołów dedykowanych do realizacji zadań nieplanowanych, w przypadku gdy ilość tych zadań jest mniejsza niż możliwości zespołu cześć ich członków, może zostać przeniesiona do realizacji prac planowanych. 
  2. Zadania realizowane na podstawie typu 3 i 4 powinny być zorganizowane w formule przepływu czynności pomiędzy poszczególnymi etapami. Jednym z lepszych sposobów organizacji jest Kanban wraz ze swoimi podstawowymi zasadami:
    • Wizualizacja Pracy
    • Ograniczenie Pracy w toku (WIP – Work-In-Progress)
    • Pomiar i zarządzanie przepływem
    • Określenie procesu (flow)
    • Eksperymentowanie i wdrażanie usprawnień.
  3. Wdrożenie zmian w obszarze czynności prostych i dobrze zdefiniowanych poprzez ich robotyzację, częściowe przeniesienie możliwości realizacji niektórych operacji na zaawansowanych użytkowników biznesowych, a także wdrożenie strategii automatyzacji procesów wdrożeniowych, testowania i utrzymania co przekłada się na mniejsze zaangażowanie zasobów w zadania rutynowe i lepsze skoncentrowanie na możliwościach wdrażania zmian i usprawnień. 

Podsumowanie

Każdy kierownik zespołu dąży do tego, aby jego drużyna i on sam pracował w dobrze zdefiniowanym i niechaotycznym środowisku, w którym może przynosić najwięcej korzyści dla organizacji, i aby realizowane przez niego zadania były dobrze postrzegane przez partnerów. Realizacja tego zadania jest możliwa poprzez zastosowanie metody DevOps i Kanban jako fundamentu pracy wraz z jednoznacznym zdefiniowaniem typów pracy i przydzieleniem odpowiednich przepływów i zasobów do ich realizacji.

Zmian, o której mowa nie powinna być realizowana w zaciszu IT, rekomendowanym jest przeprowadzenie odpowiedniej komunikacji w organizacji i zaangażowanie kluczowych interesariuszy do wspólnego przeniesienia organizacji na kolejny poziom dojrzałości procesowej i operacyjnej. 

Literatura:

Podstawowe założenia, o których napisałem w tym artykule, zostały rozszerzone w dwóch poniższych publikacjach (oczywiście jest wiele różnych pozycji książkowych, które warto przeczytaj, jednak ja polecam na start te dwie):

1. The DevOps Handbook: : How to Create World-Class Agility, Reliability, and Security in Technology Organizations

2. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win 5th Anniversary Edition

Autor:
Cezary Brzozowski