Prompty Zarządzanie projektami

Przygotuj kartę projektu (Project Charter) dla projektu [nazwa projektu] realizowanego przez [firma]. Cel projektu: [cel]. Sponsor: [sponsor]. Zespół: [skład]. Budżet: [budżet]. Planowany termin zakończenia: [termin]. Kontekst biznesowy: [co zainicjowało projekt].

Struktura: kontekst i problem do rozwiązania (3 linie), cel sformułowany w sposób mierzalny, zakres projektu (in-scope), zakres wyraźnie WYŁĄCZONY (out-of-scope – równie szczegółowy jak zakres włączony, aby uniknąć rozmycia projektu), produkty końcowe z kryteriami akceptacji, kamienie milowe z datami, role i odpowiedzialności (kto decyduje, kto wykonuje, kto jest konsultowany, kto informowany), zidentyfikowane ryzyka wraz z planem mitygacji ([przewidywane ryzyka]), założenia i zależności.

Sformułuj każdą sekcję tak, aby ewentualne rozbieżności wyszły na jaw TERAZ, podczas lektury, a nie w trakcie realizacji. Zakończ listą 3 kluczowych pytań, które komitet sterujący musi rozstrzygnąć przed startem.

Przekształć moje surowe notatki ze spotkania w ustrukturyzowany protokół (MoM). Spotkanie: [temat spotkania] z dnia [data], uczestnicy: [uczestnicy]. Moje notatki: [surowe notatki].

Format wyjściowy: podjęte decyzje (sformułowane jednoznacznie, ze wskazaniem decydenta), zadania (tabela: zadanie, osoba odpowiedzialna, termin; jeśli w notatkach brakuje którejś z tych informacji, wpisz „DO DOPRECYZOWANIA” zamiast zmyślać), omówione punkty bez decyzji (maks. 2 linie na punkt), punkty przełożone z datą kolejnej dyskusji.

Zasady: maksymalnie jedna strona, brak parafraz zmieniających sens wypowiedzi, zero dyplomatycznych ogólników typu „uzgodniono postępy w temacie”. Zakończ listą punktów „DO DOPRECYZOWANIA” do wysłania uczestnikom w celu walidacji.

Podziel poniższy projekt na pakiety prac (WBS) i przygotuj harmonogram. Projekt: [opis projektu i produkt końcowy]. Termin: [data]. Dostępny zespół: [osoby i dostępność, np. 2 osoby na pół etatu]. Znane ograniczenia: [ograniczenia: akceptacja klienta, zależność od dostawcy, okresy urlopowe].

Postępuj według schematu: podziel na pakiety prac generujące weryfikowalne produkty (brak pakietu „koordynacja”), rozbij każdy pakiet na zadania trwające od 0,5 do 3 dni, zidentyfikuj zależności między zadaniami i ścieżkę krytyczną, umieść wyraźny bufor czasowy przy niepewnych zadaniach zamiast ukrytego marginesu wszędzie.

Dostarcz: ustrukturyzowaną listę pakiety → zadania z estymacjami, harmonogram tygodniowy z kamieniami milowymi akceptacji, wyróżnioną ścieżkę krytyczną oraz 3 zadania, które muszą ruszyć natychmiast, bo warunkują resztę. Zasygnalizuj, jeśli termin [data] jest nierealny przy opisanym zespole, podając konkretne liczby.

Przygotuj cotygodniowy raport Flash dla projektu [nazwa projektu] dla [odbiorcy, np. komitet sterujący]. Dane z tygodnia: postęp [co zrobiono vs plan], trudności [napotkane problemy], ewoluujące ryzyka [ryzyka], zużycie budżetu [wydatki vs plan], oczekiwane decyzje [blokady czekające na decyzję i od kiedy].

Ścisły format jednej strony: status projektu (zielony/pomarańczowy/czerwony) z JEDNYM zdaniem uzasadniającym kolor, 3 najważniejsze fakty tygodnia, postęp vs plan (jedna linia na aktywny pakiet), ryzyka i punkty krytyczne (tylko to, co zmieniło się od zeszłego tygodnia), oczekiwane decyzje z nazwiskiem decydenta i skutkiem opóźnienia, priorytety na kolejny tydzień.

Zasady: projekt nigdy nie wraca na zielono bez wyjaśnienia, co rozwiązało problem; status pomarańczowy przez dwa tygodnie z rzędu staje się czerwony; przy oczekiwanych decyzjach podaj datę pierwotnego zgłoszenia.

Przygotuj scenariusz retrospektywy dla projektu [nazwa projektu], który właśnie się zakończył [wynik: terminowo, opóźnienie o X, przerwany]. Uczestnicy: [uczestnicy i role]. Czas trwania: [czas, np. 1,5h]. Kluczowe momenty: [co poszło dobrze/źle, ewentualne napięcia].

Dostarcz: szczegółowy plan (otwarcie z zasadą „szukamy przyczyn, nie winnych”, indywidualne zbieranie uwag przed dyskusją grupową w celu uniknięcia konformizmu, dyskusja nad kluczowymi punktami, decyzje), konkretne pytania pozwalające wyjść poza ogólniki („w którym dokładnie momencie wiedzieliśmy, że termin się przesuwa? co przeszkodziło nam o tym powiedzieć?”) oraz technikę poruszenia [ewentualny drażliwy temat] bez wywoływania wzajemnych oskarżeń.

Format wniosków: każda lekcja staje się konkretną zasadą na kolejny projekt („od teraz będziemy...”) z przypisaną osobą odpowiedzialną. Maksymalnie 5 zasad: powyżej tej liczby nic nie zostanie wdrożone.

Działaj jako doświadczony dyrektor projektów. Pomóż mi przygotować analizę zasadności (Business Case) projektu [nazwa projektu] rozważanego przez [firma]. Problem lub szansa u podstaw: [kontekst]. Oczekiwane korzyści: [spodziewane zyski]. Maksymalny budżet: [kwota]. Znane alternatywy: [alternatywy, w tym zaniechanie działań].

Ustrukturyzuj dokument w 6 częściach: problem do rozwiązania i koszt bezczynności, możliwe opcje (w tym status quo) z zaletami i wadami, zgrubne szacunki kosztów i terminów dla każdej opcji (szerokie widełki), oczekiwane korzyści powiązane z mierzalnymi wskaźnikami, główne ryzyka każdej opcji, uargumentowana rekomendacja.

Ograniczenia: każda korzyść musi być przypisana do weryfikowalnego wskaźnika, inaczej oznacz ją jako „zakładana korzyść niemierzalna”. Sformułuj 5 kryteriów decyzji go/no-go dla komitetu. Zakończ listą brakujących informacji, które osłabiają analizę, wraz ze wskazaniem, kto powinien ich dostarczyć.

Przygotuj jednostronicową kartę projektu dla małej inicjatywy, która nie wymaga pełnej dokumentacji. Projekt: [opis w 2 zdaniach]. Zlecający: [zlecający]. Zaangażowane osoby: [osoby i dostępny czas]. Pożądany termin: [data]. Ewentualny budżet: [kwota lub brak].

