fbpx

Wąskie gardła w projekcie IT

Wąskie gardła w projekcie IT

Pewnie nie raz pojęcie wąskiego gardła obiło Ci się o uszy. Nie było to prawdopodobnie związane z wytwarzaniem oprogramowania, a jakąś firmą produkcyjną, ale jednak. Ja pierwszy raz zrozumiałam o co w tym chodzi po przeczytaniu Projektu Feniks. Do dzisiaj jest ona na mojej liście TOP książek. Pokazuje, że wąskie gardła w projekcie IT są ciężkie do zidentyfikowania, ale poświęcony na to czas zawsze jest wart swojej ceny.

Czym jest wąskie gardło

Termin wąskiego gardła pochodzi z teorii ograniczeń inaczej TOC. Jest to pewien element procesu, który spowalnia go i/lub generuje przestoje. Termin ten jest często spotykany w zarządzaniu produkcją, głównie w fabrykach i innych przedsiębiorstwach przesyłowych lub logistycznych.

Wąskimi gardłami możemy zarządzać i nauczyć się je eliminować. Na mojej liście książek do przeczytania w najbliższym czasie znajduje się seria CEL, która opowiada na bazie prawdziwych historii firm produkcyjnych, jak wygląda stosowanie teorii ograniczeń.

Projekt jako proces

W IT od zawsze podejmowany jest temat wytwarzania oprogramowania i metod zarządzania nim. Skoro coś wytwarzamy to musi istnieć na to jakiś proces, a skoro proces to coraz więcej specjalistów od zarządzania zaczęło znajdować analogię między firmami IT, a firmami produkcyjnymi. Czy słusznie? Moim zdaniem jak najbardziej.  Czemu nie korzystać z wiedzy i doświadczenia innych nawet jeśli są z innych branż.

Projekt Feniks

Pierwszy raz z takim spojrzeniem na wytwarzanie oprogramowania spotkałam się podczas lektury Projektu Feniks, który zachwycił mnie od pierwszych stron. Ta książka sprawiła, że w ogóle zaczęłam się interesować zarządzaniem projektem i sposobami na usprawnianiem procesu wytwarzania oprogramowania i zarządzaniem kryzysem.

Świetnie obrazuje dwa główne tematy, zagadnienie wąskich gardeł i zarządzania zmianą. Do tego wszystko ubrane się w ciekawą fabułę.

Jak znajdować wąskie gardła w projekcie IT

Metody zarządzania projektem takie jak Scrum czy Kanban wspierają identyfikacje wąskich gardeł. Tablica kanbanowa bardzo szybko pokaże nam, kiedy zadania są zawieszone zbyt długo w jednym stanie. Za to na daily na bieżąco możemy zgłaszać blokady. Najczęstszymi wąskimi gardłami bywają:

  • Maszyny

Pierwszą rzeczą jaka przychodzi mi na myśl to sprzęt. W trakcie pracy nad projektami często wszystko jest na już. Zawsze jednak przychodzi taki czas, kiedy w komputerze członka zespołu kończy się miejsce na dysku lub procesor jest za słaby albo zaczyna doskwierać zbyt mała pamięć RAM. Wtedy musimy liczyć się z tym, że wyskakuje nam pół dnia lub dzień jego pracy, aby ten problem rozwiązać i nigdy nie ma dobrego momentu, żeby to zrobić.

Musimy jednak pamiętać, że czasami ten jeden dzień to mniejsza strata niż obniżona wydajność jednego członka zespołu przez najbliższe miesiące.

  • Członkowie zespołu

W codziennej pracy spotykamy ludzi o różnych charakterach i umiejętnościach. Każdy ma inną wydajność oraz sposób pracy. W zespole trafią się nam osoby szybko radzące sobie z zadaniami, rewelacyjnie działające w stresie i szybko znajdujące rozwiązania. Choć często te osoby są również mniej skrupulatne i dokładne w tym co robią.

