Waarom software-inschattingen altijd fout zijn, en hoe u er een krijgt waarmee u kunt plannen

Het gesprek gaat ongeveer zo. De manager vraagt om een aanpassing in het orderscherm: een nieuw veld, een nieuwe kortingsregel, een klein rapport. De developer denkt even na en zegt: “Ongeveer twee weken.” Twee maanden later is het nog steeds niet af, en de manager vraagt zich af of de developer loog, lui is of gewoon zijn werk niet goed doet.

Meestal geen van de drie. De inschatting was waarschijnlijk eerlijk voor het werk zoals het op dag één werd beschreven. Het probleem is dat het werk op dag één en het werk dat uiteindelijk werd opgeleverd niet hetzelfde werk waren, en dat die twee weken uitgingen van twee weken ongestoorde tijd die er nooit is geweest.

Dit artikel is voor de eigenaar, de directeur of het hoofd operations die rond software moet plannen en steeds weer verrast wordt. Het gaat over waarom inschattingen misgaan, wat er werkelijk met de tijd gebeurt en hoe u een inschatting vraagt waarmee u echt kunt plannen.

Een inschatting begint breed, en dat is normaal

Steve McConnell, die het standaardwerk over het inschatten van software schreef, beschrijft de cone of uncertainty (onzekerheidskegel). Helemaal aan het begin, als het werk nog maar een idee is, kan een inschatting er een factor vier naast zitten, naar boven of naar beneden. Twee weken kan in werkelijkheid een halve week zijn, of acht weken. Naarmate het werk wordt uitgewerkt, ontworpen en gestart, wordt de bandbreedte smaller.

Fase	Realistische bandbreedte voor “twee weken”
Idee, in één zin beschreven	0,5 tot 8 weken
Afgesproken wat het moet doen	1 tot 4 weken
Eisen op papier en gecontroleerd	1,3 tot 3 weken
Ontwerp klaar, werk gestart	1,6 tot 2,5 weken

Volgens McConnell is dit het beste geval. De kegel wordt alleen smaller als iemand ook echt de beslissingen neemt die de onzekerheid wegnemen. Dat er tijd verstrijkt, maakt hem op zichzelf niet smaller.

Dat is de eerste reden voor de verrassing: één getal, op dag één gegeven voor een verzoek van één zin, is de minst betrouwbare inschatting die er ooit zal zijn. En de meeste “twee weken” worden precies op dat moment uitgesproken.

Waar de tijd werkelijk naartoe gaat

Ook als de inschatting voor het schrijven van de code klopt, is de code maar een deel van het werk. Een realistische verdeling van een aanpassing van “twee weken” in een bestaande bedrijfsapplicatie:

Werk	Meestal meegeteld in de inschatting?	Gebruikelijk aandeel
De nieuwe code schrijven	Ja	40 %
De bestaande code begrijpen die geraakt wordt	Deels	15 %
Testen, en oplossen wat de tests vinden	Vaak niet	15 %
Code review en aanpassingen na de review	Zelden	10 %
Release, configuratie, migratie van data	Zelden	10 %
Vragen, verduidelijkingen, wachten op antwoord	Nooit	10 %

De percentages zijn ter illustratie en niet gemeten, maar iedereen die ooit software heeft opgeleverd, herkent ze. Als de developer alleen de eerste regel heeft ingeschat, lag het eerlijke totaal eerder rond de vier à vijf weken, nog voordat er iets misging. Bij oudere systemen wordt de tweede regel veel groter, zoals ons artikel over technische schuld en trage ontwikkeling uitlegt.

Hoe twee weken twee maanden worden

De grootste oorzaak is zelden de inschatting zelf. Het is wat er daarna gebeurt. Een voorbeeld, verzonnen maar typisch:

1. Week 1Het werk start zoals afgesproken
2. Week 2"Kan het ook retouren aan?"
3. Week 3Dringend probleem in productie, drie dagen kwijt
4. Week 4Een ander project krijgt topprioriteit
5. Week 6Weer terug, de helft moet opnieuw worden uitgezocht
6. Week 7De kortingsregel verandert na een demo
7. Week 9Eindelijk opgeleverd

Niemand deed iets dramatisch fout. Elk afzonderlijk verzoek was redelijk. Samen maakten ze van een klus van twee weken een klus van negen weken. Wat elk verzoek werkelijk kostte:

Wat er gevraagd werd	Hoe het klinkt	Wat het werkelijk kost
“Kan het ook retouren aan?”	Eén geval erbij	Nieuwe regels, nieuwe tests, vaak een herontwerp van wat al gebouwd was
Een dringend probleem in productie	Drie dagen	Drie dagen, plus de tijd om weer in het werk te komen
“Zet dit even stil, het andere project is dringender”	Een pauze	Later alles opnieuw uitzoeken, en het risico dat de code eronder intussen is veranderd
Een wijziging na een demo	Een kleine correctie	Een deel van wat af is terugdraaien en opnieuw doen
“Even een snelle vraag”, meerdere keren per dag	Niets	Telkens weer een onderbroken concentratie

Die contextwisselingen verdienen een getal. Softwareauteur Gerald Weinberg stelde een vuistregel voor: elk extra project waar iemand tegelijk aan werkt, kost ongeveer 20 % van zijn tijd, alleen al aan het schakelen. Een developer die over twee projecten verdeeld is, geeft elk project niet de helft van zijn week, maar eerder 40 %, en de overige 20 % gaat verloren tussendoor.

Waarom druk niet helpt

