Dzisiejsze prowadzenie projektów IT naszpikowane jest procesami przygotowawczymi oraz analitycznymi a praca programistów (tj. deweloperów oprogramowania) 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żnaby 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 7 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”.
Time tracker – pierwsze starcie
Zwinne (mniej lub bardziej) prowadzenie projektów IT wymusza stosowanie estymat. To oznacza że potrzebujemy jakiegoś sposobu na sprawdzenie czy nadal mieścimy się w założeniach. To naturalna sprawa, nie chcemy przecież skończyć na koniec sprintu/tygodnia/miesiąca z nieukończoną połową zadań. Dzieją się wtedy dwie rzeczy:
- 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ą dwie 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 wziąć na swoje barki lub mieć wliczone w ryzyko. Do przełknięcia. Niestety druga opcja ma bezpośredni, negatywny wpływ na pracowników. Koszt utrzymania projektu zwiększa się – rosnący dług technologiczny zaczyna 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 powiększyć ilość pracowników lub zwiększyć 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 i czasochłonny proces. Druga opcja wygląda idealnie. Co ciekawe, zwykle zaczynamy od bardzo optymistycznej i równie błędnej wyceny możliwości naszego budżetu:
- Pracownik w 8 godzinnym dniu pracy pracuje 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. Ś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
Dyrektorze, 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,
- 30% narzutu po wyestymowaniu zadania,
- Zadania o skończonym czasie wykonania.
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.
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ść ze zwinnego sposobu prowadzenia, opartego na estymacjach i liczeniu czasu.