Dokument for produktkrav

Et produktkravsdokument beskriver, hvad et produkt eller en funktion skal kunne, for hvem og hvorfor, sammen med de begrænsninger, det skal respektere, og de kriterier, hvorefter succes bedømmes. Det går forud for iterativ udvikling og afvises ofte som et artefakt af sekventiel levering, men det underliggende behov, det tjener, er ikke forsvundet: væsentligt arbejde kræver stadig en fælles, skriftlig redegørelse for intentioner.

Indvendingen mod formatet er i virkeligheden en indvending mod, hvordan det blev brugt. Et dokument, der specificerer hver eneste detalje på forhånd, underskriver den og behandler den som fast i et år, er uforeneligt med læring, og dets fejl var veldokumenteret. Et dokument, der beskriver problemet, brugerne, de tilsigtede resultater og begrænsningerne, samtidig med at det lader løsningsdetaljerne blive udarbejdet, efterhånden som forståelsen forbedres, tjener en anden funktion og forbliver værdifuldt.

De mest nyttige afsnit er dem, der beskriver problemet snarere end løsningen. Hvem har dette problem, hvilke beviser understøtter, at de gør det, hvad de gør i stedet, hvilket resultat ville udgøre succes, og hvad er bevidst uden for rammerne. Et dokument, der åbner med en liste over funktioner, har sprunget den argumentation ud, der ville give alle mulighed for at vurdere, om funktionerne er de rigtige.

Begrænsninger fortjener en eksplicit angivelse, fordi det er her, de fleste sene overraskelser opstår. Reguleringsforpligtelser, sikkerhedskrav, tilgængelighedsstandarder, forventninger til ydeevne, understøttede platforme, integrationsafhængigheder og driftsmæssige begrænsninger former alle, hvad der kan bygges, og det er dyrt at opdage dem under implementeringen. Det er billigt at registrere dem fra starten og forhindrer en kategori af omarbejde, der kan undgås fuldstændigt.

Succeskriterier er det afsnit, der oftest udelades, og det, der afgør, om investeringen nogensinde kan vurderes. Ved på forhånd at angive, hvilken målbar ændring arbejdet forventes at producere, og over hvilken periode, omdannes en funktion til et testbart forslag og giver organisationen mulighed for at lære af resultaterne. Dokumenter, der beskriver, hvad der vil blive bygget, uden at angive, hvad det forventes at opnå, gør evaluering efter implementeringen umulig.

Dokumentet bør behandles som levende snarere end som en underskrevet aftale. Forståelsen forbedres under levering, beviser ankommer, begrænsninger ændres, og et dokument, der ikke opdateres, bliver en historisk registrering, der modsiges af produktet. Ved at bevare det som den aktuelle hensigtserklæring, med synlige væsentlige ændringer, forbliver det nyttigt for de personer, der senere deltager i arbejdet, og som har brug for at forstå, hvorfor beslutningerne blev truffet.

Åbne spørgsmål fortjener deres egen sektion i stedet for at blive udeladt for at fremstå afgørende. Registrering af, hvad der endnu ikke er kendt, hvem der vil løse det, og hvornår, omdanner usikkerhed fra en skjult risiko til sporet arbejde, og det forhindrer den almindelige situation, hvor et uløst spørgsmål opdages under implementeringen af ​​en person, der antog, at det var blevet afgjort.

Længde er omvendt proportionalt med nytteværdien ud over et vist punkt. Et dokument, som ingen læser, fordi det fylder fyrre sider, har fejlet uanset dets fuldstændighed, og disciplinen med at formulere problemet, brugerne, resultaterne, begrænsningerne og de åbne spørgsmål præcist producerer noget, der rent faktisk konsulteres. Detaljer hører hjemme i de artefakter, der har brug for dem, herunder design, acceptkriterier og tekniske specifikationer, snarere end at blive konsolideret i ét ulæst dokument.

Fordi dokumentets værdi ligger i at etablere fælles forståelse på tværs af funktioner, der ellers ville basere sig på forskellige antagelser, har det brug for bidrag ud over produktstyring. I praksis produceres det inden for en produktstudie engagement i problemet bevismateriale leveret af produktundersøgelse, de begrænsninger, der er bekræftet af produktudvikling, og de succeskriterier, der er aftalt med dataanalyse så de rent faktisk kan måles efter lanceringen.