Konsekvenser av mjukvaruprojekt med fast pris

Fritt översatt till svenska från denna artikel i Dr. Dobbs Journal.

”Fastpris”-projekt är praxis i IT-industrin, antingen som ett resultat av en budgivningsprocess mellan konkurrerande mjukvaruföretag, eller ett budgetteringstryck om det gäller ett internsystem. Jag sätter citattecken kring ”fastpris” eftersom mjukvaruprojekt har en tendens att spränga budget, men för denna diskussions skull kan vi låta detta faktum vila därhän.

Organisationer föredrar ofta fastpris-projekt i ett försök att minimera finansiell risk. I praktiken är det tvärtom: de drar på sig risk när de begär fixt pris på ett projekt. Alla verkar veta om detta, men av någon anledning kan vi inte ta oss ur denna mossiga affärsmodell. I denna artikel ska jag diskutera de problem som omger IT-projekt som säljs in med ett på förhand fixerat pris i ett försök att motivera dig att gå ifrån detta tveksamma arbetssätt.

Det fundamentala problemet med fastpris-projekt är att de uppmuntrar dig att göra högst tvivelaktiga saker, som oundvikligen leder till bortkastade resurser. Det är nämligen så att för att göra en god uppskattning krävs förståelse för de krav som ska uppfyllas för projektets slutförande, och förståelse för den miljö programmet ska köras i. Ju större behov av en exakt uppskattning, desto större behov av detaljerad information. Detta betyder att följande mer eller mindre krävs av dig:

1. En kravanalys före projektets start eller mycket tidigt i projektets livscykel, som resulterar i en rejäl kravspecifikation
2. En mekanism för att hantera förändringar i denna kravspecifikation (för att undvika ”glidande målbild”)
3. En stor, tidig design/arkitektur av programmet, innan programmets implementation påbörjas
4. En mjukvaruutvecklingsprocess som är nästintill linjär i sin natur.

Låt oss undersöka de grundläggande problem som finns med var och en av dessa punkter.

Först av allt, svårigheten med att göra en tidig kravanalys är att människor har svårt att säga exakt vad det är de vill ha; de vet inte detta själva helt enkelt. Folk är bra på att tydliggöra sitt syfte och när de får se ett gränssnitt eller körbart program kan de säge vad de gillar och inte gillar, och hur de vill ha det istället. Genom att göra iterationer (korta utvecklingscykler) kan vi ”målsöka” oss fram till vad de egentligen är ute efter, men det betyder också att vi kommer att flyta iväg från vad vi trodde var krav på programvaran från början (de krav som våran första tidsuppskattning var baserad på!). Sådana ”kravförändringar” är egentligen ”förståelseförändringar” hos oss själva, och medför en risk att projektet spräcker budget. Resultatet blir att du förmodligen har en bra uppskattning på hur lång tid det kommer att ta att utveckla något som kunden inte vill ha, eller en inprecis tidsupskattning på vad folk vill ha.

För det andra så är många mekanismer för att hantera ”kravförändring” egentligen ett sätt att bromsa alla önskemål från kunden, t.ex. om de ändrar sig om vad de vill ha när de förstått programvaran bättre. En sådan mekanism ökar chansen att programvaran följer specifikationen, men minskar chansen att den verkligen infriar de önskemål som finns hos kunden. Resultatet av detta är att en massa pengar spenderas på saker som kunden egentligen inte vill ha, och lite pengar spenderas på det de verkligen vill ha.

För det tredje, att designa/bestämma arkitektur för programvara innan utvecklingen av densamma, är opraktiskt. Om man i förväg bestämmer i detalj hur systemet ska vara uppbyggt, vid ett tillfälle då man har som minst kunskap om kundens önskemål (under första månaden i ett projekt har man väsentligt mindre information tillgänglig jämfört med i tionde månaden) är mindre bra. När besluten tagits, är man motiverad att följa dem, eftersom man gjort en massa jobb för att ta fram designen. Ännu värre, om det var någon del av kravanalysen som inte var riktigt korrekt (som vi sett ofta är fallet!) kan det kvitta hur smart uttänkt designen var, den är helt enkelt baserad på fel underlag.

För det fjärde: punkt två och tre är båda två aspekter på en linjär process. Linjära processer medger få inspektionspunkter för kund och ökar därmed risken för hela projektet. Även om kunden oftast är aktiv i kravanalysen, förminskas hans roll dramatiskt i design- och utvecklingsfasen, för att komma med igen först vid testning långt senare. Ibland finns det milstenar, då genomgång av kravdokument och andra tekniska artefakter sker, men mestadels kan man se mjukvaruutvecklingsprocessen som en svart låda: kunden vet inte vad han får förrän mot projektets slutfas.

Tråkigt nog är de flesta tidsuppskattningar inte alls så bra i praktiken. Oavsett hur detaljerad kravspecifikation och designen är, finns alltid osäkerheten. Så för att minska risken lägger utvecklarna på så mycket tid det går utan att förlora kunden, för att få en buffert av tid att ta av, utifall någon uppskattning är felaktig. I realiteten flyttar utvecklarna så mycket finansiell risk över på kunden som möjligt, vilket strider emot att över huvud taget ha ett fast pris.

Som regel går utvecklingsprojekt över tiden, och oftast får kunden betala för detta. Paradoxalt nog ger detta ytterligare vatten på kvarnen att nästa gång göra en ”ännu bättre tidsuppskattning”, och så är vi där igen.

Alternativet till fastpris är såklart projekt med variabelt pris. I praktiken är det mycket lättare att reducera finansiell risk när man har att göra med variabelt pris, genom att kräva fungerande (om än ej komplett) programvara under vägens gång. Detta sätt att attackera problemet kräver en god relation mellan utvecklingsföretaget och kunden, och dessutom en kund som aktivt deltar i projektutvecklingen.

Fastpris-projekt är inte bra för utvecklare då de uppmuntrar tveksamma beteenden som på sikt sätter anställningen på prov. Fastpris-projekt är inte heller bra för kund, då de ger ökad finansiell risk istället för att minska den, som utlovat.

Det är dags att tänka om när det gäller den affärsmodell vi är vana att se i IT-industrin.

Läs även andra bloggares åsikter om programmering, riskhantering, mjukvarubranschen, projektledning, fastpris, it-branschen, vattenfallsmodellen, agile, agila metoder