Læsetid: 5 minutter
I softwareudvikling er det vanskeligt at opnå forudsætningen om god, hurtig og billig. Kan vi få alle tre? Er det muligt at opnå en balance? Det vil vi fortælle dig om her.
Mange af os, der arbejder i softwareindustrien, har, når vi begynder at arbejde med projekttilbud, konsultationer eller overslag, stået over for et næsten uundgåeligt must fra markedet: at udvikle god, hurtig og billig software. Er det muligt at have disse tre variabler på samme tid? Er denne idé utopisk?
For at kunne besvare dette spørgsmål og se gennemførligheden af dette postulat er det vigtigt, at vi først gennemgår to nøgleidéer.
Hvilken pris sætter man på en immateriel enhed?
Software er et immaterielt produkt; vi kan ikke se det og kender ikke dets godhed, før det er færdigt. At sætte en pris på en softwareudvikling er noget komplekst (medmindre man køber pakkesoftware i stedet for specialudviklet software), ikke kun på grund af den subjektivitet, der eksisterer af dens værdi (baseret på mange kriterier), men også på grund af de eksisterende forskelle på, om projektet er lettere eller mere komplekst at gennemføre.
Overslag, en søjle for succes
I betragtning af det uhåndgribelige er det meget vigtigt at foretage et korrekt skøn -og så nøjagtigt som muligt, da det er en tilnærmelse-, således at budgetoverskridelser og tidsspild undgås.
Indholdsrelateret: Når vi tænker på, at et godt estimat er grundlaget for et udviklingsprojekts succes, kan vi ikke ignorere det faktum, at hvert estimat omsættes til mandetimer. Den faglige kvalitet af teammedlemmerne og deres erfaringer er direkte proportional med omkostningerne ved udviklingen.
Kort sagt, når vi ved, at estimering, planlægning og udførelse af et projekt udføres af mennesker, kan vi udlede, at kvaliteten og ekspertisen hos de professionelle påvirker omkostningerne ved et projekt.
Den gode, den hurtige og den billige
Når vi har forstået, at software er en immateriel enhed, hvis pris er vanskelig at definere, især hvis der ikke er en klar vurdering, vil vi fortsætte med at forklare egenskaberne ved den gode, den hurtige og den billige, og hvordan det er muligt at kombinere dem, men ikke at have dem alle tre på samme tid.
Godt og hurtigt
Det er muligt at gøre noget godt med hurtighed. For at opnå dette er det vigtigt at lave et godt estimat og derefter have en god udførelsesplan for projektet, så hastigheden ikke påvirker kvaliteten af resultatet.
Nøglen til at opnå kvalitet og hastighed ligger i de mennesker, der arbejder på projektet, som skal være kvalificerede nok til at tackle projektet. Husk, at kvaliteten af de fagfolk er en afgørende faktor for omkostningerne.
Tænk på, at hastighed kan virke modproduktivt på produktiviteten: I teorien kan et team (og dets medlemmer) nå sit produktionstempo på en given tid og fastholde det indtil projektets afslutning. Jo højere hastighed, jo kortere tid vil holdet være på topproduktivitet.
Likeledes vil koordination også være en faktor, der skal analyseres: Jo flere personer, der arbejder parallelt, jo større koordinering kræves der (måske bør der tilføjes flere personer som koordinatorer).
Det gode og hurtige gælder især for kritiske eller centrale projekter, hvor produktets kvalitet skal sikres for enhver pris. I disse tilfælde er det nødvendigt at have teams med stor erfaring. Hvis dette er tilfældet, vil løsningen være god og hurtig, men også dyr.
Snav og billig
Her er den anden af vores kombinationer af de tre variabler: Den enkleste måde at gøre noget hurtigt og billigt på er at gøre det uden kvalitet eller i det mindste at være opmærksom på, at den kan være ringere end den ønskede kvalitet. Vi kan ofre kvaliteten op til et vist punkt, så længe softwaren ikke håndterer kritiske oplysninger, eller den ikke afhænger af en eller anden følsom del af organisationen.
For at opnå hastighedseffekter – da kvaliteten af applikationen i fremtiden kan forbedres – er det muligt at gå i produktion med de nøglefunktioner, der er nødvendige for at produktet kan fungere. I disse tilfælde kan man gøre følgende:
- Mindske kvaliteten af koden
- Simplificere dens brugervenlighed
- Lad kodegennemgangene ligge til side
- Reducer kvalitetskontroller og testning.
Derved får vi højst sandsynligt et værktøj med en grundlæggende funktionalitet, men vi får ikke et 100 % tilfredsstillende produkt. Dets anvendelighed er måske ikke den bedste, ligesom kvaliteten af koden, og dets udvidelsesmuligheder (mulighed for ændring eller udvidelse) og genanvendelighed kan være problematiske.
Dette gælder for demoapplikationer, koncepttest, ikke-kritisk software eller enhver applikation, der er skalerbar eller kan udvides over tid.
Godt og billigt
Jeg giver dig den sidste af vores ligninger: Hvis kunden ønsker en god og billig løsning, kan han ikke forvente en hurtig levering.
Det kan lade sig gøre at lave noget godt og til en acceptabel pris, men på bekostning af tiden. Grundlæggende er det sådan, at hvis der er tid, er det nemmere at planlægge – da der ikke er så mange opgaver parallelt, og der kræves ikke så meget koordinering – og produktivitetstoppen for de involverede personer vil være på sit højeste i længere tid.
Det at få noget godt og billigt er velegnet til projekter, hvor tid ikke er en kritisk variabel, samt til inkrementelle projekter eller med teams med deltider (som har interne projekter eller initiativer).
Du må ikke gå glip af dette: Softwarekvalitet eller pris:
Sammenfattende
I softwareudvikling er det meget vanskeligt at opfylde postulatet om god, hurtig og billig softwareudvikling. Vi vil altid være i stand til at få to af dem, men vi bliver nødt til at opgive det resterende. På denne måde er det muligt at opnå kvalitet på fastsatte tidspunkter og til en rimelig pris; det er blot nødvendigt at vide, hvordan man finder balancen mellem disse tre variabler, kende konsekvenserne og vide, hvordan de hænger sammen med hinanden, for at nå denne balance.
Det vil være muligt at opnå denne balance, så længe skønnene, koordineringen, udvælgelsen af holdet, arbejdsmetoderne og brugen af værktøjer og teknologier er de rigtige.
Har du opnået en balance mellem disse variabler i et projekt? Hvordan har du gjort det?
