Zespół aktualizuje Asanę wtedy, gdy wpis w niej jest częścią wykonania zadania, a nie sprawozdaniem dla kierownika. Dlatego zamiast przekonywać ludzi do narzędzia, ogranicz to, co mają w nim robić, do kilku rzeczy, z których ktoś naprawdę korzysta: jednego właściciela, terminu, jednej zmiany statusu i zgłoszenia blokady. Resztę usuń albo przekaż regule.
Poniżej jest minimalny standard zadania, który stosuję przy wdrożeniach, przykład projektu z sześcioma statusami, w którym wykonawca klika tylko raz, i sposób, żeby po trzech miesiącach sprawdzić, czy Asana żyje. Jeśli dopiero poznajesz to narzędzie, zacznij od przewodnika czym jest Asana i jak działa w pracy zespołu.
W skrócie:
Bo ma ją aktualizować po to, żeby ktoś inny miał raport. Przy samej pracy nic mu to nie daje, więc robi to wtedy, gdy musi, czyli przed spotkaniem.
Najwyraźniej widziałem to w organizacji pozarządowej, która przez dwa i pół roku prowadziła w Asanie jeden duży projekt, zanim zaczęliśmy współpracę. Raz w miesiącu odbywało się spotkanie planujące i kierowniczka programu prosiła wszystkich, żeby przed nim uzupełnili Asanę. Na początku robili to wszyscy. Po roku robiła to połowa zespołu i tylko przed spotkaniem. Zadania były tak duże, że nie było czego odhaczać na co dzień, więc Asana pokazywała strukturę projektu, a bieżąca praca szła obok: na cotygodniowych spotkaniach, w mailach, w rozmowach.
Nikt tam nie był leniwy ani przeciwny zmianom. Zespół robił dokładnie to, do czego system go zaprojektował: raz w miesiącu dostarczał raport.
Sygnały, że Asana stała się raportem zamiast miejscem pracy, powtarzają się w różnych firmach:
| Co widzisz | Co to zwykle znaczy | Co zmienić |
|---|---|---|
| Aktualizacje pojawiają się dzień przed spotkaniem | Asana służy do sprawozdania, a praca przechodzi między ludźmi gdzie indziej | Podzielić zadania tak, żeby dało się je zamknąć w kilka dni, i przekazywać pracę przez Asanę |
| Część zespołu pracuje w Asanie, część jej nie otwiera | Proces wychodzi z systemu, najczęściej na etapie akceptacji | Przenieść do Asany etap, na którym praca wraca do maila |
| Pole wypełniano przez pierwsze tygodnie, potem zostało puste | Nikt nie korzystał z tej informacji przy pracy | Usunąć pole albo wypełniać je regułą |
| Statusy stoją, choć praca idzie | Wykonawca ma przeklikać kilka statusów na jedno zadanie | Zostawić wykonawcy jedną zmianę statusu |
| To samo polecenie trafia na Teams i do Asany | Nie ustalono, gdzie się zleca pracę, a gdzie o niej rozmawia | Zadanie powstaje w Asanie, komunikator zostaje do rozmowy |
Przejdź przez każde pole, status i obowiązkowy komentarz w projekcie i zadaj przy każdym dwa pytania: kto to wpisuje i kto na tej podstawie coś robi. Jeśli wpisuje wykonawca, a korzysta tylko osoba składająca raport na koniec miesiąca, masz dane do raportu. Takie dane albo wylatują, albo wypełnia je reguła.
Dane do pracy wyglądają inaczej. Termin jest potrzebny osobie, która czeka na wynik. Właściciel jest potrzebny każdemu, kto chce zapytać, co dalej. Blokada jest potrzebna kierownikowi, bo tylko on może ją zdjąć. W tych miejscach wpis w Asanie oszczędza komuś maila albo telefonu, więc ludzie robią go bez przypominania.
Rzeczy, które przy wdrożeniach najczęściej wylatywały:
Zadanie, które da się wykonać bez dopytywania, ma sześć elementów. Każdy wpisuje konkretna osoba w konkretnym momencie i każdy ma odbiorcę.
| Element | Kto wpisuje | Kiedy | Kto z tego korzysta | Co się dzieje bez niego |
|---|---|---|---|---|
| Nazwa z rezultatem, np. „Wysłać ofertę do dostawcy etykiet” | zlecający | przy tworzeniu | wykonawca i każdy, kto przegląda listę | Sama „oferta” nie mówi, czy trzeba ją napisać, wysłać, czy zatwierdzić |
| Jeden właściciel | zlecający | przy tworzeniu | cały zespół | Zadanie „wspólne” nie ma kogo zapytać i stoi |
| Termin wyniku | zlecający albo wykonawca | przy przypisaniu | osoba, która czeka na wynik | Nie wiadomo, czy zadanie się spóźnia |
| Kontekst w opisie: co ma powstać, skąd wziąć materiały | zlecający | przy tworzeniu | wykonawca | Wykonawca pisze maila z pytaniem albo zgaduje |
| Jedna zmiana statusu | wykonawca | gdy oddaje pracę | kierownik i następna osoba w procesie | Kierownik wchodzi w każde zadanie albo pyta na spotkaniu |
| Blokada w komentarzu | wykonawca | gdy nie może ruszyć | osoba, która może blokadę zdjąć | Zadanie stoi, a na liście wygląda na normalnie trwające |
Kontekst najczęściej pomijają kierownicy, bo sami go znają. Liderka jednego z zespołów w dużej organizacji opisała mi, jak wyglądało delegowanie przed Asaną: przekazany dalej mail bez jednego słowa, z którego odbiorca miał się domyślić, co ma zrobić. Samo przeniesienie tego do Asany niczego nie zmienia. W firmie produkcyjnej zespół ustalił jedną prostą zasadę: kto daje komuś zadanie, pisze w komentarzu, co jest do zrobienia. Chodziło o to, żeby ograniczyć maile, i była to reguła, którą ludzie wymyślili sami.
Wszystko poza tą tabelą jest opcjonalne. Pola własne, tagi, estymacje i dodatkowe statusy dokładasz dopiero wtedy, gdy potrafisz wskazać osobę, która podejmuje na ich podstawie decyzję. Z tego samego powodu przy wyborze narzędzia liczba ustawień, które ktoś potem musi pilnować, waży więcej niż lista funkcji. Pokazuję to w porównaniu Asany i ClickUpa, z testem zmiany konfiguracji po starcie.
Zbuduj projekt tak, żeby wykonawca zmieniał status tylko raz, a pozostałe przejścia robił kierownik albo reguła. Kierownik czyta wtedy stan projektu z listy zadań: nazwa, termin i status wystarczą, żeby wiedzieć, czy projekt idzie zgodnie z planem.
Dokładnie o to zapytała mnie na warsztacie liderka zespołu marketingu w dużej organizacji. Wcześniej próbowała wdrożyć podobne narzędzie i wiedziała, że jeśli ludzie sami nie będą pilnować statusów, informacja dla zarządzającego będzie bezwartościowa. Chciała wiedzieć, jak to zrobić, żeby wymagało od ludzi jak najmniej, a osoba zarządzająca miała bieżący obraz.
Projekt publikacji, nad którym wtedy pracowaliśmy, miał sześć sekcji odpowiadających etapom. Role rozłożyliśmy tak:
Etap „W trakcie” zaproponowałem usunąć. Kierownikowi prawie nic nie mówił, a wykonawcy dokładał drugie kliknięcie przy każdym zadaniu.
Zasada, którą powtarzam przy każdym projekcie: zmiana statusu nie może zabierać więcej czasu niż wykonanie zadania. Jeśli zabiera, ludzie przestaną ją robić i będą mieli rację.
Reguły dokładaj według tego samego klucza. Automatyzuj to, co zespół już dziś robi ręcznie za każdym razem, jak przekazanie zadania do akceptacji. Reguła, która wprowadza nowy obowiązek, rodzi pytania i nikomu nie ułatwia pracy.
Po stronie wykonawcy pomaga widok „Moje zadania” z sekcjami układanymi według terminu: dziś, najbliższe siedem dni, później. Po zmianie daty zadanie samo przechodzi do właściwej sekcji, więc nikt nie porządkuje listy ręcznie. Ręczne porządkowanie utrzymują osoby z dużą samodyscypliną, reszta szybko je porzuca. Różne układy tego widoku opisałem w poradniku o widoku Moje zadania w Asanie.
Wtedy, gdy robi ją właściciel projektu i dotyczy stanu całego projektu. Każdy, kto odpowiada za projekt, przed spotkaniem aktualizuje jego status jednym, dwoma zdaniami: co się przesunęło, co zagraża terminowi, jakiej decyzji potrzebuje. Spotkanie służy wtedy decyzjom zamiast zbierania informacji.
Problem zaczyna się, kiedy przed spotkaniem aktualizuje się wszystko. To znak, że zadania nie żyją w ciągu tygodnia, a status projektu powstaje z pamięci prowadzącego.
Co lider musi widzieć ponad wszystkimi projektami naraz i jak zbudować taki widok bez dokładania ludziom raportowania, opisałem w tekście o zarządzaniu wieloma projektami w Asanie.
Może, i dlatego trzeba o tym powiedzieć zespołowi na starcie. Asana pokazuje, kto ma jakie zadania, na kiedy i co stoi. Tę samą informację da się użyć do zdjęcia blokady albo do rozliczania ludzi z każdego dnia. Zespół bardzo szybko wyczuwa, który z tych dwóch użytków wybrał kierownik.
Opór rzadko dotyczy samego narzędzia. Kiedy ktoś pierwszy raz rozpisze swoją pracę na kilka miesięcy do przodu, bywa przerażony tym, ile jej jest. Dopóki nie była nigdzie spisana, nie było też poczucia, że ktoś go z niej rozliczy. Są też osoby, których pracy do tej pory nie dało się łatwo zmierzyć, i dla nich przejrzystość jest zagrożeniem. Uprzedzam o tym sponsora wdrożenia na pierwszym spotkaniu, bo z zewnątrz ten opór wygląda jak problem z obsługą narzędzia.
Trzy zasady, które warto, żeby kierownik powiedział zespołowi, zanim ktokolwiek zacznie wpisywać zadania:
Kierownik dwóch czy trzech osób nie zaplanuje każdej z nich całego dnia i nie powinien próbować. Wystarczy, że pilnuje obciążenia: czy ktoś nie ma na ten tydzień trzy razy więcej niż reszta.
Zespół pracuje w Asanie tak długo, jak długo pracują w niej osoby, które zlecają i akceptują. Właściciel małej firmy opisał mi to bez owijania w bawełnę. Kiedy miał czas, delegował przez Asanę i wszystko było w niej wpisane. Kiedy nie miał, pisał na WhatsAppie, dzwonił albo wysyłał maile, i wtedy Asana zamierała.
Najczęstsze miejsce, w którym proces wychodzi z systemu, to akceptacja. Pracownicy prowadzą projekt w Asanie, a na etapie zatwierdzenia ktoś musi wysłać maila do członka zarządu, poczekać na odpowiedź i przepisać ją z powrotem. Dla procesu to tylko opóźnienie. Dla ludzi to jasny sygnał, że zasady obowiązują ich, a osoby z asystentką już nie. Dlatego etap akceptacji projektuję w Asanie od pierwszego dnia, nawet jeśli członek zarządu ma tam zaglądać wyłącznie po to.
Z tego samego powodu trzeba ustalić, gdzie się zleca pracę, a gdzie się o niej rozmawia. Komunikator jest zbudowany tak, żeby reagować od razu. Asana zbiera powiadomienia po to, żeby zająć się nimi wtedy, gdy jest na to czas. Polecenie wrzucone na Slacka albo Teams nie ma właściciela ani terminu i po tygodniu nikt go nie znajdzie. Właściciel innej firmy po warsztatach sam zdecydował, że przestaje delegować przez Slacka i zaczyna zakładać zadania. Podział między Asaną, Teams i plikami w OneDrive opisałem osobno: Asana i Microsoft 365 bez dublowania pracy.
Praca, która do nich przychodzi: zadanie przekazane przez kolegę, akceptacja, odblokowany etap. Dlatego wdrożenie zaczynam od procesu, który przechodzi przez kilka osób. Każda z nich dostaje w Asanie własne zadania, a nie sam dostęp do narzędzia. Kryteria takiego procesu zebrałem w tekście o tym, od którego procesu zacząć wdrożenie Asany.
Druga rzecz to powiadomienia. Asana domyślnie wysyła ich tyle, że nie da się ich czytać na bieżąco, więc ludzie uczą się ignorować wszystkie naraz. Na starcie ustaw je tak, żeby mail przychodził tylko wtedy, gdy ktoś czeka na Twoją reakcję: nowe zadanie, komentarz z oznaczeniem, zbliżający się termin.
Trzecia to wspólne sprzątanie. Przez pierwsze tygodnie umów z zespołem krótkie, regularne spotkanie tylko po to, żeby przejść tablicę: zamknąć zrobione, poprawić terminy, usunąć to, co przestało być aktualne. Jeśli ktoś nie robi tego na bieżąco, robicie to razem, dopóki nie wejdzie mu to w nawyk.
Policz, ile zadań i projektów powstaje w Asanie po zakończeniu wdrożenia. Liczba przeszkolonych osób i frekwencja na warsztatach nie mówią, czy nowy nawyk przetrwa. Dopiero aktywność po wyjściu osoby, która wdrażała, pokazuje, czy praca przeszła do systemu, czy wróciła do maila.
| Co sprawdzasz | Gdzie | Dobry znak | Zły znak |
|---|---|---|---|
| Kto zakłada zadania | projekt, od którego zaczęło się wdrożenie | zadania zakładają różne osoby, także wykonawcy dla siebie nawzajem | zadania zakłada tylko lider albo kierownik |
| Kiedy zmieniają się statusy | historia zadań | zmiany rozłożone na cały tydzień | zmiany zbite w dzień przed spotkaniem |
| Gdzie odbywa się przekazanie pracy | sekcja akceptacji, komentarze | następna osoba dostaje zadanie z komentarzem | przekazanie idzie mailem, a w Asanie ktoś je potem odhacza |
| Ile zadań jest po terminie i bez ruchu | lista z filtrem po terminie | pojedyncze, z komentarzem o blokadzie | dziesiątki zaległych zadań, których nikt nie zamyka |
| Czy nowe projekty startują z szablonu | lista projektów zespołu | każdy nowy projekt powstaje z szablonu | projekty zakładane od zera, każdy inaczej |
Sprawdź to po trzech miesiącach od zakończenia wdrożenia, na tym samym procesie, od którego zaczynaliście. Raport liczby utworzonych zadań według osoby, która je utworzyła, zbudujesz już na planie Starter.
Jedna z organizacji, z którymi pracowałem, wpisała wykorzystanie Asany do rocznych KPI. To dobry znak, że zarząd traktuje wdrożenie poważnie, ale sam wskaźnik trzeba dobrze nazwać. „Liczba logowań” zmierzy klikanie. „Odsetek przekazań w procesie, które odbyły się przez Asanę” zmierzy, czy proces faktycznie przeszedł do systemu.
Jeśli Asanę masz od dawna i przy tej tabeli większość odpowiedzi wypada w kolumnie „zły znak”, zanim zaczniesz przekonywać ludzi od nowa, sprawdź konfigurację. Audyt procesów w Asanie zaczynam od tego, co trafia do systemu niepotrzebnie, bo w takim koncie zwykle więcej trzeba usunąć niż dołożyć.
Pilnuje ich lider po stronie firmy, czyli osoba, która zna proces, ma czas na Asanę i prawo powiedzieć „u nas robimy tak”. Bez niej zasady z wdrożenia rozmywają się w kilka miesięcy, bo każdy nowy pracownik uczy się od kolegi, a kolega pamięta tylko część.
Najlepsi liderzy, jakich spotkałem, nie byli kierownikami. W firmie produkcyjnej był to pracownik, który sam przeszedł typowe błędy pierwszych tygodni i na warsztatach ostrzegał kolegów, żeby nie rozpisywali zadań na kilkanaście podzadań, bo jego zespół odklikiwał je potem do trzeciej w nocy. Takie ostrzeżenie od kogoś z zespołu działa mocniej niż ta sama zasada ode mnie.
W dziale liczącym kilkadziesiąt osób jeden lider nie wystarczy. Potrzebny jest ktoś w każdym zespole i wspólne zasady, których pilnuje sponsor.
Przy wdrożeniu Asany ze szkoleniem zespołu ustalamy minimalny komplet informacji dla Waszego procesu, układamy statusy tak, żeby wykonawca klikał jak najmniej, i usuwamy wszystko, czego zespół w pierwszych tygodniach nie używa. Na koniec przekazuję system liderowi po Waszej stronie, razem z zasadami, czego do Asany nie wpisywać. Współpraca trwa trzy miesiące, kosztuje 6 000 zł netto miesięcznie, czyli 18 000 zł netto łącznie, i obejmuje zespół do 15 osób.
Adopcji całego zespołu nie obiecuję, bo zależy także od tego, czy kierownicy będą zlecać pracę w Asanie. Mogę za to zaprojektować system tak, żeby nikt nie musiał raportować ponad potrzebę. Nie wiesz, czy potrzebujesz wdrożenia, czy audytu? Umów 30 minut rozmowy.
O autorze
Wdrażam CRM, AI w sprzedaży i automatyzacje w firmach.
Zamiast przekonywać do narzędzia, zmniejsz to, co zespół musi w nim robić. Ludzie aktualizują Asanę, gdy wpis zastępuje im maila albo telefon: przekazanie zadania, zgłoszenie blokady, oddanie pracy do akceptacji. Zacznij od procesu, który przechodzi przez kilka osób, usuń pola, z których nikt nie korzysta, i dopilnuj, żeby kierownicy też zlecali pracę w Asanie.
Zbuduj projekt tak, żeby wykonawca zmieniał status zadania tylko raz, kiedy oddaje pracę. Przejścia między pozostałymi etapami robi kierownik albo reguła, na przykład zmiana właściciela na osobę akceptującą. Kierownik odczytuje stan projektu z nazw zadań, terminów i statusów, bez wchodzenia w każde zadanie i bez pytania ludzi na spotkaniu.
Bo Asana służy mu do przygotowania sprawozdania, a codzienna praca odbywa się gdzie indziej. Zwykle zadania są za duże, żeby dało się je zamykać w ciągu tygodnia, a przekazanie pracy idzie mailem albo przez komunikator. Pomaga podział zadań na mniejsze i przeniesienie przekazań do Asany.
Licz aktywność po zakończeniu wdrożenia, nie liczbę przeszkolonych osób. Sprawdź, kto zakłada zadania, czy statusy zmieniają się w ciągu całego tygodnia, czy przekazanie pracy odbywa się w Asanie i czy nowe projekty startują z szablonu. Najlepiej po trzech miesiącach, na tym samym procesie, od którego zaczęło się wdrożenie.
Może zostać tak użyta, dlatego zasady trzeba ustalić na starcie. Termin powinien dotyczyć wyniku, nie dnia, w którym ktoś zaczyna pracę, a wskaźniki z Asany powinny opisywać proces, bez zamieniania ich w indywidualne cele. Zespół, który widzi, że lista zadań służy do zdejmowania blokad i ustalania priorytetów, aktualizuje ją chętniej niż zespół, który czuje się obserwowany.
Przymus działa krótko i kończy się odklikiwaniem statusów po fakcie. Skuteczniej jest usunąć powody, dla których ludzie pracują obok systemu: pracę zlecaną poza Asaną, akceptacje prowadzone mailem i pola bez odbiorcy. Jedna zasada może obowiązywać od pierwszego dnia: nowe zadanie w procesie powstaje wyłącznie w Asanie.
Lider po stronie firmy, który zna proces i ma prawo rozstrzygać, jak się w nim pracuje. Poprawia szablony, wprowadza nowe osoby i przez pierwsze tygodnie prowadzi z zespołem krótkie przeglądy tablicy. Nie musi być kierownikiem; często lepiej sprawdza się ktoś z zespołu, kto sam przeszedł typowe błędy początku.
Raz w tygodniu dostaniesz bezpłatnie, jedno gotowe rozwiązanie, jak skutecznie wykorzystać nowoczesne technologie w sprzedaży B2B.
Zapisując się, zamawiasz newsletter Wellbiz sp. z o.o. i zgadzasz się na otrzymywanie e-maili z poradami i ofertami. Wypiszesz się jednym kliknięciem. Link jest w każdej wiadomości. Regulamin newslettera, Polityka prywatności
