Sprint operatorski 90 dni: jak wygląda od środka i co dostajesz na koniec

Sprint operatorski to 90 dni pracy operatora wewnątrz twojej organizacji, 2-3 dni w tygodniu, z jednym celem: przewidywalne delivery. Nie jest to audyt z rekomendacjami ani interim management na czas nieokreślony. Faza pierwsza (dni 1-30) to diagnoza na żywym organizmie, faza druga (31-60) przebudowa rytmu pracy, faza trzecia (61-90) utrwalenie systemu i przekazanie go zespołowi. Na koniec zostajesz z działającym systemem delivery i danymi, które pokazują różnicę, a nie z prezentacją.

Audyt kończy się dokumentem. Dokument ląduje w Notion obok poprzednich trzech audytów. Problem organizacji, w których velocity spada, prawie nigdy nie polega na braku wiedzy o tym, co jest zepsute. Polega na tym, że nikt nie ma mandatu, czasu i doświadczenia, żeby to zmienić w trakcie normalnej pracy, bez zatrzymywania roadmapy.

Stąd formuła operatorska: wchodzę w codzienny rytm (sprinty, planowanie, decyzje produktowe, 1-1 z liderami) i zmieniam sposób pracy od środka, na działającym zespole. Zmiana wdrożona w trakcie delivery ma tę przewagę nad rekomendacją, że w dniu 90 już działa i nikt nie musi jej "zaimplementować kiedyś".

Diagnoza w ruchu (dni 1-30): dzieje się obserwacja rytmu pracy, 1-1 z zespołem, analiza danych delivery i mapa blokerów. Wynik fazy: lista 3-5 zmian o największym wpływie i baseline metryk. Przebudowa (dni 31-60): nowy rytm planowania i decyzji, ownership per obszar, redukcja WIP, usunięcie blokerów. Wynik fazy: zespół pracuje w nowym systemie, pierwsze dane porównawcze. Utrwalenie (dni 61-90): przekazanie systemu liderom wewnętrznym, dokumentacja rytmu, korekty na danych. Wynik fazy: system działa beze mnie i gotowy raport przed/po.

Celowo nie zaczynam od zmian w tygodniu pierwszym. Zmiany wprowadzone przed zrozumieniem kontekstu to główny powód, dla którego zewnętrzni "naprawiacze" psują więcej, niż naprawiają. Ale diagnoza trwa 30 dni, nie kwartał, bo prowadzę ją na danych i w codziennej pracy, a nie przez wywiady raz w tygodniu.

Dwa do trzech dni w tygodniu, w tym co najmniej jeden na miejscu, jeśli zespół pracuje hybrydowo. Stały rytm: udział w planowaniu i review, 1-1 z liderami produktu i inżynierii, przegląd metryk delivery, jedna decyzja strukturalna tygodniowo (nie pięć, bo organizacja trawi zmiany w ograniczonym tempie). Reszta asynchronicznie: jestem na Slacku, odpowiadam, odblokowuję.

Rola foundera w tym czasie: nie znika. Spotykamy się co tydzień na 30-60 minut, przechodzimy przez zmiany i decyzje, które wymagają jego mandatu. Sprint nie działa w modelu "oddaję problem i wracam za kwartał", bo część blokerów zawsze siedzi na poziomie founderów: sposób podejmowania decyzji, zmiany priorytetów w połowie sprintu, nadpisywanie roadmapy ad hoc.

Mierzalnie, na trzech poziomach. Przewidywalność: stosunek rzeczy zaplanowanych do dowiezionych w cyklu (baseline z fazy 1 vs dni 61-90). Przepływ: czas od decyzji do wdrożenia na produkcję. Jakość rytmu: mniej eskalacji do foundera, decyzje zapadają tam, gdzie jest kontekst. Konkretne wartości zależą od punktu startu, dlatego pierwszym produktem sprintu jest baseline, a nie obietnica procentów.

Ten model wypracowałem, skalując delivery w organizacjach od kilkunastu do 185 osób, m.in. w Zety i InterviewMe, gdzie przebudowa systemu pracy przełożyła się na wzrost konwersji o 208% i retencji o 600%. Szczegóły w case studies.

Uczciwie: sprint nie zadziała, gdy problemem jest brak PMF (żaden system delivery nie uratuje produktu, którego rynek nie chce), gdy founder nie ma gotowości oddać części kontroli nad sposobem pracy zespołu, albo gdy organizacja jest w środku tak głębokiego kryzysu płynności, że horyzont decyzji to dwa tygodnie. W pierwszym przypadku lepszym narzędziem jest praca nad produktem i badaniem rynku, w ostatnim restrukturyzacja, nie sprint.

Jeśli natomiast problem jest ciągły, a nie ostry (delivery kuleje od kwartałów, ale nic się nie pali), rozważ model fractional CTO/CPO: mniejsza intensywność, dłuższy horyzont. Porównanie obu modeli opisałem w tekście o kosztach fractional CTO.

Czym sprint operatorski różni się od interim CTO? Zakresem i końcem. Interim przejmuje rolę na czas nieokreślony i zarządza wszystkim, co robi CTO. Sprint ma jeden cel (przewidywalne delivery), zdefiniowany koniec po 90 dniach i wbudowane przekazanie systemu liderom wewnętrznym. Interim zastępuje osobę, sprint naprawia system.

Czy zespół nie odbierze tego jako kontroli z zewnątrz? To zależy od wejścia. Pierwsze 30 dni to praca z zespołem, nie nad zespołem: 1-1, słuchanie, usuwanie blokerów, o które inżynierowie prosili od miesięcy. Zaufanie buduje pierwsza zmiana, która ułatwia ludziom pracę. Opór pojawia się wtedy, gdy zmiany wprowadza się dekretem przed zrozumieniem kontekstu.

Co jeśli po 90 dniach system się rozjedzie? Dlatego faza trzecia to utrwalenie: system przejmują liderzy wewnętrzni jeszcze w trakcie sprintu, pod moją obserwacją, z dokumentacją rytmu. Po sprincie dostępna jest opcja advisory 1-2 dni w miesiącu na przeglądy. Jeśli organizacja potrzebuje stałej obecności, to sygnał na model fractional, nie na kolejny sprint.

Ile kosztuje sprint operatorski? Widełki zależą od skali organizacji i zaangażowania (2 vs 3 dni w tygodniu), podaję je po krótkiej rozmowie diagnostycznej. Punkt odniesienia: koszt kwartału pracy operatora porównuj z kosztem kwartału nieprzewidywalnego delivery, czyli niedowiezionych funkcji, przepalonych godzin zespołu i przesuniętych celów rundy.

W 30 minut przejdę z tobą przez objawy: co się nie dowozi, od kiedy i co już próbowaliście. Powiem wprost, czy to problem na sprint, na fractional, czy na coś zupełnie innego. Umów bezpłatny audyt.