Włączone, wyłączone: funkcje zarządzania projektami, z których zespoły przestają korzystać
Śledzenie czasu: Wiele zespołów rezygnuje z funkcji śledzenia czasu, ponieważ nie odpowiada ona dobrze rzeczywistym potrzebom związanym z monitorowaniem postępów projektu.
Kolumny niestandardowe: Nadmierna liczba kolumn niestandardowych może komplikować przepływy pracy oraz zmniejszać ogólną wydajność i przejrzystość zespołu.
Zależności między zadaniami: Zależności między zadaniami często zawodzą w praktyce z powodu trudności z ich utrzymaniem i zakłóceń występujących w rzeczywistych warunkach.
Nadmierna automatyzacja: Złożona automatyzacja może dezorientować zespoły, prowadząc do braku zaufania i odchodzenia od zamierzonych przepływów pracy.
Prostota wygrywa: Powrót do prostych i skutecznych metod często prowadzi do lepszych rezultatów w zarządzaniu projektami niż korzystanie ze złożonych funkcji.
Narzędzia do zarządzania projektami są wyposażone w funkcje zaprojektowane z myślą o uporządkowaniu złożonej pracy. Więcej funkcji nie zawsze jednak oznacza lepsze rezultaty. We wszystkich zespołach, niezależnie od ich wielkości, schemat się powtarza: obiecująca funkcja zostaje włączona, działa przez kilka tygodni, a następnie po cichu umiera. Pozostaje system trudniejszy w obsłudze niż wcześniej i zespół, który wypracował własne obejścia.
Zapytaliśmy kilku praktyków, jakie funkcje spotkali w pracy, które podczas konfiguracji wyglądały na przydatne, ale w praktyce się nie sprawdziły. Oto dobre, złe i brzydkie strony.
Obietnica śledzenia czasu (i dlaczego się nie sprawdziła)
Wbudowane śledzenie czasu to jedna z najczęściej włączanych — i porzucanych — funkcji w narzędziach takich jak Jira. Aaron Whittaker, wiceprezes ds. generowania popytu w Thrive Agency, włączył wbudowany rejestr pracy w Jira dokładnie z tych samych powodów co większość zespołów. „Włączyliśmy ją, ponieważ wyglądała na praktyczny sposób zrozumienia, jak wysiłek rozkłada się między pracę nad płatnymi mediami, SEO i treściami” — mówi. „Celem było uzyskanie przejrzystszego raportowania i lepsze planowanie harmonogramów kampanii”.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Funkcja nigdy się nie przyjęła. Whittaker wskazuje na zasadniczą rozbieżność między tym, co mierzy funkcja, a tym, co zespoły rzeczywiście muszą wiedzieć. „Funkcja śledzi godziny, a nie postęp” — wyjaśnia. „Rejestrowanie pięciu czy sześciu godzin optymalizacji reklam lub aktualizacji stron docelowych nie mówi, czy wyniki się poprawiły ani czy praca zbliża się do ukończenia”.
Konieczność ręcznego wprowadzania danych jeszcze pogorszyła sytuację. Po około miesiącu korzystania z funkcji przy ponad 170 elementach pracy tylko około 55 miało użyteczne wpisy — a i tym brakowało spójności. „Rejestrowanie czasu oznaczało przechodzenie w ciągu dnia do wielu zadań, co nieustannie rozpraszało uwagę” — mówi Whittaker. „Po pewnym czasie wydawało się po prostu czymś, co trzeba robić, a nie czymś, co rzeczywiście pomaga”.
Rejestrowanie czasu oznaczało przechodzenie w ciągu dnia do wielu zadań, co nieustannie rozpraszało uwagę. Po pewnym czasie wydawało się po prostu czymś, co trzeba robić, a nie czymś, co rzeczywiście pomagało.
Jego zespół zrezygnował z tej funkcji i wrócił do prostego przepływu pracy opartego na tablicy. „Śledzenie czasu wyglądało obiecująco podczas konfiguracji, ale w rzeczywistych przepływach pracy dublowało widoczność, którą już mieliśmy, i powodowało dodatkowe utrudnienia bez poprawy realizacji zadań”.
Niestandardowe kolumny przepływu pracy: gdy elastyczność staje się obciążeniem
Niestandardowe kolumny wydają się naturalnym rozszerzeniem dobrego podejścia do procesów. Scott Davis, założyciel i dyrektor generalny Outreach.io, przekonał się na własnej skórze, że ta funkcja może szybko wymknąć się spod kontroli. „Kilka lat temu włączyliśmy opcję „dodaj niestandardowe kolumny” na tablicach scrumowych w Jira, aby zapewnić przejrzystość naszego przepływu pracy” — mówi. „Włączyliśmy tę funkcję w mniej niż minutę. Przez kilka tygodni zamienialiśmy ją w ukryty narzut”.
Włączyliśmy tę funkcję w mniej niż minutę. Przez kilka tygodni zamienialiśmy ją w ukryty narzut
To, co zaczęło się od jednej kolumny „Do weryfikacji” między kolumnami „W toku” i „Gotowe”, szybko się rozmnożyło. „Zanim się zorientowaliśmy, każdy zespół miał własną kolumnę do przeglądu” — mówi Davis; dział produktu dodał kolumnę do zatwierdzania przez interesariuszy, a zespół QA kolejną do dodatkowej kontroli. „Każda tablica scrumowa wyglądała inaczej i niełatwo było się po niej poruszać. Ludzie musieli sprawdzać konfigurację tablicy tylko po to, żeby wiedzieć, jak przenieść dane zgłoszenie”.
Koszt był widoczny w danych. „Czas cyklu naszego zespołu podczas intensywnych sprintów stale się wydłużał — średnio z 8 do 10,75 dnia — głównie dlatego, że nie było jasne, co oznacza każde dodatkowe niestandardowe pole statusu” — wyjaśnia Davis. „Wskaźniki informacji zwrotnych z naszych retrospektyw były pełne uwag o „marnowaniu czasu na debatowanie nad nazwami statusów””.
Jego rada dla każdego zespołu rozważającego dostosowanie kolumn brzmi: „Traktuj każdą dodaną kolumnę jak dług techniczny. Bez dobrej dyscypliny ról i uzasadnionego powodu, by odejść od ustawień domyślnych, skalowanie pracy jest trudniejsze niż modyfikowanie domyślnego przepływu. Większość zespołów po kilku sprintach po cichu rezygnuje z tych dodatkowych kolumn”.
Zależności zadań: przejrzyste w teorii, zepsute w praktyce
Zależności zadań to jedna z najbardziej atrakcyjnych funkcji każdego narzędzia do zarządzania projektami. Logika jest prosta: połącz zadania, aby opóźnienia automatycznie się ujawniały i uruchamiały odpowiednie reakcje. W praktyce ta funkcja często załamuje się pod wpływem zmienności rzeczywistego świata.
Dmitrii Malashkin, założyciel i dyrektor generalny Born to Move, wdrożył zależności oraz zaawansowane automatyzacje ukończenia zadań w Asanie — a później także w monday.com — aby aktualizować harmonogramy projektów i sprawować nad nimi kontrolę. „Rzeczywistość była jednak taka, że członkowie naszego zespołu tak naprawdę nigdy nie korzystali z nich dłużej niż przez pierwszy tydzień po wdrożeniu” — mówi. Powód był prosty: „Utrzymywanie zależności i automatyzacji to osobna praca na cały etat, której nikt nie powinien wykonywać ani faktycznie nie chce wykonywać, zwłaszcza gdy nie jest to egzekwowane”.
Utrzymywanie zależności i automatyzacji to osobna praca na cały etat, której nikt nie powinien wykonywać ani faktycznie nie chce wykonywać, zwłaszcza gdy nie jest to egzekwowane.
Gdy pojawiały się zakłócenia w rzeczywistym świecie — brak pozwolenia, nagła zmiana harmonogramu, konflikt z dostępnością klienta — łańcuch się rozpadał. „To sprawia, że pojedynczy punkt awarii może przerwać cały łańcuch zależności” — wyjaśnia Malashkin. „W efekcie przepływ pracy zaczyna wysyłać ludziom lawinę ogólnych próśb o aktualizację statusu, co z kolei prowadzi do tego, że wszyscy je wyciszają”. Rezultatem było powszechne zmęczenie powiadomieniami.
Ostatecznie jego zespół całkowicie zrezygnował z tej funkcji. „Nasi kierownicy projektów i liderzy ekip wrócili do płaskich, niehierarchicznych list zadań oraz czatów grupowych jako głównego sposobu działania, aby koordynować pracę i realizować więcej zadań”.
Eric Turney, prezes The Monterey Company, zaobserwował ten sam schemat. „Funkcją, którą widziałem rozpadającą się w kontakcie z rzeczywistymi przepływami pracy, są zależności zadań w narzędziu do zarządzania projektami” — mówi. „Nigdy się nie przyjęły, ponieważ priorytety zmieniały się zbyt często, ich utrzymanie było uciążliwe, a system dezaktualizował się szybciej, niż ktokolwiek chciał go aktualizować”. Jego zespół wrócił do prostszego przypisywania odpowiedzialności, jasnych terminów i bezpośredniej komunikacji. „Funkcja wyglądała inteligentnie na etapie konfiguracji, ale w rzeczywistości dodawała pracy administracyjnej, nie zapewniając nam wystarczającej kontroli, aby można było to uzasadnić”.
[Zależności zadań] nigdy się nie przyjęły, ponieważ priorytety zmieniały się zbyt często, ich utrzymanie było uciążliwe, a system dezaktualizował się szybciej, niż ktokolwiek chciał go aktualizować.
Nadmierna automatyzacja: gdy system działa przeciwko zespołowi
Automatyzacja to jeden z największych atutów współczesnych platform do zarządzania projektami — i jedna z najłatwiejszych rzeczy do nadużycia. Tom Jauncey, dyrektor zarządzający Global Sound Group, opisuje dobrze znaną pułapkę: „Jedną z rzeczy, które dobrze wyglądają na papierze, ale w praktyce nie działają, jest nadmierna automatyzacja w narzędziach takich jak monday.com. Może to stać się zbyt skomplikowane, aby zespół mógł za tym nadążyć”.
Jedną z rzeczy, które dobrze wyglądają na papierze, ale w praktyce nie działają, jest nadmierna automatyzacja w narzędziach takich jak monday.com. Może to stać się zbyt skomplikowane, aby zespół mógł za tym nadążyć.
Gdy automatyzacja staje się zbyt wielowarstwowa, zespoły przestają jej ufać. „Dzieje się tak, że ludzie zaczynają ignorować system albo robią wszystko po swojemu, ponieważ wydaje się on zbyt trudny do zrozumienia lub mają wrażenie, że ich ogranicza” — mówi Jauncey. Zaplanowany przepływ pracy i rzeczywisty przepływ pracy zaczynają się rozchodzić. „Sposób, w jaki planujemy pracę, wygląda świetnie na etapie planowania. W rzeczywistości nie odpowiada temu, jak zespół pracuje na co dzień”.
Wniosek, do którego doszedł jego zespół, był prosty: „Najlepszy sposób działania to taki, z którego ludzie faktycznie korzystają, a nie taki, który ma najwięcej funkcji”.
Pola procentowego ukończenia i iluzja postępu
Niektóre funkcje zawodzą nie dlatego, że są zbyt złożone — zawodzą, ponieważ są zbyt uproszczone. Nikita Patil Brennan, starsza kierowniczka projektów, wskazuje pola procentowego ukończenia jako doskonały przykład. „Jedną z funkcji zarządzania projektami, która pojawia się w MS Project/Asanie, jest procent ukończenia zadań” — mówi. „Nie pokazuje ona całej historii — 71% może oznaczać, że większość zadań została ukończona, że zadania są zagrożone, zablokowane itd.” Pojedyncza liczba spłaszcza kontekst, którego zespoły potrzebują, aby podejmować działania. Postęp nie jest tym samym co kondycja projektu, a wskaźnik, który nie potrafi ich rozróżnić, nie dostarcza nikomu użytecznych informacji.
Nie pokazuje ona całej historii — 71% może oznaczać, że większość zadań została ukończona, że zadania są zagrożone, zablokowane itd.
More Articles
- Narzędzia do zarządzania projektami, z których kierownicy projektów musieli zrezygnować
- Jedyne narzędzie do zarządzania projektami, z którego nigdy bym nie zrezygnował
- Stos technologiczny, którego użyłoby 6 ekspertów ds. zarządzania projektami, gdyby musieli zacząć od zera
- 14 zalet i wad oprogramowania do zarządzania projektami dla dzisiejszych kierowników projektów
Funkcje AI, które obiecywały zbyt wiele, a dostarczały zbyt mało
W miarę wdrażania funkcji AI na platformach do zarządzania projektami różnica między działaniem podczas prezentacji a użytecznością w rzeczywistym świecie stawała się powracającym źródłem frustracji. Megan Cotterman, kierowniczka projektów pracująca w niepełnym wymiarze oraz konsultantka ds. operacyjnych, doświadczyła tego na własnej skórze. „Tak, miałam takie doświadczenie, gdy Asana po raz pierwszy wprowadziła swoją funkcję AI” — mówi. „Zadawałam pytania dotyczące określonych projektów w określonych kontekstach i miałam ogromne trudności ze znalezieniem tego, o co pytałam”.
Zadawałam pytania [do Asany AI] dotyczące określonych projektów w określonych kontekstach i miałam ogromne trudności ze znalezieniem tego, o co pytałam.
Problem nie dotyczy wyłącznie Asany — odzwierciedla szersze wyzwanie związane z funkcjami AI, które są tworzone z myślą o ogólnych przypadkach użycia, ale nie zostały jeszcze wytrenowane w zakresie specyfiki i niuansów tego, jak są zorganizowane i wyszukiwane rzeczywiste dane projektowe.
Powrót do podstaw — argumenty za prostotą
W każdej kategorii funkcji zespoły, które ponownie odnalazły właściwy kierunek, osiągnęły to dzięki uproszczeniu. James Dyble trafnie oddaje odczucia, do których ostatecznie dochodzi wielu praktyków. „Kiedyś gorąco polecałem cyfrowe menedżery zadań, przekonany, że wszystko powinno znajdować się w aplikacji” — mówi. „Potem zauważyłem, że raz za razem sięgam po długopis i papier”.
Kiedyś gorąco polecałem cyfrowe menedżery zadań, przekonany, że wszystko powinno znajdować się w aplikacji. Potem zauważyłem, że raz za razem sięgam po długopis i papier.
Jego rozwiązaniem nie było całkowite porzucenie narzędzi cyfrowych, lecz bardziej świadome podejście do tego, do czego są używane. „Teraz zdecydowałem się na podejście hybrydowe: przechowuję najważniejsze projekty i listy w narzędziu cyfrowym, ale codzienne priorytety zapisuję na zwykłej karteczce samoprzylepnej. Jest coś satysfakcjonującego w fizycznym odhaczaniu kolejnych rzeczy w miarę ich realizacji”.
Najskuteczniejszy system zarządzania projektami to nie ten, w którym włączono najwięcej funkcji. To ten, z którego zespół faktycznie będzie korzystać.
Chcesz poznać więcej podobnych spostrzeżeń? Załóż bezpłatne konto DPM, aby poznać opinie kolejnych ekspertów.