Als deadlines verschuiven, is druk de natuurlijke reactie: een harde datum, een dagelijkse statusmeeting, een herinnering dat de klant zit te wachten. Meestal maakt dat het erger.

• Onder druk worden inschattingen korter, niet beter. Mensen noemen het getal dat de meeting beëindigt, niet het getal waar ze zelf in geloven.
• Tests en review sneuvelen als eerste. De deadline wordt gehaald, een week later komen de bugs, en die oplossen kost meer dan de gewonnen tijd.
• Statusmeetings zijn ook onderbrekingen. Een dagelijkse check-in over een taak die te laat is, haalt tijd weg bij die taak.
• Goede developers merken het. Voortdurende deadlinedruk bovenop voortdurend wisselende prioriteiten is een van de redenen waarom senior developers vertrekken.

Hoe u een inschatting vraagt waarmee u kunt plannen

Een inschatting voor softwareontwikkeling precies maken, lukt niet. Bruikbaar maken wel.

1. Vraag om een bandbreedte, niet om één getal. “Tussen twee en vier weken” zegt meer dan “drie weken”. Is de bandbreedte erg breed, dan is dat ook nuttige informatie: het werk wordt nog niet begrepen.
2. Vraag wat het langer zou maken. “Wat kan hier zes weken van maken?” Het antwoord laat u de risico’s zien, en vaak ook een beslissing die u nu al kunt nemen om er een weg te nemen.
3. Knip het werk op. Een groot stuk werk dat in zijn geheel wordt ingeschat, is een gok. Hetzelfde werk, opgeknipt in stukken van een paar dagen die elk apart worden opgeleverd en getoond, is een plan. Een helder programma van eisen voor software helpt daarbij enorm.
4. Laat de inschatting alles bevatten. Vraag het expliciet: zitten tests, review, release en datamigratie hier ook in? Zo niet, tel ze erbij op.
5. Laat opnieuw inschatten als er iets verandert. Een nieuwe eis is een nieuwe inschatting, geen voetnoot bij de oude.

Wat u als manager kunt doen

Het grootste deel van de verloren tijd in het voorbeeld hierboven lag niet in handen van de developer. Dit ligt in uw handen:

• Eén kanaal voor nieuwe verzoeken. Ideeën, bugs en wijzigingen komen op één plek binnen, niet rechtstreeks bij de developer die toevallig het dichtst in de buurt zit.
• Prioriteiten die minstens twee weken overeind blijven. Wijzig ze als het moet, maar niet om de paar dagen. Een plan dat twee weken standhoudt, is meer waard dan een perfect plan dat twee dagen standhoudt.
• Nieuwe ideeën gaan naar de volgende ronde. “Kan het ook retouren aan?” is een goede vraag, en het antwoord luidt: ja, in het volgende stuk werk, met een eigen inschatting.
• Bescherm de focustijd. Minder meetings, minder snelle vragen, en één persoon die dringende productieproblemen oppakt, zodat niet iedereen wordt onderbroken.
• Kijk naar de trend, niet naar één misser. Zit een team structureel 50 % boven de inschatting, plan dan met 1,5 keer hun inschattingen en pak de oorzaken aan. Dat is eerlijker dan doen alsof het de volgende keer anders gaat.

Gaat het werk naar een externe partner, dan geldt dezelfde logica voor het contract. Ons artikel over vaste prijs of nacalculatie legt uit waarom een vaste prijs deze onzekerheid niet wegneemt, maar haar alleen in de prijs verstopt.

Vragen die we vaak horen

Waarom kan een developer niet gewoon een exacte deadline geven?

Omdat aan het begin niemand precies weet wat het werk zal inhouden, ook degene die erom vraagt niet. De details komen boven tijdens het werk. Een exacte datum aan het begin is een belofte, geen inschatting, en beloftes die onder onzekerheid worden gedaan, worden meestal gebroken.

Moeten we bij elke inschatting een buffer optellen?

Een verborgen buffer waar iedereen van weet, raakt meestal toch op. Beter werkt het om om een bandbreedte te vragen, voor zaken die er echt toe doen in de bovenste helft daarvan te plannen en de redenen voor die bandbreedte zichtbaar te houden.

Ons team is altijd te laat. Zijn ze gewoon traag?

Misschien, maar kijk eerst naar de andere oorzaken: hoe vaak de prioriteiten veranderen, aan hoeveel projecten ieder tegelijk werkt, hoeveel onderbrekingen er zijn en hoe oud en verknoopt de code is. In onze ervaring verklaren die het grootste deel van de vertraging.

Helpen inschattingstechnieken zoals story points?

Ze kunnen een team helpen om consequent in te schatten en de eigen patronen te herkennen. Ze helpen niet als het werk onder de inschatting steeds blijft veranderen. Breng eerst de aanvoer van werk op orde, daarna pas de techniek.

Hoe wij werken

ProCoding is een .NET-studio in Split, Kroatië. Wij bouwen en onderhouden bedrijfsapplicaties, en een groot deel van dat werk goed doen zit in de planning: kleine stukken die elke week of twee weken te zien zijn, inschattingen als bandbreedte met de risico’s erbij benoemd, en wijzigingen die naar de volgende ronde gaan in plaats van de huidige te verstoren. Op uw eigen project, met uw team, of met een freelance .NET-developer binnen uw team. De eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• The Cone of Uncertainty, Steve McConnell, Construx
• The Multi-Tasking Myth, Jeff Atwood, over de vuistregel van Gerald Weinberg voor het schakelen tussen projecten