De beste en slechtste manier om een productspecificatie op te stellen

Een van de grootste uitdagingen voor productontwikkelingsteams is eenvoudigweg hoe te beslissen welk product moet worden gebouwd. In het geval van teams die werken op basis van een productspecificatie, met name bij de ontwikkeling van hardware, mogen technici doorgaans pas aan de slag als de specificatie is voltooid en goedgekeurd. En aangezien de meeste tijdlijnen voor ontwikkeling ongelooflijk kort zijn, is er vaak niet genoeg tijd om alternatieve oplossingen te overwegen zodra nieuwe informatie in beeld komt.

Een manier om naar deze uitdaging te kijken, wordt hier getoond. U kunt zich voorstellen dat de cirkel alle mogelijke manieren weergeeft waarop het team het product zou kunnen bouwen. En dat kleine blauwe puntje is de specificatie voor één bepaald product. Deze productspecificatie definieert precies op welk product de ontwikkelaars zich moeten richten en het moeten bouwen.

In dit bericht zal ik eerst enkele veelgebruikte methoden beschrijven die worden gebruikt om overeenstemming te bereiken over een productspecificatie. Daarna zal ik de problemen met die methoden verkennen en hoe ze kunnen leiden tot het bouwen van producten op basis van een spec die de problemen van uw klant niet echt oplost.

Ik moet zeggen dat mijn perspectief voortkomt uit 10 jaar ervaring met het werken in de analoge en mixed-signal halfgeleiderindustrie, eerst als een applicatie-ingenieur en later als een productdefinitie. Nu ben ik consultant hier bij Jama.

Slechtste manieren om een productspecificatie te maken:

Vraag uw klant wat zij willen dat u bouwt

Eén manier om te beginnen is om uw klanten te vragen wat zij nodig hebben. Dit kan worden gedaan door te wachten op een verzoek om prijsopgave (RFQ) van de klant, of minder formeel, door middel van vergaderingen en discussies. Typisch wat u met deze aanpak te weten komt, is welke oplossing of product ze vandaag gebruiken en wat ze graag veranderd zouden zien in de zeer nabije toekomst. In zekere zin treedt u op als een aannemer en is uw klant verantwoordelijk voor alle details van de specificatie.

Gezien het feit dat dit scenario vraagt om iteratie op een bestaand product, is de kans groot dat u zult eindigen met een zeer specifiek idee dat u zeker kunt implementeren.

Echter, er zijn verschillende problemen met deze aanpak:

Wat uw klant u vertelt over hun productstrategie vertellen ze waarschijnlijk ook aan uw concurrentie, en een belangrijk doel van het project is waarschijnlijk om iets goedkoper te maken dan de bestaande oplossing. U zult zich in een prijzenoorlog bevinden.
Uw klant is al ingesteld op een type oplossing, gebaseerd op wat hij eerder heeft gekocht, wat het moeilijk maakt om iets voor te stellen dat beter aan zijn behoeften voldoet.
De planning is waarschijnlijk extreem agressief, waardoor er weinig gelegenheid is om iets nieuws te bouwen, of echte innovatie mogelijk te maken.
Uw klant is zich misschien niet bewust van nieuwe technologieën, of ze weten gewoon niet wat ze nodig hebben.

In dit geval vertrouwt u op uw klant om zijn interne eisen te vertalen in een specificatie voor u, in plaats van dat u eisen schrijft voor een product dat de bredere markt nodig heeft en zal kopen.

Tijdens de ontwikkeling van het product zal uw team om verschillende redenen onvermijdelijk afwegingen moeten maken. De enige manier om er zeker van te zijn dat de beste keuze wordt gemaakt, is om de wijzigingen in de resulterende productspec met uw klant door te nemen. Doet u dat niet, dan loopt u het risico dat u een product bouwt dat zij niet zullen accepteren. Maar omdat het ontwerpteam onder extreme druk zal staan om een agressief schema uit te voeren, is de kans groot dat zij productafwegingen zullen maken zonder over de beste informatie te beschikken. Dit verhoogt nog het risico dat het verkeerde product wordt gebouwd.

Deze aanpak werkt in die zin dat een product wordt geleverd. Als u zich bezighoudt met het leveren van commodity-componenten, dan is dit prima. Als u op zoek bent naar een unieke oplossing die de brutomarge verdedigt, dan is dit niet de beste aanpak.

GERELATEERDE POST: How to Perform Better Impact Analysis on Upstream and Downstream Relationships

2. Have an Engineer Write the Entire Spec

Een ander veelvoorkomend scenario is dat een engineer, of een ander klantgericht teamlid, een oplossing voor ogen heeft op basis van gesprekken die hij of zij met een of enkele klanten heeft gehad. Het team schaart zich achter dit idee en in een stroomversnelling van interne opwinding worden de vereisten snel gedocumenteerd en stort het team zich op het schrijven van de productspecificaties en het ontwikkelen van de oplossing.

