De bedste og værste måder at lave en produktspecifikation på

En af de største udfordringer, som produktudviklingsteams står over for, er simpelthen hvordan de skal beslutte, hvilket produkt de skal bygge. I tilfælde af teams, der arbejder ud fra en produktspecifikation, især inden for hardwareudvikling, får ingeniørerne typisk ikke lov til at begynde at arbejde, før den er færdiggjort og godkendt. Og da de fleste udviklingstidslinjer er utroligt korte, er der ofte ikke tid nok til at overveje alternative løsninger, når der kommer nye oplysninger frem.

En måde at se på denne udfordring på er vist her. Du kan forestille dig, at cirklen er alle mulige måder, som teamet kunne bygge produktet på. Og den lille blå prik er specifikationen for et bestemt produkt. Denne produktspecifikation definerer præcis, hvilket produkt udviklerne skal fokusere på og bygge.

I dette indlæg vil jeg først beskrive nogle af de almindelige metoder, der bruges til at blive enige om en produktspecifikation. Derefter vil jeg undersøge problemerne med disse metoder, og hvordan de kan føre til, at man bygger produkter ud fra en specifikation, der faktisk ikke løser kundens problemer.

Jeg bør sige, at mit perspektiv stammer fra 10 års erfaring med at arbejde i analog- og mixed-signal halvlederindustrien, først som applikationsingeniør og senere som produktdefinerer. Nu er jeg konsulent her hos Jama.

Dårligste måder at lave en produktspecifikation på:

Spørg din kunde, hvad de vil have dig til at bygge

En måde at starte på er at spørge dine kunder, hvad de har brug for. Dette kan gøres ved at vente på en anmodning om tilbud (RFQ) udstedt af kunden, eller mindre formelt gennem møder og diskussioner. Det, du typisk vil få at vide med denne fremgangsmåde, er, hvilken løsning eller hvilket produkt de bruger i dag, og hvad de gerne vil have ændret i en meget nær fremtid. På en måde optræder du som entreprenør, og din kunde er ansvarlig for alle detaljerne i specifikationen.

Da dette scenarie kræver iteration af et eksisterende produkt, er der stor sandsynlighed for, at du ender med en meget specifik idé, som du helt sikkert kan implementere.

Der er imidlertid flere problemer med denne fremgangsmåde:

• Det, som din kunde fortæller dig om deres produktstrategi, fortæller de sandsynligvis også til dine konkurrenter, og et centralt mål med projektet er sandsynligvis at lave noget, der er billigere end den eksisterende løsning. Du vil finde dig selv i en priskrig.
• Din kunde er allerede indstillet på en type løsning, baseret på hvad de har købt før, hvilket gør det svært at foreslå noget, der måske bedre opfylder deres behov.
• Den tidsplan er sandsynligvis ekstremt aggressiv, hvilket giver ringe mulighed for at bygge noget nyt, eller giver mulighed for ægte innovation.
• Din kunde er måske ikke bekendt med nye teknologier, eller de ved måske bare ikke, hvad de har brug for.

I dette tilfælde er du afhængig af, at din kunde oversætter sine interne krav til en specifikation til dig, i stedet for at du skriver krav til et produkt, som det bredere marked har brug for og vil købe.

Når du udvikler produktet, vil dit team uundgåeligt være nødt til at foretage afvejninger af forskellige årsager. Den eneste måde at være sikker på, at det bedste valg er truffet, er at gennemgå ændringer i den resulterende produktspecifikation med din kunde. Hvis du ikke gør det, risikerer du at bygge et produkt, som de ikke vil acceptere. Men da designteamet vil være under ekstremt pres for at gennemføre en aggressiv tidsplan, er der stor sandsynlighed for, at de vil foretage produktvalg uden at have alle de bedste oplysninger. Dette øger yderligere risikoen for at bygge det forkerte produkt.

Denne fremgangsmåde fungerer, idet der leveres et produkt. Hvis du er i gang med at levere råvarekomponenter, så er det fint. Hvis du er på udkig efter en unik løsning, der forsvarer bruttomarginen, så er dette ikke den bedste tilgang.

RELATERET POST: Sådan udfører du en bedre konsekvensanalyse af opstrøms- og nedstrømsrelationer

2. Få en ingeniør til at skrive hele specifikationen

Et andet almindeligt scenarie er et, hvor en ingeniør eller et andet kundevendt teammedlem forestiller sig en løsning baseret på samtaler, de har haft med en eller et par kunder. Teamet samler sig om denne idé, og med et sus af intern fremdrift bliver kravene hurtigt dokumenteret, og teamets indsats går hurtigt over til at skrive produktspecifikationerne og udvikle løsningen.

