W pierwszych pięciu dniach w płonącym projekcie nie musisz umieć ugasić pożaru. Musisz umieć nazwać, co się pali i pokazać zespołowi, że wiesz jak te pożary ugasić.

Zrozumienie tego zajęło mi kilka lat. Daję Ci ten tip już na starcie, gdybyś nie miał czasu na przeczytanie całego tekstu, choć uważam, że warto przeczytać całość.

Sytuacja, którą pewnie znasz

Dostajesz projekt w trakcie. Poprzedni PM zniknął albo właśnie odchodzi i przekazanie projektu trwa pół godziny, z czego dwadzieścia minut to narzekanie. Klient wyraża swoją złość i frustrację w trzech wątkach mailowych. Na Slacku wiszą pytania sprzed tygodnia, na które nikt nie odpisał. Ktoś w zespole robi zadanie, które przestało być potrzebne pięć dni temu, tylko nikt mu o tym nie powiedział.

I najgorsze nie jest to, że jest chaos. Najgorsze jest to, że wszyscy zakładają, że Ty ten chaos rozumiesz, a Ty dopiero wszedłeś i dociera do Ciebie, jak jest źle.

W tym momencie większość osób popełnia ten sam błąd: próbuje w tydzień zrozumieć wszystko. Otwiera każdy wątek, chce mieć pełny obraz, zanim zrobi pierwszy ruch. Efekt jest odwrotny do zamierzonego. Po tygodniu nadal nie masz pełnego obrazu, a zespół ma już wyrobione zdanie: kolejny PM, który nic nie zmieni. Jeśli wchodzisz do płonącego projektu, to najgorsze, co możesz zrobić, to zamknąć się w pokoju i czytać całą dokumentację projektową. I wiesz co? Ona prawdopodobnie jest tak aktualna jak sanki na lato.

Zmiana, która realnie działa, jest w Twojej głowie. Nie wchodzisz z nastawieniem „muszę wiedzieć wszystko", tylko z nastawieniem „muszę wiedzieć, gdzie znajdę odpowiedzi". Pierwsze paraliżuje. Drugie uwalnia.

Pierwsze zamyka Ciebie w pokoju z nieaktualną dokumentacją, drugie pozwala wejść w interakcję z zespołem i zobaczyć samemu, gdzie są realne problemy i na czym stoicie.

Jak już zrozumiesz, gdzie są problemy, jakie są oczekiwania i co aktualnie w projekcie się dzieje, wtedy możesz przejść do robienia porządków. Dzień po dniu, aż wyprowadzisz projekt na prostą.

Dzień 1. Nie zarządzasz. Słuchasz

Rozmawiasz z każdą osobą z zespołu po kolei, najlepiej 1:1, po 15-20 minut. Zadajesz jedno pytanie: „Co Cię teraz najbardziej blokuje?". Notujesz. Nic nie obiecujesz.

To „nic nie obiecujesz" jest trudniejsze, niż brzmi. Będziesz chciał od razu naprawiać, bo to naturalny odruch kogoś, kto chce się wykazać. Pamiętaj jednak, że każda obietnica z dnia pierwszego to dług zaciągnięty na ślepo: nie znasz jeszcze zależności, więc nie wiesz, ile ta obietnica będzie kosztować. Najgorsze, że ten dług trzeba będzie któregoś dnia spłacić.

Wracając do rozmów, po rundzie takich rozmów masz coś, czego nie da żadna dokumentacja: mapę frustracji. Zwykle kilka osób niezależnie wskaże ten sam problem. Zapamiętaj go, wróci w dniu trzecim.

Dzień 2. Robisz mapę projektu

Nie czytasz wszystkiego. Odpowiadasz na trzy pytania: gdzie są pliki i która wersja jest prawdziwa, kto za co odpowiada, gdzie zapadają decyzje.

To ostatnie pytanie jest najmniej oczywiste i najcenniejsze. W każdym projekcie jest oficjalny obieg decyzji i jest ten prawdziwy: czasem decyzje zapadają na spotkaniu, a czasem w wątku prywatnym między klientem a jednym developerem. Dopóki nie wiesz, którędy naprawdę płyną decyzje, nie prowadzisz projektu, tylko go obserwujesz.

Nie musisz wiedzieć wszystkiego. Musisz wiedzieć, gdzie to znaleźć. Mapa na jednej stronie wystarczy.

Dzień 3. Gasisz jeden mały pożar