Als een oplossing eenmaal is voltooid en klaar is om op de markt te worden gebracht, valideren sommige teams hun idee bij klanten, maar omdat het team een oplossing presenteert – en niet een behoefte onderzoekt – gaat de discussie meestal over details in de productspecificaties. Deze teams hebben niet de mogelijkheid om uit te vinden of de oplossing een probleem oplost.

Typisch, in dit scenario, komen de producteisen rechtstreeks uit het hoofd van één individu en worden dan vastgelegd in een lange spec sheet, en de rest van het team handelt met behulp van de gedocumenteerde specificatie. Elke keer als het team in een conflict komt waarbij een afweging moet worden gemaakt, moet de persoon die de requirements heeft opgesteld zelfstandig de juiste afweging maken, met weinig of geen nieuwe informatie. Bovendien, als die persoon de eisen niet heeft onderzocht of gevalideerd, dan zal het team het verkeerde product bouwen.

Waarom deze benaderingen niet tot succes leiden

Wat beide vorige benaderingen gemeen hebben, is dat de focus ligt op het zo snel mogelijk bereiken van een afgewerkte productspecificatie. Teams hebben zo’n haast om te beginnen met het bouwen van iets en de deadline van de klant te halen, dat ze er niet eerst voor zorgen dat het iets het juiste iets is.

Daar komt bij dat de kennis van de eisen bestaat bij slechts één individu in het team. Dat individu is ofwel de persoon die interfacing met de sponsor klant, of het is de persoon die kwam met het product idee. In beide gevallen mist de rest van het team elke context voor de oplossing, de reden waarom ze dit product bouwen, en kan daarom geen aanbevelingen doen.

Het resultaat is vaak dat producten later sneuvelen dan zou moeten, nadat veel tijd en geld is verspild, of dat teams producten maken die niet succesvol zijn of me-too-producten die grotendeels op prijs concurreren. Geen van deze zaken is goed voor de zaken.

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

De beste manieren om een productspecificatie te maken:

De beste manier om producten te bouwen die uw klanten zullen kopen, is om er op uit te gaan en met uw doelmarkt te praten lang voordat u begint met het schrijven van uw specificatie. Eerst moet u uw probleemverklaring articuleren.

Een productprobleemverklaring is een paar zinnen of alinea’s die een marktbehoefte beschrijven. Ze zijn geschreven vanuit het perspectief van de persona die het probleem heeft en – dit is van cruciaal belang – zeggen niets over hoe het probleem daadwerkelijk moet worden opgelost. Het doel van deze fase in de verkenning is om een begrip van het probleem over te brengen en een gevoel van de waarde die wordt geassocieerd met het oplossen ervan.

Een probleemverklaring bestaat over het algemeen uit drie delen:

De eerste is de persona, of een beschrijving van wie het probleem heeft. Het is nuttig om de persona in groot detail afzonderlijk te beschrijven en dan naar een bepaalde persona in de probleemverklaring te verwijzen om te voorkomen dat dezelfde persona-beschrijving wordt herhaald.
Volgende is een beschrijving van het probleem. Hoe gedetailleerder, hoe beter. U wilt er zeker van zijn dat de behoefte kristalhelder is. Geef het probleem ook een naam. Dit maakt het voor teams gemakkelijker om er tijdens het project naar terug te verwijzen.
Ten slotte schrijf je een beschrijving van hoe vaak het probleem zich voordoet. Als het probleem zich zelden voordoet en weinig impact heeft, dan is het oplossen ervan van weinig waarde. Als het probleem zich vaak voordoet en een hoge impact heeft, dan zal de waarde van het oplossen ervan hoog zijn.

U kunt beginnen met klanten te vragen welke problemen zij hebben waarvan zij denken dat u ze kunt oplossen, maar u moet dieper graven om bij de echt waardevolle probleemverklaringen of golden nuggets te komen. Deze gouden nuggets komen over het algemeen voort uit het ontwikkelen van een diep begrip van de markt en het samenvoegen van informatie uit een breed scala van bronnen.

Als u dit met succes doet, zult u uiteindelijk een probleem identificeren dat u kunt oplossen en waarvoor uw klant wil betalen.

Tijdens het proces moet u oppassen dat u niet tegen valse positieven of negatieven aanloopt. Te veel luisteren naar mensen binnen uw bedrijf of slechts naar een klein aantal klanten kan ertoe leiden dat u een probleem ten onrechte valideert of laat varen. Praat met zoveel mogelijk klanten en verzamel zoveel mogelijk gegevens.

Laten we teruggaan naar ons diagram van alle mogelijke producten die we kunnen bouwen.

