Articles

Vad bör ingå i en detaljerad uppskattning från ett företag som utvecklar webb- och mobilappar

Varje kund vill veta priset på projektet så fort som möjligt. Även om det finns ett snabbt sätt att bestämma priset med en grov uppskattning släcker det inte törsten. Det är här en detaljerad uppskattning kommer in i bilden.

Varje gång vi inleder ett samarbete med en ny kund förbereder vårt företag för utveckling av webb- och mobilappar två omfattande dokument som avslöjar alla de finaste detaljerna i samband med kostnaderna för vår kunds projekt.

Kanske har du redan läst om varför och hur vi gör grova uppskattningar (om inte, bör du definitivt göra det). Och nu är det dags att avslöja allt du någonsin velat veta om detaljerade uppskattningar i MindK.

Vad är en detaljerad uppskattning?

En detaljerad uppskattning är ett fylligt dokument som ger dig en omfattande uppdelning av kostnaderna för ditt projekt.

Det delar in hela arbetets omfattning i elementära delar – funktioner.

Varje funktion uppskattas separat av våra tvärfunktionella team.

Den tid det tar att färdigställa varje funktion adderas för att bilda en detaljerad budget för din app.

Detaljerad uppskattning vs. grov uppskattning

Om du vill att vi ska sätta en prislapp på en grundläggande idé som du precis har delat med oss, skickar vi gärna en grov uppskattning till dig. Det kan bara ge dig en allmän uppfattning om kostnaderna för ditt projekt.

En detaljerad uppskattning är ett mycket mer nyanserat och omfattande dokument.

I grova uppskattningar delar vi in din app i enorma block av funktionalitet som kallas epik.

I detaljerade uppskattningar tar vi ett steg längre och delar upp varje epic i funktioner.

Innan vi kan skriva den detaljerade uppskattningen måste vi samla in och dokumentera alla krav, reda ut alla öppna frågor och skriva specifikationen (om vi använder oss av en modell med fast pris för projektet).

På så sätt kan vi ta reda på alla nödvändiga detaljer i förväg och ge den mest exakta uppskattningen som resultat.

Det får inte finnas några antaganden i detta skede, bara påståenden.

Detaljriktad uppskattning vs. noggrann uppskattning

När det gäller uppskattningar betyder detaljerad inte nödvändigtvis noggrann.

Här är anledningen till detta.

En riktigt noggrann uppskattning är endast möjlig efter att ha avslutat upptäcktsfasen, tagit fram en prototyp av lösningen, skrivit specifikationen och godkänt den detaljerade omfattningen av arbetena.

För projekt med fast pris upprättar vi en detaljerad uppskattning först efter att upptäcktsfasen har avslutats. Vi fakturerar vanligtvis denna fas som ett separat projekt.

För Agile/Scrum-projekten använder vi ett annat tillvägagångssätt.

Enligt denna metod är produktutveckling en dynamisk och mycket flexibel process. Dess huvudsyfte är att producera en färdig lösning varannan till var fjärde vecka och anpassa sig till användarnas feedback.

Att göra en definitiv uppskattning för hela projektet passar inte riktigt för den här metoden.

I de flesta fall kan du inte riktigt förutsäga vilken form din app kommer att ta månader och år framåt i tiden. Det är därför som vi för agila projekt föredrar att använda det vi kallar Guesstimate.

Det gör det möjligt för oss att förbereda ungefärliga, men ändå extremt detaljerade uppskattningar utan att slösa bort en massa tid på upptäcktsfasen.

Vad utgör en detaljerad uppskattning?

En detaljerad uppskattning i MindK består vanligen av tre sektioner: själva uppskattningen, programvarurelaterade kostnader och riskanalys.

Skattningen

Avsnittet ger dig en uppdelning av kostnaderna för ditt projekt funktion för funktion.

För projekt med fast pris skriver vi bara ner den exakta kostnaden för varje funktion, men för de agila projekten kan vi bara ge en gissning.

I det här avsnittet tar vi inte med något annat än de funktioner som är 100 % bekräftade av våra kunder. Om de vid något tillfälle bestämmer sig för att lägga till en funktion uppskattar vi den separat och uppdaterar dokumentet.

Om ett projekt är komplext (dvs. du behöver både en webbapplikation, en iOS/Android-app, en chattbot och så vidare) uppskattas var och en av dessa komponenter separat.

Varje funktion skrivs ner i form av en user story. Detta är ett förenklat sätt att återge en funktionalitet från användarens synvinkel.

Den lyder vanligtvis: Som <roll> vill jag ha <funktion> så att <fördel> (dvs. som bloggägare vill jag ha ett prenumerationsformulär så att jag kan få prenumeranter att få uppdateringar om nya blogginlägg.).

Användarberättelser är korta, koncisa och flexibla. Men viktigast av allt är att de är extremt lätta att förstå, även om du är helt nybörjare i mjukvaruutvecklingsvärlden.

