De Kegel van Onzekerheid, beschreven door Steve McConnel, laat zien wat elke ervaren softwareprofessional weet. Dat is dat we aan het begin van elk project niet precies weten hoe lang een project gaat duren.
De redenen hiervoor zijn velerlei. Geen twee projecten hebben ooit:
- dezelfde vereisten.
- dezelfde mensen.
- dezelfde zakelijke context.
- dezelfde technologie.
- dezelfde prioriteiten &beperkingen.
Elk project is uniek. Elke regel code is met de hand gemaakt. En kenniswerk waarbij slimme creatieve mensen betrokken zijn, leent zich niet voor precisie zoals het graven van greppels dat doet.
Toch is precisie wat gevraagd wordt. Sponsors willen precies weten wanneer het project klaar is, en hoeveel het gaat kosten.
Het omgaan met dit raadsel is bijna zo oud als de tijd zelf. Hier zijn een paar manieren waarop teams en bedrijven met deze onzekerheid omgaan.
Omgaan met de kegel
Verhoog de schatting
Nadat men de angel van een te lage schatting voelt, is een veel voorkomende reactie om de schatting de volgende keer te verdubbelen of te verdrievoudigen. Dit verlaagt zeker het risico vooraf, maar het opvullen van de cijfers is moeilijker dan het klinkt.
Geef een te hoog getal, en sponsors zullen terugdeinzen en je project niet goedkeuren. Geef een te laag getal en je loopt het risico zonder geld te komen zitten. Dit wordt nog gevaarlijker als je biedt op contracten met een vast bod, waar de druk nog groter is om de cijfers laag te houden.
De meeste projecten voegen een soort opvulling toe aan de uiteindelijke cijfers om zichzelf voldoende speelruimte te geven. Wat teams ook kunnen doen, is dit project vergelijken met andere.
Bepaal de omvang van het project relatief
Mensen zijn heel goed in het bepalen van de omvang van dingen relatief. We kunnen je niet precies vertellen hoe groot een steen is. Maar we kunnen je wel vertellen hoe groot het is in vergelijking met iets anders. Dit kunnen we ook gebruiken bij het dimensioneren van projecten.
Wees eerlijk en open
De standaard werkwijze van Agile is transparantie en zichtbaarheid. Het mag dus geen verrassing zijn dat de Agile-manier om met de kegel om te gaan, is om recht voor z’n raap en eerlijk te zijn.
Kijk. We weten niet hoe lang dit gaat duren. Dit is onze beste gok. Maar als u ons een paar iteraties geeft, kunnen we iets bouwen, meten hoe lang dat duurt en u dan een veel beter idee geven van hoe groot dit ding is.
Een andere benadering die sommige Agile-teams kiezen om de onzekerheid te communiceren, is om de schattingen als een bereik te presenteren.
Dit heeft het voordeel dat sponsors zichtbaar de onzekerheid zien die bij het project hoort, en dan kunnen sponsors beslissen hoeveel risico ze zich kunnen veroorloven.
Fund incrementeel
Een andere aanpak die heel zinvol is, maar die ik helaas niet vaak genoeg toegepast zie, is incrementele financiering.
Met incrementele financiering vraag je niet de hele zak met geld van te voren. Alleen genoeg om genoeg van het werk te doen, om terug te rapporteren hoe lang het gaat duren.
Het is niet foolproof. Je kunt later nog steeds in de problemen komen. Maar door teams $ 30-50K te geven, ze iets te laten bouwen en te zien hoe lang dat duurt, kun je een heel eind komen om de variatie in dat getal vooraf te verminderen.
Je kunt meer lezen over deze manier van plannen en de voordelen ervan in Beyond Budgeting
De hoofdoorzaak
We leven in een wereld van jaarlijkse budgetten. En helaas drijft dit veel van de spanning en drama op onze werkplek. In sommige opzichten zijn jaarlijkse begrotingen natuurlijk (we leven en volgen de tijd in jaarlijkse cycli), maar in andere opzichten zijn ze verschrikkelijk voor de planning, want een jaar is een lange tijd in de markt.
Als je merkt dat je gestruikeld raakt door de kegel van onzekerheid, bedenk dan dat het hele punt van software schatting is om te bepalen of het project zelfs mogelijk is.
Of zoals Steve McConnell zegt:
Het primaire doel van softwareschatting is niet om de uitkomst van een project te voorspellen; het is om te bepalen of de doelstellingen van een project realistisch genoeg zijn om het project zodanig te kunnen sturen dat ze worden gehaald.
-Steve McConnell, Software Estimation: Demystifying the Black Art