ProgrammaProgrammaProgramma vanvanvan eiseneiseneisen opstellenopstellenopstellen voorvoorvoor productontwikkelingproductontwikkelingproductontwikkeling: zo maak je eisen concreet en toetsbaar

Wat is een programma van eisen?

Een programma van eisen, vaak afgekort als PvE, is het document waarin je vastlegt waaraan een product moet voldoen.

Dat gaat niet alleen over techniek. Een goed PvE kan ook eisen bevatten over functionaliteit, gebruiksgemak, veiligheid, technische prestaties, productie, maakbaarheid, kosten, volumes, uitstraling, duurzaamheid en relevante wet- en regelgeving.

Bij Brisk werken we met een Programma van Eisen en Wensen: het PvE/W. Dat onderscheid is belangrijk. Niet alles is even hard. Sommige zaken zijn essentieel voor de kern van het product. Andere zaken versterken het concept, maar zijn niet bepalend voor de basis.

Een goed PvE/W helpt je dus niet alleen om eisen te formuleren, maar ook om prioriteit aan te brengen.

Waarom een goed programma van eisen belangrijk is

Een product ontwikkelen zonder scherp PvE lijkt in het begin vaak prima te gaan. Alles ligt nog open. Er is ruimte. Maar juist daar ontstaat vaak het probleem.

Zonder helder programma van eisen:

• gaat het ontwerp alle kanten op
• wil iedere stakeholder iets anders
• wordt feedback subjectief
• test je in prototypes vaak de verkeerde aannames
• moet engineering later terugrekenen wat eerder al duidelijk had moeten zijn

Een goed PvE/W voorkomt dat. Volgens de Brisk-richtlijnen maakt het klantwensen concreet, ontwerpkeuzes toetsbaar, bewaakt het ontwerpvrijheid en dwingt het tot keuzes.

Wat is een goede eis?

Een goede eis beschrijft wat het product moet kunnen of waar het aan moet voldoen.

Binnen Brisk geldt dat een goede eis:

• beschrijft wat het product moet kunnen of waar het aan moet voldoen
• functioneel is geformuleerd
• concreet genoeg is om ontwerpkeuzes aan te toetsen
• toetsbaar is waar mogelijk

Dat klinkt logisch, maar in de praktijk gaat het hier vaak mis.

Slechte formulering

Het product moet innovatief zijn.

Dat klinkt goed, maar je kunt er niets mee. Het zegt niet wat je moet ontwerpen, niet waarop je moet toetsen en niet wanneer het goed genoeg is.

Betere formulering

Het product moet zich functioneel onderscheiden van bestaande oplossingen binnen deze productcategorie.

Dat geeft richting zonder het ontwerp al dicht te timmeren.

Waarom vage eisen problemen veroorzaken

Vage eisen lijken handig omdat ze ruimte laten. In werkelijkheid zorgen ze vaak voor verwarring.

Neem formuleringen zoals:

• het product moet premium zijn
• het product moet gebruiksvriendelijk zijn
• het product moet duurzaam zijn
• het product moet onderscheidend zijn

Dit zijn geen ontwerpcriteria. Dit zijn containerbegrippen.

Pas als je ze vertaalt naar iets concreets, kun je ontwerpkeuzes maken.

Voorbeelden

Te vaag:
Het product moet premium zijn.

Concreter:
Het product moet qua materiaalgebruik, detaillering en afwerking aansluiten bij het hogere marktsegment.

Te vaag:
Het product moet gebruiksvriendelijk zijn.

Concreter:
Het product moet intuïtief te bedienen zijn zonder uitgebreide instructie of handleiding.

Te vaag:
Het product moet duurzaam zijn.

Concreter:
Het product moet ontworpen zijn voor een minimale levensduur van 15 jaar bij normaal gebruik en geschikt zijn voor reparatie of vervanging van slijtageonderdelen.

Daar zit het verschil. Niet in mooie taal, maar in bruikbare taal.

Het verschil tussen eisen en wensen

Een sterk product vraagt om prioriteit.

Daarom is het belangrijk om onderscheid te maken tussen eisen en wensen.

Eisen

