Zin en onzin van specificaties

De “juiste aanpak” waar ik mijn vorige blog mee afsloot, is door José al beschreven in haar laatste blog “Voortschrijdend inzicht”. In plaats van in één keer een groot product (of proces) te implementeren, doe je dat in stukjes. Elk stukje wordt ontwikkeld in een zogenaamde sprint, waarbij het belangrijk is dat het sprint-resultaat bij voorkeur een compleet, bruikbaar deelproduct is.

Het zou natuurlijk efficiënter (en overall gezien goedkoper) zijn als je je hele product in één keer zou kunnen implementeren. Daar heeft men in het verleden uitgebreid onderzoek naar gedaan en een enorm scala aan methodieken, methoden en technieken voor ontwikkeld. Vaak aangekondigd als de ultieme oplossing die dan vervolgens toch niet tot het gewenste resultaat leidde.

De eerste horde zit al aan het begin van een ontwikkeltraject en dat is de specificatie.  In principe is het duidelijk wat een goede specificatie is, namelijk correct en volledig. Maar in de praktijk is het bereiken daarvan enorm lastig. Want je hebt (vooral bij een nieuw product of proces) alleen een concept van waaruit je moet specificeren. In de huisstijlpraktijk moet je bijvoorbeeld aangeven welke elementen op documenten altijd aanwezig moeten zijn. Als daar aan het einde van het implementatieproces een fout in blijkt te zitten, heb je een groot probleem. Er is bijvoorbeeld maar plaats voor één afzenderadres en er blijkt een afdeling te zijn die over twee lokaties verdeeld is. Dramatisch als je al voor alle docmenttypen drukwerk hebt laten maken.

Even terzijde: als je via de scrum-methode hebt gewerkt en in de eerste sprint alleen een brief hebt gemaakt, blijft de schade  dan beperkt .

Maar wat ik hier aan wil geven, is dat een fout snel gemaakt is.

Even moeilijk is het om zeker te weten dat je specificatie volledig is. De enorme specificaties van bijvoorbeeld automatiseringsprojecten van de overheid, waarbij het eindresultaat dan toch nog grote hiaten vertoonde, tonen dit overtuigend aan.

In mijn ervaring kun je alleen volledige en correcte specificaties maken voor gesloten (vaak technische) systemen. Bijvoorbeeld een verwarmingsthermostaat of een schaakprogramma. Dat is ook de reden waarom de mensen die zich hiermee bezig houden zo dol zijn op schaakprogramma’s. Het is precies bekend wat de regels zijn en hoeveel er zijn. Dat er nog steeds geen perfect schaakprogramma is, heeft andere oorzaken, maar het ligt niet aan de specificaties.

Bijkomend probleem is dat een goede specificatie ook eigenlijk alleen op een formele (wiskundige) wijze te formuleren is, waarmee deze voor “normale” mensen onleesbaar wordt. Ik kom nog terug op alternatieven hiervoor.

Alsof dit nog niet lastig genoeg is, loop je hierdoor het risico dan maar zoveel mogelijk te gaan specificeren, wat niet hetzelfde is als volledig. Want alles wat je “te veel” specificeert, wordt wel meegenomen in de implementatie en dus de kosten. Met “te veel” bedoel ik dan alles wat niet nodig is om tot een bruikbaar product te komen. Bijvoorbeeld de positie van de adresgegevens op een brief die in een vensterenvelop verstuurd moet worden. Zo’n brief zal in de envelop al gauw een paar milimeter kunnen verschuiven, dus je moet geen positie tot op 0,001mm nauwkeurig opgeven; beter is het een marge om het adresveld te laten van bijvoorbeeld 3mm (en dus ook niet 3,000 mm).

Vraag je bij specificaties ook altijd af hoe je gaat controleren of er aan voldaan is. Ik heb in de praktijk meegemaakt dat (professionele) instanties met specificaties kwamen die zelfs zij met hun state-of-the-art apparatuur niet konden meten.  Dat is dus compleet onzinnig. Maak er wel een gewoonte van om bij het schrijven van specificaties altijd aan te geven hoe ze gecontroleerd (getest) moeten worden.  Als bonus verhoogt dat namelijk je begrip en verbetert het ook vaak je beschrijving ervan.

Wat is nu de relatie met de “nieuwe” aanpak, bijvoorbeel de scrum-methode? Specificaties blijven nodig (want ook bij scrum moet je goed weten wat je gaat ontwikkelen). Scrum levert “an sich” geen betere specificaties op: ze kunnen nog steeds incorrect of incompleet zijn. Dat is vaak het gevolg van het feit dat je keuzes maakt, zeker bij nieuwe zaken, waarvan je de gevolgen niet vooraf kunt overzien. Bij het testen (of gebruiken) van een deelproduct worden die consequenties zichtbaar en kun je besluiten hoe daarmee om te gaan (accepteren of corrigeren): het voortschrijdend inzicht!

De gefaseerde aanpak verlaagt daarmee de kosten als gevolg van fouten,  hiaten en voortschrijdend inzicht, want bij volgende sprints kun je er rekening mee houden.

Omdat je na een sprint een concreet deelproduct hebt, maakt dat je beeld van het totale product ook concreter, wat helpt bij de specificaties in de volgende sprints.

Tenslotte heeft het opleveren van (direct bruikbare) deelproducten ook een bijkomend voordeel qua kosten omdat je een deel je investering direct begint terug te verdienen. Bij de klassieke aanpak gebeurt dat pas na oplevering van het complete product; tot die tijd is de ontwikkeling alleen maar een kostenpost.