Dlaczego zadania IT powinny być krótkie?
Często z pozoru trudny problem, po rozbiciu na mniejsze kawałki staje się prostszy do rozwiązania. W teorii nie powinno to mieć znaczenia. Równie dobrze nierozbite zadania powinno zająć tyle samo czasu i być tak samo skomplikowane jak te podzielone na małe fragmenty. Czas realizacji ani poziom trudności nie uległ zmianie. O co więc tak naprawdę chodzi?
Chodzi o szybsze uświadamianie sobie aktualnego stanu zadania. Jeśli nie wiemy, w którym miejscu wykonywanego zadania jesteśmy – nie możemy odpowiednio reagować. Jest to szczególnie istotne z punktu widzenia kierownika projektu. Głównym czynnikiem tego, czy zadanie jest odpowiednio rozbite jest ilość problemów, które są w nim zawarte. Ważną jest również skala powiązania tych problemów oraz ich zależności między sobą.
Posłużę się przykładem, żeby lepiej zobrazować to co mam na myśli.
Wyobraźmy sobie, że tworzymy system wspomagający monitoring w sklepach, który ma pomagać w identyfikowaniu klientów i dopasowaniu oferty pod ich potrzeby.
#1-Task
Odebranie streamingu z kamery monitorującej, która umieszczona jest przy wejściu do sklepu. Następnie na odebranym obrazie musimy rozpoznać twarz oraz ją zidentyfikować (przypasować do osoby). Klienta oznaczamy etykietą, która za nim podąża na wszystkich nagraniach. Jest to modyfikacja obrazu z kamery z naniesionym identyfikatorem klienta. Zmodyfikowany obraz jest dalej przekazywany do innych części systemu.
Zadanie jest złożone – wynika to z dużego skomplikowania projektu. Nie opisywałem innych elementów systemu, ale zawiera on dużo więcej funkcji na wzór #1-Task. Zadań podobnych do tego z przykładu występuje w projekcie około 30. Każde z nich zawiera mniej lub więcej taką samą część zakresu projektu. Taki podział wydaje się sensowny. Jeśli zastanowimy się głębiej nad zadaniem, możemy zauważyć, że jego zamknięcie rozwiąże więcej niż jeden problem, m.in:
- odebranie streamingu z kamery monitoringu
- rozpoznanie twarzy
- identyfikacja twarzy z osobą
- obsłużenie serwisu dodającego nowego klienta (niezidentyfikowana twarz)
- edycja obrazu – nałożenie etykiety
- przekazanie streamingu w inne elementy systemu
Dopiero teraz można zauważyć faktyczne skomplikowanie zadania i ilość zagadnień, które porusza. Są w nich problemy łatwiejsze i trudniejsze, ale każde z nich narażone jest na potencjalne opóźnienie względem planowanego czasu realizacji. Osoba wyceniająca zadanie prawdopodobnie uwzględniła problemy, które występują w tym zadaniu i całościowa wycena zadania była sumą wszystkich wycen czasowych problemów, które zauważyła osoba wyceniająca.
W tym miejscu warto zaznaczyć, że bardzo często zadania wycenia osoba, która będzie je realizować. Postawione jest przed nią pytanie: “ile ci to zajmie?”. Osoba realizująca zadania w projekcie IT jest programistą (nie analitykiem). Oczywiście, że programiście potrzebne jest myślenie analityczne, ale to nie jest tożsame z rolą analityka systemowego. Programista wyceniający zadanie, nawet jeśli ma dobrze rozwinięte myślenie analityczne – może nie znać całości systemu. Rozpatruje fragment projektu, nad którym będzie pracował. Może zdarzyć się tak, że kontekst zadania nie wskazuje na inne problemu rzutujące na wyceniany fragment projektu – siłą rzeczy, programista nie weźmie ich pod uwagę. Zwrócenie uwagi na te problemy i odpowiednie zbudowanie kontekstu (żeby programista wiedział o co ewentualnie zapytań) leży w obowiązkach analityka, który ma całościowy pogląd na system. Jeśli tego nie zrobi, zrzuca tą odpowiedzialność na programistę, który pomimo tego, że zrobi to najlepiej jak potrafi (z dostępną dla niego wiedzą) – wykona to błędnie poprzez źle skonstruowaną analizę. Istnieje więc ryzyko, że programista nie zauważy wszystkich problemów występujących w zadaniu. Na rzeczy niezauważone nie zostanie przeznaczony czas, ale będzie trzeba go znaleźć żeby wykonać zadanie.
Załóżmy (optymistycznie), że programista przewidział wszystkie problemy występujące w zadaniu. Jeśli nie musimy podać czasu wykonania, każdego z problemów – traktujemy je jako jeden większy problem. Suma czasów cząstkowych problemów jest zaokrąglana – w dół i w górę. Czasami to zjawisko wystarczy by przeszacować lub nie doszacować zadanie. O tym, że przeszacowanie zadania również wpływa niekorzystnie na termin realizacji możesz przeczytać w wpisie o buforach bezpieczeństwa w zadaniach. Mając zaokrąglony czas wykonania z góry wiadomo, że będzie różnił się względem czasu wykonania (na plus lub na minus). Okrągłe liczby kłamią! Dodatkowo istnieje możliwość, że zadania są wyceniane w sposób hurtowy – czyli czym więcej tym taniej. W naszym przypadku taniej równa się szybciej – analogia do mniejszej marży za sprzedaż (taniej, mniejszy zarobek) i wykonania zadania szybciej (optymistycznie). Jest to psychologiczny aspekt, w którym jesteśmy bardziej skłonni do dania rabatu na usługi, jeśli klient weźmie “więcej”. Niestety takie podejście podczas wyceny zadań może wpłynąć na rentowność projektu. Jeśli zadania nie są wystarczająco “krótkie”, “rozbite” – czyli zawierają większą ilość problemów do rozwiązania to zwiększamy ryzyko, że osoba wyceniająca wyceni je hurtowo lub nie przewidzi wszystkich zagadnień.
Gdyby nasze zadanie było podzielone np na podzadania, zawierające po jednym problemie:
- odebranie streamingu z kamery monitoringu – 4h
- rozpoznanie twarzy – 8h
- identyfikacja twarzy z osobą – 18h
- obsłużenie serwisu dodającego nowego klienta (niezidentyfikowana twarz) – 3h
- edycja obrazu – nałożenie etykiety – 6h
- przekazanie streamingu w inne elementy systemu – 3h
Sumaryczny czas zadania to 42h, czyli tydzień roboczy (5 dni po 8h pracy) i 2h dnia pracy w kolejnym tygodniu. Podchodząc do zadań hurtowo, możemy mieć skłonność do zaokrąglenia tego czasu do jednego tygodnia pracy – 40h. W tym przypadku 2h to 4% czasu zadania. Nie jest to dużo, ale jeśli zwiększymy skalę i przekroczymy o 4% milionowy budżet projektu – robi się z tego spora suma.
Pomijając aspekt trudniejszej wyceny tego rodzaju zadań, istnieje jeszcze ryzyko związane z realizacją. Realizując zadanie zawierające mnogą ilość problemów (z których nie zdajemy sobie sprawy) trudno jest nam określić poziom postępu prac. Dzieje się tak ponieważ wiemy o tym, że przed nami są kolejne czynności do wykonania (problemy do rozwiązania), ale nie mają ram czasowych. Jako pewnik, mamy jedynie czas przewidziany na wszystkie z problemów. Będąc w środku złożonego zadania (zawierającego wiele zagadnień) trudno jest określić, w którym miejscu jesteśmy względem całego zadania. Znając czas spędzony nad zadaniem, nie jesteśmy w stanie określić czy podążamy zgodnie z planem – czy wykonujemy zadanie szybciej niż nam się wydawało lub może przeciwnie, czyli mamy do czynienia z opóźnieniem.
Ważną kwestią w tym miejscu, jest interpretacja poziomu zaawansowania wykonania i opóźnienia zadania przez programistę. My jako ludzie, nie lubimy być poddawani karom, ulegać stresowi oraz przyznawać się do błędu – nie robię z tego reguły, ale generalnie jeśli mamy możliwość uniknąć “konsekwencji” naszych czynów – decydujemy się na to. W podjęciu tej decyzji często pomaga nam podświadomość. Niestety ma to przełożenie na realizację zadań. Jeśli wystąpi sytuacja, w której wykonaliśmy 10% złożonego zadania, a poświęciliśmy na to 30% przeznaczonego czasu na całokształt. Mamy około 20% opóźnienia (dla przykładu załóżmy, że wykonanie 1% zakresu zajmuje nam 1% czasu). Będąc w takiej sytuacji, łatwiej nam pójść w tezę, że:
- nie mogę stwierdzić jednoznacznie opóźnienia bo problemy cząstkowe nie mają czasu realizacji. Nie da się przekroczyć czasu, który nie jest zdefiniowany;
- stracony czas na pewno uda mi się zaoszczędzić podczas realizacji kolejnych zagadnień
Do przyznania się do opóźnienia zadania jest potrzebny pewnego rodzaju wysiłek (głównie nastawienie mentalne na trzeźwe ocenienie sytuacji). Jeśli programista w takim przypadku mówi o opóźnieniu, wynika to z tego, że podjął w tym temacie świadomą decyzję, która naraziła go na “konsekwencje”. Konsekwencje ująłem w cudzysłów bo mogą być nieformalne – czyli np wytknięcie błędu programiście, monolog przełożonego o poprawie jakości wyceny itp. Ludzie mają problem z decyzyjnością, szczególnie jeśli z podjęciem decyzji wiąże się ryzyko. W takim przypadku o opóźnieniu dowiemy się w momencie gdy upłynie 100% czasu przeznaczonego na zadanie. Wtedy już nie ma innej możliwości interpretacji tego faktu. Skutkiem jest to, że nastąpiło opóźnienie, któremu można było zapobiec gdybyśmy dowiedzieli się o nim wystarczająco wcześnie. Jednak sytuacja i struktura zadania potoczyła bieg zdarzeń w innym kierunku. Gdyby kierownik projektu dowiedziałby się wystarczająco wcześnie o tym, że programista ma problem z zadaniem mógłby przydzielić kogoś do pomocy rozwiązania problemu lub przepisać zadanie na innego programistę, ewentualnie przebudować projekt, wynegocjować zmianę zakresu z klientem – scenariuszy jest mnóstwo, ogranicza nas wyobraźnia. Jednak po upływie 100% czasu zadania nasze możliwości są ograniczone.
Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯
Podsumowanie
Z teoretycznego punktu widzenia ilość problemów zawartych w zadaniu nie ma wpływu na jego skomplikowanie i czas realizacji. Jednak gdy uwzględnimy w tym “czynnik ludzki” okazuje się, że mnogość problemów w zadaniu może niekorzystnie wpłynąć na realizację i wycenę zadania. Obie te rzeczy działają na naszą niekorzyść. Nie jest to regułą, złożone zadania nie skazują na opóźnienie, są natomiast jedną z przyczyn opóźnień. Układając zadania dla programistów powinniśmy zwracać uwagę jak bardzo złożony jest zakres zawarty w zadaniu. Nie popadajmy też ze skrajności w skrajność – zbyt szczegółowe zadania powodują to, że bardzo ciężko nimi zarządzać i je kategoryzować.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
