Een van de eerste fasen in de ontwikkeling van een nieuwe tool (software of hardware) is een functionele specificatie. De functionele specificatie rijpt in discussies tussen de ontwikkelaars (afdeling R&D) en de vertegenwoordigers van de klant (vaak de afdelingen marketing en verkoop).
Natuurlijk is een functionele specificatie handig: het is erg moeilijk om iets nieuws te ontwikkelen zonder een idee te hebben van hoe de nieuwe tool zal worden gebruikt en waarmee deze zal worden vergeleken. Het definiëren van een functionele specificatie kan echter ook te ver gaan. In sommige organisaties zijn de functionele specificaties tot in de kleinste details uitgewerkt. Aan het einde van een lange formele procedure wordt het bestekboek ondertekend als een contract tussen marketing en ontwikkeling. De ontwikkeling kan pas worden gestart als de lijst met handtekeningen compleet is en zal worden uitgevoerd in complete afzondering van de wereld van potentiële gebruikers. Waarom maken organisaties hun specificaties op deze manier? Het is vaak een poging om de verantwoordelijkheden van de afdelingen te scheiden, zodat als er iets niet lukt de juiste partij de schuld krijgt. Als het eindproduct niet voldoet aan de functionele specificaties, kan dit worden toegeschreven aan de ontwikkelaars. En als het product niet slaagt terwijl het wel aan alle functionele specificaties voldoet, wordt dat aan de marketing toegeschreven.
Ik heb een serieus probleem met deze benadering: hoe kan men er met behulp van deze procedure voor zorgen dat het product nuttig zal zijn? Na twee jaar zonder interactie kan ontwikkeling precies opleveren waar marketing om vroeg (alle deadlines halen en binnen budget), maar de markt is veranderd en heeft het ontworpen product niet meer nodig. Of de techniek is veranderd, en betere specificaties zouden binnen handbereik zijn geweest en worden aangeboden door de concurrentie. Of misschien heeft marketing echt een fout gemaakt en gevraagd om iets waar de wereld niet op zit te wachten. In deze gevallen kan de ontwikkelingsafdeling duidelijk niets worden verweten! Maar als je op deze manier een verouderd product ontwikkelt, waar blijft de organisatie als geheel dan? En als dit niet de beste oplossing is voor de organisatie als geheel, is het dan wel goed voor de ontwikkelafdeling? Ook al deed iedereen precies wat er van hem verwacht werd, toch kunnen er mensen ontslagen worden omdat ontwikkelingskosten niet terugverdiend kunnen worden.
De oplossing is, zoals zo vaak, om een middenweg te behouden. Met behulp van b.v. Met Agile- of LEAN-ontwikkelingsmethoden kunnen ontwikkelaars voortdurend in contact blijven met marketing. Iteratieve en modulaire ontwerpprocedures kunnen worden gebruikt om te controleren of de nieuwe tool doet wat hij moet doen, zonder te vertrouwen op het vermogen van mensen om specificaties vooraf in woorden te beschrijven. En omdat de communicatie met de markt niet verloren gaat tijdens het ontwikkelproces, heeft de tool een aanzienlijk grotere kans om daadwerkelijk bruikbaar te zijn op het moment van introductie.
Afbeelding (door QuiteLucid op Flickr): "een kameel is een racepaard ontworpen door een commissie".