Zo maak je nauwkeurige tijdschattingen

Dit artikel schreef ik voor onze eigen developers, om gezamenlijk tot de beste ureninschattingen te komen. We delen onze inzichten graag ook extern om een steentje bij te dragen aan de community, en zo ook het leven van andere developers een beetje makkelijker te maken 🙂. Ben je geen developer? Voel je vrij om dit artikel alsnog te lezen, zij het wel met enkele tech-termen. Wil je graag de business-uitleg? Neem dan even contact op met Glenn via de contact-optie onderaan deze pagina of via onze contactpagina.

In dit artikel zal ik onze inzichten en stappen voor nauwkeurige ureninschattingen delen. Aan het einde is er een checklist voor een volledig overzicht. Maar laten we eerst eens kijken waarom het maken van schattingen vaak zo moeilijk is voor developers.

Waarom het maken van ureninschattingen moeilijk is

Als developer vind je het waarschijnlijk niet fijn als je uit het comfort van je coding omgeving wordt gerukt en in de koude en meedogenloze wereld van ureninschattingen wordt gegooid. Je moet ineens inschattingen maken op basis van onvolledige informatie, en deze bespreken met mensen die niet precies begrijpen wat je doet - en waarom. Nieuwe ideeën en concepten vliegen je om de oren, en het onvermijdelijke enthousiasme van een nieuw project hangt in de lucht. 

Natuurlijk wil je zo snel mogelijk teruggaan naar je natuurlijke omgeving om problemen op te lossen met code, in plaats van potentiële toekomstige problemen te creëren. En dit is waar het soms misgaat.

We ervaren het inschatten van uren als een stressvolle taak, en met die stress in ons achterhoofd lijkt ons programmeerwerk ineens veel rooskleuriger dan het daadwerkelijk is. Het development proces lijkt ineens veel makkelijker dan het eigenlijk is, want ja… het is gewoon je werk - in tegenstelling tot dit vreemde urenschatten. En alleen al het hebben zo’n soort emotionele achtergrond maakt je vatbaarder om de belemmeringen die zich onderweg kunnen voordoen te cognitief negeren, terwijl je het gemak van development overschat.

💡 Verlangend naar het lekker kunnen programmeren terwijl je vastzit in de ongemakkelijke wereld van het maken van ureninschattingen, onderschat je problemen die je tijdens het programmeren tegenkomt, terwijl je het gemak waarmee je ze oplost, overschat.

Hoe je dit kunt oplossen? Een optie kan zijn om het inschatten van uren een comfortabelere ervaring te maken (met geurkaarsen enzo). Maar hoe comfortabel en gewend we het ook zijn, het is en blijft niet je daily job, wat resulteert in een vertekend beeld van development. Ons beste wapen hiertegen is dus om ons hiervan bewust te zijn van en elkaar eraan te herinneren dat dit effect bestaat.

Voorgestelde oplossing en andere problemen

Dit is hoe ik denk dat we het inschattingsproces zo pijnloos mogelijk kunnen laten verlopen. 

1. Maak een lijst van functionaliteiten en hoe ze zich verhouden tot de app-flow

Het identificeren en opsommen van de belangrijkste functionaliteiten kun je het beste niet op basis van designs doen, aangezien de schermen waarschijnlijk aan verandering onderhevig zijn en een kleine wijziging in het design grote impact zou kunnen hebben op de manier waarop functionaliteiten worden geïmplementeerd.

Het is echter belangrijk om de hele flow van de app goed te bekijken en in je achterhoofd te houden bij de specifieke functionaliteiten. Dit helpt je om deze op de juiste manier te bekijken en te ontwikkelen. Bijvoorbeeld: Een winkelwagen-functionaliteit zal je anders ontwikkelen als je weet dat deze maar op één plek in de app terugkomt, ten opzichte van een app flow waarbij de winkelwagen op veel plekken getoond en geüpdatet moet worden.  

