Waarom wijken de schattingen van softwareontwikkelingstaken regelmatig af met een factor 2-3?

Waarom wijken de schattingen van softwareontwikkelingstaken regelmatig af met een factor 2-3?

Dit is een antwoord op de Quora-vraag: Waarom zijn schattingen niet exact?

Hier zijn meerdere factoren voor. Hier enkele veelvoorkomende:

1) Klant is niet technisch en voelt “alles is gemakkelijk”

Het ontwikkelen van software is niet zo eenvoudig als het lijkt.

Ook al lijkt het makkelijk, het is soms beter om bepaalde taken over te slaan.

• Om een analogie te nemen:

Er is een enorme heuvel en we moeten een spoorlijn aanleggen. De ontwikkelaars zullen adviseren: “Het is beter om de heuvel te vermijden en de baan rond de heuvel te bouwen. Zo besparen we 5 maanden extra werk.”

Hier zou het duidelijk zijn dat het veel meer tijd zal zijn om een tunnel door de heuvel te boren en de klant zou instemmen met het “werk eromheen”.

• Laten we nu eens kijken naar softwareontwikkeling:

De ontwikkelaar zegt: “Het zou beter zijn om maar één mobiele versie te hebben met één schermformaat en één desktopversie met één schermformaat. We moeten een mobiele app vermijden en ook een volledig responsive design vermijden, want dat ziet er niet goed uit”.

Hier zal de klant hoogstwaarschijnlijk zeggen: “Waarom? Andere websites zijn ook responsive en kunnen veranderen naar alle schermformaten. Het is een gemakkelijke taak.”

Maar: er kunnen verschillende en goede redenen zijn waarom de ontwikkelaar dit heeft voorgesteld. Misschien ziet een responsive design er niet goed of professioneel uit. Vooral sommige knoppen kunnen gemakkelijk kwaadaardig worden enz. enz.
Dus wat er nu zal gebeuren, is dat de ontwikkelaar dat zal doen 1) bouw de pagina responsief en 2) zal de uren verhogen.

• Voor de urenverhoging vindt geen acceptatie door de opdrachtgever plaats: “Waarom meer uren? Het is makkelijk toch?”
• Wanneer de taak is voltooid, kijkt de klant met zijn mobiel naar de website en zegt: “Alles is niet goed uitgelijnd als ik de site op mobiel bekijk. Waarom? Ik heb veel meer betaald en nu dit?”.

Als de klant had ingestemd met de eerdere manier om het te doen (niet-reagerend, met slechts twee versies), dan zou de website goedkoper zijn geweest (minder uren) en zou het prima zijn op bijna elk mobiel scherm en elke desktopbrowser.

Het belangrijkste probleem hier is ook: Het is niet goed om met iemand in discussie te gaan. Vooral ruzie maken met de klant is geen goed idee. Dus de ontwikkelaar/de serviceprovider zal altijd zeggen: “Ja, je hebt gelijk, laten we het zo doen”.

En als de klant niet echt tevreden is, moet de ontwikkelaar opnieuw de schuld op zich nemen (ook al weet hij / zij dat het niet zijn schuld was, maar dat de vereiste op zo’n manier was).

2) Het is niet mogelijk om veel tijd te nemen om precies in te schatten

In de echte wereld krijgt een softwarebedrijf dagelijks of wekelijks aanvragen voor softwaretoepassingen.

Als elk verzoek exact zou worden geschat, zouden de ontwikkelaars niets anders hoeven te doen dan exacte schattingen te maken. Ze zouden niet in staat zijn om aan echte projecten te werken, omdat het maken van die exacte schattingen erg tijdrovend is.

Dus wat er feitelijk gebeurt, is: ze zullen naar het project kijken en de benodigde tijd ‘schatten’. Daarom wordt het een “schatting” genoemd, omdat het niet exact is.

Ook: De opdrachtgever zelf is niet geïnteresseerd in een of meerdere weken wachten met het specificeren van de behoefte. Er wordt maximaal een document van 5 pagina’s gemaakt en dat zal de basis zijn voor de ontwikkeling.

3) Elke eis verandert tijdens het project

Ik citeer graag Andrew Rose uit de Quora-thread/link aan het begin van dit artikel:

“Het maakt niet uit hoe groot of klein een project is, er zal altijd iets opkomen nadat je aan het project bent begonnen. Het is waarschijnlijker dat er veel dingen naar boven komen. Het is gewoon de aard van het beestje. Als Product Manager is het jouw taak om samen met je klanten te bedenken wat ze nodig hebben en waarvoor ze bereid zijn te betalen. Je moet ook bedenken wat je redelijkerwijs kunt leveren met de hulp van je ontwikkelaars. Terwijl je eraan werkt om die doelen te bereiken, kom je veranderingen in reikwijdte tegen, onjuiste tijdschattingen en soms veranderingen in de mensen die werken om het project te voltooien.”

Tijdens het project verandert er veel. Zoals Andrew al zei, zullen niet alleen de vereisten veranderen. Zelfs mensen kunnen in andere projecten gaan voordat het huidige project is voltooid.

Hier een analogie:

Een sprinter van 100 meter traint 10 jaar lang om de 100 meter in minder dan 10 seconden te lopen.

Op de dag van de sprint, zegt de klant, hebben we onderweg ook 5 hindernissen nodig.

Dan zal de sprinter zeggen: “maar dan zal ik het niet onder de 10 seconden kunnen lopen” en de klant zal zeggen “waarvoor heb je de afgelopen 10 jaar getraind, doe het alsjeblieft onder de 10 seconden”.

