Hoppa till innehållet

Guider

Vad ska en betald förstudie i ett IT-projekt leverera?

· 6 min läsning

En betald förstudie ska sluta med beslut, inte bara dokument: vad som ska byggas först och vad som lämnas utanför, de största riskerna och hur de har testats, en uppskattning i form av ett intervall med dess antaganden och ett första delmål som är redo att starta. Bedöm den med ett enda test: skulle du kunna ta resultaten till ett annat team och börja bygga utan att börja om från början?

Förstudien finns till för att fatta stora beslut medan de är billiga

En förstudie, även kallad avgränsning eller discovery, är en kort betald fas före utvecklingen av en mjukvara. Dess uppgift är att ta bort den osäkerhet som gör uppskattningar opålitliga och att avgöra de stora besluten medan de fortfarande är billiga att ändra. Att ändra ett beslut på papperet kostar ett samtal; att ändra det efter att koden har skrivits kostar omarbete.

Tidiga uppskattningar av mjukvaruprojekt är breda, och de blir smalare först när beslut tar bort osäkerhet, en effekt som ofta kallas osäkerhetskonen. Möten ensamma gör dem inte smalare. En förstudie är värd att betala för när den tvingar fram de besluten: vad produkten måste göra först, vilka begränsningar som är fasta och vilka tekniska risker som är verkliga.

Kom överens om vad du ska få innan förstudien börjar

Köp en förstudie som vilken annan leverans som helst: en fast tidsram, ett fast pris, namngivna personer och en skriftlig lista över resultat. Om en partner inte kan säga vad du kommer att ha i handen i slutet kan fasen glida över i workshoppar utan slut. En fullständig uppsättning resultat omfattar oftast följande.

  • En problembeskrivning: vilka användarna är, vad de behöver och hur framgång ska mätas
  • Omfattningen för den första versionen: vad som ingår, vad som inte ingår och vad som skjuts upp
  • De viktigaste användarflödena, skissade eller prototypade där de är osäkra
  • En översiktlig arkitektur: huvudkomponenter, integrationer, data och drift, med de alternativ som övervägts
  • Ett riskregister som rangordnar det som kan få projektet att misslyckas, och hur varje risk ska hanteras
  • En uppskattning i form av ett intervall med dess antaganden, och ett första delmål med kriterier för godkännande
  • En beslutslogg som registrerar vad som beslutades, av vem och varför

Leta efter beslut, inte en hög med dokument

En rapport från en förstudie kan vara lång och ändå inte avgöra någonting. Läs den med sikte på åtaganden: vilka funktioner som ingår i den första versionen och vilka som inte gör det, vilka val av teknik och drift som har gjorts, vilka integrationer som behövs och vilka frågor som fortfarande är öppna, var och en med en ansvarig och ett datum.

En användbar signal är vad partnern avrådde från. Om omfattningen är större i slutet än i början och ingenting har strukits har förstudien troligen registrerat din önskelista snarare än prövat den. Ibland är rätt slutsats att köpa en befintlig produkt, bygga mindre eller inte bygga alls, och en bra förstudie säger det.

De mest riskfyllda antagandena ska testas, inte bara listas

Varje projekt vilar på några antaganden som skulle ändra allt om de var fel: ett externt API som inte stöder den åtgärd du behöver, data som är rörigare än väntat, ett prestandamål som den valda designen inte klarar eller användare som inte vill ändra sitt sätt att arbeta.

Be partnern att namnge de antagandena tidigt och att testa de värsta av dem under förstudien, med en teknisk spike, en klickbar prototyp eller en arbetssession med dem som driver det berörda systemet. En risk som har testats är information. En risk som bara har skrivits ner är fortfarande en gissning.

En ärlig uppskattning är ett intervall med antagandena bifogade

En enda siffra i slutet av förstudien döljer den osäkerhet som finns kvar. Be om ett intervall för den första versionen, uppdelat per huvudkomponent, med de antaganden som skulle flytta det uppåt eller nedåt. Till exempel: uppskattningen förutsätter att betalningsleverantörens API redan stöder delvisa återbetalningar; om det inte gör det tillkommer integrationsarbetet som anges separat.