Narzucony format, maks. jedna strona: cel w jednym mierzalnym zdaniu, produkt końcowy i sposób weryfikacji jego ukończenia, co jest wyłączone z zakresu (minimum 3 linie – to najważniejsza sekcja), kto podejmuje ostateczne decyzje, kamienie milowe (maks. 3), główne ryzyko i plan przeciwdziałania.

Ograniczenia: zero żargonu projektowego, zdania zrozumiałe dla laika przy pierwszym czytaniu. Jeśli moje dane wejściowe nie pozwalają wypełnić sekcji, wpisz „DO WYJAŚNIENIA z [osoba]” zamiast zmyślać. Zakończ 2 pytaniami do zlecającego przed startem.

Rozpoczynam projekt [nazwa projektu] dla [firma] i muszę zebrać wymagania przed ustaleniem zakresu. Osoby do wywiadu: [lista profili, np. zarząd, użytkownicy operacyjni, wsparcie, IT]. Co projekt ma dostarczyć: [przewidywany produkt]. Czas na jeden wywiad: [czas].

Przygotuj dla każdego profilu dopasowany scenariusz: 8-10 pytań otwartych od ogółu do szczegółu, rozróżniając pytania o obecny sposób pracy (problemy, obejścia, wolumeny) od pytań o przyszłe potrzeby. Dodaj dla każdego profilu 2 „podchwytliwe” pytania wydobywające nieuświadomione potrzeby, np. „co robisz, gdy obecne narzędzie zawodzi?”.

Ograniczenia: zakaz pytań sugerujących odpowiedź oraz pytań zamkniętych (tak/nie). Dostarcz również szablon syntezy: potrzeby wyrażone, potrzeby wywnioskowane, sprzeczności między profilami do rozstrzygnięcia oraz kluczowe cytaty (verbatimy).

Przekształć te surowe potrzeby w User Stories gotowe dla zespołu realizacyjnego. Projekt: [nazwa i krótki opis]. Użytkownicy: [profile użytkowników]. Wyrażone potrzeby: [lista potrzeb, nawet ogólnych].

Dla każdej potrzeby przygotuj: User Story w formacie „Jako [profil], chcę [akcja], aby [korzyść]”, 3-5 kryteriów akceptacji sformułowanych binarnie (weryfikowalne tak/nie, bez słów typu „szybko” czy „intuicyjnie” bez progu) oraz pytania do zlecającego, jeśli potrzeba jest zbyt ogólna do podziału.

Ograniczenia: historyjka musi być możliwa do zrealizowania w kilka dni, inaczej zaproponuj jej podział. Wskaż potrzeby, które są de facto gotowymi rozwiązaniami i sformułuj je jako realne potrzeby. Przedstaw wynik w tabeli: story, kryteria akceptacji, szacowany rozmiar (S/M/L), pytania otwarte. Zakończ listą zależności między historyjkami.

Pomóż mi spriorytetyzować backlog projektu [nazwa projektu]. Elementy oczekujące: [lista zgłoszeń z opisem]. Wydajność zespołu: [wydajność, np. 15 osobodni na miesiąc]. Priorytetowy cel kwartału: [cel]. Najbardziej naciskający interesariusze: [ewentualny kontekst polityczny].

Oceń każdy element na dwóch osiach: wartość (wkład w cel kwartału, liczba użytkowników, koszt nierozwiązania problemu) oraz szacowany wysiłek (rozmiar relatywny). Podziel na 4 kategorie: do zrobienia teraz (wysoka wartość, mały wysiłek), do zaplanowania (wysoka wartość, duży wysiłek), do wypełnienia luk (niska wartość, mały wysiłek), do odrzucenia lub jawnego odroczenia (niska wartość, duży wysiłek).

Ograniczenia: nacisk interesariusza nie jest kryterium wartości, ale wypisz osobno odmowy wymagające wyjaśnienia. Przedstaw ranking w tabeli z uzasadnieniem w jednym zdaniu, a następnie przygotuj 3 najtrudniejsze komunikaty o odmowie – krótkie i oparte na faktach.

Zbuduj roadmapę na najbliższe 2 kwartały dla [produkt lub projekt] w [firma]. Cele roczne: [cele]. Kandydaci do realizacji: [lista planowanych prac]. Wydajność zespołu: [wielkość i dostępność]. Podjęte zobowiązania: [nienegocjowalne terminy klienckie lub wewnętrzne].

Zorganizuj roadmapę kwartalnie, formułując każdą pozycję jako oczekiwany rezultat, a nie funkcjonalność („skrócenie czasu obsługi zgłoszeń” zamiast „budowa modułu X”). Dla każdego kwartału: maks. 2-3 duże tematy, cel, wskaźnik sukcesu, zależności.

Ograniczenia: zachowaj 20% wolnych mocy na nieprzewidziane zdarzenia i zaznacz to wyraźnie. Wymień, czego świadomie brakuje i dlaczego, aby uciąć pytania „a dlaczego nie X?”. Dostarcz dwie wersje: szczegółową dla zespołu i 5-liniową dla zarządu. Wskaż tematy, których wartość jest zbyt mglista, by je zaplanować.

Pomóż mi oszacować pracochłonność projektu [nazwa projektu]. Zakres: [lista pakietów lub zadań]. Zespół: [profile i doświadczenie]. Dane historyczne: [podobne projekty i ich realny czas trwania, jeśli znane].

Dla każdego pakietu: szacunek w widełkach (optymistyczny, prawdopodobny, pesymistyczny) zamiast jednej liczby, założenia leżące u podstaw szacunku (co musi być prawdą, by się udał) oraz czynnik, który zepchnąłby nas do scenariusza pesymistycznego.

Ograniczenia: jeśli istnieją dane historyczne, skonfrontuj szacunek z realnym czasem z przeszłości i wyjaśnij różnicę. Dodaj systematycznie pomijane koszty: poprawki po testach, koordynacja, wdrożenie nowych osób, planowane nieobecności. Przedstaw sumę w 3 scenariuszach z procentową różnicą. Jeśli różnica przekracza dwukrotność, wskaż, jakie informacje zmniejszyłyby niepewność przed podaniem wiążącej liczby.

Zbuduj pełny budżet projektu [nazwa projektu] dla [firma]. Planowane koszty wewnętrzne: [osobodni wg profilu i koszt dzienny]. Zakupy i usługi zewnętrzne: [lista]. Czas trwania: [czas]. Zatwierdzona pula: [kwota].

Najpierw przygotuj budżet wg kategorii: koszty wewnętrzne, usługi zewnętrzne, licencje i narzędzia, koszty dodatkowe oraz rezerwa na ryzyka (uzasadnij jej procent poziomem niepewności). Sprawdź spójność z zatwierdzoną pulą i zasygnalizuj przekroczenia już na etapie planowania.

Następnie zaprojektuj system miesięcznego monitoringu: tabela wydatki vs budżet, ponowna estymacja kosztów do końca (ETC – nie tylko to, co zostało w budżecie), prognoza końcowa (EAC) oraz 2 progi alarmowe uruchamiające informację dla sponsora. Zakończ listą 3 najczęstszych przyczyn przekroczeń w takich projektach i sposobami na ich wczesne wykrycie.