Hetzelfde geldt ook voor softwareprojecten. Klanten en projectmanagers zullen nieuwe eisen stellen omdat “Oh, ik vergat deze zeer belangrijke functionaliteit. Het moet in de software zitten, anders is het voor ons niet bruikbaar”.

Deze vereistenwijzigingen zullen meestal tijdens het volledige project plaatsvinden. Het is als het toevoegen van een vijver, een muur, een ladder, enz., in de weg van de sprinter, in de verwachting dat hij/zij het nog steeds doet in minder dan 10 seconden.

4) Architectuur niet goed gecontroleerd

Vooral wanneer dingen niet helemaal opnieuw worden gedaan en tools van derden (WordPress, TYPO3, Drupal, Magento, Shopware en vele anderen) worden gebruikt en die moeten worden aangepast om iets specifieks te doen waartoe het kan komen verkeerde schattingen .

In deze tools van derden kunnen we niet zomaar alles veranderen wat we willen. Eenvoudige dingen zoals de URL-structuur of andere dingen moeten worden gevolgd.

Net als in punt 1) in deze tekst is niet alles even eenvoudig uit te voeren. Als eenmaal is ontdekt dat de huidige architectuur van het systeem van derden een specifieke functionaliteit niet ondersteunt, is het altijd beter om die specifieke functionaliteit te vermijden en een work around te gebruiken die hetzelfde werk doet, maar de bestaande architectuur gebruikt.

Opmerking: dit probleem/probleem zal zich ook voordoen als het project helemaal opnieuw wordt uitgevoerd met tools zoals PHP, ASP.NET, Laravel, Zend, Symfony, Java, Ruby on Rails, Node.Js, enz. en enkele aanvankelijke, verkeerde veronderstellingen zijn gemaakt over de architectuur van het systeem.

5) De “één zin” of “één woord” showstopper

Ik had het voorbeeld van het 5 pagina’s tellende document al genoemd, dat door de klant zal worden verstrekt. Als de ontwikkeling bijna klaar is of in volle gang is, zegt de klant: “Er ontbreekt een belangrijke functionaliteit. Op pagina 3 bij regel 22 staat dat we – een rapportagetool – nodig hebben”.

Maar het bouwen van deze rapportagetool, die slechts kort in het document wordt genoemd, kost hetzelfde bedrag als het hele project. En omdat de ‘rapportagetool’ in het document wordt genoemd, zal de klant natuurlijk aandringen op de implementatie ervan.

6) Het project winnen

Stel dat u het gevoel heeft dat veel bedrijven op hetzelfde project bieden. Nu wil je beslist niet het voorstel zijn dat de meeste uren rekent. Jij wilt degene zijn die het laagste aantal uren laat zien. Als een klant kan kiezen tussen 100 uur en 500 uur, zal zeker iedereen voor de 100 uur kiezen.

In werkelijkheid heeft iedereen in een ideale wereld hetzelfde aantal uren nodig. Dus ook al werd 100 uur geciteerd, het zal uiteindelijk 500 uur worden.

7) Onbekenden/ Wachttijden

Er zijn verschillende onbekenden in softwareprojecten:

• a) Technologie verandering: Als een van de ontwikkeltools (bijv. Android) een grote update krijgt, moet er meer worden gedaan om die technologische veranderingen door te voeren.
• b) Ervaring van de teamleden: Als een senior ontwikkelaar aan het project werkt, kost het minder tijd, als het een junior ontwikkelaar is, dan zal het waarschijnlijk meer tijd kosten.
• c) Feedback komt laat: Klanten zijn meestal niet erg geïnteresseerd in het project, ze willen geweldige resultaten. Dus wanneer de klant tijdens het project wordt benaderd, is hij misschien niet bereid om binnen een uur een antwoord te geven. Het kan enkele dagen duren. Gedurende die tijd ligt het project stil en kan de serviceprovider gedurende die tijd zelfs uren in rekening brengen, als de ontwikkelaars stilzitten vanwege de vertraging in de reacties.

8) Project is te groot om correct in te schatten

Laten we aannemen dat het een taak is die meerdere ontwikkelaars nodig heeft over een periode van enkele maanden.

Het is bijna onmogelijk om de taken in zulke kleine stukjes werk op te splitsen om de juiste schatting te krijgen.

De overige zaken die in dit artikel genoemd worden zullen uiteraard ook een rol spelen.

Conclusie

De beste aanpak is:

• Maak een geschatte schatting
• Vermeld dat het het beste is om de functionaliteiten te verminderen, als het project te lang duurt en veel uren in beslag neemt (bijv. maak een prioriteitenlijst van functionaliteiten, doe alleen de belangrijkste)
• Gebruik de agile methodologie voor ontwikkeling en facturering

Wil je een exacte prijs/uren, dan kan dat meestal alleen bij kleinere projecten die enkele weken duren.

Andere interessante artikelen over het onderwerp:
Hoe een softwareontwikkelingsproject in manuren realistisch te schatten?
Waarom schatting van de softwareontwikkelingstijd niet werkt en alternatieve benaderingen

Afbeeldingsbron: Flickr.com/ Michael Kappel/ Judit Klein/ Markus Spiske

De auteur: Sascha Thattil werkt bij Software-Developer-India.com, een onderdeel van de YUHIRO Group. YUHIRO is een Duits-Indiase onderneming die programmeurs levert aan IT-bedrijven, agentschappen en IT-afdelingen.