Task management potrafi uporządkować pracę, ale równie łatwo stworzyć system, w którym zarządzanie zadaniami zajmuje więcej czasu niż ich wykonywanie. Najczęściej dzieje się tak, gdy każde ma kilkanaście pól, kilka etykiet, pięć poziomów priorytetu i status dla każdego możliwego wyjątku.
Jedno zadanie powinno mieć jasny rezultat
„Zająć się stroną” to słaby opis. „Przygotować wersję strony produktu do akceptacji” mówi, po czym poznać zakończenie pracy. Dobrze opisane zadanie zmniejsza liczbę komentarzy i pytań, bo odbiorca wie, czego oczekuje autor.
Po zakończeniu projektu archiwum decyzji, zakresu i problemów może być materiałem do następnego planu. System ma wartość również po zamknięciu ostatniego zadania.
Statusów powinno być tyle, ile naprawdę zmienia sposób działania
Prosty przepływ do zrobienia, w toku i gotowe wystarcza w wielu zespołach. Osobny status ma sens, gdy uruchamia inną odpowiedzialność, na przykład oczekiwanie na klienta albo przegląd. Jeśli dwa statusy niczego nie zmieniają, użytkownicy zaczną wybierać je przypadkowo.
Priorytet bez reguły szybko traci znaczenie
Gdy połowa zadań jest „pilna”, etykieta nie pomaga. Warto określić, co faktycznie otrzymuje najwyższy priorytet: awaria, termin zewnętrzny, blokada innej pracy czy duża wartość biznesowa. Wtedy kolejka zadań zaczyna wspierać decyzje.
Task management nie powinien zastępować rozmowy tam, gdzie potrzebna jest szybka decyzja. Narzędzie ma przechowywać ustalenia i pilnować odpowiedzialności.
Zbyt wiele statusów zwiększa koszt aktualizowania systemu i skłania użytkowników do obchodzenia procesu zamiast korzystania z niego.
Mały zespół zwykle korzysta na prostszym procesie. Jeżeli aktualizacja zadania trwa dłużej niż wykonanie drobnej pracy, system jest zbyt ciężki.
Eksport danych i historia zmian są ważne przy długich projektach oraz wtedy, gdy firma może w przyszłości zmienić narzędzie.
Komunikator nie powinien być drugim systemem zadań
Krótka rozmowa jest szybsza na czacie, lecz wynik powinien wrócić do zadania, jeśli ma znaczenie dla późniejszej pracy. Inaczej za tydzień nikt nie pamięta, w którym kanale zapadła decyzja.
Warto oddzielić termin zobowiązania wobec klienta od wewnętrznej daty planowanej. Zespół potrzebuje bufora, ale raport powinien jasno pokazywać oba poziomy.
Najlepszym testem jest przeniesienie jednego realnego projektu do wersji próbnej, zamiast oceniania przykładowej tablicy przygotowanej przez producenta.
System projektowy powinien pokazywać odpowiedzialność, termin i zależności, a nie tylko przechowywać długą listę zadań.
Przegląd raz na jakiś czas jest konieczny
Nawet najlepsza tablica zarasta starymi zadaniami. Regularne usuwanie nieaktualnych pozycji, zamykanie spraw i porządkowanie właścicieli jest częścią task managementu. Brudna lista przestaje być wiarygodna, więc ludzie zaczynają prowadzić prywatne notatki.
Dobry system zadań jest nudny w najlepszym znaczeniu tego słowa. Otwierasz go i od razu wiesz, co jest następne. Jeśli wymaga ciągłego administrowania, trzeba uprościć proces zamiast dodawać kolejne automatyzacje.
System projektowy powinien pokazywać odpowiedzialność
System projektowy powinien pokazywać odpowiedzialność, termin i zależności, a nie tylko przechowywać długą listę zadań.
Zbyt wiele statusów zwiększa koszt aktualizowania systemu i skłania użytkowników do obchodzenia procesu zamias
Zbyt wiele statusów zwiększa koszt aktualizowania systemu i skłania użytkowników do obchodzenia procesu zamiast korzystania z niego.
Z tym tematem bezpośrednio łączy się poradnik: business intelligence a zwykły raport – gdzie zaczyna się analiza. W tym samym obszarze przydaje się także System Business Intelligence.
Zależność między zadaniami powinna być używana tam, gdzie rzeczywiście blokuje termin. Łączenie wszystkiego ze wszystkim tworzy skomplikowany wykres, który trudno utrzymać.