Lästid: 5 minuter
I mjukvaruutveckling är det svårt att uppnå förutsättningen att vara bra, snabb och billig. Kan vi få alla tre? Är det möjligt att uppnå en balans? Vi ska berätta om det här.
Många av oss som arbetar inom mjukvarubranschen har, när vi börjar arbeta med projektofferter, konsultationer eller uppskattningar, ställts inför ett nästan oundvikligt måste från marknaden: att utveckla bra, snabb och billig programvara. Är det möjligt att ha dessa tre variabler samtidigt? Är denna idé utopisk?
För att kunna besvara denna fråga och se om detta postulat är genomförbart är det viktigt att vi först går igenom två viktiga idéer.
Vilket pris sätter man på en immateriell enhet?
Mjukvara är en immateriell produkt; vi kan inte se den, och vi kan inte heller veta hur bra den är förrän den är färdig. Att sätta ett pris på en mjukvaruutveckling är något komplicerat (om man inte köper paketerad mjukvara i stället för skräddarsydd utveckling), inte bara på grund av den subjektivitet som finns när det gäller dess värde (baserat på många kriterier), utan också på grund av de existerande skillnaderna i fråga om huruvida projektet är lättare eller mer komplicerat att genomföra.
Skattningar, en grundpelare för framgång
Med tanke på den immateriella situationen är det mycket viktigt att göra en korrekt skattning – och så exakt som möjligt, eftersom det är en uppskattning – så att budgetöverskridanden och tidsförluster undviks.
Innehållsrelaterat: Om vi tänker på att en bra uppskattning är grunden för att ett utvecklingsprojekt ska lyckas, kan vi inte bortse från det faktum att varje uppskattning översätts till arbetstimmar. Lagmedlemmarnas yrkesmässiga kvalitet och erfarenheter är direkt proportionella mot utvecklingskostnaden.
Som vi vet att uppskattningen, planeringen och genomförandet av ett projekt utförs av människor kan vi kort sagt dra slutsatsen att yrkesmännens kvalitet och expertis påverkar kostnaden för ett projekt.
Det goda, det snabba och det billiga
När vi har förstått att programvara är en immateriell enhet vars pris är svårt att definiera, särskilt om det inte finns någon tydlig uppskattning, ska vi fortsätta att förklara attributen för det goda, det snabba och det billiga och hur det är möjligt att kombinera dem, men inte ha alla tre samtidigt.
Gott och snabbt
Det är möjligt att göra något bra med snabbhet. För att uppnå detta är det viktigt att göra en bra uppskattning och sedan ha en bra genomförandeplan för projektet så att hastigheten inte påverkar resultatets kvalitet.
Nyckeln till att uppnå kvalitet och snabbhet ligger i de personer som arbetar med projektet, som måste vara tillräckligt kvalificerade för att ta sig an projektet. Kom ihåg att de professionellas kvalitet är en avgörande faktor för kostnaden.
Tänk på att snabbhet kan vara kontraproduktivt för produktiviteten: I teorin når ett team (och dess medlemmar) sin produktionstopp på en viss tid och bibehåller den fram till projektets slut. Ju högre hastighet, desto kortare tid kommer teamet att vara vid sin högsta produktivitet.
På samma sätt kommer samordning också att vara en faktor att analysera: Ju fler personer som arbetar parallellt, desto större samordning krävs (kanske bör fler personer läggas till som samordnare).
Det goda och snabba gäller särskilt för kritiska eller viktiga projekt, där produktens kvalitet måste garanteras till varje pris. I dessa fall är det nödvändigt att ha team med stor erfarenhet. Om så är fallet blir lösningen bra och snabb, men också dyr.
Snabbt och billigt
Här är den andra av våra kombinationer av de tre variablerna: Det enklaste sättet att göra något snabbt och billigt är att göra det utan kvalitet eller åtminstone vara medveten om att den kan vara sämre än den önskade. Vi kan offra kvaliteten upp till en viss punkt, så länge programvaran inte hanterar kritisk information eller är beroende av någon känslig del av organisationen.
För snabbhetseffekter – eftersom kvaliteten på applikationen i framtiden kan förbättras – är det möjligt att gå in i produktion med de viktigaste funktionerna för att produkten ska fungera. I dessa fall är det här vad som kan göras:
- Minimera kvaliteten på koden
- Förenkla användbarheten
- Lämna kodgranskningarna åt sidan
- Reducera kvalitetskontroller och testning.
Genom att göra detta får vi med största sannolikhet ett verktyg med en grundläggande funktionalitet, men vi kommer inte att få en 100 % tillfredställande produkt. Användbarheten kanske inte är den bästa, liksom kvaliteten på koden, och dess utbyggbarhet (möjlighet till ändring eller utvidgning) och återanvändbarhet kan vara problematiska.
Detta gäller för demoapplikationer, koncepttestning, icke-kritisk programvara eller någon applikation som är skalbar eller utbyggbar med tiden.
Gott och billigt
Jag ger dig de sista av våra ekvationer: Om kunden vill ha en bra och billig lösning kan han inte förvänta sig en snabb leverans.
Något bra och till en acceptabel kostnad kan göras, men på bekostnad av tiden. I grund och botten, om det finns tid är det lättare att planera – eftersom det inte finns så många uppgifter parallellt och det krävs inte lika mycket samordning – och produktivitetstoppen för de inblandade personerna kommer att vara på topp längre.
Att få något bra och billigt är lämpligt för projekt där tiden inte är en kritisk variabel, liksom för inkrementella projekt eller med team med partiella tider (som har interna projekt eller initiativ).
Missa inte det här: Programvarukvalitet eller pris:
Sammanfattningsvis
I programvaruutveckling är det mycket svårt att uppnå postulatet att programvaruutvecklingen ska vara bra, snabb och billig. Vi kommer alltid att kunna få två av dem, men vi måste överge den återstående. På detta sätt är det möjligt att uppnå kvalitet inom stipulerade tider och till en rimlig kostnad; det är bara nödvändigt att veta hur man hittar balansen mellan dessa tre variabler, känna till konsekvenserna och hur de hänger ihop med varandra för att nå denna balans.
Det är möjligt att uppnå denna jämvikt så länge som uppskattningarna, samordningen, urvalet av team, arbetsmetoderna och användningen av verktyg och teknik är de rätta.
Har du uppnått en balans mellan dessa variabler i något projekt? Hur gjorde du det?
