Biblioteka promptów

Retrospektywa po projekcie

Wnioski z zakończonego projektu: co powtórzyć, czego unikać i co konkretnie zmieniamy.

Prompt – 3 zmienne do uzupełnienia

Pomóż mi przygotować i podsumować retrospektywę po projekcie.
Projekt: [NAZWA I OPIS PROJEKTU].
Jak się zakończył (termin, budżet, efekt): [WYNIK PROJEKTU].
Moje notatki i uwagi zespołu:
[WKLEJ NOTATKI]

Zrób:
1. podsumowanie w 3 kolumnach: co zadziałało, co nie zadziałało, co nas zaskoczyło,
2. 3 główne przyczyny problemów (przyczyny, nie objawy – zastosuj pytanie „dlaczego?” kilka razy),
3. maksymalnie 5 konkretnych zmian na kolejne projekty: co, kto, od kiedy,
4. jedną rzecz, którą warto pochwalić zespołowi.
Pisz bez szukania winnych – chodzi o proces, nie o osoby.

Kiedy użyć tego promptu

Po zakończeniu projektu albo etapu, zanim zespół rozejdzie się do kolejnych zadań i szczegóły wypadną z pamięci. Retrospektywa ma sens tylko wtedy, gdy kończy się konkretnymi zmianami – i do tego służy punkt 3 promptu.

Przykład

Przykładowe dane do uzupełnienia:

  • NAZWA I OPIS PROJEKTU: wdrożenie nowego sklepu na PrestaShop dla klienta z branży ogrodniczej
  • WYNIK PROJEKTU: start 3 tygodnie po terminie, budżet przekroczony o 12%, klient zadowolony z efektu

Czego się spodziewać: Model wyciągnie z notatek np. to, że opóźnienie wzięło się z późno dostarczonych treści i braku jednej osoby decyzyjnej po stronie klienta, i zaproponuje zmiany typu „termin dostarczenia treści wpisany do umowy” albo „wskazanie osoby decyzyjnej na spotkaniu startowym”.

Jak dopasować prompt do siebie

  • Retrospektywa z klientem: poproś o wersję bez wewnętrznych uwag i z naciskiem na wspólne ustalenia na przyszłość.
  • Projekt zakończony sukcesem: też warto – poproś o listę praktyk, które warto zapisać jako standard.
  • Duży projekt: zrób retrospektywę po każdym etapie, a nie tylko na końcu.

Wskazówki

  • Zbierz uwagi zespołu przed spotkaniem (np. anonimowa ankieta) – na spotkaniu mniej osób mówi otwarcie.
  • Przy każdej zmianie wpisz osobę odpowiedzialną. Zmiana „bez właściciela” nie zostanie wdrożona.
  • Wróć do listy zmian na starcie kolejnego projektu.

Najczęstsze błędy

  • Retrospektywa, która kończy się listą żali, a nie decyzjami.
  • Szukanie winnego zamiast przyczyny. Zespół szybko uczy się wtedy niczego nie zgłaszać.

Co dalej – dopytaj model

Gdy dostaniesz odpowiedź, możesz pójść krok dalej tym poleceniem:

Na podstawie tej retrospektywy przygotuj checklistę startu projektu, która zapobiegnie trzem głównym problemom.