Een goede manier om een ​​balans te vinden tussen het negeren van designs en er overdreven op vertrouwen, is het gebruik van low-fidelity wireframes bij het maken van inschattingen. Op deze manier kom je niet vast te zitten in de details van designs, terwijl je tegelijkertijd in gedachten houdt hoe de functie die je inschat, verband houdt met andere aspecten van de app.

 💡 Maak een lijst van de functionaliteiten die je nodig hebt om te implementeren op basis van low-fidelity wireframes. Schat ze niet afzonderlijk in of op basis van gedetailleerde designs.

Veel voorkomende valkuil: Schat niet op basis van voltooide designs

Schatten op basis van volledig afgewerkte designs is geen goed idee. Hier zijn een paar belangrijke redenen waarom:

• Er zullen altijd verborgen functionaliteiten zijn die je over het hoofd ziet. Het bestaan ​​van een functie is misschien duidelijk voor de klant of de designer, maar kun je misschien missen als je de context of de markt niet helemaal begrijpt. Doe geen aannames, maar vraag altijd om bevestiging van welke functionaliteiten moeten worden geïmplementeerd.
• Afgewerkte designs zorgen ervoor dat je je concentreert op hoe het eindproduct eruit zal zien, niet op het proces om daar te komen. Het komt vaak voor dat je een visueel component ziet die je kunt hergebruiken tussen verschillende schermen (wat goed is om te doen), maar soms vergeet je dan om rekening te houden met de tijd en moeite die nodig is om dat component te ontwikkelen.       
• Zelfs als het klikbare mockups zijn, zijn ontwerpen volledig statisch in vergelijking met de app die je gaat maken. Dit betekent dat ze de complexiteit verbergen van alle vreemde flows die gebruikers zouden kunnen aanhouden om hun doelen in de app te bereiken. Als pas later in het ontwikkelingsproces duidelijk wordt dat je daar rekening mee moet houden, is het al te laat.
• Designers richten zich vooral op de ‘happy paths’ en met perfecte data. Als je naar designs kijkt, is de kans groter dat je al het werk over het hoofd ziet dat moet worden gedaan om bijvoorbeeld foutmeldingen en lege statussen te implementeren. Je moet ook rekening houden met content die niet precies past zoals de designer het bedacht heeft: de designer heeft de perfecte lettergrootte en het perfecte lettertype voor die titel gekozen, maar jij bent degene die ontwerpbeslissingen moet nemen en compromissen moet sluiten voor als de titel niet netjes op één regel past.

2. Kies één tot drie risicovolle dingen

Zelfs als je er volledig zeker van bent dat je over alle tools en vaardigheden beschikt die nodig zijn om de app te bouwen, is het verstandig om verschillende gebieden op te noemen waar het risico bestaat dat er iets misgaat.

Risico's kunnen overal vandaan komen. Het is misschien iets voor de hand liggends, zoals het implementeren van technologie die je nog niet eerder hebt gebruikt, of ontwikkelen voor een nichepubliek waarmee je geen ervaring hebt. Als je bijvoorbeeld een app maakt die medische gegevens verwerkt, kan het zijn dat je het aantal richtlijnen onderschat waaraan je moet voldoen. Of als je een app ontwikkelt die wordt gebruikt door een ander publiek dan jij (bijv. kinderen of ouderen), kunnen er extra feedbackrondes zijn waarop je niet bent voorbereid.

Ervaring helpt hierbij ook. Als app developer weet ik dat het een voordehandliggend risico is om te vertrouwen op een externe SDK (Software Development Kit) voor belangrijke functionaliteiten. Zeker als het gaat om SDK’s die niet open source zijn. Soms zitten hier namelijk veel fouten in. De tijd die je nodig hebt om fouten te herstellen die je niet zelf hebt gemaakt blijft lastig in te schatten, maar hier moet je wel rekening mee houden.

Afgezien van SDK's van derden, zijn externe developers sowieso een risico om rekening mee te houden. Bijvoorbeeld als jij de front-end ontwikkelt op basis van een API van externen. In tegenstelling tot interne developers uit je team, zijn de belangen van externe developers soms niet volledig in lijn met die van jou (bijvoorbeeld als de API ook andere front-ends moet ondersteunen, of als ze veel logica en checks bij jou leggen). Je zult ook meer tijd kwijt zijn met communiceren, omdat het nou eenmaal om een ander team gaat.