Hier móét het product aan voldoen. Zonder deze eis vervalt de kernwaarde of functionaliteit van het product.

Wensen

Hier mág het product aan voldoen. Wensen versterken het concept, maar zijn niet essentieel voor de kernfunctie.

Die tweedeling lijkt simpel, maar is strategisch belangrijk.

Zodra alles een eis wordt, verlies je ontwerpvrijheid. Zodra alles een wens wordt, verlies je richting.

Juist de discussie over wat een eis is en wat een wens is, scherpt de basis van het ontwerp aan.

Formuleer geen oplossingen als eisen

Dit is een van de meest gemaakte fouten in productontwikkeling.

Veel teams denken dat ze een eis formuleren, terwijl ze in werkelijkheid al een oplossing vastzetten.

Bijvoorbeeld:

• het product moet een scharnier bevatten
• het product moet een app hebben
• het product moet Bluetooth bevatten

Dat zijn niet automatisch goede eisen.

Vaak ligt daar een onderliggende functionele behoefte onder, zoals:

• het product moet eenvoudig met één hand te openen zijn
• de gebruiker moet instellingen en data op afstand kunnen beheren
• het product moet draadloos kunnen communiceren met externe apparaten

Dat verschil is essentieel.

Zodra je te vroeg een oplossing als eis formuleert, sluit je andere, mogelijk betere richtingen uit voordat ze zijn onderzocht.

Binnen Brisk wordt een oplossing alleen als eis opgenomen wanneer die technisch onvermijdelijk is, wettelijk verplicht is, commercieel vastligt, onderdeel is van branding of positionering, bestaande tooling of infrastructuur dit vereist, of er al strategische besluitvorming over heeft plaatsgevonden.

Een programma van eisen moet toetsbaar zijn

Niet elke eis hoeft volledig in cijfers vast te liggen, maar een eis moet wel concreet genoeg zijn om ontwerpkeuzes te beoordelen.

Dat betekent dat je ermee moet kunnen:

• toetsen
• afwegen
• discussiëren
• valideren

“Het product moet gebruiksvriendelijk zijn” is te vaag.

“Het product moet eenvoudig met één hand te openen zijn” is al veel bruikbaarder, omdat je daar direct iets mee kunt in conceptontwikkeling, prototyping en testen.

Een goede vuistregel is simpel: als een eis niet richtinggevend is voor ontwerpkeuzes, hoort hij niet in je programma van eisen.

Tegenstrijdige eisen zijn waardevolle input

Botsende eisen lijken een probleem, maar zijn vaak juist waardevolle ontwerpinput.

Een product kan bijvoorbeeld:

• lichtgewicht moeten zijn
• en tegelijk extreem robuust

Dat botst. Maar juist die spanning maakt zichtbaar waar de echte ontwerpbeslissingen zitten.

Uiteindelijk moeten zulke tegenstrijdigheden wel worden opgelost, maar in een vroeg stadium helpen ze om de juiste gesprekken te voeren en prioriteiten helder te krijgen. Ook dat is expliciet onderdeel van de Brisk-richtlijnen.

Een goed PvE/W is dus niet alleen een lijst. Het is ook een afwegingskader.

Waarop baseer je een goed programma van eisen?

Een sterk programma van eisen ontstaat niet uit losse meningen.

Bij Brisk wordt het PvE/W opgebouwd op basis van:

• het probleem
• de eindgebruiker
• het gebruikersritueel
• de uitdagingen per stap

Dat is belangrijk, want een goede eis komt voort uit context.

Niet:
het product moet compact zijn.

Maar bijvoorbeeld:
het product moet compact op te bergen zijn zodat het in de laadruimte van een volgeladen schildersbus past. Dat soort formuleringen zie je ook terug in jullie projectdocumentatie.

Een goede eis komt dus niet uit de lucht vallen. Hij komt voort uit gebruik, observatie en doel.

Voorbeelden van goede eisen in productontwikkeling

Te vaag

Het product moet zo klein mogelijk zijn.

Beter

Het product moet binnen de volgende maximale afmetingen passen: 10 x 20 x 35 mm.
Of: het product moet binnen de aangeleverde behuizing passen.

Te vaag

Het product moet geschikt zijn voor iedereen.