Trafimy także na takich, którzy realizują zadania znacznie wolniej od tych pierwszych. Analizują dogłębnie całą sytuację zanim dokonają zmiany. Przygotowują sobie różne schematy i parę razy upewnią się, że na pewno to co rozrysowały i wymyśliły jest tym czego się od nich oczekuje. A czas leci. Często takie osoby są postrzegane właśnie jako wąskie gardła procesu. Ja się z tym jednak nie mogę zgodzić, ponieważ jest to patrzenie zerojedynkowe. OK, proces jest wydłużony z powodu długiej realizacji, jednak takie zadania zwykle już nie wracają do poprawki z testów, czyli zyskujemy na innym etapie.

Członków zespołu jako na wąskie gardło możemy traktować nie tylko jednostkowo, ale i grupowo np. frontowców, backendowców czy testerów. Tak zdarza się najczęściej, że wąskim gardłem nie jest jednostka, a grupa odpowiadająca za cały etap wytwarzania oprogramowania. Jeśli pracujesz w IT na pewno nie raz spotkałeś się z sytuacją, kiedy zadania notorycznie utykały w testach lub czekały na frontowca, bo był jeden na trzech backendowców i zwyczajnie nie wyrabiał.

  • Automatyzacje

Możesz to uznać za śmieszne, ale tak, to nie pomyłka, automatyzacje również mogą być wąskim gardłem projektu. Przykładowo, kiedy build wykonuje się 30 minut, a zgodnie z naszą konfiguracją dzieje się to po każdym pushu na branch zadaniowy to nie trudno wyobrazić sobie sytuację, kiedy to kolejka buildów się zapycha nawet przy niewielkim zespole.

Build zakończony sukcesem często jest elementem wymaganym do zmergowania zadnia na branch rozwojowy. W sytuacji, kiedy formatowanie nie jest zgodne ze standardem, lokalnie przed pushem programista nie uruchomił analizy, to dowiedział się o tym po 20 minutach zamiast po 2, gdyby to zrobił lokalnie. Poprawia formatowanie i znowu czeka 30 aż zakończy się build. Tym sposobem zanim zmerguje zadanie mija prawie godzina. 

Rozwiązaniem jest oczywiście optymalizacja buildów, aby nie trwały tak dużej ilości czasu oraz zastanowienie się nad tym czy konfiguracja odpalająca build po każdym pushu jest słuszna i potrzebna.

  • Klient

Wąskim gardłem możemy być również klient. Objawia się to na kilka sposobów. Pierwszy to decyzyjność klienta, jest powiązany z następnym przykładem wąskiego gardła. Zdarzają się klienci niezdecydowani albo co gorsza często zmieniający zdanie co generuje brak płynności procesu. Aby temu zaradzić potrzebny jest sprawny PM lub Product Owner, który będzie potrafił doradzić klientowi, a nawet lekko nim kierował, aby ten proces decyzyjny i ustalanie priorytetów usprawnić już u klienta w firmie, a nie na poziomie zespołu.

Drugi przypadek, czyli mało dostępny klient. To taki, który na każdego maila odpowiada po tygodniu, a telefonu nie odbiera, tylko oddzwania po dwóch dniach. Tutaj jedynym rozwiązaniem jest szczera rozmowa i uświadomienie klientowi konsekwencji jego działania i ich wpływ na deadline.

  • Proces decyzyjny

 O procesie decyzyjnym u klienta pisałam wyżej, jednej podobne sytuacje mogą zdarzyć się również po stronie zespołu. Często przyczyna leży w niejasnej hierarchii lub procesie podejmowania decyzji.

Kolejnym powodem może być to brak zastępowalności członków zespołu. Dobrze mieć w zespole specjalistów, jednak pamiętajmy, że zakres prac każdego z nich nie może być uzależniony wyłącznie od niego. Nie możemy dopuścić do sytuacji, aby wypadek losowy, grypa żołądkowa czy inne problemy zdrowotne mogłyby zatrzymać projekt. Zawsze musi być ktoś drugi, kto jest w stanie chociażby tylko w kryzysowej sytuacji ugasić pożar.

