När du som kund kommer till oss med en idé om en lösning ditt företag vill bygga är ofta det första steget en förstudie där vi tillsammans skapar oss en övergripande förståelse för projektets omfattning, krav och kostnader innan det faktiska arbetet påbörjas. Det är helt enkelt här vi sätter ramarna för vad som behöver göras. Därför är det också först efter genomförd förstudie som vi kan ge en realistisk uppskattning på vad investeringen kommer landa på.
Det är dock viktigt att nämna att vi innan en påbörjad förstudie kan ge någon typ av kostnadsestimering, men då rätt mycket mellan tummen och pekfingret – som i det här fallet hålls långt ifrån varandra. Vanligtvis kan vi ge en “från-kostnad”, något som vi gör i artikeln Vad kostar det att utveckla mjukvara?, där vi ger exempel på vad några mjukvarulösningar kan kosta. Här bortser vi dock från en hel del funktioner som kunden ofta både behöver och vill ha och vi anger alltså något slags grundpris. Det är därför viktigt att vara medveten om att investeringen ofta blir större.
När förstudien sedan är genomförd och vi vet mer om projektet reviderar vi det estimat som tidigare getts.
Första stegen i processen för att utveckla mjukvara kan delvis liknas med att bygga ett hus. Och har du någonsin hört om någon som vänt sig till en snickare och sagt:
“Jag vill bygga ett hus, vad kostar det?”
Och fått svaret:
“Absolut, 2,5 miljoner kronor. Jag sätter igång direkt.”
Inte? Tänkte väl det. För att ens kunna börja tänka på husbygget måste snickaren först se en ritning gjord av en arkitekt. Dessutom kommer du behöva svara på en massa frågor – och inte bara från snickaren utan även från andra experter. De måste veta storlek, materialval, hur tomten ser ut, vad för typ av värme du ska ha och mycket, mycket mer. Det är alltså många saker du behöver ta ställning till innan det första spadtaget kan tas – och innan du kan få ett hum om vad kostnaden kan bli. Har du förresten någonsin hört talas om ett byggprojekt som håller sig till budget? Inte? Tänkte väl det.
Självklart finns det undantag. Men ofta, till och med väldigt ofta, drar husbyggen iväg både pengamässigt och tidsmässigt. Och vi ska inte ljuga – relativt ofta är det också fallet för mjukvaruutveckling. Men för att i möjligaste mån försöka undvika detta genomför vi alltså en förstudie, där en del består av själva offertarbetet.
Förstudien är alltså det första steget när vi påbörjar ett nytt projekt, och nödvändigt för att vi ska ta reda på mer om omfattningen. Den genomförs med hjälp av intervjuer, workshops och genom att gräva i relevanta system och kodbaser hos kunden.
Vi ser förstudien som en begränsad investering för våra kunder där vi minimerar risker i ett projekt. Vi identifierar potentiella risker och produkt- och projektkrav samt undersöker teknisk genomförbarhet. Detta resulterar i ett underlag för beslutsfattare hos kunden som skapar bättre förutsättningar för att framöver kunna ta viktiga beslut. Efter det arbetet har vi en tydligare bild av investeringen som behöver göras av dig som kund.
Under arbetets gång fokuserar vi på främst tre frågor:
Nu låter kanske detta som att det har med vår tekniska kompetens att göra, men nej – den finns alltid där! Om vi rent tekniskt kan bygga mjukvaran syftar mer på om det, med tanke på de förutsättningar som finns hos kunden, går att utveckla lösningen. Till exempel har vi tidigare befunnit oss i situationer där kunden vill ha data från ett visst system som saknade API, vilket betyder att det är en omöjlighet att transportera data. Första steget blev alltså att skapa ett API istället för att påbörja det tilltänkta projektet. Något som direkt påverkar budgeten.
Mycket av den mjukvara vi bygger är inte bara till för våra kunder utan även för kundens kunder. Ibland kanske endast för dem. Men då det är kunden och inte slutanvändaren som driver projektet är det lätt att gå miste om värdefulla insikter. Vi försöker därför sätta oss in i slutanvändarens perspektiv för att se det slutgiltiga värdet lösningen ska skapa. Detta kallas ofta för perceived usefulness och är ett välkänt begrepp när det kommer till modeller för teknologiacceptans.
Utöver perceived usefulness tittar vi även på perceived ease of use, något som också påverkar det slutgiltiga värdet då det har att göra med hur lättanvänd lösningen uppfattas vara. En lösning som användarna verkligen behöver men som är svår att använda minskar motivationen att använda den, på samma sätt som en användarvänlig lösning utan något tydligt värde gör.
För att vara säkra på att uppnå både perceived usefulness och perceived ease of use diskuterar vi lösningens innehåll och projektets upplägg med både våra kunder och användarna för att kunna ta fram de slutgiltiga designförslagen.
Vi kollar här på om lösningen ni vill ha i er verksamhet passar in och fungerar med den affärsmodell ni har. Det kan ha att göra med alltifrån intäktsströmmar och kundsegment till nyckelresurser och aktiviteter. Med våra tränade ögon kan vi dessutom lätt identifiera flera möjligheter ni kanske inte ser själva, exempelvis data som kan användas på flera ställen där den inte tidigare gjorts.
Tack vare frågorna ovan får vi svar på det mesta vi behöver för att kunna planera projektet, inklusive saker som resursbehov, riskhantering och klarläggande av krav. Andra frågor som kan vara viktiga att svara på i en förstudie är:
Vi bryter sedan ner lösningen till mindre leverabler som alla får egna estimat. Till sist sammanställer vi en kravbild som vi går igenom med er – allt för att säkerställa att vi inte missar viktiga områden och detaljer.
Att ta fram mjukvara är ett omfattande projekt som kräver en hel del förarbete innan det egentliga utvecklingsarbetet kan komma igång. Den information vi samlar in och analyserar under förstudiens gång behövs för att vi ska kunna skissa på en lösning men också för att ta reda på om förutsättningarna för att bygga lösningen finns – eller om det är något vi tillsammans med kunden behöver titta på först.
Offertarbetet blir ett naturligt resultat av förstudien då den ger oss möjlighet att bättre förstå projektets krav och utmaningar. Genom att i förstudien kartlägga projektets komplexitet kan vi skapa en offert som försöker speglar de verkliga kostnaderna och tidsåtagandena. Men det är viktigt att komma ihåg att mycket kan hända på vägen när det gäller mjukvaruutveckling. Läs mer om varför det är svårt att uppskatta kostnaden för mjukvara.
Block QuoteTillbaka