Stwórz rejestr ryzyk dla projektu [nazwa projektu]. Kontekst: [opis projektu, termin, cele]. Przewidywane ryzyka: [zidentyfikowane ryzyka]. Zależności zewnętrzne: [dostawcy, inne zespoły, oczekiwane zgody].

Uzupełnij moją listę o typowe ryzyka dla tego typu projektów, których nie wymieniłem, szukając w 4 grupach: ludzkie (odejścia, przeciążenie, brak kompetencji), techniczne, organizacyjne (opóźnione decyzje, puchnący zakres), zewnętrzne. Dla każdego ryzyka: konkretny opis skutków, prawdopodobieństwo (niskie/średnie/wysokie), wpływ (niski/średni/wysoki), wynikowa krytyczność, wczesny sygnał ostrzegawczy, plan zapobiegania, plan awaryjny (contingency), osoba odpowiedzialna.

Ograniczenia: formułuj każde ryzyko jako zdarzenie („dostawca dostarcza z miesięcznym opóźnieniem”), nigdy jako ogólne hasło („opóźnienia”). Posortuj wg krytyczności i ogranicz rejestr do 10 kluczowych ryzyk. Określ częstotliwość przeglądów i pytania kontrolne.

Zmapuj interesariuszy projektu [nazwa projektu] w [firma]. Zidentyfikowani aktorzy: [lista osób/działów z rolami]. Co projekt zmieni dla każdego z nich: [przewidywany wpływ]. Zaobserwowane wsparcie lub opór: [kontekst].

Umieść każdego aktora na dwóch osiach: wpływ na projekt (może zablokować, przyspieszyć lub nie ma wpływu) oraz obecne nastawienie (wspierający, neutralny, sceptyczny). Dla każdego kluczowego aktora określ: co zyska lub straci na projekcie, prawdopodobne obiekcje sformułowane jego słowami oraz dopasowaną strategię zaangażowania (udział w decyzjach, regularne info, rozmowa 1:1 przed ogłoszeniami).

Ograniczenia: nie myl struktury organizacyjnej z realnym wpływem – wskaż osoby bez tytułów, których głos się liczy. Przedstaw plan w tabeli: aktor, obecna pozycja, pozycja niezbędna do sukcesu, działania, właściciel, termin. Wskaż 2 osoby, z którymi muszę porozmawiać w pierwszej kolejności w tym tygodniu.

Zbuduj plan komunikacji projektu [nazwa projektu]. Odbiorcy: [odbiorcy, np. sponsor, zespół, użytkownicy, inne działy]. Czas trwania: [czas]. Znane kluczowe momenty: [kamienie milowe, wdrożenia, ogłoszenia]. Dostępne kanały: [kanały: spotkania, e-mail, intranet, komunikator].

Dla każdej grupy zdefiniuj: co muszą wiedzieć (i tylko to), optymalną częstotliwość, kanał, format (2 linie, jedna strona, spotkanie) oraz kto przygotowuje komunikat. Rozróżnij komunikację cykliczną (statusy) od eventowej (start, wdrożenie, incydent, zakończenie).

Ograniczenia: każdy komunikat musi odpowiadać na pytanie odbiorcy „co to dla mnie zmienia?”, inaczej usuń go z planu. Przygotuj gotowe szablony wiadomości na start i na wdrożenie. Przedstaw plan w tabeli, a następnie wymień 3 najczęstsze błędy komunikacyjne w takich projektach i jak ten plan ich unika.

Zbuduj macierz RACI dla projektu [nazwa projektu]. Główne aktywności: [lista działań lub produktów]. Aktorzy: [osoby lub funkcje]. Zaobserwowane napięcia: [kontekst, np. dwie osoby myślą, że decydują o tym samym].

Dla każdej aktywności przypisz role: R (Responsible – wykonuje), A (Accountable – ostatecznie decyduje i odpowiada, tylko jedna osoba na linię), C (Consulted – konsultowany przed), I (Informed – informowany po). Wyjaśnij w jednej linii każde nieoczywiste przypisanie.

Zasady jakościowe do sprawdzenia: nigdy dwóch A w jednej linii, brak linii bez R, zasygnalizuj nadmiar C (wąskie gardło konsultacyjne) oraz osoby bez żadnej roli (do usunięcia z projektu). Przedstaw macierz w tabeli, a następnie wskaż 3 punkty najbardziej narażone na konflikt z rekomendacją ich zabezpieczenia oraz pytania do rozstrzygnięcia z zespołem przed publikacją macierzy.

Przygotuj spotkanie inauguracyjne (kick-off) projektu [nazwa projektu]. Uczestnicy: [uczestnicy i role]. Czas trwania: [czas, np. 1h]. Status definicji: [karta projektu zatwierdzona lub w trakcie]. Wrażliwe punkty: [napięcia, sceptycyzm, historia nieudanych projektów w tym obszarze].

Dostarcz: agendę z podziałem na minuty (dlaczego ten projekt i dlaczego teraz, konkretny wynik końcowy, co jest poza zakresem, kto co robi, kamienie milowe, zasady współpracy, pytania), 3 kluczowe przekazy, które każdy musi zapamiętać, oraz sposób na poruszenie [wrażliwy punkt] bez psucia atmosfery, ale i bez unikania tematu.

Ograniczenia: kick-off to nie tylko prezentacja, zaplanuj 2 momenty interaktywne (np. szybka identyfikacja ryzyk, runda pytań o obawy). Przygotuj treść zaproszenia z agendą i listę rzeczy, które muszą być zatwierdzone PRZED spotkaniem, aby nie startować z chaosem.

Przygotuj najbliższy komitet sterujący projektu [nazwa projektu]. Uczestnicy: [członkowie komitetu]. Czas trwania: [czas]. Sytuacja projektu: [postęp, trudności, budżet]. Decyzje, których potrzebuję: [oczekiwane decyzje z opcjami]. Tematy, które mogą zdominować dyskusję: [drażliwe kwestie].

Zbuduj agendę wychodząc od decyzji, a nie od statusu: każda decyzja to punkt z przypisanym czasem, przygotowanymi opcjami (2-3 warianty z zaletami, wadami i rekomendacją) oraz skutkiem ponownego odroczenia decyzji. Status projektu omawiany jest w maks. 10 minut na bazie dokumentu wysłanego wcześniej.

Dostarcz: agendę minutową, dokładne sformułowanie próśb o decyzję, technikę uprzejmego ucinania dygresji na [drażliwy temat] oraz szablon notatki decyzyjnej do wysłania w ciągu 24h. Wymień materiały, które muszę wysłać uczestnikom 48h przed spotkaniem.

Zaprojektuj strukturę prezentacji na komitet sterujący projektu [nazwa projektu]. Dane z miesiąca: postęp [realizacja vs plan], budżet [zużycie vs plan], ryzyka [zmiany], oczekiwane decyzje [lista], kluczowe wydarzenia [fakty z miesiąca].

Przygotuj plan slajd po slajdzie, maks. 10 slajdów: synteza na jednym slajdzie (status, główny przekaz, decyzje), postęp wg pakietów z odchyleniami, trajektoria budżetu, ryzyka ze zmienioną oceną, zoom na najtrudniejszy punkt miesiąca z opcjami i rekomendacją, prośby o decyzje (jeden slajd na decyzję), kolejne kroki.

