Sign-off (Zatwierdzanie wymagań)

Sign-off (Zatwierdzanie wymagań)

Definition (short):

Sign-off (zatwierdzanie wymagań) to formalny akt, w którym osoba odpowiedzialna biznesowo (zwykle Product Owner, sponsor projektu lub klient zewnętrzny) potwierdza, że zaakceptowane wymagania w bieżącej wersji odpowiadają potrzebom biznesowym i zgadza się na rozpoczęcie ich realizacji. Sign-off tworzy baseline - formalny punkt odniesienia, od którego każda zmiana wymaga oddzielnego procesu change control. Forma sign-off zależy od projektu: w small/Agile zespołach to akceptacja PO w Jirze (kliknięcie "Approve" + komentarz), w projektach enterprise/regulated podpis na PDF lub formalna akceptacja w systemie zarządzania wymaganiami (DOORS, Polarion, Jama). Sign-off różni się od "akceptacji" tym, że akceptacja może być nieformalna (mail, słowne potwierdzenie), a sign-off zawsze tworzy artefakt nadający się do audytu. Najczęstsza pułapka - "sign-off bez przeczytania" - gdy biznesowy podpisuje 80 wymagań w 30 minut, a po 4 miesiącach twierdzi, że tego nie zamawiał. Praktyka: sign-off odbywa się na warsztacie czytania, nie mailem.

Body (extended definition):

Co dokładnie zatwierdza sign-off

• Zakres wymagań (lista, co wchodzi, co nie wchodzi).
• Treść poszczególnych wymagań (że są zrozumiałe, zgodne z potrzebą biznesową).
• Priorytety wymagań (MoSCoW / WSJF / inny).
• Acceptance criteria (kiedy uznamy, że wymaganie jest spełnione).
• Pomijane / odroczone wymagania (że biznesowy świadomie rezygnuje z nich w tej fazie).

Kto sign-offuje

Rola zależy od projektu i fazy:

• Product Owner - w projektach Scrumowych dla pojedynczych user stories / epics. Continuous sign-off podczas refinementu i sprint planning.
• Sponsor projektu - dla baseline'u na koniec analizy w projektach hybrid/waterfall.
• Klient zewnętrzny - w projektach dla zewnętrznego zamawiającego (B2B, administracja publiczna). Często formalny dokument z podpisem.
• Compliance officer - dodatkowy sign-off dla wymagań regulacyjnych (RODO, AML, KSeF).
• Architekt rozwiązań - dla wymagań niefunkcjonalnych mających wpływ na architekturę.

W większych projektach sign-off jest wielowarstwowy (functional sign-off przez PO + compliance sign-off przez officera + technical sign-off przez architekta). W małych zwykle jeden PO/sponsor.

Kiedy odbywa się sign-off

• Po fazie analizy (waterfall, hybrid) - sign-off na pełen pakiet wymagań przed przekazaniem do developmentu.
• Po release wymagań na sprint (Agile) - PO akceptuje stories podczas sprint planning lub refinementu.
• Po milestone (large project) - sign-off na kolejne pakiety w trakcie projektu.
• Przed go-live - finalna akceptacja, że produkt spełnia wymagania (często łączony z UAT sign-off).

W jakiej formie

• Mail z akceptacją - szybko, ale słaby audit trail. Akceptowalne dla małych projektów.
• Akceptacja w systemie (Jira, Confluence, DOORS) - najczystsza forma, audit trail w jednym miejscu.
• Podpis na PDF - dla projektów dla administracji publicznej, kontraktów B2B z formalnymi wymaganiami prawnymi.
• Decyzja w protokole spotkania - akceptowalna, jeśli protokół jest pisany na bieżąco, podpisany i przechowywany.

Akceptacja vs sign-off - różnica

• Akceptacja może być nieformalna (kciuk w górę na statusie, "ok" w czacie). Często ma charakter operacyjny.
• Sign-off zawsze tworzy artefakt nadający się do audytu - z osobą, datą i wersją wymagań.

Akceptacja może poprzedzać sign-off ("biznes powiedział, że ok") albo go zastąpić w małym projekcie. Sign-off jest wymagany dla projektów regulowanych, audytowanych lub gdy stawka jest wysoka.

Sign-off bez przeczytania - najczęstsza pułapka

PO podpisuje 80 wymagań w 30 minut bo "ufa zespołowi". Po 4 miesiącach mówi "tego nigdy nie zamawiałem". Praktyczne rozwiązania:

1. Warsztat sign-off, nie mail. BA prowadzi PO przez każde wymaganie, PO faktycznie czyta i pyta. 2-4h na 80 wymagań.
2. Sign-off w paczkach (10-15 wymagań naraz), nie wszystko w jednym ruchu.
3. Sign-off z przygotowaniem - PO dostaje dokument na 3 dni wcześniej, na warsztacie omawiacie już znanego materiału.
4. Acceptance criteria czytelne dla biznesu - bez tego sign-off jest niewykonalny.

Praktyka enterprise vs startup

Enterprise/regulated:

• Sign-off formalny, dokumentowany w narzędziu (DOORS / Polarion / Jama).
• Wielowarstwowy (biznes + compliance + architektura + security).
• Baseline z wersjonowaniem, każda zmiana = change control.
• Dla projektów dla administracji często podpisy odręczne na PDF.

Startup/Agile:

• Continuous sign-off podczas refinementu sprintu.
• Jeden PO akceptuje, brak compliance officera w cyklu.
• Akceptacja w Jirze (status change), bez osobnego dokumentu.
• Baseline nieformalna (snapshot Confluence per release).

Forma musi być dopasowana do projektu. Enterprise w startupie zabija prędkość. Startup w enterprise = audyt fail.

Common pitfalls

• Sign-off bez przeczytania - opisany wyżej.
• Sign-off przez "niewłaściwą" osobę - junior PO podpisuje, sponsor potem mówi "nie zgodził się". Fix: jasna lista, kto ma prawo do sign-off na jakim poziomie wymagań.
• Brak baseline - sign-off odbył się, ale nigdzie nie ma "wersji 1.0". Sześć miesięcy później nie wiesz, co dokładnie zostało zaakceptowane. Fix: po sign-off zawsze utwórz wersjonowany snapshot (Confluence baseline, DOORS baseline, Word file z datą).
• Sign-off jako blokada postępu - proces tak biurokratyczny, że trwa tygodniami. Fix: dopasuj formę do skali projektu.

Powiązane pojęcia

governance wymagań, change control board, acceptance criteria, requirements baseline, UAT, Definition of Done, Product Owner, RACI, audit trail