Jak przygotować projekt, żeby uniknąć chaosu od pierwszego dnia?

Większość projektów IT, które widzę, nie sypie się w połowie. Sypie się na starcie – tyle że nikt tego jeszcze nie zauważa. Wszyscy są zajęci kick-offem, planowaniem sprintów i ustawianiem środowisk. W tym czasie zakres jest dziurawy, termin wzięty z sufitu i nikt nie ustalił, kto podejmuje decyzje, kiedy coś pójdzie nie tak. Wiem, bo naprawiam to u klientów regularnie. Prawie zawsze zaczynam od tych samych pięciu rzeczy. Żadna nie jest skomplikowana. Każda wymaga odwagi, żeby powiedzieć głośno to, o czym wszyscy wiedzą, ale nikt nie mówi.

Discovery w większości firm, z którymi pracuję, wygląda tak: zespół siada z klientem, klient mówi, czego chce, zespół zapisuje. Po dwóch-trzech spotkaniach jest dokument z setką wymagań. Wszystko ma ten sam priorytet. Nikt nie zapytał: „A co z tego jest naprawdę potrzebne na start?” Były marzenia i ktoś zamienił je w backlog.

Kiedy wchodzę do takiego projektu, pierwszą rzeczą, którą robię, jest rozdzielenie zakresu na trzy części. Pierwsza: bez tego produkt nie działa. Druga: przydatne, ale może poczekać na wersję drugą. Trzecia: fajne, ale nikt za to nie zapłaci więcej ani nie kupi szybciej.

Brzmi prosto? W praktyce to najtrudniejsza rozmowa w całym projekcie. Bo klient nie chce wyrzucać ficzerów – płaci i oczekuje wszystkiego. Zespół nie chce mówić „nie” – bo boi się, że straci kontrakt. Więc wszyscy udają, że da się zrobić wszystko w podanym czasie. To jest dokładnie moment, w którym delivery zaczyna się sypać.

Dobre discovery nie kończy się listą. Kończy się decyzją: co robimy, czego nie robimy i dlaczego. Jeśli po discovery nie wyrzuciliście co najmniej 30% początkowych pomysłów – nie zrobiliście discovery. Zrobiliście sesję zbierania życzeń.

Pokażę Wam, jak to wygląda w praktyce. Ostatnio robiłem discovery z klientem, który chciał „małą” platformę. Na wejściu miał 47 ficzerów. Po trzech sesjach zostało 18 – i to było MVP, które miało sens biznesowy. Klient na początku protestował. „Ale ja potrzebuję gamifikacji. Ale ja potrzebuję integracji z Teamsem.” Nie – potrzebował, żeby ludzie mogli się zalogować, przejść kurs i zdać test. Reszta to były marzenia na drugą i trzecią wersję. Kiedy to zobaczył na papierze – sam przyznał, że od początku wiedział, co jest ważne, ale nikt go nie zmusił do wyboru.

To pytanie słyszę od liderów i project managerów najczęściej. Rozumiem, dlaczego się boją. Mówienie „nie” klientowi, który płaci, wydaje się ryzykowne. Wiecie, co jest bardziej ryzykowne? Powiedzenie „tak” na coś, czego nie jesteście w stanie dowieźć, a potem tłumaczenie się przez trzy miesiące.

Mam na to prostą zasadę, którą wdrażam u klientów: nigdy nie mów „nie” bez „ale”. Klient chce dziesięć ficzrów w osiem tygodni? Nie mówisz: „Nie da się”. Mówisz: „Możemy zrobić sześć w osiem tygodni i dostarczyć działający produkt. Pozostałe cztery dołożymy w kolejnej iteracji, albo robimy dziesięć, ale potrzebujemy dwunastu tygodni. Którą opcję wolisz?”

To zmienia dynamikę rozmowy. Zamiast być kimś, kto blokuje, stajesz się kimś, kto daje wybór. Klient czuje, że ma kontrolę. Ty masz realistyczny zakres. Widziałem, jak ta jedna zmiana – przejście z „tak, na pewno damy radę” na „oto dwie opcje, wybierz” – ratowała projekty, zanim jeszcze ruszyły.

