Na pewno niejednokrotnie znalazłeś się w sytuacji, w której projekt świetnie się rozpędzał tylko po to, by potem przeistoczyć się w jedno z tych doświadczeń, które przypomina o uczuciu towarzyszącemu waleniem warząchwią w wiadro założone na głowę? Łatwo się rozpędzić, a trudniej czasem wyhamować. Często okazuje się, że niemiłych rozczarowań “poniewczasie” można uniknąć nawet za pomocą najprostszego planowania. Wiem jednak, że łatwo o tym zapomnieć albo — co gorsza — zlekceważyć wartość tego procesu.
Powiesz: “Planowanie… To nie jest sexy! To dla tych dziadów programistów z pięćdziesięcioletnim stażem!” A ja powiem: wcale nie!
Dzisiaj będzie o tym, jak można udokumentować nasze i innych oczekiwania tak, by po miesiącu wciąż wiedzieć, na czym się siedzi. Lub leży.
Co to jest plan?
Plan to niekoniecznie tony dokumentacji projektowej, której i tak nie czyta. Nad planem wcale nie musi pracować piętnaście osób. Nie trzeba również do planowania zużywać stu dwudziestu karteczek Post-It, chociaż można. Prosty plan projektu napędzanego metodologią UX to dokument, który:
- Pozwala każdej osobie pracującej przy projekcie dowiedzieć się w szybki sposób, co dzieje się teraz i co wydarzy się później.
- Umożliwia interesariuszom natychmiastowy wgląd w oszacowania czasu i kosztu podejmowanych działań.
- Pozwala personelowi wykonawczemu (czytaj: Tobie i twoim koleżankom i kolegom) zrozumieć, co Was czeka i przygotować się do tego bez zbędnego zdenerwowania wynikającego z działania “w ostatniej chwili”.
- Wskazuje na etapy w procesie, które obarczone są szczególnym ryzykiem — nic tak nie poprawia jakości snu jak wiedza o tym, że trzymamy rękę na pulsie wydarzeń, które mogą ale nie muszą mieć miejsca.
Czy ja robię z Ciebie teraz project managera, zapytasz? Nie. Podstawowe planowanie i tak wykonujesz przy każdym projekcie, ale pewnie rzadko tworzysz dystrybuowany wśród całego zespołu dokument, który jasno wytycza zależności między procesami i tłumaczy kolejność działań. A tymczasem zrobienie czegoś takiego wydatnie zmniejsza ryzyko wystąpienia nieprzyjemnych sytuacji w rodzaju “ale miałeś zrobić jeszcze to!” albo “a ja myślę, że to powinniśmy zrobić inaczej”. Ja od lat tworzę tego rodzaju plany, które potem wysyłam do interesariuszy, swojego PMa i kolegów. W ten sposób każdy wie, czym się zajmuję, a co lepsze, czego będę od niego wymagał. I nie ma niespodzianek (to znaczy, oczywiście, są — ale mniej i jakby strawić je łatwiej).
Jak napisać plan projektu
Pokrótce sprowadza się to do tego, że wszystkie podejmowane w projekcie czynności trzeba umieścić w czasie. Następnie każdy z tych etapów trzeba opisać w sposób zrozumiały nie tylko dla personelu technicznego, ale i dla tych, których interesują zagadnienia finansowe czy marketing (pamiętaj o doborze odpowiedniego języka dla grupy docelowej swoich interesariuszy). Po stworzeniu takowego szkieletu wystarczy dopisać notki o koszcie każdego z etapów (PM pomoże), ryzyku, jakie może spowodować niewypełnienie któregoś z projektowych kryteriów i zawrzeć informację o odpowiedzialności, czyli wypisać, kto powinien realizować każdy z etapów. Gotowe.
Może to wyglądać na przykład tak:
Ten przykładowy etap opisuje czynności i ryzyko związane z rekrutacją partycypantów do testów użyteczności. Podobną tabelę można zastosować dla każdego z kroków procesu. „Kolejność” mówi sama za siebie.
Tak przygotowany plan można wysłać do wszystkich, których powinien on interesować:
- Kolegów i koleżanek w zespole. Grafików, programistów i UXów. Specjalistów od contentu. Jednym słowem, ekipy projektowej.
- Project managera i product ownera, jeśli taki jest. Tip: jeżeli pracujesz w firmie od niedawna, wyślij taki plan także do szefa, nawet, jeśli on nie bierze udziału w projekcie. Będzie naprawdę zadowolony.
- Drużyny po stronie klienta. Zrobienie tego pokaże, iż zależy Ci na procesach przejrzystych i otwartych na sugestie. Poza tym pokażesz klasę udowadniając, że myślisz w sposób logiczny i ustrukturyzowany, a nie tak jak “ci od kredek” (tym się zawsze obrywa).
Czym to się różni od pracy PMa?
Tym, że przygotowujesz jedno źródło informacji o wszystkim, co będzie się działo. O ile tego rodzaju założenia częściowo spełnia chociażby roadmap projektu, to rzadko kiedy można w jednym miejscu zobaczyć, jak łączą się ze sobą kolejne etapy procesu UX. Dodatkową zaletą sporządzenia planu i rozesłania go do zainteresowanych stron jest prosta zasada: co zostało napisane, może służyć jako referencja w sytuacji, w której gówienko uderza w wentylator.
Przed czym, jak wiadomo, zawsze warto się ochronić. Niezależnie od tego, na jakim szczeblu drabiny się stoi.
No, to do pisania!
Pomocy!
Jeżeli uczestniczyłeś w moich warsztatach w Warszawie, pomóż mi się rozwijać — i wypełnij ankietę na temat tego wydarzenia. Będę Ci ogromnie wdzięczny! Dziękuję.
Dodaj komentarz