Egyedi szoftvernél a gyors, az olcsó és a jó egyszerre nem jön össze, de a népszerű „válassz kettőt” szabály sem pontos. A minőséggel nem érdemes alkudozni, mert a belső minőségen spórolt idő hamar visszaüt lassabb és drágább fejlesztésben. A valódi mozgástér a terjedelem, vagyis az, hogy mi kerül bele az első verzióba. Ezért nem azt kérdezzük az ügyféltől, hogy a három közül melyikről mond le, hanem azt, hogy nála mi a fix: a határidő, a keret vagy a funkciólista.
A „gyorsan és olcsón” kérés teljesen érthető. Aki vállalkozást visz, annak minden hét és minden forint számít. A gond ott kezdődik, amikor a kérés mögött az a feltételezés áll, hogy valahol van egy fejlesztő, aki ugyanazt adja kevesebbért és hamarabb. Ilyenkor általában nem ugyanazt kapod, csak a különbség később derül ki.
- A projektháromszög klasszikus oldalai: idő, költség, terjedelem. A minőség ezek eredménye, nem egy negyedik csúszka.
- A belső minőségen (tesztek, áttekinthető kód, átgondolt szerkezet) spórolni Martin Fowler szerint nem olcsóbb, mert a következő fejlesztéseket lassítja.
- A DORA kutatásai szerint a gyorsaság és a stabilitás nem egymás rovására megy.
- Késésben lévő projektre több embert tenni ritkán segít (Brooks törvénye).
- Nálunk a döntés menete: rögzítjük, mi fix, a terjedelmet MoSCoW szerint rangsoroljuk, rövid szakaszokban szállítunk, és leírjuk, mit hagytunk ki.
Honnan jön a háromszög, és mit mond valójában?
A projektmenedzsment-háromszöget (angolul iron triangle vagy triple constraint) általában Martin Barnes nevéhez kötik, 1969-ből, bár a Wikipedia szócikke szerint a pontos eredete bizonytalan. A modell három oldala az idő, a költség és a terjedelem. A lényege, hogy a minőséget ez a három határozza meg, és ha az egyiken változtatsz, a többinek is mozdulnia kell.
A mémmé vált változat („gyors, olcsó, jó – válassz kettőt”) ezt leegyszerűsíti, és a minőséget teszi meg az egyik csúszkának. Szerintünk itt van a csapda. Ha a minőség csúszka, akkor a „gyors és olcsó” kombináció logikusnak tűnik: kicsit rosszabb lesz, de hamar és olcsón kész. Szoftvernél viszont a gyengébb minőség nem egyszeri engedmény, hanem kamatozó tartozás.
Miért nem jó alkudozási tétel a minőség?
Martin Fowler Is High Quality Software Worth the Cost? című írása különválasztja a külső és a belső minőséget. A külső az, amit a felhasználó lát: működik-e, kényelmes-e. A belső az, amit csak a fejlesztő lát: mennyire áttekinthető a kód, vannak-e tesztek, mennyire könnyű módosítani. Fowler szerint a belső minőség nem drágítja, hanem olcsóbbá teszi a fejlesztést, mert a következő funkciók gyorsabban és kevesebb hibával készülnek el. A tapasztalatuk az, hogy a rendetlen kódbázis nem évek, hanem jellemzően már hetek alatt lassítani kezdi a munkát.
Ugyanezt írta le Ward Cunningham 1992-ben, amikor bevezette a technikai adósság fogalmát: egy kis adósság gyorsíthat, ha hamar visszafizeted, a veszély az, ha soha. Minden perc, amit a „majdnem jó” kóddal töltesz, kamatként jelentkezik.
A DORA (DevOps Research and Assessment) kutatási program évek óta méri a szoftverszállítás teljesítményét, és a saját összefoglalója szerint a kutatásaik ismételten azt mutatják, hogy a gyorsaság és a stabilitás nem egymás ellen dolgozik. Vagyis nem az a csapat szállít gyorsan, amelyik lazábban veszi a minőséget.
A gyakorlatban ez azt jelenti, hogy a „gyorsan és olcsón, majd később rendbe tesszük” ritkán marad olcsó. A „később” ugyanis általában akkor jön el, amikor a rendszer már élesben fut, adatok vannak benne, és minden módosítás kockázatosabb.
Miért nem lesz gyorsabb, ha több embert teszünk rá?
A gyorsítás legkézenfekvőbb ötlete a létszám növelése. Fred Brooks 1975-ös könyvében, a The Mythical Man-Month-ban fogalmazta meg azt, amit ma Brooks törvényeként ismerünk: késésben lévő szoftverprojektre több embert tenni csak tovább késlelteti. Az új embereknek idő kell, mire beletanulnak, és minden új taggal nő az egyeztetési teher. Brooks maga is túlzó leegyszerűsítésnek nevezte, de az iránya stimmel.
Ugyanez igaz az „olcsó” oldalra. Az alacsonyabb óradíj nem jelent alacsonyabb teljes költséget: ha a munka kétszer annyi ideig tart, vagy a felét újra kell írni, a végösszeg magasabb lesz. Mi ezért kis, állandó maggal dolgozunk, és partnert csak jól elkülöníthető részfeladatra vonunk be.
Hogyan hozunk döntést az ügyféllel?
A háromszöget nem elméletként használjuk, hanem az első egyeztetés kérdéseként. Négy lépésben szoktuk végigvinni.
1. Kiderítjük, mi a valóban fix
Szinte minden projektnél van egy kemény korlát. Lehet ez egy határidő (szezonkezdet, vásár, jogszabályi dátum), egy jóváhagyott keret, vagy egy funkciókör, ami nélkül nincs értelme élesíteni. Mindhárom egyszerre ritkán kőbe vésett, és ha mégis, azt jobb az elején kimondani.
| Mi fix? | Mi mozdulhat? | Tipikus helyzet |
|---|---|---|
| A határidő | A terjedelem | Szezonhoz kötött webshopindulás, kampány |
| A keret | A terjedelem és az ütemezés | Első verzió egy ötlet kipróbálására |
| A funkciókör | Az idő | Jogszabályi megfelelés, régi rendszer kiváltása |
Észreveheted, hogy a minőség egyik sorban sincs a „mozdulhat” oszlopban. Ez szándékos.
2. A terjedelmet rangsoroljuk, nem alkudozunk rajta
A funkciólistát a DSDM-ből ismert MoSCoW-módszerrel soroljuk be: Must have (enélkül nem élesítünk), Should have (fontos, de van rá átmeneti megoldás), Could have (jó, ha belefér) és Won't have this time (most biztosan nem). A módszert gondozó Agile Business Consortium azt javasolja, hogy a kötelező elemek a ráfordításnak legfeljebb nagyjából 60 százalékát vigyék el, így marad tartalék a meglepetésekre.
3. Rövid, időkeretes szakaszokban szállítunk
Egy hosszú, egyben átadott projekt helyett rövid szakaszokra bontunk, és mindegyik végén működő, kipróbálható állapotot mutatunk. Így a terjedelemről menet közben, valós tapasztalat alapján lehet dönteni, nem egy hónapokkal korábban megírt specifikáció alapján.
4. Leírjuk, mit hagytunk ki és miért
Minden tudatos egyszerűsítést rögzítünk: mit hagytunk későbbre, mi a kockázata, és mikor érdemes visszatérni rá. Ez a technikai adósság nyilvántartása. Nem bürokrácia, hanem ettől marad fél év múlva is érthető, miért úgy néz ki a rendszer, ahogy.
Mikor jó döntés tudatosan a gyors és egyszerű?
Nem vagyunk a „mindent tökéletesen” hívei. Van, amikor kifejezetten jó ötlet a gyors, egyszerű megoldás:
- Ötletvalidálás: ha még nem tudod, kell-e egyáltalán a funkció, egy kattintható prototípus vagy egy kész SaaS-eszköz okosabb első lépés, mint az egyedi fejlesztés.
- Eldobható kód: egy egyszeri adatmigráció vagy belső szkript nem igényel ugyanakkora gondosságot, mint egy évekig futó webshop.
- Szűk határidő, vállalt adóssággal: ha a vásár napja nem mozdul, belefér egy egyszerűbb megoldás, de csak akkor, ha előre megbeszéljük, mikor és mennyi munkával tesszük rendbe.
A különbség a tudatosság. A rossz „gyors és olcsó” az, amikor senki nem mondja ki, mi maradt ki. A jó az, amikor ez le van írva, és az ügyfél dönt róla. Az AI-alapú fejlesztőeszközök sem írják felül ezt a logikát: egyes lépéseket gyorsítanak, de azt a döntést, hogy mi kerüljön bele és milyen minőségben, nem veszik át. Arról, hol térül meg ténylegesen az AI, külön cikkben írtunk.
Gyakori kérdések
Tényleg nem lehet egyszerre gyors, olcsó és jó egy szoftver?
Ugyanarra a terjedelemre nem. Ha viszont a terjedelmet leszűkíted arra, ami igazán kell, egy kisebb, de jó minőségű első verzió gyorsabban és kisebb keretből is elkészülhet. A háromszög nem tiltja a gyorsaságot, csak azt, hogy mindent egyszerre kérj.
Mi az a technikai adósság, és miért én fizetem?
Az a többletmunka, ami az elhalasztott rendbetétel miatt minden későbbi módosításnál jelentkezik. Mivel a rendszer a tiéd, a kamatot is te fizeted: lassabb fejlesztésben, több hibában, drágább bővítésben.
Fix áras vagy ráfordítás alapú projekt a jobb?
A fix ár akkor működik jól, ha a terjedelem tényleg ismert és stabil. Ha menet közben tanulsz, a szakaszos, ráfordítás alapú elszámolás általában őszintébb, mert a terjedelemről a valós tapasztalat alapján dönthetsz. Ezt a projekt elején közösen választjuk ki.
Honnan tudom, hogy egy ajánlat azért olcsó, mert kimaradt belőle valami?
Kérdezz rá a tesztelésre, a dokumentációra, az átadásra és arra, ki és hogyan javítja a hibákat élesítés után. Ha ezekre nincs konkrét válasz, valószínűleg nem az ár alacsony, hanem a terjedelem kisebb, mint gondolod.
Ha egyedi fejlesztésen gondolkodsz, és már az elején tisztázni szeretnéd, mi fix és mi mozdulhat, nézd meg, hogyan dolgozunk egyedi szoftverfejlesztésnél. Egy több részből álló projektről (app, webshop és weboldal együtt) a G8 Alakváltók esettanulmánya ad képet.