Flowchart for produktudviklingsprocessen (stage-gate)

Hvad er flowchart for produktudviklingsprocessen (stage-gate)?

En produktudviklingsproces forvandler en strøm af idéer til et lille antal lancerede produkter, og det arbejde, den udfører, er mest af alt fratrækning. Enhver organisation kan generere koncepter; disciplinen ligger i at beslutte, hvilke der skal stoppe, og at stoppe dem, før pengene er brugt. Det er dét, en stage-gate-struktur er til for. Arbejdet grupperes i faser, hver fase slutter ved en gate, og en gate er kun en gate, hvis den kan sige nej. Uden en stopgren har I ikke en gate, men et statusmøde: projekterne ankommer med momentum, ingen har lyst til at være den, der lukker et af dem, og porteføljen fyldes stille og roligt med halvdøde programmer, der æder udviklingskapacitet uden nogensinde at nå frem til en lanceringsbeslutning.

Denne side kortlægger hele forløbet, fra idé til evaluering efter lancering, for et tværfagligt produktteam. Den er bevidst bredere end tre nabosider. Det er ikke software release-processen på /da/templates/software-release-proces, som starter ved et færdigt build og slutter ved overvågning i produktion, og det er ikke go/no-go-beslutningstræet på /da/templates/go-no-go-beslutningsproces, som zoomer helt ind på lanceringsporten og folder den ud i et dusin dokumentationsspørgsmål. Er produktet allerede lanceret, og handler det om ændringer til det, er processen, I skal bruge, ændringsstyring på /da/templates/aendringsstyring-proces. Her er lanceringsporten én node med tre grene; alt før den, fra idéscreening til en begrænset pilotproduktion, er diagrammets egentlige indhold.

Skabelonen løber tyve trin fordelt på fem swimlanes (Produktledelse, Udvikling / R&D, Design, Kvalitet og Kommerciel) over fem faser: Idé og screening, Business case, Design og udvikling, Validering samt Lancering og evaluering. Den indeholder de sløjfer, de fleste tegnede versioner udelader: en returgren, der sender en svag business case tilbage til omarbejdning frem for at stoppe den, et ikke-godkendt designreview, der går tilbage til det detaljerede design, en "Opfylder produktet kravene?"-beslutning, der sender fejlet validering tilbage i design frem for videre i pilotproduktion, og en forlæng-pilot-gren ved gate 2 til et produkt, der er næsten klar, men ikke helt.

Hvad dette flowchart dækker

I denne skabelon

• Fem funktionsbaner (Produktledelse, Udvikling / R&D, Design, Kvalitet og Kommerciel) fordelt på fem faser: Idé og screening, Business case, Design og udvikling, Validering samt Lancering og evaluering
• Et screeningstrin før enhver udgift: idéen registreres i pipelinen og screenes mod strategien i produktledelsens bane, så svage koncepter filtreres fra, før fire funktioner bliver bedt om at bruge tid
• Fire separate input til business casen, ét pr. funktion: teknisk gennemførlighed fra Udvikling / R&D, produktkonceptet fra Design, lovgivningsmæssige krav fra Kvalitet og markedspotentialet fra Kommerciel, alle samlet i "Udarbejd business casen"
• Gate 1 med tre navngivne udfald: "Gate 1: udvikl eller stop?" forgrener Go til krav og specifikation, Retur tilbage til business casen til omarbejdning, og Stop til "Idé lagt på hylden med begrundelse" som afsluttende afvisning
• To adskilte omarbejdningssløjfer ind i "Udarbejd det detaljerede design": "Er designreviewet godkendt?" går retur på Omarbejd, før validering overhovedet forsøges, og "Opfylder produktet kravene?" går retur på Nej efter valideringstesten, så en fejlet test aldrig siver videre ud i pilotproduktionen
• Gate 2 som lanceringsbeslutning: "Gate 2: godkendes lancering?" forgrener Lancer til den kommercielle bane, Forlæng pilot tilbage til den begrænsede pilotproduktion, og Stop til "Lancering stoppet ved gate 2", med en evaluering efter lancering og lukning som flowets afslutning

Hvornår du skal bruge skabelonen

• I indfører en stage-gate-proces for første gang og har brug for ét fælles billede af faser, gates og ejerskab, før det bliver til en skabelonpakke og en række mødeindkaldelser
• Projekterne i jeres portefølje ser aldrig ud til at stoppe: intet bliver formelt lukket, kapaciteten er spredt over for mange igangværende programmer, og ingen kan pege på den beslutning, der satte hvert af dem i gang
• Udviklingsarbejdet sættes i gang, før business casen findes, eller specifikationen skrives efter designet, og I har brug for at vise den tilsigtede rækkefølge til dem, der udfører arbejdet
• I skal koble processen til et kvalitetsledelsessystem: ISO 9001 punkt 8.3 dækker design og udvikling og forventer, at planlægning, reviews, verifikation og validering gennemføres og dokumenteres, og har brug for flowet, før I skriver proceduren
• Overleveringerne mellem produkt, udvikling, design, kvalitet og det kommercielle er den reelle flaskehals, og I vil kunne se, hvilken funktion der holder på arbejdet i hver fase, frem for at diskutere det efter en overskredet lanceringsdato

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.