Articles

Wat moet er in een gedetailleerde offerte van een web- en mobile app-ontwikkelingsbedrijf staan

Iedere klant wil zo snel mogelijk weten wat de prijs van het project is. Ook al is er een snelle manier om de prijs te bepalen met een ruwe schatting, het lest niet de dorst. Dit is waar een gedetailleerde schatting om de hoek komt kijken.

Telkens wanneer we met een nieuwe klant gaan samenwerken, stelt ons bedrijf voor de ontwikkeling van web- en mobiele apps twee uitgebreide documenten op die alle fijne details onthullen met betrekking tot de kosten van het project van onze klant.

Misschien hebt u al gelezen waarom en hoe we ruwe schattingen maken (zo niet, dan moet u dit zeker doen). En nu is het tijd om alles te onthullen wat je ooit hebt willen weten over de gedetailleerde schattingen in MindK.

Wat is een gedetailleerde schatting?

Een gedetailleerde schatting is een vlezig document dat u voorziet van een uitgebreide uitsplitsing van de kosten voor uw project.

Het verdeelt de hele omvang van het werk in elementaire onderdelen – functies.

Elke functie wordt afzonderlijk geschat door onze cross-functionele teams.

De tijd die nodig is om elke functie te voltooien, telt op tot een gedetailleerd budget voor uw app.

Gedetailleerde schatting vs. ruwe schatting

Als u wilt dat wij een prijskaartje hangen aan een basisidee dat u zojuist met ons hebt gedeeld, sturen wij u graag een ruwe schatting. Het kan u slechts een algemeen idee geven over de kosten van uw project.

Een gedetailleerde schatting is een veel genuanceerder en uitgebreider document.

In ruwe schattingen, verdelen we uw app in grote blokken van functionaliteit die epics worden genoemd.

In gedetailleerde schattingen gaan we een stap verder en splitsen we elke epic op in features.

Voordat we de gedetailleerde schatting kunnen schrijven, moeten we alle vereisten verzamelen en documenteren, alle open vragen ophelderen, en de specificatie schrijven (in het geval van een Fixed Price-contractmodel dat voor het project wordt gebruikt).

Op deze manier zijn we in staat om alle noodzakelijke details van tevoren te achterhalen en de meest nauwkeurige schatting als resultaat te leveren.

Er kunnen in deze fase geen aannames zijn, alleen beweringen.

Gedetailleerde schatting vs. nauwkeurige schatting

Wanneer we te maken hebben met schattingen, betekent Gedetailleerd niet noodzakelijkerwijs Nauwkeurig.

Hierom.

Echt nauwkeurige ramingen zijn pas mogelijk na afronding van de Discovery-fase, prototyping van de oplossing, schrijven van de specificatie en goedkeuring van de gedetailleerde scope of works.

Voor de fixed-price projecten stellen we pas een gedetailleerde raming op nadat de Discovery-fase is afgerond. Deze fase factureren we meestal als een apart project.

Voor de Agile/Scrum projecten hanteren we een andere aanpak.

Volgens deze methodiek is productontwikkeling een dynamisch en zeer flexibel proces. Het belangrijkste doel is om elke 2 tot 4 weken een kant-en-klare oplossing te produceren en aan te passen aan de feedback van de gebruikers.

Het maken van een definitieve schatting voor het hele project past niet echt bij deze aanpak.

In de meeste gevallen kun je niet echt voorspellen hoe je app er maanden en jaren later uit zal gaan zien. Daarom gebruiken we voor Agile-projecten liever wat we Guesstimate noemen.

Hiermee kunnen we benaderende, maar toch uiterst gedetailleerde schattingen maken zonder veel tijd te verspillen aan de Discovery-fase.

Wat is een gedetailleerde schatting?

Een gedetailleerde schatting in MindK bestaat meestal uit drie delen: de schatting zelf, software-gerelateerde kosten, en risico-analyse.

De schatting

De sectie geeft u een feature-by-feature uitsplitsing van de kosten voor uw project.

Voor de Fixed-price projecten, schrijven we gewoon de exacte kosten van elke functie, maar voor de Agile projecten, kunnen we alleen maar een schatting.

In deze sectie, nemen we niets anders dan de functies die 100% worden bevestigd door onze klanten. Als zij op een gegeven moment besluiten een feature toe te voegen, schatten we die apart in en werken we het document bij.

Als een project complex is (d.w.z. je hebt zowel een webapplicatie, een iOS / Android app, een chatbot, enzovoort nodig), wordt elk van deze onderdelen apart geschat.

Elke feature wordt opgeschreven in de vorm van een user story. Dit is een simplistische manier om een stuk functionaliteit weer te geven vanuit het oogpunt van de gebruiker.

Het luidt typisch: Als <role>, wil ik <feature> zodat <voordeel> (d.w.z. als blog-eigenaar wil ik een inschrijvingsformulier, zodat ik abonnees kan krijgen om updates te ontvangen over de nieuwe blogpost.).

User stories zijn kort, beknopt en flexibel. Maar het belangrijkste is dat ze zeer gemakkelijk te begrijpen zijn, zelfs als je een groentje bent in de wereld van software-ontwikkeling.

