Praktyczny przewodnik po budowaniu systemu zarzadzania projektami wokol tego, jak twoj zespol naprawde realizuje prace: dlaczego uniwersalne narzedzia PM sa ignorowane, jak odwzorowac wlasne etapy i przekazania, co musi znalezc sie w wersji pierwszej i jak widziec prace w toku bez spotkan o statusie.
Agencje, zespoly kreatywne, wykonawcy, zespoly produktowe i firmy uslugowe, ktorych dostawa nie miesci sie w gotowych narzedziach do projektow.
- Model projektu zbudowany na twoich rzeczywistych etapach dostawy i przekazaniach
- Jeden widok pracy w toku, ktory zastepuje spotkanie o statusie
- System, ktory mozesz przebudowac wraz ze zmiana procesu dostawy
Wiekszosc zespolow probowala juz narzedzia do zarzadzania projektami i wrocila do arkuszy oraz czatu. Problemem nie bylo narzedzie, tylko dopasowanie. Uniwersalne narzedzia narzucaja ksztalt, zadania w kolumnach, a twoja dostawa ma wlasny ksztalt: twoje etapy, twoje akceptacje, twoje przekazania. Kiedy narzedzie nie pasuje do tego, jak naprawde realizujesz prace, jego aktualizowanie staje sie zbedna robota i po cichu umiera. Ten przewodnik jest o zbudowaniu takiego, ktory pasuje, zeby sie przyjal.
Bo narzucaja uniwersalny ksztalt, zwykle zadania przesuwane po kolumnach, a twoja dostawa ma konkretne etapy, akceptacje i przekazania, ktore w niego nie wchodza. Wiec ludzie utrzymuja narzedzie dla dobra kierownictwa, podczas gdy prawdziwa koordynacja dzieje sie na czacie, narzedzie sie starzeje i staje sie drugim miejscem do aktualizowania zamiast miejscem, do ktorego sie zaglada. System projektowy przyjmuje sie tylko wtedy, gdy jego etapy to twoje etapy, twoimi slowami.
Ten sygnal jest znajomy: narzedzie mowi, ze projekt jest "w toku", podczas gdy wszyscy wiedza, ze tak naprawde "czeka na materialy od klienta", a na taki stan narzedzie nie ma nazwy. Kazdy brakujacy stan to male klamstwo, a tablicy pelnej malych klamstw nikt nie ufa, wiec nikt jej nie aktualizuje. Rozwiazaniem nie jest wiecej dyscypliny, tylko system, ktorego etapy odpowiadaja tym rzeczywistym, wlacznie z tymi niewygodnymi stanami oczekiwania, w ktorych praca naprawde grzeznie.
Dlatego opisanie wlasnej dostawy i zbudowanie systemu wokol niej bije konfigurowanie cudzego szablonu. Etapy, punkty akceptacji i przekazania to produkt, i sa specyficzne dla tego, jak pracujesz.
Zanim powstanie jakakolwiek tablica, odtworz, jak kilka niedawnych projektow faktycznie przeszlo od startu do konca, wlacznie z miejscami, gdzie utknely. Wyciagasz ksztalt swojej dostawy.
Studio projektowe ciagle gubilo projekty w luce miedzy "wyslane do klienta" a "klient odpowiedzial", gdzie sprawy stały calymi dniami bez wlasciciela i bez widocznego zegara. Uczciwie odwzorowany, ich przeplyw mial osiem etapow, trzy z nich to stany oczekiwania, a decydujaca funkcja bylo po prostu uczynienie stanow oczekiwania widocznymi wraz z zegarem, tak by projekt utkniety w "oczekiwanie na odpowiedz klienta" przez tydzien pokazywal sie na czerwono, zamiast chowac sie w uniwersalnej kolumnie "w toku". Nic wiecej sie nie zmienilo, a terminowosc dostaw skoczyla w gore.
Narzedzia do projektow puchna szybciej niz niemal kazdy inny rodzaj: sledzenie czasu, fakturowanie, planowanie zasobow, portale klienta, zaleznosci. Wersja pierwsza to najmniejsza rzecz, ktora czyni prace widoczna i posuwajaca sie naprzod.
Cykliczne spotkanie o statusie istnieje, bo status nigdzie nie jest widoczny; ludzie zbieraja sie, zeby powiedziec na glos to, co pokazywalby dobry system. Celem systemu projektowego jest uczynienie tego spotkania zbednym, a nie dodanie narzedzia, o ktorym na nim rozmawiacie.
Dochodzisz do tego, gdy kazdy moze otworzyc jeden widok i zobaczyc kazdy projekt, jego etap, jego wlasciciela i jak dlugo stoi. Etapy oczekiwania z zegarem zamieniaja ciche przestoje w widoczne; projekt, ktory jest w "przegladzie klienta" od osmiu dni, sam sie ujawnia, a rozmowa staje sie decyzja, a nie odkryciem. Gdy tablica jest zaufana i aktualna, spotkanie kurczy sie do tych nielicznych spraw, ktore naprawde wymagaja omowienia, i czesto znika.
Utrzymanie zaufania do systemu opiera sie na dwoch rzeczach, ktore plyna z posiadania go na wlasnosc: tablica odpowiada rzeczywistosci, bo twoje etapy to te prawdziwe, i nadal odpowiada, bo sam mozesz zmieniac etapy, gdy twoja dostawa ewoluuje. System projektowy zbudowany wokol twojego przeplywu pracy, ktory mozesz przebudowac bez zgloszenia do dzialu inzynierii, to system, ktory twoj zespol utrzymuje w aktualnosci, bo w koncu mowi prawde o pracy.
Bo narzedzie narzuca uniwersalny ksztalt, zwykle zadania w kolumnach, ktory nie pasuje do twoich rzeczywistych etapow dostawy, akceptacji i przekazan. Ludzie utrzymuja je dla kierownictwa, podczas gdy prawdziwa koordynacja zostaje na czacie, wiec sie starzeje. System sie przyjmuje, gdy jego etapy to twoje rzeczywiste etapy, wlacznie ze stanami oczekiwania, w ktorych praca naprawde grzeznie.
Odtworz, jak kilka niedawnych projektow faktycznie przeszlo, wlacznie z miejscami, gdzie utknely, i nazwij rzeczywiste etapy twoimi slowami: zabriefowane, w projektowaniu, przeglad klienta, poprawki, zatwierdzone i tak dalej. Co kluczowe, uwzglednij stany oczekiwania jak "oczekiwanie na odpowiedz klienta", bo to tam praca chowa sie w uniwersalnych narzedziach.
Projekty znajdujace sie w jednym jasnym rzeczywistym etapie, wlasciciel dla kazdego projektu i etapu, jeden widok calej pracy w toku wedlug etapow oraz jawne przekazania, tak by nastepny wlasciciel wiedzial bez wiadomosci na czacie. Sledzenie czasu, fakturowanie i zaleznosci moga poczekac do wersji drugiej.
W duzej mierze tak. Spotkanie istnieje, bo status nigdzie nie jest widoczny. Gdy jeden zaufany widok pokazuje kazdy projekt, jego etap, jego wlasciciela i jak dlugo stoi, z zegarem na etapach oczekiwania, czesc spotkania poswiecona odkrywaniu znika i zostaja tylko prawdziwe decyzje. Tablica musi byc aktualna i prawdziwa, co plynie z tego, ze sam ja posiadasz i nadajesz jej ksztalt.