Podobnie, jeśli chodzi o decyzyjność. Każdy z członków zespołu powinien mieć zakres odpowiedzialności, a co za tym idzie również decyzyjność w tym zakresie. Zdarza się, że z każdą pierdołą zespół biega do lidera, aby podjął decyzje. Lider to też człowiek i ma prawo np. do urlopu. Z resztą nawet gdyby był codziennie w pracy przez cały rok. Decyzyjność lidera polega na tym, że ma decydujący głos, a nie jedyny w zespole.

Możliwe rozwiązania

Skoro wiemy już, gdzie mogą pojawiać się wąskie gardła w projekcie IT to teraz podrzucę Wam kilka moich sposobów na radzenie sobie z nimi. To są oczywiście tylko wybrane rozwiązania. Każda sytuacja jest inna i do każdej należy podchodzić indywidualnie. Zaczynaj zawsze od tych mniej oczywistych, ponieważ na te proste rozwiązania zawsze będzie czas.

  • Dodanie zasobów – to chyba najprostszy sposób, jeśli wąskim gardłem jest przepustowość, czyli ktoś nie wyrabia. Jednak z doświadczenia wiem, że to oczywiste rozwiązanie nie jest najlepsze. Problem zwykle jest ukryty gdzieś głębiej.  To doraźny sposób, na który zawsze jest czas. Jeśli ono przychodzi Ci do głowy zastanów się czy w zbyt małych zasobach właśnie jest problem.
  • Udrożnienie przestojów – inaczej mogłabym to nazwać proporcją zasobów. Kiedy w projekcie pojawiają się przestoje to często wynika to ze złych proporcji zasobów np. zbyt dużo backendowców względem frontowców lub za dużo programistów, a za mało testerów, którzy często mogą dodatkowo nie mieć wsparcia dzięki automatyzacjom. Udrożnieniem nie zawsze jest wyrównanie proporcji, ponieważ sytuacja może jest jedynie czasowa. Innym rozwiązaniem może być dobór innych proporcji zadań na sprint, jeśli pracujemy w scrumie. Może warto zastanowić się czy przestoje nie wynikają z tego, że wzięliśmy np. dużo zadań frontowych, a zbyt mało backendowych, albo wzięliśmy same kobyły, gdzie po ich realizacji tester musi przetestować cały system wzdłuż i w szerz kilka razy, a nie ma grama testów do tego.
  • Zwiększenie ilości maszyn lub ich ulepszenie – to rozwiązanie doraźne, które często pomaga w problemach ze sprzętem lub z automatyzacjami. Czasami nie ma innego rozwiązania właśnie przy tego typu wąskich gardłach jak zwiększenie możliwości maszynowych.
  • Optymalizacja – zanim zaczniemy dokładać maszyn czy podnosić parametry sprzętowe zastanówmy się czy nie zacząć od optymalizacji procesów. Wspominałam już o tym wyżej. Jeśli build aplikacji trwa 30 minut, przez co zapycha się kolejka, a przyrost spada, bo programiści czekają po 40 minut zanim będą mogli coś zmergować to pierwszym krokiem powinno być zastanowienie się nie nad tym jak podnieść wydajność maszyn, żeby obsłużyły taką ilość kolejek, a nad tym jak zoptymalizować build żeby nie trwał tak długo albo nie był tak często odpalany.

Wszyscy znamy przysłowie lepiej zapobiegać niż leczyć. W przypadku wąskich gardeł jest to bardzo ciężkie, ponieważ jest wiele zmiennych, które mogą je generować. Zawsze jednak warto próbować. Znając przyczyny tworzenia się wąskich gardeł starajcie się brać je pod uwagę jako prawdopodobne zagrożenia. Nie ma jednak złotego rozwiązania, ale sama świadomość ich wystąpienia i umiejętność reagowania na nie, jest już czymś bardzo cennym.

Zgarnij darmowy ebook i cotygodniową dawkę wiedzy

.
Tags:
Magdalena Limanówka-Kuciel
magdalena@panizkomputerem.pl

Jestem programistką, która lubi mieć ręce pełne roboty. Do życia potrzebuje komputera z internetem i kubka gorącej kawy. Więcej na stronie o mnie.