Dla każdego slajdu: tytuł będący wnioskiem („Pakiet 2 nadrabia zaległości”, a nie „Status pakietu 2”), treść w maks. 5 punktach oraz to, co należy powiedzieć ustnie, a czego nie ma na slajdzie. Ograniczenia: zero slajdów przypominających kontekst, który komitet już zna; liczby zaokrąglone i porównane (vs plan, vs zeszły miesiąc). Zakończ testem: czy jeśli komitet przeczyta tylko slajd 1, będzie miał komplet kluczowych informacji?

Zaprojektuj proces zarządzania zmianą dla projektu [nazwa projektu]. Kontekst: [źródło zmian, np. klient dodaje wymagania na bieżąco, zarząd zmienia zdanie]. Istniejące gremia: [spotkania i komitety]. Dostępny margines: [pozostały bufor czasu i budżetu].

Zdefiniuj: minimalny formularz zgłoszenia zmiany (opis, zgłaszający, uzasadnienie, realna pilność), 4 systemowe pytania analizy wpływu (wpływ na termin, budżet, inne pakiety prac, co się stanie, jeśli nie wdrożymy), kto decyduje w zależności od skali wpływu (zaproponuj progi kwotowe/czasowe) oraz sposób ewidencji w rejestrze zmian.

Przygotuj 3 wzory odpowiedzi: zmiana zaakceptowana z ogłoszonym wpływem, zmiana odroczona do kolejnej wersji, zmiana odrzucona z uzasadnieniem. Ograniczenia: proces musi mieścić się na pół strony, inaczej nikt go nie użyje; żadna zmiana nie może być przyjęta „na gębę” bez wpisu do rejestru. Zakończ sposobem na przedstawienie tego procesu najbardziej naciskającemu interesariuszowi.

Pomóż mi przygotować się do renegocjacji nierealnego terminu. Projekt: [nazwa projektu]. Narzucony termin: [data]. Moje przekonanie: potrzeba [realny czas], ponieważ [powody: szacowana praca, zależności, dostępność zespołu]. Sponsor: [profil sponsora i co jest dla niego ważne]. Cel ukryty za datą: [dlaczego ta data, jeśli wiem].

Przygotuj: faktyczne wykazanie luki (pracochłonność vs wydajność w prostych liczbach) oraz 3 uczciwe opcje: dotrzymanie daty poprzez redukcję zakresu (wskaż dokładnie, co wyleci), zachowanie zakresu przy przesunięciu daty, dodanie zasobów z podaniem kosztów i ograniczeń tej opcji (nowa osoba nie jest efektywna od pierwszego dnia).

Ograniczenia: nigdy nie mów „to niemożliwe” bez podania alternatywy; nigdy nie akceptuj na spotkaniu kompromisu bez przeliczenia liczb. Przygotuj odpowiedzi na 3 prawdopodobne obiekcje sponsora, w tym „poradźcie sobie jakoś” i „zobaczymy w trakcie”. Format: jedna strona argumentacji plus tabela porównawcza 3 opcji.

Stwórz plan naprawczy dla projektu [nazwa projektu], który ma [wielkość opóźnienia] opóźnienia względem terminu [data]. Zidentyfikowane przyczyny: [przyczyny]. Pozostałe prace: [pakiety lub zadania z estymacjami]. Zespół: [skład i dostępność]. Pole manewru: [możliwy dodatkowy budżet, zakres negocjowalny lub nie].

Zacznij od weryfikacji diagnozy: czy opóźnienie wynika z niedoszacowania, spuchniętego zakresu, zabranych zasobów czy blokad zewnętrznych? Odpowiedź determinuje plan. Następnie zbuduj plan naprawczy w oparciu o realne dźwignie: redukcja zakresu, zmiana kolejności prac (równoległość), usunięcie zbędnych zadań, wzmocnienie wyłącznie na ścieżce krytycznej.

Ograniczenia: zakaz nadrabiania poprzez „ściskanie” estymacji bez uzasadnienia; zakaz usuwania czasu na testy. Dostarcz: nowy harmonogram z wiarygodną datą, informację o tym, co zostało poświęcone, 2 warunki sukcesu planu oraz komunikat dla sponsora, który bierze odpowiedzialność za opóźnienie bez owijania w bawełnę.

Przygotuj eskalację blokady w projekcie [nazwa projektu]. Blokada: [opis blokady, np. brak decyzji, nieprzydzielone zasoby, konflikt między działami]. Od kiedy: [data]. Co już zrobiłem: [podjęte próby rozwiązania]. Odbiorca eskalacji: [osoba i jej poziom]. Osoby zaangażowane w blokadę: [aktorzy i ewentualne punkty zapalne].

Napisz wiadomość eskalacyjną: przypomnienie o blokadzie w 3 konkretnych liniach z datami, mierzalne skutki braku decyzji (stracone dni, koszty, zagrożone kamienie milowe), 2-3 opcje odblokowania z moją rekomendacją, oczekiwana decyzja i termin.

Ograniczenia: zero osobistych wycieczek – fakty i daty mówią same za siebie; odbiorca musi móc podjąć decyzję na podstawie tej wiadomości bez zwoływania spotkania. Przygotuj też 60-sekundową wersję ustną oraz komunikat dla osób, których eskalacja dotyczy, aby nie dowiedziały się o niej rykoszetem.

Zorganizuj system śledzenia zadań w projekcie [nazwa projektu] między spotkaniami. Obecna sytuacja: [problem, np. zadania ze spotkań są realizowane w połowie, przypomnienia są odbierane jako nadzór]. Częstotliwość spotkań: [częstotliwość]. Dostępne narzędzia: [narzędzia: arkusz, system ticketowy, komunikator].

Zaproponuj kompletny system: format rejestru zadań (zadanie sformułowane czasownikiem z weryfikowalnym wynikiem, jeden właściciel, termin, status), rytuał aktualizacji (kto, kiedy, ile czasu), mechanizm stopniowania przypomnień: automatyczne przypomnienie na 2 dni przed, indywidualna wiadomość w dniu terminu, wzmianka na spotkaniu dopiero przy drugim przekroczeniu.

Przygotuj wzory wiadomości na 3 poziomach – krótkie i bez pretensji. Ograniczenia: zadanie bez terminu lub bez jednego właściciela jest odrzucane na starcie; rejestr nie może przekraczać realnych mocy przerobowych zespołu. Zakończ sposobem na przedstawienie systemu zespołowi jako pomocy, a nie kontroli.

Zaprojektuj dashboard dla projektu [nazwa projektu]. Charakter projektu: [typ i produkt]. Czas trwania: [czas]. Kluczowe punkty do monitorowania: [wyzwania, np. napięty termin, sztywny budżet, krytyczna jakość]. Dostępne dane: [źródła: system ticketowy, raporty czasu pracy, budżet].

Wybierz maks. 6-8 wskaźników podzielonych na 3 bloki: postęp (zrealizowane vs planowane w gotowych produktach, a nie w procentach deklarowanych przez wykonawców), kondycja (opóźnione zadania, oczekujące decyzje i ich wiek, rosnące ryzyka), zasoby (wydatki vs budżet, obciążenie zespołu).

