Flowchart for produktudviklingsprocessen (stage-gate)

Sådan fungerer det

1. Omdøb banerne til jeres virkelige funktioner

   Erstat Produktledelse, Udvikling / R&D, Design, Kvalitet og Kommerciel med de funktioner, I faktisk har. Hardwareteams deler som regel Udvikling op i mekanik, elektronik og produktionsteknik; softwareteams har ofte ingen selvstændig kvalitetsbane og bør folde valideringen ind i udviklingen frem for at efterlade et tomt bånd. Slå enhver bane sammen, som I ikke kan sætte en navngiven ejer på, og hold antallet af baner på det, der kan være på én skærm.

2. Skriv gatekriterierne, før det første review

   En gate uden nedskrevne kriterier bliver til en præsentation. For gate 1: angiv, hvad business casen skal indeholde, og hvilke tærskler der gør den til et Go — den markedsstørrelse, I anser for værd at forfølge, de gennemførlighedsspørgsmål, der skal besvares frem for antages, og det lovgivningsmæssige omfang. For gate 2: angiv, hvilken dokumentation fra pilotproduktionen der kræves. Aftal begge dele, mens der ikke venter noget ved porten — kriterier, der forhandles på dagen, er kriterier skrevet af den, der har mest på spil i et Go.

3. Beslut, hvad Retur og Forlæng pilot rent faktisk betyder

   De to bløde grene er dér, hvor stage-gate-processer rådner. Retur ved gate 1 skal bære en konkret liste over, hvad der skal ændres, en ejer og en dato for genfremlæggelse; ellers er det et Stop, ingen turde sige. Forlæng pilot ved gate 2 skal navngive, hvad der skal læres, hvor længe forlængelsen løber, og hvilket kriterium der afslutter den. Dokumentér begge dele på projektet frem for i mødereferatet, og tæl, hvor ofte hver af dem bruges — en gate, der kun nogensinde sender retur, beslutter ikke noget.

4. Hold designreview og validering som to separate kontroller

   De besvarer forskellige spørgsmål. Designreviewet spørger, om designet og prototypen opfylder den specifikation, der blev aftalt ved udviklingens start, og det er en fagfælle- og interessentkontrol af selve designet. Valideringstesten spørger, om det færdige produkt opfylder brugerbehovet og de lovgivningsmæssige krav under virkelige forhold. At holde dem adskilt er dét, der gør de to omarbejdningssløjfer i diagrammet meningsfulde: den ene fanger et designproblem, før I bruger penge på testenheder, den anden fanger et kravproblem, før I bruger penge på en pilotproduktion.

5. Definer pilotproduktionen og dens exitkriterier

   "Kør en begrænset pilotproduktion" betyder noget forskelligt i hver organisation: en førserie, en blød lancering i én region, en tidlig adgangsgruppe. Skriv ned, hvilken af delene det er, hvilket antal enheder eller kunder det omfatter, hvad der måles — udbytte, fejlrate, supportbelastning, aktivering — og hvor længe det løber, før gate 2 indkaldes. En pilot uden en defineret afslutning er, hvordan lanceringsdatoer skrider, uden at nogen beslutning bliver truffet.

6. Navngiv gate-ejerne, og dokumentér beslutningerne

   Navngiv for hver gate den person, der har beslutningen, og den kreds, der skal være til stede. Én navngiven ejer pr. gate er bedre end et udvalg, der beslutter ved fravær af indsigelser. Registrer udfaldet, datoen, de anvendte kriterier og begrundelsen — især ved et Stop, for et udokumenteret stop dukker op igen som den samme idé om et halvt år. Arbejder I efter et kvalitetsledelsessystem, er den registrering samtidig dokumentationen for, at reviewene fandt sted.

7. Udgiv den, og revider den efter hver lancering

   Del diagrammet dér, hvor arbejdet foregår — ved siden af gate-skabelonerne frem for i en politikmappe — og få baneejerne til at godkende det. Gå flowet igennem med teamet efter hver lancering: hvilken gate blev sprunget over, hvilken sløjfe blev taget og hvorfor, og skete evalueringen efter lancering faktisk, eller blev den overhalet af det næste projekt. Gem de tidligere versioner, så I kan vise, hvornår processen blev ændret, og hvad der udløste det.

Ofte stillede spørgsmål

Hvilke faser består en produktudviklingsproces af?