💡 Probeer alle verborgen risico’s te bedenken waar jij geen invloed op hebt, maar waarvan je wel weet dat ze tijd en energie gaan kosten in je development proces.  

Veelvoorkomende valkuil: ben niet te zelfverzekerd bij het inschatten

Dit deel van het inschattingsproces sluit grotendeels aan bij het eerste deel van dit artikel: wanneer je uit je development omgeving wordt gehaald en in een omgeving wordt neergezet van nieuwe projecten waarin er tijd en eindeloze mogelijkheden zijn, is het gemakkelijk om alle dingen die fout kunnen gaan te onderschatten. Je hebt nu tenslotte veel meer ervaring dan tijdens je vorige project, wat kan er misgaan?

Het doel van het identificeren van risico's is om je blik door een roze bril op het project te doorbreken en je te laten nadenken over wat er mis kan gaan, zelfs als je er zeker van bent dat je precies weet wat je doet. Misschien zelfs juist als je precies weet wat je doet.

3. Kies een gebied om op te focussen

In een ideale wereld, met oneindig veel tijd en vaardigheid beschikbaar, zou je in een mum van tijd een prachtige, robuuste, pixel-perfecte app maken.

Maar aangezien we nog niet in die wereld leven, moeten we verstandig kiezen welke strijd we tijdens het ontwikkelingsproces wel of niet gaan voeren. Realistisch gezien kun je een app maken die één of maximaal anderhalf van de volgende kwaliteiten bevat:

• Robuust: in theorie zouden alle apps onbreekbaar moeten zijn, maar in de praktijk worden er soms bochten afgesneden. Bedenk wat je van de app zou verwachten als de API een onverwachte reactie geeft na een call, of als je gebruiker een actie probeert uit te voeren waarvoor die niet bevoegd is in de app, of als de internetverbinding ineens wegvalt. Idealiter zou je een elegante foutmelding willen tonen die precies vertelt wat er mis is gegaan en wat je kunt doen om het probleem op te lossen. In de praktijk krijg je vaak een scherm te zien (of een opdringerige pop-up) die laat zien dat "er iets mis is gegaan" en hooguit een "Vernieuwen"-knop biedt. Dit komt omdat een juiste foutafhandeling een tijdrovende klus is en veel vooruitdenken vereist voor het weergeven van fouten waarvan je hoopt dat de app ze in de eerste plaats niet zal tegenkomen!
• Pixel-perfect: designers zijn getalenteerde mensen, en het is altijd jammer als we hun ideeën moeten verdraaien zodat ze passen bij de imperfecte wereld waar onze apps mee te maken hebben. Dingen zoals schermformaten en pixel densities, ontbrekende of onverwacht opgemaakte data, de toegankelijkheidsinstellingen van gebruikers... allemaal kunnen ze ervoor zorgen dat onze apps er niet zo best uitzien op allerlei apparaten. Je kunt dit verhelpen, maar het vergt veel tijd en geduld van zowel developers als designers.       
• Snelheid: de meeste apps zouden er baat bij hebben als ze nu al beschikbaar zijn voor gebruikers, maar omdat gisteren geen haalbare deadline is, is "zo snel mogelijk" vaak de beste optie. Snel apps ontwikkelen heeft niet altijd alleen betrekking op de kalender, maar is soms ook gerelateerd aan het urenbudget van de opdrachtgever. Het punt is dat zelfs als we een betere (robuustere of beter onderhoudbare) manier weten om een finctionaliteit te implementeren, er soms gewoon niet genoeg tijd is om dat te doen.       

💡 Kies er één (of hooguit twee): robuust , pixel-perfect of snelheid.

Door te bepalen welke van deze kwaliteiten de hoogste prioriteit heeft voor je klant, kan je de aanpak van je development-team hierop afstemmen. Hierdoor wordt de ureninschatting een stuk nauwkeuriger.  

Veel voorkomende valkuil: niet-afgestemde verwachtingen