Dla każdego wskaźnika: precyzyjna definicja, źródło, częstotliwość aktualizacji, uzasadniony próg alarmowy. Ograniczenia: odrzuć wskaźniki deklaratywne („80% gotowe”) na rzecz binarnych gotowe/niegotowe; każdy wskaźnik musi wyzwalać konkretne działanie przy zmianie na czerwony. Opisz 15-minutowy rytuał przeglądu: kolejność czytania, pytania kontrolne i kiedy alarmować poza zespół.

Przygotuj miesięczny raport z postępów projektu [nazwa projektu] dla [odbiorcy, np. zarząd]. Dane z miesiąca: realizacja [co dostarczono], odchylenia [opóźnienia lub przekroczenia], budżet [wydatki vs plan], ryzyka [zmiany], podjęte decyzje [lista], alerty [punkty krytyczne].

Format: jedna strona. Ogólna trajektoria w 2 zdaniach (czy projekt dowiezie termin i budżet – tak/nie, co się zmieniło w tym miesiącu), realizacja miesiąca w 3 punktach powiązanych z kamieniami milowymi, odchylenia z przyczyną i planem naprawczym (brak odchyleń bez planu), budżet w jednej linii z prognozą końcową, alerty wymagające uwagi zarządu z jawną prośbą o wsparcie.

Ograniczenia: zarząd czyta 20 takich raportów – zero autopromocji i lania wody; każdy alert musi kończyć się konkretną prośbą (decyzja, zasoby), inaczej to tylko informacja dla zespołu. Złe wiadomości i odchylenia na początku, nie na końcu strony.

Pomóż mi w arbitrażu zasobów między konkurencyjnymi projektami. Projekty w toku: [lista projektów z terminami, wagą i postępem]. Współdzielone zasoby: [osoby pracujące w wielu projektach i ich obecny podział]. Obecny konflikt: [opis konfliktu o zasoby]. Kto podejmuje ostateczną decyzję: [gremium lub osoba].

Najpierw stwórz uczciwy obraz sytuacji: kto nad czym pracuje (procenty realne, nie teoretyczne) i gdzie obciążenie przekracza 100%. Następnie zaproponuj matrycę arbitrażu opartą na kryteriach: waga dla strategii firmy, koszt opóźnienia każdego projektu, nieodwracalność (zamykające się okno rynkowe), podjęte zobowiązania zewnętrzne.

Zastosuj matrycę do obecnego konfliktu i przygotuj 2 scenariusze alokacji z jasnym wskazaniem, co każdy projekt zyskuje i traci oraz jaka będzie nowa data zakończenia. Ograniczenia: zakaz rozwiązywania konfliktu poprzez przeciążanie ludzi lub obiecywanie pracy na 3 etatach jednocześnie; wybrany scenariusz musi być możliwy do zakomunikowania „przegranym” kierownikom z solidnym uzasadnieniem.

Przygotuj planowanie kolejnego sprintu dla zespołu [zespół] w projekcie [nazwa projektu]. Czas trwania: [czas]. Wydajność (Capacity): [obecne osoby, planowane urlopy, czas na zadania stałe: support, spotkania]. Priorytety z backlogu: [elementy do wzięcia z estymacjami]. Pozostałości z poprzedniego sprintu: [niedokończone zadania].

Ustrukturyzuj sesję: obliczenie realnej wydajności (dostępny czas minus zadania stałe i margines na nieprzewidziane), sformułowanie Celu Sprintu w jednym zdaniu (wynik biznesowy, a nie lista ticketów), wybór elementów do limitu wydajności (zaczynając od pozostałości), wspólna weryfikacja czy każdy element jest zrozumiały i wystarczająco zdefiniowany do startu.

Ograniczenia: odrzucaj elementy bez kryteriów akceptacji; jeśli zlecający naciska na więcej niż wydajność, odpowiedzią jest wybór „coś za coś”, nigdy cicha zgoda na nadmiar. Dostarcz agendę sesji, propozycję Celu Sprintu oraz 3 sygnały w trakcie sprintu, że zobowiązanie jest zagrożone.

Przygotuj scenariusz retrospektywy sprintu dla zespołu [zespół]. Czas trwania: [czas, np. 45 min]. Obecna atmosfera: [kontekst, np. rutyna, nikt nic nie mówi, niedawne napięcia, nowy zespół]. Bieżące tematy: [wydarzenia ze sprintu]. Akcje z poprzednich retro: [podjęte decyzje i ich realny status].

Dostarcz: plan spotkania zaczynający się od przeglądu akcji z poprzedniego retro (retro bez wdrożonych zmian umiera po 3 razach), format dopasowany do [atmosfera] z instrukcjami, pytania pomocnicze, gdy dyskusja jest zbyt powierzchowna oraz metodę selekcji: maks. 2 akcje usprawniające wybrane przez zespół, każda z właścicielem i terminem w kolejnym sprincie.

Ograniczenia: zakaz akcji typu „lepiej się komunikować” – każda akcja musi opisywać mierzalną zmianę; tematy poza wpływem zespołu (organizacja, hierarchia) są notowane osobno do eskalacji, a nie wałkowane w kółko. Zaproponuj 2 alternatywne formaty na kolejne spotkania.

Uporządkuj codzienne spotkania (daily) zespołu [zespół] w projekcie [nazwa projektu]. Obecna sytuacja: [problem, np. trwa 30 minut, zamienia się w raportowanie do szefa, połowa osób się wyłącza]. Wielkość zespołu: [liczba]. Tryb pracy: [stacjonarny, zdalny, hybrydowy].

Zaproponuj docelowy format: maksymalny czas, stała godzina, treść skupiona na koordynacji: co skończyłem od wczoraj, co mnie blokuje lub może zablokować, czego potrzebuję od innych. Wszystko, co nie jest koordynacją (debaty techniczne, rozwiązywanie problemów), jest notowane i omawiane zaraz po daily tylko w gronie zainteresowanych.

Podaj: zasady animacji zapobiegające raportowaniu do szefa (zespół mówi do siebie, rotacja prowadzącego), zwrot do ucinania dygresji, adaptacje dla [tryb pracy] oraz 3 sygnały, że daily przestało służyć celowi wraz z naprawą. Zakończ komunikatem do zespołu o nowym formacie, wyjaśniającym „dlaczego” bez deprecjonowania starego sposobu.

Pomóż zespołowi [zespół] stworzyć Definicję Ukończenia (Definition of Done) dla projektu [nazwa projektu]. Typ produktów: [natura prac, np. funkcje oprogramowania, materiały szkoleniowe, analizy]. Zaobserwowane problemy: [objawy, np. zadania wracają po zamknięciu, nierówna jakość, błędy znajdowane na samym końcu].

Zbuduj DoD na 3 poziomach: co czyni element „ukończonym” (weryfikowalne kryteria: sprawdzone przez drugą osobę, przetestowane, udokumentowane, zaakceptowane przez kogo), co jest jawnie wyłączone z definicji dla zachowania realizmu oraz dopuszczalne wyjątki z zasadą ich ewidencji.

