Osäkerhetskonus

Säkerhetskonus, som beskrivs av Steve McConnel, visar vad alla erfarna mjukvaruproffs vet. Vilket är att vi i början av varje projekt inte vet exakt hur lång tid ett projekt kommer att ta.

Anledningarna till detta är många. Inga två någonsin projekt har:

  1. De samma kraven.
  2. De samma människor.
  3. Den samma affärskontexten.
  4. Den samma tekniken.
  5. Den samma prioriteringarna &begränsningar.

Varje är unikt. Varje kodrad är handgjord. Och kunskapsarbete som involverar smarta kreativa människor lämpar sig inte för precision på samma sätt som dikesgrävning gör.

Ändå är det precision som efterfrågas. Sponsorer vill veta exakt när projektet kommer att vara klart och hur mycket det kommer att kosta.

Att hantera denna gåta är nästan lika gammalt som tiden. Här är några sätt för grupper och företag att hantera denna osäkerhet.

Hantering av konen

Påfyllning av uppskattningen

Ett vanligt sätt att reagera är att fördubbla eller tredubbla uppskattningen nästa gång man känner av att man underskattar. Detta sänker definitivt den initiala risken, men det är svårare än vad det låter.

Ge en för stor siffra och sponsorer kommer att tveka och inte godkänna projektet. Om du anger en för låg siffra riskerar du att få slut på pengar. Detta blir dubbelt så farligt när du lägger anbud på kontrakt med fasta anbud, där det finns ännu större tryck på att hålla siffrorna nere.

De flesta projekt lägger till någon form av utfyllnad på de slutliga siffrorna för att ge sig själva tillräckligt med svängrum. En annan sak som teamet kan göra är att jämföra projektet med andra.

Dimensionera projektet relativt

Människor är riktigt bra på att dimensionera saker relativt. Vi kan inte säga exakt hur stor en sten är. Men vi kan berätta hur stor den är jämfört med något annat. Vi kan använda detta när vi dimensionerar projekt också.

Var uppriktig och ärlig

Agiles standardförfarande är transparens och synlighet. Så det borde inte vara någon överraskning att det agila sättet att hantera konen är att vara uppriktig och ärlig.

Se. Vi vet inte hur lång tid det här kommer att ta. Detta är vår bästa gissning. Men om du ger oss några iterationer kan vi bygga något, mäta hur lång tid det tar och sedan ge dig en mycket bättre uppfattning om hur stor den här saken är.

Ett annat tillvägagångssätt som vissa agila team väljer för att hjälpa till att kommunicera osäkerheten är att presentera uppskattningarna som ett intervall.

Detta har fördelen att synligt visa sponsorer den osäkerhet som kommer med projektet, och sedan låta sponsorer bestämma hur mycket risk de har råd att ta på sig.

Förstärkande finansiering

Ett annat tillvägagångssätt som är mycket vettigt, men som jag tyvärr inte ser tillämpas tillräckligt ofta, är den ökande finansieringen.

Med ökande finansiering ber man inte om hela påsen med pengar på förhand. Bara tillräckligt mycket för att man ska kunna genomföra tillräckligt mycket av arbetet så att man kan rapportera tillbaka en bättre siffra på hur lång tid det kommer att ta.

Det är inte idiotsäkert. Du kan fortfarande råka ut för problem senare. Men genom att ge grupperna 30-50 000 dollar, låta dem bygga något och se hur lång tid det tar, kan man på ett bra sätt minska variationen i den första siffran.

Du kan läsa mer om det här sättet att planera och fördelarna med det i Beyond Budgeting av Jeremy Hope.

Rotorsaken

Vi lever i en värld av årliga budgetar. Och tyvärr driver detta en stor del av spänningen och dramatiken på vår arbetsplats. På vissa sätt är årliga budgetar naturliga (vi lever och följer tiden i årscykler) men på andra sätt är de fruktansvärda för planeringen eftersom ett år är en lång tid på marknaden.

Om du upptäcker att du blir förvirrad av osäkerhetskonusen, kom ihåg att hela poängen med uppskattning av programvara är att avgöra om projektet ens är möjligt.

Och som Steve McConnell säger:

Det primära syftet med uppskattning av programvara är inte att förutsäga resultatet av ett projekt, utan att avgöra om projektets mål är tillräckligt realistiska för att projektet ska kunna styras för att uppfylla dem.

-Steve McConnell, Software Estimation: Demystifying the Black Art

Lämna en kommentar