Het ontwikkelen van een nieuw product vergt veel tijd, aandacht en dus geld. Daarnaast kent het proces onzekerheden en risico’s. Het is daarom niet vreemd dat bedrijven en ondernemers zoeken naar mogelijkheden om een ontwikkelproces zo kort mogelijk te houden. Ze zijn gedreven door een wens om de kosten te beperken of om een ambitieuze time to market te realiseren. Daarnaast is het wenselijk om zo snel mogelijk naar de markt te gaan met een werkend product. Op die manier kan de markt worden gevalideerd met een MVP (Minimum Viable Product).
De ambitie om tijd en kosten te besparen is logisch. Maar een te grote nadruk hierop in de beginfase van een ontwikkelproject, kan leiden tot ongewenste risico’s. Het risico bestaat dat tijdens de beginfase in een ontwikkelproces stappen worden overgeslagen. Dit heeft verderop in het ontwikkelproces gevolgen die juist hogere kosten en langere doorlooptijden tot gevolg hebben. Daarom is het cruciaal om, zeker ook wanneer de doorlooptijd van belang is, een goede en volledige definitiefase uit te voeren.
In de definitiefase worden ideeën en concepten van mensen met klant- en marktkennis, overgedragen aan mensen met technische kennis. Het doel is om deze ideeën en concepten op zo’n te manier vertalen dat er een succesvol product gemaakt kan worden. Wordt deze fase succesvol uitgevoerd, dan pluk je daar later de vruchten van: de vervolgfasen kunnen op tempo worden uitgevoerd en de kans op kostbare vertragingen wordt sterk verminderd. Maar hoe doorloop je deze fase succesvol?
Met deze 4 tips zorg je voor een goede definitiefase en geef je je een ontwikkelproject een grote kans van slagen!
1. Take your time to go fast
2. Communiceerbaar maken
3. Ideeën en concepten concreet en valideerbaar maken
4. Werk samen
Het principe ‘take your time to go fast’ moet tijdens de definitiefase het mantra zijn. Dit vraagt om een projectmanager die stevig in de schoenen staat. Een goede projectmanager neemt de klant mee en weerstaat de druk om stappen over te slaan. Aan de andere kant is het de taak van de projectmanager om ook de betrokken teamleden te motiveren om lastige vragen te stellen en voldoende detailniveau te onderzoeken. Zowel de markt en klantgerichte betrokkenen als engineers kunnen de neiging hebben aannames te doen (“Het is toch wel duidelijk?” / “Ik begrijp wat je bedoelt”) en details over te slaan. Daarnaast zijn deze teamleden, veelal door de opdrachtgever, beïnvloedbaar door druk op tijd en budget. Een goede projectmanager beseft dat het zijn of haar opdracht is om een succesvol eindproduct op te leveren en niet om een fase zo snel mogelijk af te ronden.
De definitiefase gaat voor een groot gedeelte over het communiceerbaar maken van het productidee en de eisen en wensen. In deze fase worden gedachten en ideeën van de ene groep mensen overgebracht op de andere groep mensen. En wel op een manier dat deze beklijven en gedurende het project geraadpleegd kunnen worden. De gedachten en ideeën moeten goed begrepen en doorleefd worden. Hiervoor zijn creatieve sessies en workshops nodig waarin zowel marketing, sales, service engineers etc, en de development engineers aanwezig zijn.
Daarnaast is het van belang dat de output concreet en gestructureerd wordt gedocumenteerd. Een goede product definitie bestaat uit:
• Een duidelijke beschrijving van de context van het product;
• Use cases en;
• Een opsomming van testbare requirements, bij voorkeur met een prioritering.
Om het productidee communiceerbaar en begrijpelijk te maken, zal dit zo concreet mogelijk moeten worden uitgewerkt. Alleen als dit goed gebeurt, zullen engineers in staat zijn te ontwerpen wat er verwacht wordt. Deze uitwerking bestaat minimaal uit de context, de requirements en use cases.
De context beschrijft het verhaal van het product en het bredere concept, waarom het een goed product is en wat voor waarde het biedt voor de gebruikers. Daarnaast is een uitleg van het business model waardevol om te begrijpen hoe er geld verdient gaat worden met het product. Ten slotte is het van belang om de grotere omgeving, waarbinnen het product moet werken, te omschrijven.
Use cases zijn beschrijvingen van scenario's hoe een gebruiker interacteert met het product. Het definiëren van use cases is een goed middel om vroegtijdig na te denken over de verschillende scenario’s die mogelijk zijn en hoe daarmee om te gaan. Het forceert de product owner om in detail de interactie met de gebruikers te beschrijven. Use cases geven heel veel context waarin en hoe een product gebruikt wordt. Dit is onmisbaar bij het ontwerpen van het systeemgedrag, met name als er menselijke interactie is (denk aan human machine interface (HMI)).
Vervolgens worden de functionele en niet-functionele eisen vastgelegd (requirements). Functionele eisen zeggen iets over wat het product moet kunnen en niet-functionele eisen zeggen waar het product aan moet voldoen. Het goed vastleggen van requirements is absoluut noodzakelijk. Ook is het belangrijk dat de requirements van goede kwaliteit zijn. Het is een valkuil om ‘alles’ te willen specificeren: dat is een een onhaalbaar doel. De kwaliteit van de requirements is belangrijker. Met goede requirements zullen engineers een ontwerp maken wat voldoet aan de verwachtingen. Op basis van goede requirements is het ook mogelijk om aan te tonen dat het ontwerp aan de eisen voldoet (verificatie).
Goede requirements voldoen in ieder geval aan de volgende punten:
• Er staat in een requirement nooit een oplossing. Er staat wat het product moet doen of waar het aan moet voldoen, nooit hoe het dat moet doen.
• Requirements zijn niet ambigue. Oftewel, concreet. Voorkom dat er mogelijkheden voor interpretatie en aannames in de requirement zitten. Impliciete aannames zijn de bron van falen!
• Per requirement wordt ook vastgelegd hoe deze requirement getest (geverifieerd) gaat worden. Een bijkomend voordeel van het vastleggen van een test per requirement, is dat het mogelijke aannames over de requirement voorkomt. De requirement wordt dus nog concreter.
• Een requirement is één requirement. Staan er twee in één zin, maak er dan twee requirements van.
Er zijn een aantal valkuilen en misvattingen als het om requirements gaat, zoals:
Het vastleggen van goede requirements is geen gemakkelijke taak en het vergt de aandacht van zowel product owners als engineers.
• Product owners denken soms te veel in termen van oplossingen, in plaats van eisen. Dit levert geen goede requirements op en beperkt de creativiteit van engineers. Hier geldt: schoenmaker, blijf bij je leest!
• Requirements worden soms benaderd als statisch en onwijzigbaar. Door deze benadering wordt het vastleggen van requirements nog moeilijker, zo niet onmogelijk. Datzelfde geldt als requirements de basis zijn voor commerciële afspraken. Requirements kunnen wijzigen gedurende het project, zolang dat maar volgens een goede procedure gaat.
De laatste tip: werk samen! Dit klinkt als een open deur, maar in de praktijk blijkt dat het niet te zijn. Dit terwijl het van grote invloed is op het succes van de definitiefase en dus het succes van het gehele project. In een ontwikkelproject zijn vaak mensen met verschillende achtergronden en expertises betrokken. Vooral in de definitiefase zullen deze mensen goed moeten samenwerken. Het doel is immers om de informatie vanuit de markt- en klantgerichte betrokkenen over te dragen aan het engineering team.
De verschillen in achtergrond, expertise en ervaring betekent ook dat betrokkenen op andere manieren naar de wereld kijken. Dit is de kracht van het multidisciplinaire team, maar direct ook het gevaar omdat het communicatie bemoeilijkt. Om een goede samenwerking tijdens de definitiefase mogelijk te maken, moet er een duidelijk gezamenlijk doel zijn en moet er een hoge mate van vertrouwen zijn binnen het team. Dit geldt voor teams samengesteld uit verschillende afdelingen binnen een bedrijf, maar zeker ook voor teams waarin een klant - leverancier relatie bestaat. In dit laatste geval is het van belang dat deze relatie de samenwerking niet in de weg staat. Het is ook hier de taak van de projectmanager om een goede samenwerking in het team te bewerkstelligen.
Kortom, een doordachte definitie is het fundament voor een succesvol product. Hierin ligt de verantwoordelijkheid bij het hele team, inclusief de opdrachtgever. Het is aan de projectmanager om dit in goede banen te leiden.
In het tweede deel van deze serie gaan we dieper in op het proces en de do’s en dont’s tijdens het hardware design proces:
Kwalitatief hardware design, deel 2: specificaties waarborgen