Product Blueprint & Scope forklaret

Hvad det er

Arbejdet kortlægger den aftalte produktafgrænsning tilstrækkeligt detaljeret til at understøtte en realistisk beslutning om næste fase. Det kan dække brugerroller, kerneflows, funktionsprioriteter, behov for data og integrationer, platformsvalg, antagelser, udeladelser, leverancefaser og konsekvenser for ændringsstyring. Detaljeringsgraden tilpasses den aktuelle beslutning med fokus på de funktioner, der har betydning for næste fase. Blueprinten beskriver, hvad der er omfattet nu, og hvad der bevidst holdes uden for den første fase. Den registrerer også spørgsmål, der afhænger af kundens adgang, tredjepartssystemer, input fra leverandører eller yderligere teknisk undersøgelse. Fuld udvikling og implementering følger under et separat leveranceomfang. Formålet er at mindske uklarhed, ikke at skabe falsk sikkerhed.

Hvem er det for?

En Product Blueprint & Scope passer til teams, der:

• Har gennemført en indledende discovery og har brug for en klarere bro mellem produkttænkning og implementeringsplanlægning
• Har brug for, at flere interessenter bliver enige om brugerroller, funktionsprioriteter, leverancefaser og udeladelser
• Forbereder samarbejde med interne udviklere eller eksterne leverandører og ønsker en mere brugbar beslutningsregistrering
• Har brug for at forstå konsekvenserne af integrationer, antagelser og fremtidige ændringsønsker, før de forpligter sig til udvikling

Hvad det hjælper med at afklare

En blueprint hjælper med at afklare:

• Hvilke brugerroller og kerneflows der er væsentlige for den aftalte første fase
• Hvilke funktioner, integrationer, indhold og driftsmæssige afhængigheder der hører inden for eller uden for den nuværende afgrænsning
• Hvordan antagelser, udeladelser og leverancefaser påvirker estimater, ejerskab og senere ændringsstyring
• Hvilke spørgsmål der kræver yderligere adgang, input fra leverandører, teknisk validering eller et separat specialistomfang

Hvad er inkluderet

• Skriftlig bekræftelse af produktbeslutningen, brugerrollerne, den tilsigtede fase og de tilgængelige input
• En struktureret skitse af kerneflows, funktionsafgrænsninger, prioriteter, integrationer, antagelser og udeladelser med en anbefaling af teknisk arkitektur og teknologistak
• En plan for leverancefaser med et estimat af tidsplanen og et budgetmæssigt omkostningsinterval (et planlægningsestimat), der adskiller det umiddelbare omfang fra senere idéer og afhængigheder
• En beslutningsregistrering, der forklarer, hvor krav fortsat er åbne eller afhænger af ekstern adgang og eksterne systemer
• Praktisk vejledning i ændringsstyring, så nye ønsker kan håndteres uden i stilhed at udvide den aftalte afgrænsning
• En overdragelsesdrøftelse, der egner sig til stiftere, produktejere, tekniske teams og leverancepartnere

Hvad er ikke inkluderet?

• Fuld udvikling, implementering, udrulning i produktion eller løbende produktledelse, medmindre det afgrænses separat
• Et løfte om, at omfang, omkostninger, tidsplan eller teknisk tilgang aldrig behøver at ændre sig
• Ubegrænset funktionsdefinition, udarbejdelse af skærmbilleder, leverandørforhandling eller revisioner ud over det aftalte arbejde
• Formel rådgivning om jura, compliance, tilgængelighed, sikkerhedscertificering eller indkøb
• Bekræftelse af tredjepartssystemers adfærd, tilgængelighed eller priser uden den nødvendige adgang og dokumentation

Hvornår du skal vælge det

Vælg en Product Blueprint & Scope, når produktretningen er klar nok til at planlægge, men teamet har brug for en stærkere enighed om brugere, flows, funktioner, afhængigheder og afgrænsninger, før implementeringen begynder. Den er nyttig efter discovery, før en MVP-sprint, før en genopbygning, eller når en samtale med en leverandør har brug for et klarere grundlag end en ønskeliste over funktioner. Den kan mindske undgåelig uenighed ved at registrere, hvad den nuværende fase skal opnå, og hvad den ikke skal løse. Den er mindre passende, når teamet stadig er usikkert på det grundlæggende problem eller målbrugeren; her kan discovery være det bedre første skridt. Blueprinten er mest effektiv, når beslutningstagerne er parate til at foretage afvejninger og udpege udeladelser i stedet for at lade alt potentielt være omfattet.

Vores tilgang

Vi begynder med at bekræfte den tilsigtede fase og de beslutninger, blueprinten skal understøtte. Derefter arbejder vi os igennem brugerroller, kerneforløb, funktioner, integrationer, indhold, driftskrav og begrænsninger. Drøftelsen skelner mellem et krav og en antagelse og mellem en forpligtelse i første fase og en fremtidig idé. Vi dokumenterer udeladelser lige så omhyggeligt som det, der er omfattet, fordi det er afgrænsningerne, der gør et senere estimat og en leveranceplan mere pålidelige. Hvor et krav afhænger af adgang, et tredjepartssystem, samarbejde fra en leverandør eller yderligere teknisk arbejde, forbliver denne afhængighed synlig. Omkostninger og tidsplan i blueprinten præsenteres som planlægningsestimater. Ved overdragelsen har teamet et beslutningsklart overblik over produktafgrænsningen, faserne, konsekvenserne for ændringsstyring og de oplysninger, der stadig mangler, før implementeringen ansvarligt kan bekræftes.

Ofte stillede spørgsmål

Relaterede artikler