Dokument wymagań dotyczących produktu

Dokument wymagań produktu określa, co produkt lub funkcja powinna robić, dla kogo i dlaczego, wraz z ograniczeniami, które musi spełniać, oraz kryteriami oceny sukcesu. Powstał on przed iteracyjnym rozwojem i jest często odrzucany jako artefakt sekwencyjnego dostarczania, ale podstawowa potrzeba, której służy, nie zniknęła: istotna część pracy nadal wymaga wspólnego, pisemnego uzasadnienia intencji.

Zastrzeżenie wobec formatu jest w rzeczywistości zastrzeżeniem wobec sposobu jego wykorzystania. Dokument określający każdy szczegół z góry, podpisany i traktowany jako niezmienny przez rok jest niezgodny z nauką, a jego brak został już dawno udowodniony. Dokument określający problem, użytkowników, oczekiwane rezultaty i ograniczenia, pozostawiając jednocześnie szczegóły rozwiązania do opracowania w miarę pogłębiania wiedzy, pełni inną funkcję i pozostaje cenny.

Najbardziej przydatne są sekcje opisujące problem, a nie jego rozwiązanie. Kto ma ten problem, jakie dowody na to wskazują, co robi obecnie, jaki wynik byłby sukcesem i co celowo wykracza poza zakres. Dokument otwierający się listą funkcji pominął uzasadnienie, które pozwoliłoby każdemu ocenić, czy funkcje są właściwe.

Ograniczenia zasługują na wyraźne omówienie, ponieważ to właśnie one są źródłem większości późnych niespodzianek. Obowiązki regulacyjne, wymogi bezpieczeństwa, standardy dostępności, oczekiwania dotyczące wydajności, obsługiwane platformy, zależności integracyjne i ograniczenia operacyjne – wszystkie te czynniki wpływają na to, co można zbudować, a ich odkrycie podczas wdrażania jest kosztowne. Rejestrowanie ich na samym początku jest tanie i zapobiega kategorii przeróbek, których można całkowicie uniknąć.

Kryteria sukcesu to sekcja najczęściej pomijana i decydująca o tym, czy inwestycja w ogóle będzie mogła zostać oceniona. Określenie z góry, jaką mierzalną zmianę ma przynieść praca i w jakim okresie, przekształca funkcję w testowalną propozycję i pozwala organizacji wyciągać wnioski z rezultatów. Dokumenty opisujące, co zostanie zbudowane, bez określenia oczekiwanych rezultatów, uniemożliwiają ocenę po wdrożeniu.

Dokument należy traktować jako żywy, a nie podpisany dokument. Zrozumienie poprawia się w trakcie realizacji, pojawiają się dowody, a ograniczenia ulegają zmianie, a dokument, który nie jest aktualizowany, staje się zapisem historycznym, sprzecznym z produktem. Utrzymanie go jako aktualnego oświadczenia o zamiarach, z widocznymi istotnymi zmianami, sprawia, że ​​jest on użyteczny dla osób dołączających do pracy później, które muszą zrozumieć, dlaczego podjęto decyzje.

Pytania otwarte zasługują na osobną sekcję, a nie są pomijane dla pozoru rozstrzygające. Rejestrowanie tego, co jeszcze nie jest znane, kto to rozwiąże i kiedy, przekształca niepewność z ukrytego ryzyka w śledzoną pracę i zapobiega częstej sytuacji, w której nierozstrzygnięta kwestia zostaje odkryta podczas wdrażania przez kogoś, kto zakładał, że została już rozstrzygnięta.

Długość jest odwrotnie proporcjonalna do użyteczności po przekroczeniu pewnego punktu. Dokument, którego nikt nie czyta, ponieważ liczy czterdzieści stron, jest niekompletny, niezależnie od jego kompletności, a dyscyplina zwięzłego przedstawienia problemu, użytkowników, rezultatów, ograniczeń i pytań otwartych prowadzi do powstania czegoś, z czym faktycznie się konsultuje. Szczegóły powinny znaleźć się w artefaktach, które ich potrzebują, w tym w projektach, kryteriach akceptacji i specyfikacjach technicznych, a nie być konsolidowane w jednym nieprzeczytanym dokumencie.

Ponieważ wartość dokumentu polega na budowaniu wspólnego zrozumienia między funkcjami, które w przeciwnym razie działałyby w oparciu o odmienne założenia, wymaga on wkładu wykraczającego poza zarządzanie produktem. W praktyce jest on tworzony w ramach studio produktowe zaangażowanie w problem, dowody dostarczone przez badania produktów, ograniczenia potwierdzone przez rozwój produktówi kryteria sukcesu uzgodnione z Analityka danych tak aby można je było zmierzyć po starcie.