Deze keer hebben we kruisende lijnen toegevoegd die beperkingen vertegenwoordigen. Als we probleemverklaringen zien als lijnen die de cirkel doorkruisen, dan zal een goede probleemverklaring, gebaseerd op inzicht in de markt, een gebied in de cirkel afbakenen dat alle aanvaardbare oplossingen weergeeft. Alles in dit gebied lost het probleem op en zou aanvaardbaar zijn voor de klant.

U zult merken dat de grootte van dit gebied veel groter is dan de vorige RFQ en productidee cirkels. Dit komt omdat deze probleemverklaringen en context opzettelijk de oplossing zo losjes mogelijk afbakenen, zodat nieuwe ideeën naar voren kunnen komen.

Het idee is om het ontwerpteam maximale flexibiliteit te geven bij het creëren van de meest innovatieve oplossing mogelijk binnen de beperkingen.

GELATEERDE POST: Checklist: Selecting a Requirements Management Tool

Hoe kom je tot een Final Problem Statement?

Hier zijn mijn aanbevelingen:

Start met het toewijzen van iemand voor elk project die verantwoordelijk is voor het zijn van de stem van de klant.
Volgende, belast die persoon met het identificeren van de marktproblemen uitsluitend gebaseerd op informatie verzameld uit de markt.
Zorg ervoor dat deze marktproblemen worden gedocumenteerd en gedeeld op een plaats waar het hele team toegang toe heeft.
Schrijf een rechtvaardiging op voor elke marktprobleemverklaring die uitlegt waarom het een probleem is en hoe belangrijk het is om op te lossen
Voeg een mijlpaal in het projectplan toe waar de probleemverklaringen moeten worden beoordeeld en goedgekeurd door het team, samen met een business case.
Terwijl het team begint met het ontwikkelen van een oplossing, keer dan periodiek terug naar de lijst van probleemverklaringen om iedereen eraan te herinneren wat het doel is.
Voor elk probleem, leg een lijst vast van de producteigenschappen die het probleem zullen oplossen.
Als een probleem niet volledig kan worden opgelost, herzie dan de business case om ervoor te zorgen dat het product nog steeds levensvatbaar is.

Van probleemstelling naar specificatie

Nu u uw probleemstellingen hebt en het team ermee vertrouwd is geraakt, begint u gezamenlijk een productspecificatie te ontwikkelen. Aangezien iedereen in het team het probleem begrijpt dat wordt opgelost, kan iedereen bijdragen aan de specificatie.

Omdat u het werk vooraf hebt gedaan om het probleem te identificeren dat u oplost, binnen de vastgestelde beperkingen, en uw team meerdere manieren heeft overwogen om de oplossing te leveren, beschikt u over voldoende informatie om de productspecificatie te schrijven.

Release the Product Specification in Small Batches

De beste aanpak hier is om kleine stukjes van de specificatie zo vroeg mogelijk aan het team vrij te geven om snel feedback te krijgen. Dit helpt om geen tijd te verspillen door de verkeerde weg in te slaan en maakt het voor het team veel gemakkelijker om feedback van hoge kwaliteit te geven.

Niet overtuigd? Denk hier eens over na: Wat gebeurt er als u een specificatieblad van 200 pagina’s ontvangt om te beoordelen? U bekijkt waarschijnlijk de eerste paar pagina’s en bladert de rest door.

Nou, wat gebeurt er als u een document van één pagina ontvangt? U bekijkt het waarschijnlijk in zijn geheel. Tweehonderd documenten van één pagina leveren veel betere feedback op dan één document van 200 pagina’s.

Refer to the Problem Statement to Ensure You’re on Track

Ook tijdens de ontwikkeling van de specificatie moet u controleren of het product nog steeds een geldige oplossing voor het probleem is. Het is gemakkelijk om verstrikt te raken in de afweging die inherent is aan het ontwikkelen van een product en te vergeten om te controleren of u nog steeds op schema ligt.

Deze aanpak beheert ook de verwachtingen van uw belanghebbenden. Omdat het proces wordt beheerst, is er een kader en transparantie dat voorkomt dat iemand beslissingen kan overrulen. Op elk moment in het project kunt u precies uitleggen welke waarde uw product biedt en waarom het de functies moet hebben die het team heeft gespecificeerd.

Producten ontwerpen op basis van de marktbehoeften is essentieel voor succes

Ik erken dat dit in sommige industrieën een grote verandering is ten opzichte van de manier waarop producten tot nu toe werden ontworpen en gebouwd. Maar naarmate de markten concurrerender worden en de producten complexer, zal het leveren van een nieuwe iteratie van iets dat u eerder hebt gebouwd, u niet lang in de business houden.

Om meer te weten te komen over hoe u requirements zo kunt schrijven dat alle belanghebbenden een duidelijk begrip hebben van de ontwikkelingsbehoeften, download ons eBook, Best Practices for Writing Requirements.

READ THE EBOOK