Z rozmów z dnia pierwszego wybierasz jedną irytację zespołu. Nie największy problem projektu, tylko coś małego, co ciągnie się od tygodni i codziennie kogoś uwiera: cykliczne spotkanie, które nic nie wnosi, brak dostępu do narzędzia, niejasny właściciel jednego zadania. Twoim celem jest usunięcie tego irytującego problemu.

Dlaczego nie największy problem? Bo największego nie rozwiążesz w dniu trzecim, a spektakularna próba i porażka kosztują Cię utratę zaufania. Mały pożar ugaszony naprawdę robi coś odwrotnego: zespół widzi, że rozmowy z dnia pierwszego nie poszły w notatnik i do szuflady, że jak coś Ci mówią, to coś się dzieje.

Zaufanie w kryzysie buduje się szybciej jednym usuniętym problemem niż godziną prezentacji o nowym otwarciu.

Dzień 4. Ustawiasz rytm informacji

Jeden rytm, jedno miejsce, jeden format. Na przykład: krótki status w każdy wtorek i piątek, zawsze w tym samym kanale, zawsze w tej samej strukturze: co się przesunęło, co jest zagrożone, czego potrzebujemy.

Cel jest prosty: stakeholder ma wiedzieć, co się dzieje, zanim zapyta. Każde „a jak tam projekt?" na korytarzu albo na Slacku to sygnał, że Twój system informacji nie działa i ktoś musi go łatać ręcznie, pytaniem.

Uwaga na drugą skrajność: raportowanie wszystkiego wszystkim. To nie jest komunikacja, to szum, w którym giną rzeczy naprawdę pilne. Jeden format, świadomie ubogi, za to regularny jak w zegarku.

Dzień 5. Spisujesz „jak tu pracujemy"

Jedna strona. Gdzie się komunikujemy, jak wyglądają Daily, jak zgłaszamy blokady, jak podejmujemy decyzje, kiedy się nie zgadzamy. Bez teorii, bez metodyk z podręcznika, tylko to, co realnie obowiązuje od poniedziałku.

To Twój pierwszy trwały ślad w projekcie. Wszystko, co robiłeś w dniach 1-4, działo się w rozmowach i mogłoby wyparować. Ta strona sprawia, że nowy porządek istnieje niezależnie od Ciebie: można do niej odesłać nową osobę, można się na nią powołać w sporze.

Jeśli masz ochotę napisać piętnaście stron, powstrzymaj się. Dokument, którego nikt nie przeczyta, nie porządkuje niczego. Jedna strona, którą zna cały zespół, robi więcej niż segregator procedur.

„Dobrze, ale ja mam deadline za cztery dni"

Uczciwa odpowiedź: wtedy ściskasz plan, nie zmieniasz kolejności. Dzień pierwszy i drugi robisz w jeden dzień, rozmowy skracasz do 10 minut, mapę do pół strony. Ale nie pomijasz słuchania i mapy, żeby „od razu działać". Działanie bez mapy w płonącym projekcie to bieganie z gaśnicą po budynku, którego rozkładu nie znasz.

I jeszcze jedno. Po piątym dniu projekt nadal nie jest uratowany, to normalne. Masz za to trzy rzeczy, których nie miałeś w poniedziałek: wiesz, co się pali, zespół widział pierwszy konkret, a informacja płynie w rytmie, który Ty ustawiłeś. Dopiero na tym fundamencie ma sens plan naprawczy. Nie odwrotnie.

Plan na pierwsze 5 dni w wersji do skrzynki

Spakowałem ten plan w krótką pigułkę „First 5 PM Days": dzień po dniu, z pytaniami do zadania i pułapkami do ominięcia. Ten sam plan, który sam odpalam przy każdym wejściu w trudny projekt. Oddaję go za darmo.

Zostawiasz maila tutaj: https://krzysztofnyrek.pl/first-5-pm-days i plan przychodzi od razu, razem z zaproszeniem na darmowego Discorda dla PM. To miejsce, gdzie możesz pogadać z ludźmi, którzy właśnie przechodzą przez podobne wejścia.

A jeśli jesteś teraz w środku takiego przejęcia: który z tych pięciu dni wydaje Ci się najtrudniejszy? Napisz, podpowiem, jak go przejść.

Krzysztof Nyrek. IT Project Manager, ponad 10 lat prowadzenia projektów, w tym takich, które płonęły w dniu przejęcia.

Chcesz mieć ten plan pod ręką?

Zebrałem pierwsze pięć dni w projekcie w jeden dokument, dzień po dniu. Za darmo, bez haczyka: First 5 PM Days.

Jest też darmowy Discord dla PM-ów, gdzie takie sytuacje rozkładamy na czynniki pierwsze: discord.gg/ZV5jxsPXT.