Fem faser dækker de fleste produktorganisationer. Først idé og screening: registrer idéen og hold den op mod strategien, før nogen funktion binder timer. Dernæst business case: vurder teknisk gennemførlighed, skitser konceptet, afklar de lovgivningsmæssige krav og estimer markedet, og saml derefter alle fire dele i én case, som tages til gate 1. For det tredje design og udvikling: aftal krav og specifikation, udarbejd det detaljerede design, byg en fungerende prototype og afhold et designreview. For det fjerde validering: planlæg og gennemfør valideringstest op imod specifikationen, og kør derefter en begrænset pilotproduktion, når den er bestået. Og til sidst lancering og evaluering: træf lanceringsbeslutningen ved gate 2, lancer på markedet, og hold derefter en evaluering efter lancering og luk projektet.

Hvad er en stage-gate-proces, og hvad kan en gate beslutte?

En stage-gate-proces grupperer udviklingsarbejdet i faser og lægger et beslutningspunkt mellem hver af dem, så penge og timer frigives i portioner frem for alle på én gang. De klassiske udfald ved en gate er go, kill, hold og recycle: gå videre til næste fase, stop projektet, park det på grund af kapacitet eller prioritet, eller send det retur til omarbejdning af den nuværende fase, før der besluttes. Denne skabelon viser Go, Retur og Stop ved gate 1 og Lancer, Forlæng pilot og Stop ved gate 2. Producerer jeres gates aldrig andet end go, er de ikke gates — og den porteføljestyring, de skulle levere, finder ikke sted.

Hvad er forskellen på et designreview og en valideringstest?

Et designreview kontrollerer designet op imod dets input: opfylder det detaljerede design og prototypen den specifikation, der blev aftalt ved udviklingens start, og er de åbne risici forstået. Valideringstesten kontrollerer produktet op imod behovet: virker det for brugeren, under realistiske forhold, op imod kravene inklusive de lovgivningsmæssige. Verifikation er det første spørgsmål, validering det andet, og kvalitetsstandarder behandler dem som adskilte aktiviteter af gode grunde. I dette diagram er de to beslutninger med hver sin returvej ind i det detaljerede design, fordi en designfejl fundet ved reviewet er langt billigere end den samme fejl fundet, efter at testenhederne er bygget.

Hvordan adskiller det sig fra en software release-proces eller et go/no-go-beslutningstræ?

Omfanget. Dette diagram dækker hele udviklingsforløbet, fra en idé kommer ind i pipelinen til evalueringen efter lancering, og behandler hver lanceringsbeslutning som én node med en port. Software release-processen på /da/templates/software-release-proces starter langt senere, ved et færdigt build, og går i detaljer med branch cuts, testporte, staging, deployment, tilbagerulning og hotfixes. Go/no-go-beslutningstræet på /da/templates/go-no-go-beslutningsproces går den modsatte vej og folder én gate ud i et dusin dokumentationsspørgsmål med fem navngivne udfald. Brug denne side til at definere forløbet, og en af de andre til den del af det, I har brug for i flere detaljer.

Hvem bør eje hver gate-beslutning?

Én navngiven person pr. gate, hvor de bidragende funktioner deltager som dokumentation snarere end som stemmer. Gate 1 ligger som regel hos den, der ejer porteføljen og budgettet — en produktdirektør, en forretningschef eller ledergruppen i en mindre virksomhed — fordi det er en beslutning om, hvor udviklingskapaciteten skal hen. Gate 2 er både en parathedsbeslutning og en kommerciel beslutning, så ejeren skal have myndighed til at holde en lancering tilbage, når kvalitet eller forsyning ikke er klar — ikke kun til at godkende den. Skriv beslutningskompetencen ned før den første gate: en gate uden ejer havner hos den, der er mest senior i lokalet den dag.

Hvor mange gates bør en produktudviklingsproces have?

Færre end I tror, og kun dér, hvor der findes en reel beslutning. Der er to her, fordi de markerer de to punkter, hvor de bundne omkostninger springer: gate 1 frigiver udviklingen, gate 2 frigiver lanceringen og de produktions-, marketing- og supportomkostninger, der følger med. Større eller mere regulerede programmer tilføjer ofte en gate mellem koncept og detaljeret design og en, før valideringen begynder. Den brugbare test er, om porten realistisk kunne give andet svar end go. Har et review aldrig én eneste gang stoppet eller ændret et projekt, så fjern det — eller flyt det derhen, hvor pengene rent faktisk bindes.