Den detaljerade uppskattningen innehåller en uppdelning av kostnaderna för varje typ av arbete:

  • Businessanalys;
  • Design;
  • Markup (HTML);
  • Utveckling;
  • Kvalitetssäkring;
  • Projektledning (PM).

Kostnaden för PM utgör vanligen cirka 25 % av slutresultatet. Den exakta procentsatsen beror på många faktorer:

  • Desto mer komplext ett projekt blir, desto mer kommunikation och förvaltning krävs.
  • Desto större teamet blir, desto mer utmanande blir ledningen, vilket resulterar i ytterligare PM-timmar.
  • Antalet integrationer med tredje part kan också påverka förvaltningskostnaderna. Förutom att det är ännu en funktion att implementera (och hantera) kräver API från tredje part ofta att våra PM:er kontaktar tjänsteleverantörerna.

Till exempel kan kommunikationen med stora företag (stora banker, stora företag etc.) som API-leverantörer vara en riktig plåga. Den höga byråkratin och de rigida hierarkistrukturerna kan förvandla en så enkel uppgift till en plågsam syssla.

I ett separat underavsnitt listar vi alla standardfunktioner.

Vår erfarenhet av mobil- och webbutveckling säger oss att vissa funktioner och uppgifter finns i alla tillämpningar. De kan till exempel omfatta inställning av servrar och utvecklingsmiljö, projektledning, Google Play-release (för Android-appar) och så vidare.

Kostnaden för tredjepartslösningar

När det gäller mjukvaruutveckling är det kostsamt och ofta meningslöst att uppfinna hjulet på nytt. Som tur är finns det för varje standarduppgift eller frekvent problem i IT-världen minst en färdig lösning. Ibland är de gratis, men i de flesta fall måste du betala för dem.

Om vi för att slutföra ett projekt måste köpa någon programvara, tjänst eller bibliotek från tredje part uppskattar vi kostnaden för dem och inkluderar siffran i dokumentet.

Om ditt projekt till exempel stöder SMS-meddelanden måste vi betala för en SMS-gateway.

Om din webbplatsdesign är baserad på en specifik färdig mall som du vill använda så lägger vi till kostnaden för den i uppskattningen.

Och om våra kunder vill att vi ska hjälpa dem med webbhotell föreslår vi dem de bästa alternativen (till exempel Amazon Web Services, DigitalOcean eller andra beprövade tjänster). Således kommer kostnaderna i samband med hosting och serverunderhåll att visas i detta avsnitt.

Riskanalys

Varje projekt medför vissa inneboende risker. Projektledarens uppgift är att identifiera dem och utveckla strategier för att hantera dem.

Trots de bästa metoderna för riskhantering materialiseras vissa av riskerna och påverkar kostnaderna för ett projekt. Vi utvärderar varje potentiell risk och inkluderar dem i den detaljerade uppskattningen.

Du behöver bara betala den angivna summan om en viss risk blir ett verkligt problem. Annars behåller du pengarna.

Dessa uppskattningar kommer sedan att tjäna oss som en försäkring mot en mängd olika faror som hotar utvecklingen av ditt projekt.

Här är exempel på riskkategorier som förekommer i produktutvecklingen:

  • Kvalitet/Tekniskt/Prestanda (i.D.v.s. användning av ny eller exceptionellt komplex teknik, teknikändring, omöjliga produktionsmål);
  • Projekthantering (d.v.s. felaktig fördelning av medel och tid, otillräcklig projektplanering);
  • Organisatorisk (d.v.s. Bristande konsekvens mellan kostnads-, tids- och omfattningsmålen, dålig prioritering, oregelbunden uppbackning);
  • Externt (dvs. ändringar i lagstiftningen, problem med leverantörer och underleverantörer, klimat).

När riskerna har identifierats prioriterar PM dem och utför en riskanalys.

Syftet är att ta reda på varje enskild risks sannolikhet (dvs. oddsen för att den ska förverkligas) och inverkan (konsekvenserna av att den förverkligas).

Ett exempel?

Som jag redan har nämnt kan API-leverantörerna vara långsamma att svara. De kan dröja med att skicka nödvändig dokumentation eller erbjuda undermålig support. Detta är en verklig risk som vi bör varna dig för i förväg. Därför lägger vi in den i avsnittet om risker och utvecklar samtidigt en effektiv riskhanteringsstrategi för att minimera hotets sannolikhet och dess inverkan.

Vidare

Nu vet du vad du kan förvänta dig av den detaljerade uppskattningen i MindK. Dokumentet ger dig ett uttömmande svar på frågan om projektets pris och hjälper dig också med budgeteringen. Slutligen kommer det att ge en tydlig bild av vad du kommer att betala för.

Är det något annat jag kan berätta om de detaljerade uppskattningarna i MindK? Skriv bara en rad så ska jag ge ett detaljerat svar!

e-book agile development

  • 19
    Aktier
  • 19