De gedetailleerde schatting bevat de uitsplitsing van de kosten voor elk type werk:

  • Business Analyse;
  • Ontwerp;
  • Markup (HTML);
  • Ontwikkeling;
  • Kwaliteitsborging;
  • Project Management (PM).

De kosten van PM bedragen gewoonlijk ongeveer 25% van het bedrijfsresultaat. Het exacte percentage hangt van veel factoren af:

  • Hoe complexer een project wordt, des te meer communicatie en management het vereist.
  • Hoe groter het team wordt, des te uitdagender wordt het management, wat resulteert in de extra PM-uren.
  • Het aantal integraties met derden kan ook van invloed zijn op de beheerkosten. Naast het feit dat weer een andere functie te implementeren (en te beheren), derde partij API vereisen vaak onze PM’s om de dienstverleners te contacteren.

Bijvoorbeeld, de communicatie met grote bedrijven (grote banken, grote bedrijven, enz.) als API-aanbieders kan een echte pijn in de nek zijn. De hoge mate van bureaucratie en rigide hiërarchie structuren kunnen zo’n eenvoudige taak veranderen in een ondraaglijke karwei.

In een aparte subsectie, noemen we alle standaard functies.

Onze ervaring met de mobiele en web ontwikkeling leert ons dat bepaalde functies en taken zijn aanwezig in alle toepassingen. Ze kunnen bijvoorbeeld het opzetten van de servers en ontwikkelomgeving, projectbeheer, Google Play release (voor Android apps) en ga zo maar door.

De kosten van oplossingen van derden

Wanneer het gaat om de ontwikkeling van software, het wiel opnieuw uitvinden is een kostbare en vaak zinloze onderneming. Gelukkig is er voor elke standaardtaak of elk veelvoorkomend probleem in de IT-wereld wel een kant-en-klare oplossing. Soms zijn ze gratis, maar in de meeste gevallen moet je ervoor betalen.

Als we voor de uitvoering van een project software, diensten of bibliotheken van derden moeten aanschaffen, maken we een schatting van de kosten en nemen we die op in het document.

Als je project bijvoorbeeld SMS-berichten ondersteunt, moeten we betalen voor een SMS-gateway.

Als uw website-ontwerp is gebaseerd op een specifiek kant-en-klaar sjabloon dat u wilt gebruiken, dan voegen we de kosten daarvan toe aan de schatting.

Of als onze klanten willen dat we hen helpen met de hosting, stellen we hen de beste opties voor (zoals Amazon Web Services, DigitalOcean, of andere bewezen diensten). De kosten in verband met de hosting en het onderhoud van de server zullen dus in deze sectie verschijnen.

Risicoanalyse

Elk project brengt een aantal inherente risico’s met zich mee. Het is de taak van de projectmanager om deze te identificeren en strategieën te ontwikkelen om ze het hoofd te bieden.

Ondanks de beste praktijken op het gebied van risicobeheer, worden sommige risico’s werkelijkheid en hebben ze gevolgen voor de kosten van een project. Wij evalueren elk potentieel risico en nemen deze op in de gedetailleerde raming.

U hoeft het gespecificeerde bedrag alleen te betalen als een bepaald risico een reëel probleem blijkt te zijn. Anders houdt u het geld.

Deze ramingen dienen ons dan als een verzekering tegen de meest uiteenlopende gevaren die de ontwikkeling van uw project bedreigen.

Hier volgen voorbeelden van risicocategorieën die bij de productontwikkeling voorkomen:

  • Kwaliteit/Techniek/Prestatie (d.d.w.z. gebruik van nieuwe of uitzonderlijk complexe technologie, wijziging van technologie, onmogelijke outputdoelstellingen);
  • Projectbeheer (d.w.z. onjuiste toewijzing van middelen en tijd, ontoereikende projectplanning);
  • Organisatorisch (d.w.z. gebrek aan consistentie tussen de kosten, tijd, en scope doelen, slechte prioritering, onregelmatige backing);
  • Extern (d.w.z. veranderingen in wetgeving, problemen met leveranciers en onderaannemers, klimaat).

Nadat de risico’s zijn geïdentificeerd, prioriteert de PM ze en voert een risico-analyse uit.

Het doel hiervan is om van elk risico de waarschijnlijkheid (d.w.z. de kans dat het zich voordoet) en de impact (de gevolgen als het zich voordoet) te bepalen.

Een voorbeeld?

Zoals ik al zei, de API leveranciers kunnen traag zijn om te reageren. Zij kunnen wachten met het toesturen van de benodigde documentatie of bieden ondermaatse ondersteuning. Dit is een reëel risico waar we u van te voren voor moeten waarschuwen. Dus plaatsen we het in de risico’s sectie en ontwikkelen tegelijkertijd een effectieve risico-management strategie om de kans op de dreiging en de impact ervan te minimaliseren.

Wrapping Up

Nu weet u wat u kunt verwachten van de gedetailleerde schatting in MindK. Het document zal u een uitputtend antwoord geven op de vraag naar de prijs van uw project en zal u ook helpen bij de budgettering. Tenslotte zal het een duidelijk beeld geven van wat u zult betalen.

Is er nog iets dat ik u kan vertellen over de gedetailleerde ramingen in MindK? Stuur ons een berichtje en ik zal een gedetailleerd antwoord geven!

e-book agile development

  • 19
    Shares
  • 19