Prowadzenie projektów IT jest naszpikowane procesami analitycznymi a praca programistów nie polega już tylko na produkcji kodu. Są oni wciągani w wiele aktywności, które są im średnio do szczęścia potrzebne, jak np. słynne spotkania które mogłyby być mailem. Na stale podpięci do kroplówek wpychających najczęściej niepotrzebne powiadomienia walczą o czas w którym „w końcu można napisać jakiś kod”. O ich czas, a właściwie jego zagospodarowanie, ma zadbać kolejne narzędzie – licznik czasu pracy (ang. time tracker).
Rozpraszacze
Każda „przeszkadzajka” w pracy to dla programisty realny problem. Problem, można by rzec, zdrowia psychicznego. Powiadomienia na Teams, spotkania w kalendarzu czy wiadomość od kogoś z rodziny lub znajomego – normalna rzecz. Jednak żadna z nich, jakkolwiek bardzo przydatna i wygodna, nie sprzyja skupieniu się nad problemem z zadania.
Praca z nosem w monitorze również nie sprzyja, tym razem zdrowiu fizycznemu. Czyli świadomie trzeba robić przerwy na kilka minut, żeby złapać oddech, żeby wzrok odpoczął, i tak dalej.
Time tracker – kolejny rozpraszacz
Przez każdego uwielbiany. Z niecierpliwością szukasz przycisku „Play” zaraz po otwarciu zadania, bo dziś, w 8 godzinnym dniu pracy, zostało jeszcze do zalogowania tylko 8 godzin…
Jak pokazuje doświadczenie, używaniem pomiaru czasu bardzo żywo zainteresowana jest kadra kierownicza. Co ciekawe, po drugiej stronie „barykady” jest całkowicie odwrotnie. Co jeszcze bardziej ciekawe, ci pierwsi praktycznie nigdy nie używają tego narzędzia a jedynie przeglądają wyniki 😉
Time tracker – idea
Założeniem pomiaru czasu jest najczęściej… no cóż, kontrola. Zwykle spięte jest to z estymatą zadania, czyli pewnym mniej lub bardziej abstrakcyjnym okresem czasu zaplanowanego na jego wykonanie. Dzięki temu można dokonać dwóch ocen:
- Czy pracownik wykonuje swoją pracę,
- Czy czas spędzony nad zadaniem pokrywa się z czasem zaplanowanym.
Obie te oceny mają na pierwszy rzut oka negatywny wydźwięk względem pracownika, czyli w tym przypadku programisty. Mogą (bardzo szybko) prowadzić do następujących wniosków:
- Programista nie spędził tyle czasu nad zadaniem ile powinien,
- Programista źle ocenił (zaplanował) czas trwania zadania.
Od strony kierownika wygląda na to, że pracownik kolokwialnie mówiąc „obija się” a jego kompetencje nie są na najwyższym poziomie, skoro nie potrafi ocenić czasu potrzebnego na wykonanie zadania. W relacji nie-techniczny kierownik i inżynier, ten pierwszy może czuć się notorycznie oszukiwany.
Natomiast programista może bardzo szybko dojść do wniosku że każde najprostsze zadanie stanowi potencjalny problem, nawet jeśli się jeszcze nie zaczęło. Po pierwsze, trzeba wydać ocenę – estymatę. To nie jest takie proste. Po drugie, w trakcie zadania usłyszy pytanie „no ile jeszcze” – znów trzeba podjąć decyzję. Po trzecie, podczas przekraczania estymaty należy wytłumaczyć w żołnierskich słowach skąd taka „obsuwa”. Kluczowym problemem jest niezrozumienie czym estymata nie jest – a nie jest niczym dokładnym.
Time tracker – pierwsze starcie
Zwinne prowadzenie projektów IT wymusza określanie estymat – potrzebujemy jakiegoś sposobu na zaplanowanie pracy. Następnie chcemy monitorować, czy nadal mieścimy się w założeniach. Do tego zaprzęgniemy licznik czasu pracy nad zadaniami. To naturalna sprawa, nie chcemy przecież skończyć na koniec sprintu/tygodnia/miesiąca z nieukończoną połową zadań.
Początek kolejnego okresu w projekcie wygląda w skrócie tak:
- Określamy ile czasu zajmą poszczególne zadania (nasz koszt),
- Określamy ile czasu mogą poświęcić pracownicy (nasz budżet).
I teraz albo zaczynamy ciąć koszty, albo próbujemy powiększyć nasz budżet. Nie muszę mówić, że nieumiejętne posługiwanie się którąkolwiek z tych opcji prędzej czy później da o sobie znać.
Cięcie kosztów
Jak możemy skrócić czas wykonania zadania? Ano zmniejszając jego zakres. Jeśli zrobimy to na etapie planowania, są trzy opcje:
- Klient zrezygnuje z części wymagań – ryzyko mniejszego zarobku lub niezadowolenia,
- Zaciągniemy dług technologiczny – zapewniamy sobie problemy w przyszłości.
Pierwszą opcję firma może przegadać z Klientem (np. przesuwając część zadania na kolejny okres), wziąć na swoje barki lub mieć wliczone w ryzyko. Do wypracowania. Niestety druga opcja ma bezpośredni, negatywny wpływ na pracowników. Koszt utrzymania projektu zwiększa się – rosnący dług technologiczny zaczyna np. wydłużać realizację zadań. To oznacza że nawet doświadczony pracownik może mieć problem z zaplanowaniem czasu zadań. Dla mniej doświadczonego projekt jest czarną skrzynką. Co ciekawe, druga opcja jest znacznie częściej wybierana.
Zwiększanie budżetu
Nasz budżet „wytwarzają” pracownicy. Jak go zwiększyć? Ano można zwiększyć ilość pracowników lub wydajność tych obecnych. Pierwsza opcja jest nieciekawa, bo istnieje wysokie ryzyko że nadmiar pracy szybko się skończy (tak, to realna obawa), po za tym zdobycie pracownika to kosztowny proces. Druga opcja wygląda idealnie. Co ciekawe, zwykle zaczynamy od bardzo optymistycznej i bardzo błędnej wyceny możliwości naszego budżetu:
- Pracownik w 8 godzinnym dniu pracy poświęca na zadania 8 godzin,
- Pracownik jest zawsze dostępny.
Doświadczenie pokazuje że pracownik (nie tylko IT) jest w stanie pracować nad konkretnymi zadaniami przez około 6 godzin w ciągu dnia pracy. Jest to spowodowane wieloma czynnikami, m.in. pracą umysłową nad złożonymi problemami (nasz mózg ma pewne ograniczenia jak się okazuje 😉 ). Zakładanie więc że na zadania możemy rozdysponować 8 godzin dziennie na pracownika jest błędne (tudzież niebezpiecznie optymistyczne). Błędem jest również zakładanie, że pozostałe 2 godziny będzie w stanie poświecić na „inne produktywne zadania”.
Efekty
Nieumiejętne cięcie kosztów będzie prowadziło do gorszej jakości wykonanej pracy. Programista czując „oddech na karku” będzie się śpieszył. Zrobi więcej błędów. Nie zauważy błędów podczas code review. Rozwiąże problemy powierzchownie lub nawet zostanie o to poproszony. Świadomie wytworzymy dług technologiczny.
Zakładanie zbyt dużej wydajności pracownika niż określa to „natura” (która będzie dążyć do 6 godzin efektywnej pracy) spowoduje notoryczne przekraczanie estymat. Możemy również oczekiwać spadku jakości kodu.
Time tracker – zdrowe podejście
Kierowniku. Więcej luzu. Człowiek to nie maszyna i choć pracuje 8 godzin, bezpieczniej i wygodniej założyć od razu sprawdzone:
- 6 godzin realnej pracy nad zadaniami dziennie (maksymalnie),
- 30% narzutu po wyestymowaniu zadania (siła wyższa),
- Krótkie i jasne zadania
6-godzinny dzień pracy
Praca przez 6 godzin dziennie jest wprowadzana w wielu firmach ponieważ przynosi realne efekty. Mniejszy stres wśród pracowników, lepsza wydajność niż przy 8 godzinnym dniu pracy oraz często mniejsze koszty pracodawcy.
To samo można stwierdzić po analizie zapisów czasu pracy zespołów IT – średnio czas spędzony strikte nad zadaniami to od 4 do 6 godzin. Po tym czasie mózg wymaga zrobienia przerwy, coraz częściej oraz coraz dłuższej. Efektywność spada do krytycznego poziomu.
30% narzut estymat
Narzut, podobnie jak przy ustalaniu budżetów, jest mechanizmem bezpieczeństwa. Daje bufor zarówno programiście jak i na obrazie całego projektu. Podobnie jak przy krótszym czasie pracy, może wydawać się to przesadzone, ale tu znów wkracza statystyka. Mniejszy stres związany z presją czasu pozwala na skończenie pracy najczęściej poniżej estymaty. Oprócz tego że praca jest wykonana w zakładanych ramach czasowych, stwarzamy realne wrażenie płynności i postępów w projekcie. To bardzo dobrze wpływa na zespół oraz relacje z Klientami.
Krótkie i jasne zadania
Na koniec jedna z najtrudniejszych rzeczy. Podział dużych tematów na krótkie zadania, łatwe do zrozumienia oraz szybkie do wykonania.
Łatwe do zrozumienia – opis powinien zawierać wszystkie potrzebne informacje do wykonania zadania tak, by programista nie miał potrzeby dopytywać się kogokolwiek o szczegóły (tj. czekać na decyzje innych osób).
Szybkie do wykonania – zadanie nie powinno trwać kilka dni, lecz kilka godzin. Optymalne zadanie jest możliwe do wykonania w mniej niż 6 godzin. Chodzi tu o zachowanie wrażenia że praca posuwa się do przodu. Po prostu dobrze jest zamykać choć jedno zadanie w ciągu dnia i „zmieniać temat na nowy”. Znów, dobrze to działa na programistę, zespół oraz Klientów.
Podsumowanie
Jak wspominałem, nie zawsze specyfika projektu, nagromadzony dług technologiczny czy też założenia zadania pozwalają na jego podzielenie (inne formalności, takie jak wrzucenie kodu na serwer czy przeprowadzanie testów samych fragmentów może wydawać się na początku bez sensu). Większość projektów wymaga radykalnej zmiany podejścia aby czerpać korzyści ze zwinnego sposobu prowadzenia, opartego na estymacjach i liczeniu czasu.