Reading Time: 5 minutes
A szoftverfejlesztésben a jó, gyors és olcsó előfeltételét nehéz megvalósítani. Vajon mindhárom megvalósítható? Lehetséges-e egyensúlyt teremteni? Erről mesélünk itt.
A szoftveriparban dolgozók közül sokan, amikor elkezdünk projektajánlatokkal, konzultációkkal vagy becslésekkel foglalkozni, szembesülünk a piac szinte megkerülhetetlen kényszerével: jó, gyors és olcsó szoftvert kell fejleszteni. Lehetséges ez a három változó egyszerre? Utópisztikus ez az elképzelés?
Azért, hogy megválaszoljuk ezt a kérdést, és lássuk ennek a posztulátumnak a megvalósíthatóságát, fontos, hogy először két kulcsfontosságú gondolatot tekintsünk át.
Milyen árat szabunk egy immateriális egységnek?
A szoftver egy immateriális termék; nem láthatjuk, és nem tudhatjuk a jóságát, amíg el nem készül. Egy szoftverfejlesztésre árat szabni valami bonyolult dolog (hacsak nem vásárolunk csomagolt szoftvert egyedi fejlesztés helyett), nem csak az értékének szubjektivitása miatt, ami létezik (számos kritérium alapján), hanem a létező különbségek miatt is, hogy a projektet könnyebb vagy bonyolultabb megvalósítani.
A becslések, a siker egyik pillére
Az immateriális javak csomópontját tekintve a helyes – és a lehető legpontosabb, mivel közelítő becslésről van szó – becslés elkészítése nagyon fontos, hogy elkerülhető legyen a költségvetés túllépése és az időveszteség.
A tartalommal kapcsolatos:
Tartva szem előtt, hogy a jó becslés a fejlesztési projekt sikerének alapja, nem hagyhatjuk figyelmen kívül azt a tényt, hogy minden becslést lefordítunk munkaórákra. A csapattagok szakmai minősége és tapasztalata egyenesen arányos a fejlesztés költségeivel.
Röviden, tudva, hogy egy projekt becslését, tervezését és kivitelezését emberek végzik, levonhatjuk a következtetést, hogy a szakemberek minősége és szakértelme befolyásolja a projekt költségeit.
A jó, a gyors és az olcsó
Miután megértettük, hogy a szoftver egy immateriális egység, amelynek az árát nehéz meghatározni, különösen, ha nincs egyértelmű becslés, folytassuk a jó, a gyors és az olcsó tulajdonságainak ismertetését, és azt, hogy hogyan lehet ezeket kombinálni, de nem lehet mindhárom egyszerre.
Jó és gyors
A gyorsasággal lehet valami jót tenni. Ehhez elengedhetetlen a jó becslés, majd a projekt jó kiviteli terve, hogy a sebesség ne befolyásolja az eredmény minőségét.
A minőség és a sebesség elérésének kulcsa a projekten dolgozó emberekben rejlik, akiknek elég képzettnek kell lenniük a projekt megoldásához. Ne feledje, hogy a szakemberek minősége meghatározó tényező a költségek szempontjából.
Ne feledje, hogy a sebesség a termelékenységgel ellentétes hatást gyakorolhat: Elméletileg egy csapat (és annak tagjai) egy adott idő alatt eléri a termelési csúcsot, és azt a projekt végéig fenntartja. Minél nagyobb a sebesség, annál rövidebb ideig lesz a csapat a termelékenységi csúcson.
Hasonlóképpen a koordináció is elemzendő tényező lesz: Minél több ember dolgozik párhuzamosan, annál nagyobb koordinációra van szükség (esetleg több embert kell felvenni koordinátornak).
A jó és gyors különösen a kritikus vagy kulcsfontosságú projektekre vonatkozik, ahol a termék minőségét mindenáron garantálni kell. Ezekben az esetekben nagy tapasztalattal rendelkező csapatokra van szükség. Ha ez a helyzet, akkor a megoldás jó és gyors, de drága is lesz.
Gyors és olcsó
Itt a második a három változó kombinációi közül: A legegyszerűbb módja annak, hogy valamit gyorsan és olcsón, minőség nélkül, vagy legalábbis annak tudatában, hogy az a kívántnál gyengébb lehet. Egy bizonyos pontig feláldozhatjuk a minőséget, amíg a szoftver nem kezel kritikus információkat, vagy nem függ a szervezet valamilyen érzékeny részétől.
A gyorsasági hatások miatt -mert a jövőben az alkalmazás minősége javítható-, lehetséges, hogy a termék működéséhez szükséges legfontosabb funkciókkal megyünk a gyártásba. Ezekben az esetekben a következőket lehet tenni:
- Minimáljuk a kód minőségét
- Egyszerűsítsük a használhatóságot
- Hagyjuk el a kód felülvizsgálatát
- Rövidítsük a minőségellenőrzést és a tesztelést.
Ezzel valószínűleg egy alapvető funkciókkal rendelkező eszközt kapunk, de nem kapunk 100%-ban kielégítő terméket. A használhatósága nem biztos, hogy a legjobb, ahogy a kód minősége sem, és a bővíthetősége (változtatás vagy bővítés lehetősége) és az újrafelhasználhatósága is problémás lehet.
Ez vonatkozik a demóalkalmazásokra, a koncepciótesztelésre, a nem kritikus szoftverekre, illetve minden olyan alkalmazásra, amely idővel skálázható vagy bővíthető.
Jó és olcsó
Az utolsó egyenletünket adom: Ha az ügyfél jó és olcsó megoldást akar, nem várhatja el, hogy gyorsan elkészüljön.
Egy jó és elfogadható áron elkészülhet, de az idő rovására. Alapvetően, ha van idő, könnyebb tervezni -mert nincs annyi feladat párhuzamosan, és nincs szükség annyi koordinációra-, és az érintettek termelékenységi csúcsa hosszabb ideig lesz a csúcson.
Az, hogy valami jó és olcsó legyen, olyan projekteknél megfelelő, ahol az idő nem kritikus változó, valamint inkrementális projekteknél vagy részidőkkel rendelkező csapatoknál (amelyeknek belső projektjeik vagy kezdeményezéseik vannak).
Ne hagyjuk ki ezt: Szoftverminőség vagy ár:
Összefoglalva
A szoftverfejlesztésben a jó, gyors és olcsó szoftverfejlesztés posztulátumát nagyon nehéz elérni. Kettőt mindig el tudunk érni belőlük, de a maradékról le kell mondanunk. Így lehetséges a minőséget meghatározott időn belül és elfogadható áron elérni; csak tudni kell, hogyan találjuk meg az egyensúlyt e három változó között, ismerni kell a következményeket, és tudni kell, hogyan függnek össze egymással ahhoz, hogy ezt az egyensúlyt elérjük.
Az egyensúly elérése mindaddig lehetséges, amíg a becslések, a koordináció, a csapat kiválasztása, a munkamódszertan, valamint az eszközök és technológiák használata a megfelelőek.
Elérte már az egyensúlyt ezen változók között valamelyik projektben? Hogyan sikerült?