Ograniczenia: maks. 8 kryteriów, każde weryfikowalne tak/nie, żadnych kryteriów, których zespół nie może spełnić obecnymi środkami (inaczej DoD zostanie zignorowane przy pierwszym pożarze). Dostarcz: metodę wdrożenia przez warsztat z zespołem, zasadę stosowania do prac w toku oraz rytuał rewizji DoD po kilku tygodniach.

Zorganizuj testy akceptacyjne (UAT) projektu [nazwa projektu]. Produkt do odbioru: [opis]. Testerzy: [profile i dostępność]. Planowany czas: [czas]. Istniejące kryteria akceptacji: [zdefiniowane wcześniej lub brak].

Przygotuj: plan testów z przypadkami testowymi opartymi na realnych ścieżkach użytkownika (nie na funkcjach systemu), każdy przypadek opisany jako dane wejściowe, akcja, oczekiwany wynik; priorytetyzację (blokujący wdrożenie, ważny, kosmetyczny); zasady klasyfikacji błędów z przykładami, aby uniknąć jałowych sporów; obieg poprawek i re-testów.

Dostarcz szablon protokołu odbioru: co testowano, błędy wg poziomów, decyzja (akceptacja bez zastrzeżeń, akceptacja z zastrzeżeniami z datą ich usunięcia, odrzucenie) i podpisy. Ograniczenia: testy bez realnych danych nic nie warte – określ jak przygotować zestaw danych; zastrzeżenia muszą mieć właściciela i termin, inaczej zostaną na zawsze.

Przygotuj plan wdrożenia produkcyjnego [produkt/system] dla projektu [nazwa projektu]. Planowana data: [data]. Użytkownicy: [kto i ilu]. Okno serwisowe: [przedział, np. weekend, noc, godziny pracy]. Aktorzy wdrożenia: [osoby i role]. Możliwość wycofania zmian: [tak/nie/częściowo i jak].

Zbuduj: checklistę przed wdrożeniem (wymagania techniczne, zgody, komunikacja, kopie zapasowe, dostępność kluczowych osób), harmonogram wdrożenia godzina po godzinie z właścicielem każdego kroku i mierzalnym kryterium sukcesu, punkty decyzyjne go/no-go (kto decyduje i na jakiej podstawie), plan wycofania (rollback) – jakie sygnały go uruchamiają i jak go wykonać, oraz monitoring w pierwszych godzinach po starcie.

Ograniczenia: każdy krok ma weryfikowalny wynik, żadnych „powinno być ok”; plan wycofania musi być tak samo szczegółowy jak plan wdrożenia – wykonuje się go pod presją. Zakończ komunikatami do użytkowników przed i po wdrożeniu.

Zorganizuj ciągłość działania podczas migracji z [stary system/proces] na [nowy system/proces] w [firma]. Planowany czas współistnienia: [czas]. Krytyczne aktywności: [aktywności]. Zaangażowane zespoły: [zespoły]. Znane okresy ryzyka: [ograniczenia kalendarzowe, np. zamknięcie miesiąca, szczyt sezonowy].

Rozwiąż kluczowe problemy: który system jest nadrzędny (master) dla każdego typu danych w okresie przejściowym (jasna zasada na każdy przypadek), jak uniknąć podwójnego wprowadzania danych lub jak je sprawnie zorganizować, kto kończy procesy zaczęte w starym systemie oraz jak zamrozić lub zsynchronizować dane w momencie ostatecznego przełączenia.

Dostarcz: tabelę aktywności krytycznych z trybem pracy w trakcie migracji, zasady „kto jest masterem”, plan wzmocnionego wsparcia w pierwszych tygodniach oraz 3 najbardziej prawdopodobne scenariusze awarii z instrukcją postępowania.

Przygotuj zamknięcie projektu [nazwa projektu], którego produkt został zaakceptowany [data]. Elementy projektu: [dostawcy, budżet, dokumentacja, zespół]. Pozostałe zastrzeżenia: [ewentualne uwagi z odbioru].

Zbuduj pełną checklistę zamknięcia: obszar kontraktowy (rozliczenie dostawców, obsługa zastrzeżeń, odebranie dostępów zewnętrznych), obszar finansowy (zablokowanie księgowań na projekt, raport wydatki vs budżet z wyjaśnieniem różnic, zamknięcie linii budżetowych), obszar dokumentacji (co i gdzie zarchiwizować, co musi być łatwe do znalezienia za 2 lata), obszar ludzki (oficjalne zwolnienie zespołu, podziękowania na odpowiednim szczeblu), obszar przekazania (kto przejmuje opiekę nad produktem, jakie jest wsparcie).

Ograniczenia: rozróżnij co blokuje zamknięcie, a co można dokończyć później; projekt „gotowy w 98%”, który ciągnie się pół roku, generuje koszty – ustal sztywną datę zamknięcia. Dostarcz jednostronicowe podsumowanie: kluczowe liczby, sukcesy, odchylenia i miejsce archiwizacji lekcji.

Zorganizuj przekazanie projektu [nazwa projektu] między [odchodzący PM] a [nowy PM]. Kontekst odejścia: [powód i dostępny czas]. Status projektu: [postęp, gorące punkty, nadchodzące kamienie milowe]. Możliwy czas wspólnej pracy (shadowing): [czas lub brak].

Zbuduj pakiet przekazania, priorytetyzując to, czego nie ma w dokumentach: historia decyzji i ich powody, ustne zobowiązania wobec klienta/sponsora, wrażliwe tematy i cechy charakteru kluczowych osób, ryzyka, które odchodzący PM monitoruje nieformalnie, realny stan pakietów prac poza oficjalnym raportowaniem.

Zaplanuj wdrożenie: spotkania wprowadzające (ze sponsorem, klientem, zespołem), kolejność przekazywanych tematów wg pilności oraz komunikat o zmianie, który uspokaja interesariuszy. Ograniczenia: przekazanie musi być weryfikowalne – przygotuj listę pytań, na które nowy PM musi umieć odpowiedzieć samodzielnie po procesie; to, czego nie udało się przekazać, wypisz jako braki z kontaktem awaryjnym.

Przygotuj wdrożenie dla [nowa osoba, profil], która dołącza do zespołu [nazwa projektu] dnia [data]. Status projektu: [postęp i kontekst]. Oczekiwana rola: [zadania]. Dostępny czas zespołu na wsparcie: [realne ograniczenie].

Zbuduj plan na pierwsze 2 tygodnie: pakiet startowy do lektury (karta projektu, ostatni raport Flash, rejestr ryzyk, słownik pojęć), 4 spotkania z kluczowymi osobami z określonym celem każdego z nich, pierwsze konkretne i ograniczone zadanie do wykonania już w pierwszym tygodniu (wybierz jakie wg [rola]) oraz wyznaczony opiekun (buddy) z 10-minutowym spotkaniem codziennym.

Ograniczenia: zakaz planowania 15 pasywnych spotkań – nowa osoba uczy się przez działanie; wyjaw to, czego nikt nie mówi głośno: nieformalne obiegi decyzji, drażliwe tematy. Dostarcz harmonogram 2 tygodni, listę lektur i pytania, na które nowa osoba musi znać odpowiedź po 15 dniach, by uznać wdrożenie za udane.