Beter

Het product moet geschikt zijn voor de gedefinieerde primaire doelgroep. Bijvoorbeeld: schilders.

Te vaag

Het product moet onverwoestbaar zijn.

Beter

Het product moet bestand zijn tegen normaal dagelijks gebruik, inclusief vallen vanaf 0,7 meter.

Te vaag

Het product moet onder 20 euro kostprijs blijven.

Beter

De target kostprijs voor serieproductie bedraagt maximaal 20 euro per stuk bij 5000 stuks.

Zo verschuif je van wensdenken naar ontwerpcriteria.

Hoe een goed PvE/W het ontwikkeltraject sterker maakt

Een programma van eisen staat niet op zichzelf. Het werkt door in de rest van het traject.

Een goed PvE/W:

• geeft richting aan conceptontwikkeling
• maakt het makkelijker om een sterke conceptrichting te kiezen
• bepaalt wat je wel en niet test in een prototype
• helpt engineering om technisch onderbouwde keuzes te maken
• voorkomt dat je later terug moet naar discussies uit het begin

In de Brisk-werkwijze vormt het PvE/W de basis voor de ontwerpfase. Het Hero Concept moet ermee in lijn zijn. Alleen dan zijn uiteindelijke ontwerpkeuzes ook echt valideerbaar.

Daarmee is het PvE/W geen formaliteit, maar een van de belangrijkste stuurdocumenten in productontwikkeling.

Hoe Brisk hiermee werkt

Bij Brisk stellen we een programma van eisen niet op in isolatie.

We gebruiken het als vertaling van:

• het probleem dat opgelost moet worden
• de eindgebruiker voor wie we ontwerpen
• de praktijkcontext waarin het product gebruikt wordt
• de fricties en risico’s die daaruit volgen

Vervolgens maken we formuleringen concreter, signaleren we spanningsvelden, vertalen we oplossingen terug naar onderliggende eisen en zorgen we dat het Hero Concept later ook echt te valideren is. Dat is ook precies de rol die Brisk intern voor zichzelf definieert in het PvE/W-proces.

Dat zorgt voor een stevigere basis, minder ruis en betere keuzes verderop in het traject.

Conclusie

Een goed programma van eisen maakt productontwikkeling niet trager, maar scherper.

Het voorkomt dat je ontwerpt op losse ideeën. Het helpt om eisen en wensen uit elkaar te trekken. Het bewaakt ontwerpvrijheid zonder richting te verliezen. En het zorgt ervoor dat concepten, prototypes en engineering niet gebouwd worden op aannames, maar op een heldere basis.

De kwaliteit van je product hangt zelden alleen af van één slim idee. Veel vaker hangt die af van hoe scherp je in het begin definieert waar het product aan moet voldoen.

Een sterk product begint dus niet met vorm.

Een sterk product begint met een goed programma van eisen.

Veelgestelde vragen

Wat is het verschil tussen een programma van eisen en een programma van wensen?

Een eis is iets waar het product aan móét voldoen. Een wens is iets dat het product mág versterken, maar niet essentieel is voor de kernfunctie.

Waarom is een programma van eisen belangrijk in productontwikkeling?

Omdat het ontwerpkeuzes toetsbaar maakt, richting geeft aan conceptontwikkeling en voorkomt dat later kostbare herontwerpen nodig zijn.

Hoe formuleer je een goede eis?

Een goede eis is functioneel geformuleerd, concreet genoeg om keuzes aan te toetsen en waar mogelijk toetsbaar.

Mag je oplossingen opnemen in een programma van eisen?

Alleen als die oplossing technisch, wettelijk, commercieel of strategisch al vastligt. Anders formuleer je beter eerst de onderliggende eis.

Wanneer is een eis te vaag?

Als hij niet helpt om ontwerpkeuzes te maken of te beoordelen. Termen als innovatief, premium of gebruiksvriendelijk zijn zonder verdere uitwerking meestal te vaag.

Wil je je programma van eisen aanscherpen?

Wil je scherper krijgen waar jouw product echt aan moet voldoen? We helpen je graag om probleem, gebruiker en randvoorwaarden te vertalen naar een concreet programma van eisen.