Hoe we projecten bij JetBase inschatten

Iedereen weet dat een nauwkeurige schatting van webontwikkelingsprojecten belangrijk is, maar de vraag is hoe je dat kunt bereiken. Mijn naam is Sergey en ik ben CTO bij JetBase. Elke dag schat ik honderden projecten en op donderdagen geef ik een school voor teamleiders, waar aparte lessen gewijd zijn aan schattingen.

In ons bureau hebben we een methodologie voor schattingen ontwikkeld en blijven we deze continu verfijnen. Vandaag wil ik mijn observaties en ervaringen delen met iedereen die geïnteresseerd is. Bereid je voor op echte voorbeelden uit de praktijk en niet minder statistieken en cijfers.

Ik schrijf dit artikel voor iedereen die geïnteresseerd is in het onderwerp, maar vooral voor mijn mede-teamleiders en ook voor onze klanten die dagelijks contact opnemen met onze verkoopafdeling en om prijzen vragen. Nauwkeurige projectschatting is cruciaal voor deze twee groepen mensen.

Ik ben vaak de frustratie tegengekomen van zowel beginners in teamleiderschap als klanten. Nieuwe teamleiders voelen zich gefrustreerd wanneer ze te maken hebben met onvoldoende klantgegevens en zijn bang om aanvullende vragen te stellen, terwijl klanten op hun beurt in de war zijn wanneer zij bepaalde cijfers zien. Beiden hebben perfecte schattingen nodig, maar is dat gemakkelijk te bereiken? Laten we eruit zoeken wat het echte verhaal is.

Laten we beginnen met een verhaal over een klant die ooit contact met ons opnam om een sociaal platform te creëren dat vergelijkbaar is met bestaande en populaire streamingtoepassingen zoals Instagram en TikTok. De vereisten die werden verstrekt, waren tamelijk algemeen, zoals vaak het geval is in 95% van de situaties, en zoals gebruikelijk werd er niet gesproken over de zakelijke doelen van het project.

Het was niet moeilijk te raden dat het zakelijke doel van het project de verkoop van advertenties was. De overkoepelende wens van de klant was om te weten hoeveel tijd en geld het zou kosten om dit doel te bereiken. We konden wel algemene cijfers geven zoals 3 jaar en 1 miljoen dollar, maar dat is absoluut niet onze aanpak.

Het doel van ons bedrijf is om kwaliteitswerk te leveren, en het doel van het technische team is niet alleen om een schatting te geven, maar om de vereisten te analyseren en de implementatie van het project in de tijd, in sprints en fasen, te schetsen.

We richten ons op het beoordelen van de taken die essentieel zijn voor het project, met de focus op de kern van het project. Door de jaren heen is het ons duidelijk geworden dat deze aanpak realistischer en praktischer is dan ruwe schattingen te geven en vervolgens te proberen daarin te passen. Bovendien is het tijdperk van turn-key productontwikkeling voorbij.

Tegenwoordig worden alle producten iteratief ontwikkeld, evoluerend in de omgeving, in de ruimte.

Terug naar de klant die een platform zoals TikTok wilde creëren, denk ik persoonlijk dat het kopiëren van iemand anders' pad niet de meest betrouwbare manier is. Vanuit ons perspectief stellen we voor om geen TikTok te maken, met andere woorden, om het helemaal niet te noemen. In plaats daarvan stellen we voor om het project te analyseren op basis van de essentie, de zakelijke doelen te beschrijven, de pijnpunten van gebruikers aan te pakken en uit te zoeken hoe het product de problemen van de gebruiker kan oplossen.

Met andere woorden, creëer een MVP, test het, breng wijzigingen aan. Pas dan zal het duidelijk worden wat het platform daadwerkelijk zal vertegenwoordigen. Uiteindelijk kan het heel anders uitpakken dan TikTok, misschien meer zoals Snapchat.

Nu, laten we naar de essentie gaan — hoe het schattingsproces eruitziet bij JetBase. We hebben eerder in detail geschreven over schatting in het artikel "Softwareontwikkeling Schatting: Een Uitgebreide Gids."

Hier zijn de drie belangrijkste fasen waaruit het schattingsproces bestaat (er zal theorie zijn, maar daarna zult u alles in de praktijk zien):

Schaffingsfases:

Fase 1. Initiële gegevens verkrijgen van de klant met wireframes, een briefing van JetBase.io