Når en løsning er færdig og klar til at gå på markedet, vil nogle teams validere deres idé med kunderne, men da teamet præsenterer en løsning – og ikke udforsker et behov – har diskussionen tendens til at dreje sig om detaljer i produktspecifikationen. Disse teams vil ikke have mulighed for at finde ud af, om løsningen løser et problem.

Typisk set kommer produktkravene i dette scenario direkte fra en enkelt persons hoved, og de bliver derefter registreret i et langt specifikationsark, og resten af teamet handler ved hjælp af den dokumenterede specifikation. Hver gang teamet støder på en konflikt, hvor der skal foretages en afvejning, skal den person, der har skrevet kravene, selvstændigt træffe de korrekte afvejninger med få eller ingen nye oplysninger. Hvis denne person desuden ikke har undersøgt eller valideret kravene, vil teamet bygge det forkerte produkt.

Hvorfor disse fremgangsmåder ikke fører til succes

Det, som begge de foregående fremgangsmåder har til fælles, er, at fokus er på at nå frem til en færdig produktspecifikation så hurtigt som muligt. Holdene har så travlt med at komme i gang med at bygge noget og overholde kundens deadline, at de ikke først sikrer sig, at det er det rigtige noget.

Dertil kommer, at kendskabet til kravene kun findes hos én person på holdet. Denne person er enten den person, der står i kontakt med sponsorkunden, eller det er den person, der kom med produktidéen. I begge tilfælde mangler resten af teamet en kontekst for løsningen, hvorfor de bygger dette produkt, og kan derfor ikke komme med anbefalinger.

Resultatet er ofte, at produkterne bliver dræbt senere, end de burde, efter at der er spildt meget tid og penge, eller at teamene skaber produkter, der ikke er vellykkede, eller me-too produkter, der i høj grad konkurrerer på prisen. Intet af dette er godt for forretningen.

RELATERET POST: 8 Do’s and Don’ts for Writing Requirements

De bedste måder at skabe en produktspecifikation på:

Den bedste måde at skabe produkter, som dine kunder vil købe, er at komme ud og tale med dit målmarked, længe før du begynder at skrive din specifikation. Først skal du formulere din problemformulering.

En produktproblemformulering er et par sætninger eller afsnit, der beskriver et behov på markedet. De er skrevet ud fra perspektivet af den persona, der har problemet, og – dette er afgørende – de siger intet om, hvordan man rent faktisk løser problemet. Målet med denne fase i udforskningen er at formidle en forståelse af problemet og en følelse af den værdi, der er forbundet med at løse det.

En problemstilling består generelt af tre dele:

1. Den første er personaen, eller en beskrivelse af, hvem der har problemet. Det er nyttigt at beskrive personaen meget detaljeret separat og derefter henvise til en bestemt persona i problemformuleringen for at undgå at gentage den samme personabeskrivelse.
2. Det næste er en beskrivelse af problemet. Jo mere detaljeret, jo bedre her. Du ønsker at sikre dig, at behovet er krystalklart. Giv også problemet et navn. Det gør det lettere for teamene at henvise til det i løbet af projektet.
3. Slutteligt skal du skrive en beskrivelse af, hvor ofte problemet opstår. Hvis problemet forekommer sjældent og har en lille indvirkning, er det af ringe værdi at løse det. Hvis problemet forekommer ofte og har stor betydning, vil værdien af at løse det være høj.

Du kan starte med at spørge kunderne, hvilke problemer de har, som de mener, at du kan løse, men du skal grave dybere for at komme frem til de virkelig værdifulde problemformuleringer eller guldkorn. Disse guldkorn kommer som regel ved at udvikle en dyb forståelse af markedet og samle oplysninger fra en lang række kilder.

Hvis du gør dette med succes, ender du med at identificere et problem, som du kan løse, og som din kunde vil betale for.

Undervejs i processen skal du være opmærksom på, at du ikke løber ind i falske positiver eller negativer. Hvis du lytter for meget til folk i din virksomhed eller kun til et lille antal kunder, kan det føre til, at du fejlagtigt validerer eller opgiver et problem. Tal med så mange kunder som muligt og indsaml så mange data som muligt.

Lad os gå tilbage til vores diagram over alle mulige produkter, som vi kan bygge.