Pomóż mi rozwiązać konflikt w zespole projektowym. Kontekst: [faktyczny opis konfliktu między dwiema osobami, bez oceniania] w projekcie [nazwa projektu]. Zaobserwowany wpływ: [skutki: blokowanie informacji, napięte spotkania, opóźnienia]. Moja rola: [PM bez podległości służbowej / PM z podległością]. Historia: [czas trwania, podjęte próby].

Zaproponuj 3 etapy: najpierw rozmowy indywidualne (pytania pozwalające zrozumieć wersję każdej strony bez oceniania i zdradzania zaufania, pułapki bycia sędzią), następnie wspólne spotkanie (zasady otwarcia, jak wracać do faktów, gdy rozmowa schodzi na ataki osobiste, jak wypracować 2-3 konkretne zasady współpracy), na koniec monitoring (jak sprawdzać postępy bez jawnego śledzenia).

Ograniczenia: trzymaj się roli PM-a – tematy kadrowe (HR) lub dyscyplinarne zidentyfikuj i przekaż dalej, nie rozwiązuj ich sam; żadna ze stron nie może wyjść z procesu jako publicznie winna. Wskaż sygnały, które wymagają natychmiastowej eskalacji do przełożonych.

Pomóż mi zdyscyplinować dostawcę, który nie dowozi w projekcie [nazwa projektu]. Dostawca: [firma i usługa]. Problemy: [fakty z datami: opóźnienia, niska jakość, zmiana osób, niedotrzymane obietnice]. Ramy kontraktowe: [co mówi umowa: produkty, terminy, kary]. Zależność: [na ile dostawca jest zastępowalny].

Zbuduj ścieżkę: najpierw spotkanie dyscyplinujące (zestawienie faktów vs zobowiązania, protokół wymagający planu naprawczego z datą zamiast przeprosin), potem ścisły monitoring (krótkie punkty kontrolne, jasne kryteria wyjścia z kryzysu, notatka po każdym spotkaniu), na koniec przygotowanie alternatywy (dyskretne rozeznanie rynku, jeśli zależność jest duża).

Ograniczenia: wszystko musi być dokumentowane pisemnie po każdej rozmowie – to podstawa w razie sporu; bądź rzeczowy i trzymaj się umowy, zero gróźb bez pokrycia. Dostarcz: tabelę odchyleń, treść wezwania na spotkanie, agendę spotkania i obiektywne kryteria zakończenia współpracy.

Przygotuj zapytanie ofertowe (RFP) na [przedmiot zapytania, np. budowa strony, wdrożenie narzędzia, usługi stałe] dla [firma]. Potrzeba: [opis potrzeby i problemu]. Kontekst techniczny i organizacyjny: [obecne rozwiązania, ograniczenia]. Budżet indykatywny: [widełki lub informacja o braku podania]. Harmonogram: [terminy].

Struktura: prezentacja firmy i kontekstu (pół strony), problem do rozwiązania i cele sformułowane jako oczekiwane wyniki (opisuj potrzebę, nie rozwiązanie, chyba że jest to sztywne ograniczenie), zakres i wyłączenia, nienegocjowalne wymagania (techniczne, prawne, czasowe), oczekiwane produkty, ogłoszone kryteria wyboru z wagami, proces wyboru (pytania, data złożenia, prezentacje) oraz narzucony format odpowiedzi dla łatwego porównania.

Ograniczenia: każde wymaganie musi być testowalne przy odbiorze; odróżnij wymagania krytyczne od życzeń – oznaczanie wszystkiego jako „must-have” uniemożliwia porównanie ofert. Zakończ 5 pytaniami na etap prezentacji, które obnażą brak zrozumienia potrzeb.

Zbuduj arkusz porównawczy ofert otrzymanych na [przedmiot zapytania]. Oferty: [liczba ofert i krótkie podsumowanie każdej: cena, termin, podejście]. Co jest dla nas kluczowe: [priorytety, np. terminowość, wsparcie po wdrożeniu, całkowity koszt, stabilność dostawcy]. Zaobserwowane sygnały: [podejrzenia, np. cena podejrzanie niska, generyczna odpowiedź].

Zbuduj matrycę: kryteria pogrupowane (zrozumienie potrzeb, proponowane podejście, realny zespół, całkowity koszt w czasie – TCO, referencje, warunki umowne), wagi wynikające z priorytetów, skala ocen z opisem poziomów dla ograniczenia subiektywizmu.

Zastosuj matrycę do opisanych ofert i wskaż: niewyjaśnione różnice w cenie (niska cena często maskuje okrojony zakres – podaj pytania sprawdzające), zasoby obiecane w ofercie vs realny zespół projektowy, ukryte koszty cykliczne. Dostarcz wypełnioną tabelę, pytania o wyjaśnienia do każdej oferty oraz 5-liniową rekomendację.

Zbuduj plan zarządzania zmianą dla [projekt, np. nowe narzędzie, zmiana procesu] w [firma]. Grupy, których dotyczy zmiana: [grupy, liczebność i co się dla nich zmienia]. Obawy: [przewidywany opór]. Harmonogram wdrożenia: [kluczowe daty]. Dostępne środki: [czas, budżet, ambasadorzy zmiany].

Dla każdej grupy określ: co konkretnie zmienia się w ich codziennej pracy (zyski ORAZ straty – przemilczane straty uderzą później), wymagany poziom wsparcia (info, szkolenie, asysta) oraz kluczowy przekaz z ich perspektywy.

Ustrukturyzuj plan w czasie: PRZED (ogłoszenie, sieć ambasadorów wybranych za autorytet u kolegów, szkolenia), W TRAKCIE (wzmocniona asysta, zbieranie uwag, szybkie poprawianie zgłoszonych błędów), PO (pomiar realnego wykorzystania zamiast frekwencji na szkoleniach, praca z grupami oporu).

Ograniczenia: zero planów typu „więcej komunikacji” bez podania co, komu i jak; każda akcja ma właściciela i datę. Dostarcz plan w tabeli wg grup oraz skonsolidowany kalendarz.

Zaprojektuj plan szkoleń dla użytkowników końcowych wdrożenia [narzędzie/proces] w [firma]. Użytkownicy: [profile, liczebność, poziom zaawansowania, lokalizacja]. Co każdy profil musi umieć: [zadania]. Ograniczenia: [dostępność zespołów, budżet, termin wdrożenia].

Zbuduj system per profil zamiast jednego szkolenia dla wszystkich: dla każdego profilu określ 5-10 kluczowych czynności z ich realnej pracy (nie rób przeglądu wszystkich funkcji), dopasowany format (krótka sesja grupowa, tutorial, asysta przy stanowisku), czas trwania i materiały (ściągi „krok po kroku” na jedną stronę zamiast grubych instrukcji).

Zaplanuj sesje jak najbliżej wdrożenia: szkolenie przeprowadzone 6 tygodni przed startem zostanie zapomniane. Zaplanuj tryb nadrabiania dla nieobecnych i wsparcie lokalne (super-użytkownicy).

Ograniczenia: mierz sukces realnym użyciem po wdrożeniu (zdolność do wykonania zadań, liczba zapytań do supportu), a nie frekwencją. Dostarcz plan w tabeli i priorytetyzowaną listę materiałów do przygotowania.