Fråga vilka delar av uppskattningen som är säkra och vilka som fortfarande är osäkra, och hur affärsmodellen ska hantera var och en. Säkra delar kan prissättas till fast pris; osäkra delar behöver en budget och en punkt där du bestämmer dig på nytt. Det första delmålet ska vara så väl specificerat att det skulle kunna levereras till fast pris.

Behåll en utväg i varje steg

Förstudien är också det billigaste tillfället att hoppa av. Se till att du äger allt den producerar, från dokument och diagram till prototyper och kod, och att resultaten är skrivna för vilket kompetent team som helst, inte bara för partnern som skrev dem. Du ska vara fri att bygga med den partnern, lämna resultaten till ett annat team, bygga internt eller stoppa.

För in samma tanke i planen som följer: ett första delmål med kriterier för godkännande, och sedan en beslutspunkt där du kan fortsätta, byta kurs eller avsluta samarbetet. Så startar vi projekt hos SDK Enterprises: en skriftlig avgränsning, ett fast första delmål och namngivna utvecklare, så att du ser planen innan du binder dig till en större budget. När du bara behöver råd får du ett skriftligt svar som ditt eget team kan agera på, oavsett om du bygger med oss eller inte.

Sex frågor som visar om förstudien var värd pengarna

När fasen är slut: stäm av resultaten mot de här frågorna. Om de flesta svaren är ja köpte pengarna klarhet. Om de flesta är nej betalade du för workshoppar.

  • Skulle ett annat team kunna börja bygga utifrån de här resultaten utan att göra om förstudien?
  • Pratade partnern med användarna och med dem som driver de berörda systemen, inte bara med beställaren?
  • Testades de mest riskfyllda antagandena, och skrevs resultaten ner?
  • Är uppskattningen ett intervall med tydliga antaganden snarare än en enda siffra?
  • Ströks, sköts upp eller ifrågasattes något?
  • Är det första delmålet så väl specificerat att det kan godkännas eller underkännas?

Det viktigaste

  • Köp förstudien med en fast tidsram, ett fast pris, namngivna personer och en skriftlig lista över resultat.
  • Bedöm resultaten efter de beslut de innehåller, inklusive det som ströks eller avråddes.
  • De mest riskfyllda antagandena ska testas under förstudien, inte bara listas i ett riskregister.
  • Räkna med en uppskattning i form av ett intervall med antaganden, och ett första delmål som är tillräckligt specificerat för att prissättas.
  • Äg alla resultat, så att du kan bygga med den partnern, med ett annat team eller inte alls.

Vanliga frågor

Ska förstudien vara betald, eller kan en partner göra den gratis?

En gratis avgränsning är en del av försäljningen, så den stannar vid det som ryms i ett förslag. När du betalar för en förstudie köper du tid att läsa din kod, prata med dina användare och testa risker, och resultat som tillhör dig. Håll fasen kort och till fast pris så att åtagandet förblir litet.

Hur lång ska en förstudie vara?

Tillräckligt lång för att besvara de frågor som står i vägen för en pålitlig uppskattning, och inte längre. Kom i förväg överens om tidsramen utifrån produktens storlek och antalet berörda system, och avsluta med ett beslut om det första delmålet snarare än en förlängning av förstudien.

Vad händer om förstudien visar att projektet inte är värt att bygga?

Då har den gjort sitt jobb till lägsta möjliga kostnad. En bra förstudie kan komma fram till att du bör köpa en befintlig produkt, bygga en mindre första version eller stoppa, och du behåller slutsatserna oavsett vilket.

Berätta vad du behöver.

Något som ska byggas, personer som ska hittas eller en fråga som behöver ett svar. Under ett samtal på 30 minuter lyssnar vi och berättar ärligt hur vi kan hjälpa till, och vad som skulle krävas.

Boka ett samtal

30 minuter, på franska eller engelska. Kostnadsfritt.

Skriver du hellre? Skicka en kort förfrågan i stället.