Projekt IT rzadko zaczyna się źle podczas pierwszego Sprint Planningu. Najczęściej problemy pojawiają się wcześniej: kiedy cel biznesowy pozostaje ogólny, backlog jest listą pomysłów zamiast materiałem do podjęcia decyzji, a klient i dostawca inaczej rozumieją odpowiedzialność za zakres, architekturę, jakość oraz termin. Zespół może rozpocząć development, ale nie oznacza to jeszcze, że organizacja jest gotowa do przewidywalnego delivery.
W tym przewodniku przedstawiamy 12 decyzji, które warto zamknąć przed pierwszym sprintem. Nie jest to agenda spotkania kick-off ani rozbudowana lista dokumentów do przygotowania. To operacyjny framework pozwalający ocenić, czy projekt ma wystarczające podstawy biznesowe, produktowe i techniczne, aby rozpocząć realizację — oraz czy wybrany model współpracy właściwie rozdziela odpowiedzialność między klienta i dostawcę.
Najważniejsza zasada: pierwszy sprint nie powinien służyć do odkrywania, kto podejmuje decyzje, gdzie znajdują się dane i jak wdrażać oprogramowanie. Powinien służyć do dostarczenia pierwszego sprawdzalnego przyrostu wartości.
Dlaczego projekt IT zaczyna się przed pierwszym sprintem?
Sam kalendarz sprintów nie tworzy przewidywalnego delivery. Sprint zapewnia ramę pracy, ale nie zastępuje decyzji biznesowych, ownershipu, gotowości backlogu, dostępu do środowisk ani strategii jakości. Jeżeli te elementy nie zostały przygotowane, zespół wykorzysta pierwsze tygodnie nie na rozwój produktu, lecz na usuwanie zaległych problemów organizacyjnych.
Oficjalny Scrum Guide wskazuje, że Product Owner porządkuje pracę w Product Backlogu, a Scrum Team tworzy w sprincie wartościowy przyrost spełniający Definition of Done. Nie oznacza to jednak, że przed Sprintem 1 trzeba szczegółowo zaprojektować cały produkt. Potrzebny jest wystarczający poziom gotowości, aby zespół mógł podejmować decyzje na podstawie wiarygodnego kontekstu i ograniczać ryzyko w kolejnych iteracjach.
Najczęstszy pozorny start projektu
Projekt formalnie wystartował: umowa została podpisana, zespół jest dostępny, w kalendarzu pojawił się kick-off, a backlog zawiera pierwsze zadania. Po kilku dniach okazuje się jednak, że:
- sponsor i Product Owner inaczej rozumieją cel pierwszej wersji,
- zespół nie ma dostępu do środowiska lub danych,
- integracja z systemem core wymaga uzgodnienia z innym działem,
- QA ma dołączyć dopiero przed releasem,
- nie wiadomo, kto zatwierdza decyzje architektoniczne,
- każda nowa potrzeba biznesowa trafia bezpośrednio do sprintu.
W takiej sytuacji zespół jest zajęty, ale projekt nie jest jeszcze gotowy do regularnego dostarczania wartości.
| Obszar | Formalny start | Operacyjna gotowość |
|---|---|---|
| Cel | Projekt ma nazwę i ogólne założenie | Zespół zna problem, wynik i ograniczenia |
| Backlog | Istnieje lista funkcji | Pierwsze elementy są zrozumiałe, priorytetowe i możliwe do ukończenia |
| Zespół | Obsadzono role | Role mają mandat do decyzji i dostęp do potrzebnego kontekstu |
| Technologia | Wybrano stack | Rozpoznano zależności, integracje, środowiska i główne ryzyka |
| Jakość | Zaplanowano testy | Istnieją kryteria akceptacji, Definition of Done i odpowiedzialność za QA |
| Wdrożenie | Jest planowany termin release’u | Wiadomo, jak zbudować, wdrożyć, monitorować i wycofać zmianę |
Czym jest project readiness?
Definicja: project readiness to potwierdzony poziom gotowości biznesowej, produktowej, organizacyjnej i technicznej, który pozwala zespołowi rozpocząć delivery bez blokad możliwych do usunięcia przed startem.
Gotowość nie oznacza pełnej wiedzy. W projektach złożonych część założeń zostanie zweryfikowana dopiero podczas discovery, prototypowania lub developmentu. Celem nie jest więc wyeliminowanie niepewności, lecz jej nazwanie, przypisanie właścicieli i ustalenie sposobu ograniczania.
Dobry project readiness gate odpowiada na trzy pytania:
- Czy zespół wie, jaki wynik ma osiągnąć?
- Czy ma warunki, aby bezpiecznie rozpocząć pracę?
- Czy wiadomo, kto i jak podejmie decyzję, gdy pojawi się niepewność?
To ważne szczególnie w projektach enterprise, gdzie zależności obejmują wiele systemów, właścicieli biznesowych, zespoły bezpieczeństwa, dostawców i wymagania regulacyjne.
12 decyzji, które trzeba podjąć przed pierwszym sprintem
Każda z poniższych decyzji została opisana przez pięć elementów: pytanie decyzyjne, znaczenie dla delivery, oczekiwany artefakt, właściciela oraz sygnał ryzyka. Artefakt nie musi być rozbudowanym dokumentem. Powinien przede wszystkim sprawić, że ustalenie będzie widoczne, możliwe do zweryfikowania i dostępne dla zespołu.
1. Jaki problem biznesowy ma rozwiązać projekt?
„Budujemy nową aplikację”, „modernizujemy system” albo „automatyzujemy proces” opisuje rozwiązanie, nie problem. Bez precyzyjnej diagnozy zespół może sprawnie dostarczać funkcje, które nie zmieniają wyniku biznesowego.
Przed startem trzeba ustalić:
- jaki proces, koszt, ryzyko lub doświadczenie użytkownika ma się zmienić,
- kogo dotyczy problem,
- dlaczego organizacja chce rozwiązać go właśnie teraz,
- co wydarzy się, jeżeli projekt nie powstanie,
- które ograniczenia biznesowe są nienegocjowalne.
Minimalny artefakt: jednostronicowy opis problemu zawierający użytkownika, obecny proces, oczekiwany wynik i najważniejsze ograniczenia.
Właściciel: sponsor biznesowy lub Product Owner. Dostawca powinien pomóc doprecyzować problem, ale nie może samodzielnie zdefiniować wartości biznesowej klienta.
Sygnał ryzyka: interesariusze zgadzają się co do funkcji, ale udzielają różnych odpowiedzi na pytanie, jaki rezultat ma osiągnąć projekt.
2. Jak rozpoznamy, że projekt przynosi wartość?
Termin i budżet są ważne, lecz nie są wystarczającą definicją sukcesu produktu. Projekt może zostać dostarczony zgodnie z harmonogramem, a mimo to nie poprawić procesu, nie zdobyć użytkowników lub wygenerować zbyt wysoki koszt utrzymania.
Warto rozdzielić trzy grupy mierników:
- biznesowe — np. czas realizacji procesu, koszt obsługi, konwersja, liczba błędów operacyjnych,
- produktowe — adopcja, ukończenie kluczowego scenariusza, retencja, satysfakcja użytkowników,
- techniczne i operacyjne — dostępność, wydajność, częstotliwość wdrożeń, czas przywrócenia działania, liczba incydentów.
Nie każdy wskaźnik musi mieć ostateczną wartość docelową przed Sprintem 1. Trzeba jednak ustalić, które dane będą zbierane i kto podejmie decyzję na ich podstawie.
Minimalny artefakt: karta mierników sukcesu określająca stan bazowy, oczekiwaną zmianę, źródło danych i właściciela pomiaru.
Sygnał ryzyka: jedynym miernikiem jest liczba funkcji dostarczonych w terminie.
3. Jaki zakres jest rzeczywiście gotowy do realizacji?
Przed pierwszym sprintem nie trzeba mieć szczegółowej specyfikacji całego produktu. Należy jednak oddzielić:
- zakres wystarczająco rozpoznany, aby rozpocząć development,
- hipotezy wymagające discovery lub prototypu,
- zależności wymagające potwierdzenia,
- elementy świadomie pozostawione poza pierwszym releasem.
Backlog startowy powinien obejmować nie tylko funkcje, ale również zadania techniczne i ryzyka konieczne do dostarczenia działającego przyrostu. Jeżeli pierwszy sprint zawiera wyłącznie „setup projektu”, warto sprawdzić, czy część pracy przygotowawczej nie powinna wydarzyć się jeszcze przed formalnym startem.
Definition of Ready nie może zastąpić rozmowy
Lista kryteriów pomaga zespołowi ocenić element backlogu, ale nie powinna tworzyć biurokratycznej bramki. W praktyce pierwsze zadania muszą być wystarczająco małe, zrozumiałe i możliwe do zweryfikowania w sprincie.
Minimalny artefakt: uporządkowany backlog pierwszych iteracji z celem, kryteriami akceptacji, zależnościami i oznaczonymi obszarami niepewności.
Sygnał ryzyka: backlog jest listą oczekiwań wielu interesariuszy, ale nikt nie ma mandatu do odrzucania lub przesuwania zadań.
4. Jaki model współpracy odpowiada ryzyku projektu?
Model współpracy nie jest wyłącznie sposobem rozliczenia. Określa, kto zarządza backlogiem, zespołem, ryzykiem operacyjnym i rezultatem. Dlatego wybór między Staff Augmentation, Dedicated Team, SoW / Fixed Price i Managed Services powinien wynikać z dojrzałości projektu oraz zdolności klienta do samodzielnego prowadzenia delivery.
- Staff Augmentation sprawdza się, gdy klient ma własny ownership produktu, proces delivery i potrzebuje konkretnych kompetencji lub dodatkowej capacity.
- Dedicated Team jest właściwy, gdy potrzebny jest stabilny, interdyscyplinarny zespół odpowiedzialny za rozwój określonego obszaru produktu.
- SoW / Fixed Price wymaga bardziej precyzyjnego zakresu, kryteriów odbioru, założeń i zasad zarządzania zmianą.
- Managed Services koncentruje się na mierzalnym wyniku usługi, SLA i odpowiedzialności operacyjnej w ustalonych granicach.
Minimalny artefakt: karta modelu współpracy opisująca granice odpowiedzialności, sposób zarządzania backlogiem, kryteria rozliczenia i proces eskalacji.
Sygnał ryzyka: klient oczekuje od dostawcy pełnej odpowiedzialności za rezultat, ale wybiera model, w którym decyzje i zarządzanie pozostają wyłącznie po stronie klienta.
5. Kto podejmuje decyzje biznesowe, produktowe i techniczne?
Projekt potrzebuje nie tylko osób przypisanych do ról, lecz także realnego mandatu decyzyjnego. W środowisku enterprise blokadą często nie jest brak wiedzy, ale oczekiwanie na akceptację interesariusza, który nie uczestniczy w codziennej pracy zespołu.
Przed startem należy jednoznacznie ustalić:
- kto ustala priorytety Product Backlogu,
- kto akceptuje zmianę zakresu i budżetu,
- kto podejmuje decyzje architektoniczne,
- kto zatwierdza wymagania security i compliance,
- kto odpowiada za odbiór biznesowy,
- kto usuwa zależności między zespołami.
Warto dokumentować istotne decyzje architektoniczne jako krótkie Architecture Decision Records. Taki zapis powinien wskazywać kontekst, podjętą decyzję i jej konsekwencje, bez tworzenia rozbudowanej dokumentacji, która szybko się dezaktualizuje.
Minimalny artefakt: RACI lub prostsza mapa decyzji pokazująca właścicieli obszarów i maksymalny czas akceptacji.
Sygnał ryzyka: Product Owner odpowiada za backlog, ale nie może odrzucić potrzeby zgłoszonej przez sponsora lub inny dział.
6. Czy potrzebne jest discovery lub audyt techniczny?
Discovery nie jest obowiązkową fazą każdego projektu. Jest narzędziem redukcji określonego rodzaju niepewności. Powinno zostać przeprowadzone wtedy, gdy organizacja nie ma wystarczających podstaw do bezpiecznego określenia zakresu, architektury, kosztu lub kolejności realizacji.
Discovery jest potrzebne, gdy niepewność dotyczy produktu
- nie wiadomo, który problem użytkownika ma najwyższy priorytet,
- istnieje kilka możliwych scenariuszy rozwiązania,
- założenia biznesowe nie zostały zweryfikowane,
- zakres pierwszej wersji jest zbyt szeroki.
Audyt jest potrzebny, gdy niepewność dotyczy systemu
- dokumentacja architektury jest nieaktualna,
- projekt obejmuje legacy o nieznanych zależnościach,
- nie wiadomo, czy obecne API, dane i środowiska obsłużą nową funkcję,
- brakuje testów pozwalających bezpiecznie zmieniać system,
- nie jest znany rzeczywisty koszt migracji lub integracji.
Jeżeli niepewność jest wysoka, podpisanie sztywnego zakresu bez wcześniejszej analizy nie usuwa ryzyka. Przenosi je na etap developmentu, gdzie każda korekta jest droższa i wpływa na termin.
Minimalny artefakt: decyzja o zakresie discovery lub audytu wraz z pytaniami, na które etap ma odpowiedzieć, oraz kryteriami zakończenia.
Sygnał ryzyka: harmonogram jest szczegółowy, ale opiera się na założeniach, których nie zweryfikował zespół techniczny.
7. Czy architektura i integracje zostały rozpoznane?
Nie trzeba projektować całej architektury przed rozpoczęciem iteracyjnej pracy. Trzeba jednak wiedzieć, gdzie znajdują się decyzje trudne lub kosztowne do odwrócenia. Dotyczy to szczególnie danych, bezpieczeństwa, integracji z systemami core, wymagań dostępności i ograniczeń platformowych.
Minimum architektoniczne przed startem obejmuje:
- granice systemu i odpowiedzialności komponentów,
- mapę integracji i właścicieli systemów zależnych,
- krytyczne przepływy danych,
- wymagania niefunkcjonalne,
- założenia dotyczące dostępności, wydajności i skalowania,
- najważniejsze decyzje wymagające walidacji technicznej.
W projekcie legacy warto ustalić, czy przed developmentem potrzebna jest analiza obecnego kodu, bazy danych, testów i pipeline’u wdrożeniowego. Więcej o takim przygotowaniu opisujemy w przewodniku dotyczącym modernizacji systemów legacy pod AI.
Minimalny artefakt: aktualny diagram kontekstowy, mapa integracji, lista wymagań niefunkcjonalnych i rejestr kluczowych decyzji architektonicznych.
Sygnał ryzyka: nowy zespół odkrywa zależności dopiero podczas implementacji pierwszych funkcji.
8. Czy środowiska, dane i dostępy są gotowe?
Brak dostępów jest jednym z najbardziej przewidywalnych blockerów. Mimo to w wielu projektach proces ich nadawania rozpoczyna się dopiero po dołączeniu zespołu. W organizacjach regulowanych uzyskanie dostępu do repozytoriów, VPN, danych i środowisk może wymagać wielu akceptacji, szkoleń oraz konfiguracji urządzeń.
Przed Sprintem 1 warto sprawdzić:
- konta, urządzenia, VPN i uwierzytelnianie wieloskładnikowe,
- dostęp do repozytoriów, dokumentacji, backlogu i komunikacji,
- możliwość lokalnego uruchomienia systemu,
- dostępność środowisk developerskich i testowych,
- zasady używania danych produkcyjnych i anonimizacji,
- dostęp do logów, monitoringu i narzędzi diagnostycznych,
- proces zgłaszania i eskalowania problemów dostępowych.
Jeżeli projekt korzysta z zewnętrznych specjalistów, szczegółowy proces ich wdrożenia opisujemy w artykule Jak wdrożyć zewnętrznego specjalistę IT do zespołu?
Minimalny artefakt: macierz dostępów z właścicielami, statusem i terminem realizacji oraz potwierdzona ścieżka uruchomienia systemu.
Sygnał ryzyka: plan sprintu zakłada development, ale zespół nie może uruchomić rozwiązania ani wykonać testu na środowisku.
9. Jak będzie zapewniana jakość?
QA nie powinno pojawić się dopiero przed releasem. Decyzje o jakości wpływają na strukturę backlogu, architekturę, środowiska, dane testowe i sposób pracy developerów. Im później zostaną podjęte, tym więcej problemów trzeba będzie usuwać w gotowym rozwiązaniu.
Przed pierwszym sprintem należy ustalić:
- jakie kryteria akceptacji muszą posiadać zadania,
- co oznacza Done dla kodu, testów, dokumentacji i wdrożenia,
- które testy będą manualne, a które automatyczne,
- jakie scenariusze wymagają testów integracyjnych, wydajnościowych i bezpieczeństwa,
- kto przygotowuje i utrzymuje dane testowe,
- kto odpowiada za akceptację biznesową,
- jak będzie zarządzana regresja.
OWASP SAMM traktuje weryfikację jako część pełnego cyklu tworzenia oprogramowania, a nie aktywność wykonywaną wyłącznie na końcu. Podobnie w praktyce delivery: jakość trzeba zaplanować razem z zakresem i architekturą.
Minimalny artefakt: krótka strategia testów, Definition of Done oraz wskazanie odpowiedzialności za QA i odbiór.
Sygnał ryzyka: estymacja obejmuje development, ale nie uwzględnia przygotowania testów, danych i środowisk.
10. Jak będą wyglądały wdrożenia, monitoring i security?
Projekt nie kończy się na połączeniu kodu z główną gałęzią repozytorium. Przed startem należy wiedzieć, jak zmiana przejdzie przez build, testy, release, deployment i operacje. W przeciwnym razie pierwsza wersja może powstać szybko, ale jej bezpieczne uruchomienie zajmie znacznie więcej czasu.
NIST Secure Software Development Framework rekomenduje integrowanie bezpiecznych praktyk z całym cyklem SDLC. Oznacza to, że wymagania bezpieczeństwa, zarządzanie zależnościami, ochrona kodu i weryfikacja nie powinny być dodatkiem do gotowego produktu.
Przed Sprintem 1 warto uzgodnić:
- strategię branchowania i code review,
- pipeline CI/CD oraz wymagane bramki jakościowe,
- sposób zarządzania konfiguracją i sekretami,
- środowiska oraz promocję wersji między nimi,
- skanowanie zależności, kodu i obrazów kontenerowych,
- monitoring techniczny i biznesowy,
- plan rollbacku oraz reakcję na incydenty,
- wymagania prawne, regulacyjne i audytowe.
Edge One Solutions wspiera projekty w zakresie DevOps, automatyzacji CI/CD, DevSecOps, utrzymania i monitoringu, a także testowania i kontroli jakości.
Minimalny artefakt: high-level release flow obejmujący CI/CD, środowiska, odpowiedzialność, monitoring i procedurę wycofania.
Sygnał ryzyka: data pierwszego release’u jest ustalona, ale nie istnieje sprawdzona ścieżka wdrożenia na środowisko docelowe.
11. Jak będzie zarządzana zmiana zakresu?
Zmiana nie jest wyjątkiem w projekcie IT. Jest naturalną konsekwencją uczenia się, feedbacku użytkowników, nowych danych i zmieniających się priorytetów. Problem pojawia się wtedy, gdy organizacja nie ma sposobu oceny jej wpływu.
Przed rozpoczęciem prac trzeba ustalić:
- kto może zgłaszać zmianę,
- kto ocenia jej wpływ na zakres, architekturę, koszt i termin,
- kto podejmuje decyzję o priorytecie,
- które zmiany mieszczą się w bieżącej współpracy,
- kiedy potrzebny jest formalny change request,
- jak aktualizowane są backlog, prognoza i dokumentacja decyzji.
W modelach zwinnych nie chodzi o zamrożenie zakresu. Chodzi o utrzymanie jednej widocznej kolejki decyzji i świadome zastępowanie jednego priorytetu innym.
Minimalny artefakt: prosty workflow zmiany zakresu wraz z progami decyzji i zasadą aktualizacji prognozy.
Sygnał ryzyka: nowe potrzeby są dokładane do sprintu bez usuwania innych zadań i bez oceny wpływu na zobowiązania.
12. Jak będziemy mierzyć jakość delivery?
Velocity opisuje ilość pracy zrealizowanej według estymacji danego zespołu. Nie jest uniwersalnym wskaźnikiem produktywności i nie powinno służyć do porównywania zespołów ani rozliczania pojedynczych osób.
Od pierwszego miesiąca warto obserwować zestaw uzupełniających się sygnałów:
- realizację Sprint Goal,
- przewidywalność ukończenia zaplanowanej pracy,
- czas od rozpoczęcia zadania do wdrożenia,
- liczbę i czas trwania blockerów,
- czas podejmowania decyzji przez interesariuszy,
- defekty wykryte po wdrożeniu,
- stabilność środowisk i pipeline’u,
- postęp mierników produktowych oraz biznesowych.
Wskaźniki powinny prowadzić do rozmowy o systemie pracy, nie do poszukiwania winnej osoby. Jeżeli zespół regularnie czeka na decyzje, środowisko lub dane, zwiększenie liczby developerów nie poprawi delivery.
Minimalny artefakt: karta wskaźników delivery zawierająca definicję, źródło danych, częstotliwość przeglądu i osobę odpowiedzialną za reakcję.
Sygnał ryzyka: raportowanie koncentruje się na zajętości zespołu, a nie na przepływie pracy, jakości i wartości.
Jak model współpracy zmienia przygotowanie projektu?
Ten sam projekt może wymagać innego poziomu przygotowania w zależności od tego, jak podzielona jest odpowiedzialność. Poniższa tabela pokazuje model kierunkowy. Dokładny zakres zawsze powinien wynikać z kontraktu, kompetencji klienta i uzgodnionego operating modelu.
| Obszar | Staff Augmentation | Dedicated Team | SoW / Fixed Price | Managed Services |
|---|---|---|---|---|
| Cel i priorytety | Klient | Klient, wspierany przez dostawcę | Uzgodnione w zakresie i kryteriach odbioru | Klient określa wynik i granice usługi |
| Backlog | Zarządzany przez klienta | Najczęściej współdzielony proces | Zakres bazowy i kontrola zmian | Backlog operacyjny zarządzany przez dostawcę w ramach SLA |
| Zarządzanie zespołem | Klient | Dostawca lub model współdzielony | Dostawca | Dostawca |
| Ryzyko zakresu | Po stronie klienta | Współdzielone | Kontrolowane przez założenia, odbiór i change request | Zależne od granic i parametrów usługi |
| Miarą sukcesu | Skuteczne uzupełnienie kompetencji i wkład w delivery klienta | Stabilny rozwój produktu lub obszaru | Odebrany rezultat zgodny z ustaleniami | SLA, KPI i ciągłość wyniku operacyjnego |
Praktyczny wniosek: im więcej odpowiedzialności za rezultat ma przejąć dostawca, tym dokładniej trzeba przed startem ustalić granice usługi, kryteria akceptacji, założenia, zależności i sposób zarządzania zmianą.
Minimalny zestaw artefaktów przed Sprintem 1
Dokumentacja nie jest celem sama w sobie. Jej rolą jest ograniczenie zależności od pamięci poszczególnych osób i umożliwienie szybkiego podejmowania decyzji. W większości projektów wystarczy zestaw krótkich, aktualizowanych materiałów.
| Artefakt | Na jakie pytanie odpowiada? | Właściciel |
|---|---|---|
| Karta problemu i wyniku | Dlaczego realizujemy projekt i co ma się zmienić? | Sponsor / Product Owner |
| Karta mierników sukcesu | Jak ocenimy rezultat? | Biznes i produkt |
| Backlog startowy | Co jest najważniejsze w pierwszych iteracjach? | Product Owner |
| Mapa decyzji / RACI | Kto ma mandat do podjęcia decyzji? | Sponsor / Delivery Manager |
| Diagram kontekstowy i mapa integracji | Gdzie znajdują się główne zależności techniczne? | Tech Lead / Architect |
| Definition of Done i strategia testów | Co oznacza ukończony, bezpieczny przyrost? | Zespół / QA Lead |
| Release flow | Jak kod trafi do użytkownika i jak zostanie wycofany? | DevOps / Tech Lead |
| Rejestr ryzyk i założeń | Co może zmienić zakres, termin lub jakość? | Delivery Manager |
GO, warunkowe GO czy NO-GO?
Project readiness nie powinno kończyć się mechanicznym odhaczaniem listy. Rezultatem musi być decyzja o sposobie rozpoczęcia projektu.
| Decyzja | Kiedy ją podjąć? | Co dalej? |
|---|---|---|
| GO | Cel, ownership, pierwsza praca, środowiska i sposób zapewnienia jakości są wystarczająco przygotowane. | Rozpoczęcie Sprintu 1 i regularny przegląd założeń. |
| Warunkowe GO | Pozostały ograniczone ryzyka, które mają właściciela, termin i plan obejścia. | Start w ograniczonym zakresie, np. discovery techniczne, spike, przygotowanie pipeline’u lub praca na niezależnym komponencie. |
| NO-GO | Brakuje właściciela produktu, dostępu do krytycznych systemów, możliwości odbioru albo zgodności stron co do zakresu i odpowiedzialności. | Usunięcie warunków blokujących przed uruchomieniem pełnego zespołu i budżetu delivery. |
Ważne: NO-GO nie oznacza rezygnacji z projektu. Czasami jest najbardziej odpowiedzialną decyzją, ponieważ zapobiega spalaniu budżetu przez zespół, który nie ma warunków do dostarczania wartości.
Jak mierzyć pierwszy miesiąc delivery?
Pierwsze tygodnie powinny potwierdzić, czy przyjęte założenia organizacyjne i techniczne działają w praktyce. Nie warto oczekiwać od nowego zespołu maksymalnej prędkości od pierwszego sprintu. Należy jednak obserwować, czy projekt staje się bardziej przewidywalny.
| Obszar | Dobry sygnał | Sygnał ryzyka |
|---|---|---|
| Cel sprintu | Zespół realizuje spójny, możliwy do oceny rezultat | Sprint jest zbiorem niezależnych zadań bez wspólnego celu |
| Decyzje | Właściciele odpowiadają w uzgodnionym czasie | Zespół regularnie czeka na akceptacje |
| Blockery | Są widoczne, mają właściciela i termin | Te same przeszkody wracają w kolejnych sprintach |
| Jakość | Testy i kryteria akceptacji są częścią każdego zadania | Praca „development done” czeka osobno na testy |
| Wdrożenia | Zespół przechodzi pełną ścieżkę od kodu do środowiska | Pierwsza próba wdrożenia jest odkładana do końca projektu |
| Uczenie się | Założenia są regularnie weryfikowane i aktualizowane | Plan pozostaje bez zmian mimo nowych informacji |
Checklista project readiness dla CIO, CTO i sponsora projektu
Biznes i produkt
- problem biznesowy został opisany niezależnie od proponowanego rozwiązania,
- wskazano sponsora i właściciela produktu,
- ustalono mierniki biznesowe, produktowe i operacyjne,
- pierwszy zakres ma jasno określone granice,
- backlog pierwszych iteracji został uporządkowany,
- obszary niepewności zostały nazwane.
Odpowiedzialność i współpraca
- wybrano model współpracy adekwatny do ryzyka i dojrzałości klienta,
- określono odpowiedzialność klienta i dostawcy,
- wskazano osoby podejmujące decyzje biznesowe, produktowe i techniczne,
- ustalono ścieżkę eskalacji oraz oczekiwany czas decyzji,
- uzgodniono proces zarządzania zmianą zakresu.
Technologia i bezpieczeństwo
- rozpoznano główne komponenty, dane i integracje,
- zidentyfikowano decyzje trudne do odwrócenia,
- potwierdzono potrzebę lub brak potrzeby discovery i audytu,
- uwzględniono wymagania wydajnościowe, dostępnościowe i regulacyjne,
- zaplanowano zarządzanie sekretami, zależnościami i dostępami.
Delivery i operacje
- zespół ma dostęp do repozytoriów, środowisk, danych i dokumentacji,
- istnieją Definition of Done, strategia testów i odpowiedzialność QA,
- uzgodniono pipeline CI/CD oraz sposób wdrożenia, monitoringu i rollbacku,
- zdefiniowano wskaźniki jakości delivery,
- ustalono częstotliwość przeglądu ryzyk, mierników i założeń.
Rola partnera technologicznego przed startem projektu
Dojrzały partner technologiczny nie powinien reagować na niepewność przez natychmiastowe zwiększanie zespołu lub tworzenie pozornie precyzyjnego harmonogramu. Jego rolą jest pomóc klientowi ustalić, które elementy są gotowe do realizacji, które wymagają analizy i jaki model współpracy właściwie rozdzieli odpowiedzialność.
Przed rozpoczęciem delivery dostawca powinien:
- zrozumieć wynik biznesowy i krytyczne procesy,
- zweryfikować, czy zakres pozwala na wiarygodne planowanie,
- ujawnić założenia i zależności techniczne,
- zaproponować odpowiedni skład zespołu, a nie tylko dostępne role,
- włączyć QA, DevOps i security na etapie planowania,
- zdefiniować granice odpowiedzialności w wybranym modelu,
- nazwać warunki, których brak uniemożliwia bezpieczny start.
Edge One Solutions wspiera organizacje w tworzeniu i integracji oprogramowania, zarządzaniu projektami IT, testowaniu, DevOps oraz budowaniu zespołów w modelach Staff Augmentation, Dedicated Team i SoW.
Jak pracujemy: przed uruchomieniem pełnego zespołu warto sprawdzić gotowość projektu, największe ryzyka i oczekiwany podział odpowiedzialności. Pozwala to dobrać model współpracy do rzeczywistej sytuacji, a nie dopasowywać projekt do wcześniej wybranego modelu.
Jeżeli planujesz rozpoczęcie nowego projektu, zmianę dostawcy albo rozszerzenie zespołu, możemy wspólnie ocenić, czy projekt jest gotowy do delivery i które decyzje warto zamknąć przed pierwszym sprintem.
Podsumowanie
Dobry start projektu nie polega na tym, że wszystkie pytania mają gotową odpowiedź. Polega na tym, że zespół zna cel, granice odpowiedzialności i sposób pracy z niepewnością.
Przed pierwszym sprintem trzeba przede wszystkim:
- nazwać problem i oczekiwany wynik,
- ustalić mierniki sukcesu i zakres początkowy,
- dobrać właściwy model współpracy,
- przypisać ownership decyzji,
- rozpoznać potrzebę discovery lub audytu,
- potwierdzić architekturę, integracje, środowiska i dostępy,
- włączyć QA, DevOps i security do planu,
- ustalić sposób zarządzania zmianą oraz pomiaru delivery.
Jeżeli któregoś z tych elementów brakuje, nie zawsze trzeba zatrzymywać projekt. Trzeba jednak świadomie zdecydować, czy możliwy jest pełny start, ograniczony sprint przygotowawczy, discovery czy czasowe NO-GO. To właśnie ta decyzja najbardziej odróżnia odpowiedzialne przygotowanie projektu od formalnego kick-offu.