Denne gang har vi tilføjet krydsende linjer, der repræsenterer begrænsninger. Hvis vi tænker på problemformuleringer som linjer, der krydser cirklen, vil en god problemformulering, der er baseret på markedsforståelse, afgrænse et område i cirklen, der repræsenterer alle de acceptable løsninger. Alt, hvad der ligger inden for dette område, løser problemet og vil være acceptabelt for kunden.

Du vil bemærke, at størrelsen af dette område er langt større end de tidligere RFQ- og produktidee-cirkler. Det skyldes, at disse problemformuleringer og konteksten bevidst har afgrænset løsningen så løst som muligt for at give plads til nye idéer.

Det er tanken at give designteamet maksimal fleksibilitet til at skabe den mest innovative løsning, der er mulig inden for de givne begrænsninger.

RELATERET POST: Checkliste: Valg af et værktøj til kravstyring

Hvordan kommer du frem til en endelig problemformulering?

Her er mine anbefalinger:

1. Start med at tildele en person til hvert projekt ansvaret for at være kundens stemme.
2. Dernæst skal du give denne person til opgave at identificere markedsproblemerne udelukkende på baggrund af oplysninger indsamlet fra markedet.
3. Sørg for, at disse markedsproblemer dokumenteres og deles et sted, som hele teamet har adgang til.
4. Skriv en begrundelse ned for hver markedsproblemopgørelse, der forklarer, hvorfor det er et problem, og hvor vigtigt det er at løse
5. Føj en milepæl i projektplanen, hvor problemopgørelserne skal gennemgås og godkendes af teamet sammen med en business case.
6. Når teamet begynder at udvikle en løsning, skal du med jævne mellemrum vende tilbage til listen over problemformuleringer for at minde alle om, hvad målet er.
7. Fang for hvert problem en liste over de produktfunktioner, der skal løse problemet.
8. Hvis et problem ikke kan løses fuldt ud, skal du genoverveje business casen for at sikre, at produktet stadig er levedygtigt.

Fra problemstilling til specifikation

Nu, hvor du har dine problemstillinger, og teamet er blevet bekendt med dem, skal du i samarbejde begynde at udvikle en produktspecifikation. Da alle i teamet forstår det problem, der skal løses, kan alle bidrage til specifikationen.

Da du har gjort det indledende arbejde med at identificere det problem, du skal løse, inden for identificerede begrænsninger, og dit team har overvejet flere måder at levere løsningen på, har du nok information til at skrive produktspecifikationen.

Giv produktspecifikationen ud i små bidder

Den bedste fremgangsmåde her er at frigive små bidder af specifikationen til teamet så tidligt som muligt for at få hurtig feedback. På den måde undgår du at spilde tid på at gå den forkerte vej, og det vil gøre det meget lettere for teamet at give feedback af høj kvalitet.

Er du ikke overbevist? Overvej dette: Hvad sker der, hvis du modtager et 200 siders specifikationsark til gennemsyn? Du kigger sandsynligvis på de første par sider og skimmer derefter resten.

Hvad sker der nu, hvis du modtager et dokument på én side? Du gennemgår sandsynligvis hele dokumentet. To hundrede dokumenter på én side vil resultere i meget bedre feedback end et enkelt dokument på 200 sider.

Referer til problemformuleringen for at sikre, at du er på rette spor

Så snart du udvikler specifikationen, skal du også tjekke tilbage for at sikre, at produktet stadig er en gyldig løsning på problemet. Det er let at blive fanget i den afvejning, der er forbundet med at udvikle et produkt, og glemme at kontrollere, om du stadig er på rette vej.

Denne tilgang håndterer også dine interessenters forventninger. Da processen er kontrolleret, er der en ramme og gennemsigtighed, der forhindrer, at nogen kan tilsidesætte beslutninger. På ethvert tidspunkt i projektet vil du være i stand til at forklare præcis, hvilken værdi dit produkt tilbyder, og hvorfor det skal have de funktioner, som teamet har specificeret.

Design af produkter til markedets behov er afgørende for succes

Jeg erkender, at det i nogle brancher er en stor ændring i forhold til, hvordan produkter hidtil er blevet designet og bygget. Men efterhånden som markederne bliver mere konkurrenceprægede, og produkterne bliver mere og mere komplekse, er det ikke længere nok at levere endnu en iteration af noget, du har bygget før, til at holde dig i gang.

For at lære mere om, hvordan du skriver krav på en sådan måde, at alle interessenter har en klar forståelse af udviklingsbehovene, kan du downloade vores e-bog, Best Practices for Writing Requirements.

LÆS EBOOKEN