Chaos na początku projektu

Po powrocie z 6-tygodniowego urlopu rodzicielskiego zobaczyłem coś znajomego na retro zespołu. Jak wychodziłem, zespół zaczynał spory, ważny projekt dla firmy - ja go prowadziłem przez początkowy etap, ale w międzyczasie leadership chciał wprowadzić na tyle duże zmiany, że scope był praktycznie zupełnie inny.

I właśnie wtedy, na tym nowym etapie projektu, pojawiły się te same kartki co kiedyś: chaos w ustaleniach, częste zmiany wymagań, brak jasności co do scope’u projektu. Dopiero w drugim tygodniu zespół się ogarnął - ustalił co i dlaczego robią, spisał to i mógł spokojnie dowieźć projekt.

To potwierdza coś, o czym pisałem wcześniej: ktoś musi koordynować. Ale nie chodzi o mikromanagement.

Między YOLO a mikromanagementem

Próbowałem różnych podejść do prowadzenia projektów:

Skrajność pierwsza: Opisywanie wszystkiego - jak ma działać UI, jakie jest oczekiwane zachowanie aplikacji w każdym stanie, każdy szczegół.

Skrajność druga: YOLO mode - w sumie w ogóle nie angażowałem się w zarządzanie projektem, oddawałem to całkowicie zespołowi.

Żadne z tych skrajności nie działa. Feedback z piątkowego retro był jasny: potrzebna jest koordynacja. Widziałem to samo na retro zespołu, które odbyło się podczas mojego urlopu - zespół zgłaszał identyczne problemy.

Najtrudniejsza faza: ustalanie scope’u

Moje prowadzenie wygląda inaczej niż myślałem na początku kariery. Nie siedzę w Jirze ani nie opisuję każdego szczegółu - zamiast tego robię coś trudniejszego: ustalam clarity na początku projektu, kiedy wszyscy chcą już startować, ale nikt tak naprawdę nie wie dokładnie dokąd idziemy.

To intensywna praca. Jest ogromne napięcie między:

  • Chęcią szybkiego startu (“przecież wiemy co robić!”)
  • Rzeczywistością - im więcej rozmawiamy, tym więcej niejasności wychodzi na jaw

Ustalenie najważniejszych funkcjonalności i flow UX trwa. Trwa, bo trzeba zebrać feedback od wielu osób w firmie. Trwa, bo każda rozmowa odkrywa kolejne pytania bez odpowiedzi. Trwa, bo projektowanie najlepszego (na dany moment) rozwiązania wymaga czasu.

Moja rola: zarządzanie napięciem

Przejmuję to napięcie na siebie i odciążam zespół.

Chcę ich odblokować od ciągnących się zmian ustaleń. Kiedy takie się pojawiają, dążę do tego, by sprawnie i skutecznie przejść od problemu do rozwiązania.

Moderuję dyskusje. Zbieram feedback. Podejmuję trudne decyzje o tym, co odpuścić. Chronię zespół przed chaosem, żeby mogli pracować produktywnie, a nie gubić się w zmianach kierunku co drugi dzień.

Najważniejsze pytanie

“Jaki problem próbujemy tym rozwiązać?”

To pytanie zadaję najczęściej. Oto jak działam:

  • Nie umiemy odpowiedzieć? → Pomijamy funkcjonalność
  • Umiemy odpowiedzieć? → Sprawdzamy, czy jest na tyle istotna, żeby ją robić
  • Coś jest istotne, ale nie wiemy jak to rozwiązać? → Mamy “krążący meteoryt” przez jakiś czas (tak też bywa)
  • Świadoma rezygnacja → Czasem pomijamy coś celowo, żeby szybciej wypchnąć projekt do klientów, zamiast trzymać go tygodniami

Scope maksymalnie mały, ale na tyle duży, by projekt był użyteczny i dobry. Wolę wypuszczać często niż trzymać długo.

Co wystarczy zespołowi?

Kiedy dobrze zrobię swoją robotę na początku, zespół może działać autonomicznie przez kolejne tygodnie. Nie potrzebują ode mnie mikromanagementu. Wystarczy:

  • High level cel - dokąd zmierzamy i dlaczego
  • Ustalone co robimy i czego NIE robimy - jasne granice scope’u
  • Główne funkcjonalności w formie story - nie każdy piksel, ale kierunek
  • Ważne szczegóły - rzeczy, na które trzeba zwrócić uwagę przy danym temacie

Potem tylko wyjaśnianie na bieżąco i ewentualna zmiana scope’u. Ale wtedy przychodzi z konkretami: mamy ustalony scope, pojawia się propozycja zmiany - możemy rozmawiać o wpływie na termin, wycenie, priorytetach.

Nie ma chaosu w stylu “a może jednak zróbmy to inaczej” po raz piąty w tym tygodniu.

Co to mi daje jako liderowi?

Zamiast tonąć w szczegółach Jiry, mogę skupić się na tym, co naprawdę przesuwa projekt do przodu:

  • Mentoring - rozwijanie ludzi w zespole
  • Planowanie - myślenie o kolejnych krokach
  • Architektura - kluczowe decyzje techniczne
  • Code review - jakość kodu i transfer wiedzy
  • Kodowanie - praktyczna praca przy trudnych kawałkach

Co jest naprawdę ważne

Zbudowanie clarity to dopiero początek. Równie ważne jest:

  • Określenie metryk sukcesu projektu - jak zmierzymy, że osiągnęliśmy cel?
  • Ustawienie analityki produktowej i technicznej - co będziemy śledzić?
  • Mierzenie tego, co faktycznie ma znaczenie - nie vanity metrics, ale prawdziwa wartość

Feedback który się powtarza

Wróciłem z urlopu i zobaczyłem te same kartki na retro. Chaos w koordynacji. Częste zmiany na początku projektu. Brak jasności co do scope’u.

To nie przypadek. To nie jest problem konkretnego projektu ani konkretnych ludzi. To systemowa potrzeba - ktoś musi zadbać o clarity i koordynację.

Dostałem ten sam feedback kilka miesięcy temu na naszym piątkowym retro. Zobaczyłem go znowu na retro zespołu z mojego urlopu. To powtarzający się wzorzec.

I teraz wiem, gdzie jestem naprawdę potrzebny. Nie w Jirze. Nie w mikromanagemencie. Ale w tym najtrudniejszym, chaotycznym początku projektu - kiedy trzeba przejść od “mamy pomysł” do “wiemy co robimy i możemy zacząć”.

Główne przesłanie

Nie trzeba być masterem zarządzania Jirą, żeby prowadzić efektywnie zespół.

Mój zespół sam się zorganizuje, jak tylko dostarczę mu solidne fundamenty - clarity tego co robimy i dlaczego. Jestem blisko projektu, ale moje prowadzenie polega na zapewnieniu jasności i ochronie przed chaosem, nie na kontrolowaniu każdego szczegółu.

To wymagająca praca, zwłaszcza na początku projektu. Ale gdy ją dobrze wykonam, wszyscy mogą działać sprawnie i produktywnie.