W projekcie [nazwa projektu] wystąpił poważny incydent: [natura incydentu, np. nieudane wdrożenie, utrata danych, awaria usługi, poważne opóźnienie]. Skutki: [kto ucierpiał i jak]. Status naprawy: [co wiemy, czego jeszcze nie]. Odbiorcy: [zarząd, zespoły wewnętrzne, klienci, partnerzy].

Przygotuj sekwencję komunikatów: pierwsza szybka informacja (co wiemy, czego nie wiemy, co robimy i kiedy podamy kolejny komunikat – deklaruj godzinę kolejnego info, a nie godzinę naprawy, której nie znasz), raporty cząstkowe w zapowiedzianym rytmie (nawet jeśli brak nowości) oraz komunikat o rozwiązaniu z podaniem działań zapobiegawczych.

Dostosuj przekaz: zarząd chce znać wpływ i decyzje, użytkownicy chcą wiedzieć jak pracować w międzyczasie, klienci chcą wiedzieć czy ich dane są bezpieczne. Ograniczenia: zero spekulacji o przyczynach przed ich ustaleniem, zero szukania winnych, zero obietnic terminów, których nie jesteś pewien – to klucz do wiarygodności. Dostarcz gotowe wzory i zasady „kto mówi do kogo”.

Pomóż zespołowi [zespół] w [firma] sformułować OKR-y na kwartał [kwartał]. Priorytety firmy: [priorytety]. Zadania stałe zespołu: [aktywności ciągłe]. Planowane inicjatywy: [projekty i pomysły]. Skład: [wielkość zespołu].

Przygotuj maks. 2-3 Cele (Objectives): każdy sformułowany jako inspirująca, ale konkretna zmiana stanu (nie lista zadań), powiązana z priorytetem firmy. Dla każdego Celu 2-4 Wyniki Kluczowe (Key Results): mierzalne z wartością startową i docelową, mierzące rezultat, a nie aktywność („skrócenie czasu X z A do B” zamiast „wdrożenie narzędzia Z”).

Ograniczenia: bieżąca praca (run) to nie OKR – pilotuj ją osobno; wynik kluczowy, którego nie wiemy jak zmierzyć, należy zmienić lub odrzucić; wskaż cele, na które zespół ma zbyt mały wpływ, by brać za nie pełną odpowiedzialność. Dostarcz propozycje OKR, pytania na warsztat zespołu oraz rytuał monitoringu: częstotliwość, format 15 min i co robić, gdy KR-y spadają.

Przygotuj przegląd końcowy OKR-ów zespołu [zespół]. OKR-y z mijającego kwartału: [cele i wyniki z poziomem realizacji]. Kluczowe wydarzenia: [kontekst: niespodzianki, zmiany priorytetów, odejścia]. Uczestnicy: [uczestnicy]. Czas trwania: [czas].

Ustrukturyzuj przegląd w 3 etapach: uczciwa ocena każdego KR na bazie realnych liczb (wynik niezmierzony to wynik nieosiągnięty, a nie „prawie zrobiony”), analiza odchyleń z rozróżnieniem na błędy w egzekucji, źle skalibrowane ambicje lub zdarzenia zewnętrzne (każda przyczyna wymaga innej reakcji), decyzje na kolejny kwartał (co kontynuujemy, co porzucamy, co zmieniamy).

Ograniczenia: przegląd to nie sesja usprawiedliwień – zakaz slajdów z kontekstem, przejdź od razu do liczb; cel osiągnięty w 100% w pierwszym miesiącu budzi takie same pytania o ambicję, jak cel na 20% o egzekucję. Dostarcz agendę, skalę ocen, pytania analityczne per KR oraz szablon syntezy do rozesłania po spotkaniu.

Przygotuj analizę post-mortem incydentu [opis] z dnia [data] w projekcie [nazwa projektu]. Znana chronologia: [przebieg zdarzeń z godzinami]. Zaangażowane osoby: [aktorzy]. Atmosfera: [kontekst, np. ktoś czuje się atakowany, zarząd szuka winnego].

Ustrukturyzuj dokument i spotkanie: wspólne odtworzenie chronologii faktów (godzina po godzinie, bez interpretacji), analiza przyczyn głębokich wykraczająca poza błąd jednostki (błąd ludzki to tylko objaw: co pozwoliło mu wystąpić, co powinno go wyłapać przed skutkiem), co zadziałało dobrze w wykryciu i reakcji oraz akcje zapobiegawcze.

Zasady otwarcia: szukamy luk w systemie, a nie winnych; osoba mówiąca „popełniłem błąd” pomaga wszystkim i nie może ponieść za to kary. Ograniczenia: maks. 5 akcji, każda z właścicielem i terminem, priorytetyzuj te, które technicznie uniemożliwiają powtórkę błędu zamiast tych, które nakazują „większą czujność”. Dostarcz szablon dokumentu i plan spotkania.

Pomóż mi przekształcić zgromadzone lekcje (Lessons Learned) zespołu [zespół/firma] w standardy pracy. Dostępne materiały: [źródła: notatki z retrospektyw, podsumowania projektów, post-mortemy, powtarzające się uwagi]. Obecny problem: [objaw, np. te same błędy powtarzają się w każdym projekcie, raporty końcowe leżą w szufladzie].

Postępuj tak: pogrupuj wnioski tematycznie i znajdź te powtarzające się (one są priorytetem), zmień każdy wybrany wniosek w konkretną zasadę z wyzwalaczem („przy każdym starcie projektu robimy X”), określ gdzie te zasady mają żyć, by były widoczne (wplecione w szablony dokumentów i checklisty, a nie w osobnym „pliku mądrości”).

Ograniczenia: maks. 10 zasad łącznie, każda ma właściciela dbającego o jej aktualność; zaplanuj półroczny przegląd usuwający nieaktualne zasady – system, który tylko rośnie, umiera. Dostarcz propozycje zasad pogrupowane wg momentu użycia, sposób ich integracji oraz komunikat do zespołu.

Przygotuj projekt [nazwa projektu] do audytu lub przeglądu jakości prowadzonego przez [audytor: audyt wewnętrzny, klient, certyfikator, zarząd] w dniu [data]. Zakres przeglądu: [co będzie badane]. Realny stan projektu: [znane mocne i słabe strony, status dokumentacji]. Stawka: [co jest grane: dalsze finansowanie, zaufanie klienta, certyfikacja].

Zorganizuj przygotowania: zestaw dokumentów referencyjnych (karta projektu, decyzje, ryzyka, protokoły, budżet) z listą braków do nadrobienia w pierwszej kolejności, pytania które audytor prawdopodobnie zada w takim projekcie oraz dla każdego słabego punktu uczciwe stanowisko: przyznanie się, pokazanie że jest to monitorowane, przedstawienie planu naprawczego z datą.

Ograniczenia: nigdy nie fałszuj dokumentów ani nie antydatuj niczego – przyznany słaby punkt z planem naprawczym wygląda lepiej niż fasada, która pęka podczas wywiadu; poinstruuj zespół, by trzymał się faktów, a nie „przekazów marketingowych”. Dostarcz checklistę dokumentacji, listę pytań z odpowiedziami oraz harmonogram przygotowań wstecz.