In deze fase voert ons team van ontwikkelaars onder leiding van een teamleider een analyse van het project uit, waarbij niet alleen de technische aspecten worden begrepen, maar ook de essentie van het project wordt geïdentificeerd. Vaak impliceert dit een zakelijk doel. Bijvoorbeeld, een klant wil misschien een website maken voor registratie van conferentie-deelnemers of een app met vegetarische receptaanbevelingen. In het eerste geval is het doel de verkoop van tickets, en in het tweede geval de verkoop van abonnementen.

Fase 2. Het creëren van de projectarchitectuur, het opdelen in subtaken

Als we in de eerste fase die eerder werd beschreven de essentie van het project — de kern — willen begrijpen, dan nemen we hier, in de tweede fase, dit grote projectidee en splitsen het op in kleine delen, terwijl we tegelijkertijd de constructieve functies visualiseren.

Met andere woorden, we decomponeren de grote taak in subtaken en creëren de architectuur van het project. Deze fase is cruciaal en onvermijdelijk. Er zijn veel soorten decompositie in subtaken, maar daar zullen we het een andere keer over hebben.

Het visualiseren van de projectworkflow en architectuur geeft vertrouwen aan alle betrokkenen, met name degenen die substantiële bedragen investeren. Bij JetBase tekenen we contracten met onze klanten pas nadat we de projectworkflow zorgvuldig hebben uiteengezet door middel van grote, middelgrote en kleine taken. Dit zorgt voor gemoedsrust voor onze klanten en bevordert een duidelijker begrip in onze samenwerking.

Fase 3. Projectschatting op basis van de werkomvang, rollen, verantwoordelijkheden en uren.

Hier begint het zetten van de puntjes op de i — de daadwerkelijke schatting. In deze fase moet je je wiskundige geest inschakelen en niets belangrijks missen; elke numerieke waarde beïnvloedt het eindbedrag. Vergeet ondertussen niet dat projectschatting niet alleen wetenschap is, maar ook kunst, en veel zal afhangen van hoe je door de cijfers en tabellen de essentie van het project kunt zien waarvoor al dit nauwgezette werk wordt verricht.

Zeker, men moet van fouten leren, maar in de Team Lead School, waar ik op dinsdag lesgeef, geef ik tijdens een praktische les een voorbeeld van een nauwkeurige schatting. Dit is een echt voorbeeld uit het portfolio van JetBase, waar we de uren met de grootste nauwkeurigheid hebben geschat. Een wonder? Nee, gewoon een mix van wetenschap en kunst en veel nauwgezet werk. Het kostte ons twee weken voor deze schatting, en dat is een relatief korte tijdsperiode.

Tijdens de analysefase ontdekten we dat de essentie van het project de registratie van deelnemers voor offline games is. Dit was niet expliciet vermeld in de oorspronkelijke gegevens van de klant, maar het is cruciaal om dit vanaf het begin te weten.

Toen namen we deze initiële gegevens van de klant en hun wireframes en verdeelden we het project in modules die beschrijven wat er op hoog tech-niveau moet gebeuren, bijvoorbeeld:

• Maak de initiële applicatie
• Verbind de database
• Creëer projectentiteiten
• Stel configuratie in voor externe diensten, enz.

Vervolgens moet elke module worden opgedeeld in functies en subfuncties met een gedetailleerde beschrijving voor elk, zowel op de frontend als de backend. Laten we kijken naar een concreet voorbeeld. Hier is een pagina van het genoemde project.

Een onervaren of ongeïnteresseerde teamlead zou deze pagina ruwweg kunnen inschatten en, laten we zeggen, 8 uur werk toewijzen. Men kan hun perspectief begrijpen, aangezien klanten ontwikkelaars vaak vragen om een snelle en definitieve projectfiguur en vaak aarzelend zijn om een langere tijd te wachten.

Maar bij JetBase volgen we die aanpak niet. We investeren meer tijd in de schatting, maar we bereiken een nauwkeuriger resultaat. Hier ziet onze schatting van de genoemde pagina eruit:

Het punt is dat het voor toekomstige projectspecialisten veel eenvoudiger is om subfuncties in te schatten, aangezien het een technisch duidelijke en begrijpelijke taak is die de teamlead identificeert tijdens de schattingsfase. Hier ligt het geheim van nauwkeurige schatting – in nauwkeurige decompositie.