Ważna rzecz: te opcje muszą być przygotowane wcześniej. Nie możesz wymyślać ich na spotkaniu z klientem. Zanim idziesz na rozmowę o zakresie, usiądź z tech leadem i przygotujcie dwa-trzy scenariusze. Scenariusz A: co możemy zrobić w podanym czasie. Scenariusz B: co możemy zrobić, jeśli dodamy czas. Scenariusz C: co możemy zrobić, jeśli klient dołoży budżet. Kiedy klient widzi, że przemyśleliście warianty, budujecie zaufanie. Kiedy improwizujecie na spotkaniu – budujecie chaos.

Jeden z moich klientów – software house, 40 osób – stracił trzy kontrakty z rzędu, bo obiecywał za dużo i nie dowoził. Kiedy zaczęli oferować klientom wybór zamiast ślepego „tak”, utrzymanie klientów skoczyło w górę. Bo klient woli usłyszeć prawdę na starcie niż wymówki na końcu.

Zanim projekt ruszy, siadam z liderem i zadaję trzy pytania. Jeśli nie ma na nie jasnych odpowiedzi – nie pozwalam startować.

Pytanie pierwsze: „Kto jest jedyną osobą decyzyjną po stronie klienta?” Nie „kto jest zaangażowany”. Nie „z kim rozmawiamy”. Jedna osoba, która może powiedzieć tak albo nie. Jeśli odpowiedź brzmi „to zależy” albo „mamy komitet” – to jest czerwona flaga. Projekty bez jednego właściciela decyzji ciągną się w nieskończoność, bo każdy ma swoją perspektywę i nikt nie chce wziąć odpowiedzialności.

Pytanie drugie: „Co się stanie, jeśli w trzecim tygodniu klient zmieni priorytet?” To pytanie obnażające. Bo prawie nikt nie ma na to procedury. Klient dzwoni, zmienia zdanie, ktoś przekazuje to deweloperowi i sprint idzie do kosza. Zespół nie jest chroniony przed tak zwanymi strzałami z lasu. Potrzebujesz ustalonej ścieżki: zmiana priorytetów idzie do PM-a, PM ocenia wpływ na zakres i termin, dopiero potem idzie do zespołu.

Pytanie trzecie: „Na podstawie czego ustaliliście termin?” Jeśli odpowiedź to „klient potrzebuje na wrzesień” albo „tyle mamy w budżecie” – to nie jest estymacja. To życzenie. Termin powinien wynikać z zakresu, dostępności zespołu i danych z poprzednich, podobnych projektów. Jeśli takich danych nie macie – powiedzcie to głośno i dodajcie bufor. Lepiej obiecać dwanaście tygodni i dowieźć w dziesięć niż obiecać osiem i nie dowieźć w dwanaście. A jeśli klient mówi „muszę mieć na wrzesień” – to jest ograniczenie, do którego dopasowujecie zakres, nie termin, do którego dopasowujecie zespół. Więcej ludzi nie dowozi więcej rzeczy. Dowozi mniejszy, realistyczny zakres w ustalonej ramie czasowej.

To pytanie, na które większość firm nie ma odpowiedzi. I to jest problem.

Kiedy projekt ruszy i okaże się, że zakres jest za duży – kto podejmuje decyzję o cięciu? Jeśli musi to eskalować do CEO albo do klienta – traci tydzień. Jeśli nikt nie ma takiego uprawnienia – nikt nie tnie. Zespół próbuje zrobić wszystko, tnie jakość zamiast zakresu i koło się kręci. To jest takie perpetuum mobile – im dłużej trwa, tym trudniej je zatrzymać.

