Wrzucenie nowego zadania na tablicę nie wydaje się niczym szczególnym, w końcu to trzy słowa tytułowe i kolejnych kilka słów opisu. Do tego skopiujmy wymagania Klienta z maila oraz dorzućmy screen z interfejsem. Ustawmy daty. Dodajmy odpowiednie tagi. Przypiszmy do dewelopera. Ale… czy tak pisze się dobre zadania?
Typowe zadanie
Wstępem do tego artykułu jest opis jak powstaje typowe zadanie. Nie twierdzę że to zadanie będzie złe. W wielu przypadkach będzie to aż nadto, aby wykonać pracę w sposób optymalny. Są różne cele które chcemy osiągnąć powierzając komuś jakieś zadanie. Czasem wystarczy jedno zdanie, czasem najlepszy jest jeden screen ze strzałką pokazującą co zmienić a czasem nie trzeba nawet trzeba tworzyć zadania. Jednak w projekcie gdzie planujemy wykonanie a następnie monitorujemy postęp prac (np. mierząc czas wykonania zadań), przyjmujemy że wszystko musi być wyrażone przez zadanie na tablicy. To przyzwyczaja nas do tworzenia zadań szybko i nijako. Ten nawyk przenosimy z zadań prostych na te bardziej złożone. I to tutaj pozornie zyskując, tracimy najwięcej.
Złe zadanie
Kusi stwierdzić że nie ma złych zadań, bo zadanie to tylko dane wejściowe – komenda. Jeśli zadanie jest, to jest dobrze, bo gdyby go nie było, byłoby gorzej 😉 Od dowolnego zadania możemy zacząć pracę. Jak czegoś nie wiemy – dopytać. Jak nie mamy kogo dopytać – samemu podjąć decyzję. Możemy też wiedzieć więcej o samym zadaniu niż jego autor i sam jego tytuł powie nam co i jak.
Innymi słowy – jeśli wykonawca zadania to kumaty pracownik, to nie ma problemu. Niestety, takie myślenie w projekcie IT to pułapka.
Dobre zadanie
Dobre zadanie to takie, które jest kompletne. Daje pełny obraz tego co dokładnie należy zrobić. Dla obecnego wykonawcy oraz dla innych. Opisuje pracę do wykonania ze wszystkimi szczegółami, a co za tym idzie stanowi swoistą dokumentację pracy faktycznie wykonanej.
Po co nam (dobre) zadania
Wydawać by się mogło że zadania są tylko po to, aby każdy wiedział co ma robić. To jednak tylko wierzchołek góry lodowej. Zadania to maszyna czasu, to dokumentacja projektu. Zadania z opisem, screenami, komentarzami, logami czasu oraz innymi metadanymi dają nam możliwość zrozumienia co i kiedy zostało wykonane, kto to robił i dlaczego. To bardzo cenne informacje dla całego zespołu. Kierownik sprawdzi co i kiedy zostało wykonane. Deweloper pozna ideę i czas wykonania podobnego zadania. Analityk powiąże kropki między funkcjonalnościami systemu. Tester sprawdzi, co było zmieniane i czy potencjalnie nie wprowadziło błędów. Dobre zadania to dużo profitów. Warto wyrobić sobie nawyk tworzenia dobrych zadań.
Jak pisać dobre zadania
Wiemy już że zadanie może być złe, choć na takie nie wygląda. Może być złe, choć zostało przecież wykonane, „i po temacie”. Chcielibyśmy oczywiście tworzyć zadania dobre, które przyśpieszają pracę oraz procentują długo po ich wykonaniu. Spróbujmy określić pewne ramy, które nam w tym pomogą.
Zadanie powinno być krótkie
Jak już pisałem w artykule o pomiarze czasu, zadanie powinno być krótkie. Nie powinno trwać kilka dni, lecz kilka godzin. Optymalne zadanie jest możliwe do wykonania w mniej niż 6 godzin (jeden dzień pracy). Po prostu dobrze jest zamykać choć jedno zadanie w ciągu dnia – dobrze to działa na psychikę programisty oraz zespół. Chodzi tu o zachowanie wrażenia że praca posuwa się do przodu. Pozwala to również na lepsze zrozumienie zadania przez resztę zespołu.
To oznacza że długie, skomplikowane zadania należy rozbić na mniejsze, mniej złożone. Zadanie można podzielić na zadania mniejsze, możliwe do wykonania niezależnie lub jeden po drugim. Jeśli nowe zadania nie mogą być wykonane niezależnie lub jeden po drugim, można utworzyć zadanie „główne” a pod nim umieścić „pod-zadania”. Dzięki temu można lepiej śledzić postęp w początkowo zbyt obszernym zadaniu, nawet jeśli wynik prac zostanie wydany jako całość.
Osoba powracająca do krótkiego zadania również o wiele szybciej zrozumie co zostało wykonane, bez wczytywania się w długawy opis.
Zadanie powinno być mierzalne
Mierzalność zadania wynika wprost z podziału dużych zadań na mniejsze. O wiele łatwiej jest wycenić czasochłonność wielu mniejszych zadań, niż jednego dużego. Taka miara będzie również zwykle bardziej dokładna. Łatwiej też w takim procesie wyceny zauważyć pewne niuanse, które w dużym „ogólnym” zadaniu nie widać. Z tego wynika że zyskujemy dodatkowo na stabilności takiej wyceny.
Jeśli natomiast realny czas wykonania zadania będzie się diametralnie różnił od estymaty, od razu widać która część większego zadania była prostsza lub bardziej problematyczna niż zakładano. Bez podziału na mniejsze zadania (czyli więcej mniejszych estymat) nie byłoby to takie proste. Dzięki temu łatwiej jest wycenić podobne zadania w przyszłości lub namierzyć problematyczne elementy systemu w naturalny sposób.
Jasny tytuł
Pierwszym elementem zadania (a często jedynym wymaganym) jest jego tytuł. To drogowskaz i streszczenie zadania. Nie chodzi tu o to, aby koniecznie był krótki. Powinien po prostu pasować do przyjętej konwencji i być zrozumiały dla każdego w zespole.
Przykład:
❌ [Moduł zakupowy] Naprawić przycisk usuwania
✔️ Przycisk usuwania usuwa wszystkie produkty z koszyka
Pierwszy tytuł niewiele mówi osobie nie znającej problemu. Trudno będzie powiązać takie zadanie z wydarzeniem w systemie. W przypadku wielu takich zadań bałagan będzie jeszcze większy. Zawiera też fragment „[Moduł zakupowy]” użyty zamiast kategorii lub taga. Zmniejsza to czytelność w wyszukiwarce i na listach.
Jeśli system zadań nie oferuje kategorii, tagów lub pól niestandardowych, fragment „[Moduł zakupowy]” może być OK i przez ogólnie przyjętą konwencję całkowicie akceptowalny. Warto jednak wypełniać go jako metadane, które pozwolą nam np. lepiej filtrować takie zadania na tablicy.
Wyczerpujący opis
Drugim elementem zadania jest jego opis. Jest to najważniejszy element. Powinien zawierać dokładną instrukcję co należy wykonać, krok po kroku. Może być to opis słowny, obrazy, linki do makiet, wykresy, filmiki. Nie chodzi o to, że ma być długi, ale o to by przekazać informację o problemie w sposób możliwie jasny. Bez niedomówień, bez „przecież każdy o tym wie” czy „tak jak ostatnio”. Należy pamiętać że piszemy go również dla kogoś z przyszłości, kogoś kto będzie szukał punktu zaczepienia lub będzie próbował zrozumieć jakiś proces.
Ważną sprawą jest utworzenie opisu wyczerpującego temat. Wykonawca zadania nie powinien (w miarę możliwości) mieć potrzeby uzyskiwania decyzji kluczowych dla zadania już w jego trakcie. Raz, że będzie to powodować przestoje w oczekiwaniu na decyzje, dwa że będzie on zabierał komuś czas. Kilka takich zadań może skutecznie rozsypać flow pracy w zespole, gdzie każdy zacznie zajmować się „nie swoimi” zadaniami.
Przykład:
❌ Tak jak było na spotkaniu, poprawić przycisk usuwania.
✔️ Poprawić przycisk usuwania bo usuwa wszystkie produkty z koszyka. Notatki ze spotkania: <link do notatek>
Zły opis nic nam nie powie, jeśli nie było nas na tym spotkaniu, lub gdy nie dopytamy kogoś o notatki ze spotkania (jeśli istnieją). Możemy nawet zapomnieć o jakichś niuansach ze spotkania. Dodatkowo jakaś osoba w przyszłości niewiele się dowie co zostało zmienione lub jak problem miał być/został rozwiązany.
Jak widać w dobrym opisie mamy opis problemu oraz link do notatek. Jeśli notatki ze spotkania nie mogłyby być dołączone jako link (bo ekosystem na to nie pozwala), można je wkleić lub nawet notować od razu w tym zadaniu.
Metadane w zgodzie z ekosystemem
Tytuł czy opis oczywiście stanowi podstawę samego zadania, ale to metadane pozwalają zatopić je w ekosystemie. Odpowiednie otagowanie zadania pozwala na wydajne filtrowanie. Podlinkowanie zadań powiązanych ułatwi eksplorację tematu innym osobom z zespołu. Logowanie czasu pod zadaniem da nam realny obraz czasochłonności zadania.
Podsumowanie
Zadanie piszemy nie dla siebie, ale dla kogoś. Tym kimś może być obecny członek zespołu który wie więcej od nas, przyszły członek zespołu który nie wie nic, a może nawet my za kilka miesięcy czy lat. W poświęcaniu czasu na jego dobre przygotowanie należy znaleźć złoty środek, aby nie wpaść w pułapkę gdzie siedzimy 3 godziny nad jednogodzinnym zadaniem, ale nawet takie przypadki odpłacą się w przyszłości – przez danie dobrego przykładu w zespole czy przez dokumentację dodaną w ten sposób do projektu.