Als de klant van tevoren niet bekend is met deze afwegingen, kan het zijn dat hij/zij een ander product krijgt dan verwacht. Dit kan resulteren in langdurige en meestal ongeplande feedbackrondes nadat de app is opgeleverd. Resultaat: extra tijd én kosten voor alle betrokken partijen.

Verwachtingen afstemmen is ook belangrijk voor de focus binnen het team. Als het team niet goed weet wat hun gedeelde focus moeten zijn, kunnen teamleden zich (per ongeluk) concentreren op verschillende focusgebieden, wat kan resulteren in een inconsistente app. Weten aan welke gebieden veel aandacht moet worden besteed, stroomlijnt ook het ontwikkelproces, wat uiteindelijk tijd bespaart.

4. Tickets aanmaken en inschatten

Dit is hét moment om de inschattingen daadwerkelijk te doen. Afhankelijk de fase van het project (eerste grove schatting bij kennismaking met de klant, of meer gedetailleerde schatting vlak voordat de ontwikkeling begint), zullen de problemen een verschillende granulariteit hebben. Dat wil zeggen: meer of minder gedetailleerd en nauwkeurig zijn.

Probeer de lijst met functies die in de eerste stap zijn gemaakt, op te splitsen in beheersbare brokken werk, en maak dan een weloverwogen schatting. Voorkom dat je onredelijk optimistisch wordt, het is nog steeds het beste om voorzichtig te zijn.

💡 Tijd voor weloverwogen schattingen.

Er zijn tal van technieken om de werkelijke schattingen te maken (denk o.a. aan planning poker, t-shirt maten, het bucket-systeem). Welke je kiest, is aan jou en je team. De verschillende technieken hebben hun eigen voordelen, maar het blindelings volgen (zonder voorbereiding) zal je waarschijnlijk niet het gewenste resultaat opleveren.

Veel voorkomende valkuil: unhappy paths

Zorg ervoor dat er ook user stories zijn voor alles wat er mis kan gaan.

💡 Voorbeeld: Als gebruiker wil ik [...] als de app mijn gegevens niet kan ophalen, zodat ik toch mijn doel kan bereiken / informatie kan krijgen over hoe ik mijn probleem kan oplossen.

5. Vraag om een ​​tweede (en derde) mening

Als je druk bezig bent om het project goed én zo snel mogelijk af te ronden, kan het zijn dat je bepaalde problemen over het hoofd ziet. Of misschien zelfs (niet voordehandliggende) oplossingen. Daarom is het altijd een goed idee om een andere developer naar je inschattingen te laten kijken. Hij of zij kijkt met een frisse blik naar delen van het proces die jij wellicht over het hoofd hebt gezien. Jij zit er immers middenin, en kunt daarom last hebben van enige vorm van tunnelvisie. 

Checklist voor het inschattingen van de ontwikkeltijd 

Het niet makkelijk uren in te schatten om een ​​app of een ander softwareproduct te ontwikkelen. Als je een soort checklist hebt kan dat het wat beheersbaarder maken. Probeer dus de volgende keer dat je een project inschat de volgende checklist te gebruiken om er zeker van te zijn dat je niets mist:

• Maak een lijst van functionaliteiten en hoe ze passen in de app-flow       
• Identificeer de meest risicovolle onderdelen van het proces, zelfs als je denkt dat er niets echt riskant aan is       
• Kies één of hooguit twee van de volgende gebieden om op te focussen: robuustheid, pixelperfect of snelheid
• Splits de lijst met functies in behapbare brokken en maak daar een schatting en van
• Vraag (minimaal) één second opinion

Het blijft een schatting en die is bijna nooit helemaal accuraat. Er zijn zeven miljoen (ik heb ze geteld!) andere dingen die fout kunnen gaan in een ontwikkelproject, maar het hebben van een reeks richtlijnen kan ons helpen om geen fouten te maken die kunnen worden vermeden. Door welbekende valkuilen weg te nemen, komt er ook mentale ruimte vrij om na te denken over projectspecifieke risico's en hoe we eraan kunnen werken om ze te voorkomen. Zo maak je een realistische inschatting gebaseerd op een betrouwbare methode.