Widzę to w firmach, gdzie wszystko musi iść „przez górę”. PM widzi, że sprint jest przeładowany. Wie, co należy przesunąć. Nie ma uprawnienia, żeby to zrobić. Więc pisze maila do COO. COO jest na spotkaniach do piątku. W poniedziałek PM dostaje odpowiedź „porozmawiajmy”. We wtorek jest spotkanie. W środę jest decyzja. Zespół przez tydzień robił rzeczy, które i tak zostaną odłożone. Tydzień stracony – nie dlatego, że ktoś źle pracował, ale dlatego, że nikt nie miał prawa podjąć prostej decyzji.

Pracuję z klientami nad jedną konkretną rzeczą: dajcie PM-owi albo tech leadowi prawo do przesunięcia elementów zakresu z „teraz” na „później” bez eskalacji. Nie mówię o wyrzuceniu z projektu. Mówię o przesunięciu w czasie. To ogromna różnica. Bo kiedy PM może powiedzieć „to robimy w następnej iteracji”, zespół oddycha. Zamiast dostarczać wszystko byle jak, dostarcza mniej, ale porządnie.

U jednego klienta wdrożyliśmy prostą zasadę: PM może przesunąć do 20% zakresu sprintu bez zgody klienta, o ile poinformuje go w ciągu 24 godzin. Efekt? Mniej przeróbek, mniej nadgodzin, mniej sytuacji, w których widać zmęczenie realne po liderach, po zespole. Narasta mniej frustracji, bo ludzie czują, że ktoś chroni ich czas. Co ciekawe – klient ani razu nie zaprotestował. Bo dostawał działające rzeczy zamiast połowicznie skończonych. Okazało się, że klient nie potrzebował kontroli nad każdym detalem. Potrzebował pewności, że projekt idzie do przodu.

Pięć rzeczy, które możesz zrobić w najbliższym tygodniu.

Nie zamierzam Ci sprzedawać transformacji. Transformacje trwają miesiące i często kończą się slajdami, które nikt nie czyta. Dam Ci pięć rzeczy, które możesz zrobić w najbliższym tygodniu. Żadna nie wymaga budżetu, nowego narzędzia ani prezentacji przed zarządem. Każda wymaga jednej rozmowy.

Pierwsza: weź zakres najbliższego projektu i podziel go na trzy części – „musi być”, „przydatne” i „fajne”. Jeśli część „musi być” ma więcej niż 40% całości – tnij dalej.

Druga: sprawdź, kto jest osobą decyzyjną po stronie klienta. Jeśli odpowiedź nie jest jednoznaczna – umów się na spotkanie i ustal to. Jeden mail, jedna rozmowa.

Trzecia: porównaj estymację ostatniego projektu z tym, ile faktycznie zajął. Jeden arkusz. Trzy kolumny: co estymowaliśmy, ile zajęło, dlaczego różnica. Jeśli nigdy tego nie robiliście – właśnie znaleźliście największą dziurę w swoim procesie. To ćwiczenie boli, bo pokazuje, jak daleko estymacje są od rzeczywistości. Bez tego bólu nic się nie zmieni.

Czwarta: ustal z PM-em, ile procent zakresu sprintu może przesunąć samodzielnie. Nie potrzebujecie na to strategii. Potrzebujecie jednej rozmowy i jednej decyzji. Zacznijcie od 15-20% – to wystarczy, żeby PM mógł reagować bez tygodniowej eskalacji.

Piąta: na najbliższym spotkaniu projektowym zadaj pytanie „co wyrzucamy?” zamiast „co dodajemy?”. I poczekaj, co się stanie. Jeśli nikt nie potrafi odpowiedzieć – masz odpowiedź na pytanie, dlaczego delivery się sypie.

Każdy z tych kroków można zrobić w jeden dzień. Żaden nie wymaga rewolucji. Wymaga jednej rzeczy: zgody na to, że sposób, w jaki do tej pory ustawialiśmy projekty, nie działa. Czego firmy najbardziej nie chcą usłyszeć? Że popełniły błąd. Te, które to przyznają, zaczynają dowozić.

Te pięć rzeczy, od których zaczynam u prawie każdego klienta? Działają nie dlatego, że są skomplikowane. Działają dlatego, że wreszcie ktoś je robi.