En als je elk module blijft decomponeren zoals in het voorbeeld van de besproken pagina hierboven, en vervolgens alle risico's en gerelateerde taken berekent, is het resultaat een schone en betrouwbare schatting.

Hieronder geef ik een voorbeeld van een slechte schatting, en om het hele verhaal over goede schatting af te ronden, kan ik zeggen dat het behalen van de zogenaamde ideale of puurheid niet zo moeilijk is. Het is volkomen mogelijk en zelfs noodzakelijk voor alle deelnemers aan het proces. Zoals Steve McConnell in zijn boek "Software Estimation: Demystifying the Black Art" zei:

"Een goede schatting is een schatting die een duidelijk genoeg beeld van de projectrealiteit biedt om het projectleiderschap in staat te stellen goede beslissingen te nemen over hoe het project te beheersen om zijn doelen te bereiken."

Voordat we het huidige niveau van schattingsexpertise bij JetBase bereikten, maakten we fouten. We leerden ervan te verbeteren en gelukkig waren het er niet te veel. Nu zal ik kort een voorbeeld van slechte schatting noemen, zodat je begrijpt waar de risico's verborgen zijn en waarom het een treurig verhaal is voor zowel het team als de klant.

Achtergrond:

Een keer benaderde een klant ons om een online leerportal te creëren voor acteurs en professionals in de filmindustrie. Aanvankelijk was er heel weinig data beschikbaar, maar we hebben nog steeds het project geschat, wat resulteerde in een vaste totale schatting.

Uitkomst:

Zoals ik eerder al noemde, hebben we een vaste prijs voor het project aangeboden. In werkelijkheid hebben we echter de geschatte begroting overschreden omdat het duidelijk werd dat er meer tijd nodig was voor het werk. Hoewel onze klant hier niet tegen was, ontstond het probleem toen ze geen betalingen deden voor de werkfasen (sprints), waardoor ze het project aan het einde volledig konden afwijzen.

Daarom moesten we het hele project opnieuw doen, wat het dubbele aan inspanning vergde, terwijl we niet werden gecompenseerd voor ons werk. We werkten zonder betaling om onze reputatie te beschermen, terwijl onze klant kostbare tijd verloor en teleurgesteld raakte in hun ervaring met webontwikkeling. Fouten zouden gecompenseerd moeten worden.

Waar de fouten verborgen waren:

• De klant verstrekte onvoldoende gegevens aan het begin.
• We hebben geen gebruik gemaakt van agile methoden.
• De klant betaalde niet voor werkfasen, zodat ze niet betrokken waren bij de tussentijdse resultaten.
• We boden een vaste prijs in plaats van sprints te schatten (we hadden de nauwkeurige schattingsmethode kunnen gebruiken die eerder werd beschreven).

Wat betreft die twee voorbeelden van schatting die eerder zijn gegeven, is het duidelijk dat bepaalde strategieën en praktijken cruciaal zijn voor een nauwkeurige schatting in webontwikkeling.

Uit deze gevallen komen verschillende belangrijke conclusies naar voren:

• Vaste-prijs schattingen moeten vermeden worden, omdat ze vaak de werkelijke behoeften van het product niet nauwkeurig weerspiegelen.
• De verzoeken van klanten komen vaak niet overeen met de realiteit van het project.
• Meer inputgegevens aan het begin leiden tot een betere schattingsnauwkeurigheid.
• Hoe nauwkeuriger de decompositie van taken, hoe nauwkeuriger de schatting zal zijn.
• Effectieve communicatie, zoals het betrekken van klanten bij regelmatige demo-overzichten en planningssessies, is essentieel voor goed geïnformeerde besluitvorming en efficiënte productontwikkeling.

Bovendien wil ik benadrukken dat het probleem van nauwkeurige schatting en, in het algemeen, technische problemen niet alleen technische problemen zijn waar de IT-sector zich zorgen over moet maken. Klanten en bedrijven moeten ook betrokken zijn; dan is er meer groen licht voor nauwkeurige schattingen, wat leidt tot wederzijds voordeel en minder vraag naar onhandige vaste-prijs benaderingen.

Ik hoop dat mijn artikel nuttig was voor zowel IT-professionals als belanghebbenden die op zoek zijn naar een webontwikkelingsteam. Voel je vrij om neem contact met ons op als je een projectschatting nodig hebt - we zullen ons best doen om het aan te passen aan jouw specifieke behoeften.

Bron: Het IT-probleem van het bedrijfsleven: 'Het is niet mijn probleem'.