Röviden: ritkán azért csúszik egy egyedi szoftverfejlesztés, mert a fejlesztés tart tovább. Sokkal gyakrabban azért, mert az első verzió rosszul lett meghatározva: túl sok minden került bele, és menet közben derül ki, hogy fontos dolgok kimaradtak. Ehhez jön a két tétel, ami szinte soha nincs benne az ajánlatban: az adatmigráció és a döntésre várt idő. Egy használható első verzió nem a végleges rendszer kicsinyített mása, hanem egyetlen folyamat végigvitele éles adattal.
Ritkán a fejlesztés csúszik
Ha megnézed egy elhúzódó projekt idővonalát, általában nem az a látvány fogad, hogy a programozók lassan dolgoztak.
Sokkal jellemzőbb, hogy a fejlesztés két hétig áll, mert egy kérdésre nem érkezik válasz. Aztán megint áll, mert a tesztelésre kijelölt kolléga épp szabadságon van. Aztán kiderül, hogy két vezető mást gondol ugyanarról a folyamatról, és ezt előbb egymás közt kell letisztázniuk.
Ezek nem lopakodó hibák, hanem előre látható események. Egy cég működik közben: van szezon, van betegség, van szabadság, van sürgősebb dolog. A projekttervnek ezzel számolnia kell, és ez a fejlesztő cég felelőssége, nem a megrendelőé. Ha valaki hathetes határidőt ígér úgy, hogy a hat hétben nulla várakozási idővel számol, akkor az a hat hét nem terv, hanem remény.
Praktikusan ezen a legtöbbet két dolog segít. Legyen egy ember a megrendelői oldalon, aki dönthet, nem egy háromfős bizottság. És legyen fix, ismétlődő alkalom, ahol a nyitott kérdéseket lezárjátok, ne e-mailben csorogjanak.
Az első verzió nem a végleges rendszer kicsinyített mása
Ez a leggyakoribb félreértés.
A legtöbb specifikáció úgy készül, hogy összegyűjtik, mi mindent kell majd tudnia a rendszernek, aztán ezt mindenhol lecsökkentik nyolcvan százalékra. Az eredmény egy olyan szoftver, ami sok mindent tud félig, és semmit nem tud rendesen. Élesben nem használható, mert minden folyamat elakad valahol, és a végén mindenki visszatér az Excelhez.
A jó első verzió pont fordítva épül. Kiválasztotok egy folyamatot, azt viszont végigviszitek az elejétől a végéig, valódi adattal, valódi kollégákkal. Ha ez a rendelésfelvétel, akkor a rendelés bejön, végigmegy, lezárul, és ezt holnaptól így csinálja a cég. Egy folyamat, ami tényleg működik, többet ér, mint tíz, ami majdnem.
Az első verzió célja nem a teljes rendszer bemutatása, hanem egy éles, mindennap használható működés elindítása.
Ennek van egy kellemetlen következménye: az első verzióban lesznek dolgok, amiket még kézzel kell csinálni. Ezt előre ki kell mondani, különben csalódásnak fog tűnni.
Amit majdnem mindenki túl korán kér
Van néhány visszatérő tétel, ami szinte minden specifikációba bekerül, és az első fél évben szinte soha nincs használva:
- Részletes jogosultsági rendszer. Nyolc szerepkör, mezőszintű jogosultságokkal, egy tizenöt fős cégnél. Az elején két szint általában elég: aki mindent lát, és aki a sajátját.
- Riportok és statisztikák. Amíg nincs adat a rendszerben, addig nincs mit kimutatni. Ez a funkció akkor lesz értelmes, amikor már fél év működés van mögötte, és addigra általában más kimutatás kell, mint amit az elején kértek.
- Testreszabható felület. Ki melyik oszlopot lássa, milyen sorrendben. Sok munka, kevés haszon az első körben.
- Mobilalkalmazás. Sok esetben egy jól működő, telefonon is használható webes felület pontosan ugyanazt megoldja, töredék költségen. Külön alkalmazás akkor indokolt, ha offline működés vagy eszközfunkció kell hozzá.
Ez a négy tétel együtt sokszor a költség felét viszi el, és pont azt a részt szorítja ki, ami tényleg kellett volna.
Nem arról van szó, hogy ezek feleslegesek. Arról, hogy a második körben olcsóbbak és jobbak lesznek, mert addigra tudni fogjátok, mire van szükség.
Amit viszont soha ne hagyj ki belőle
Van három dolog, ami unalmas, nem látszik a demón, és a legelső verzióban is benne kell lennie.
- Adatmentés. Legyen automatikus, és legyen valaki, aki tudja, hogyan lehet visszaállítani. Az a mentés, amit soha senki nem próbált visszatölteni, nem mentés.
- Naplózás. Ki mit módosított és mikor. Nem számonkérés miatt, hanem mert enélkül egy hiba okát nem lehet kideríteni, csak találgatni.
- Exportálhatóság. Ki tudod-e vinni az adataidat a rendszerből, normális, feldolgozható formátumban, anélkül hogy bárkit meg kellene kérned. Ez azt jelenti, hogy ha nem válik be a szoftver vagy a fejlesztő cég, akkor tudsz továbblépni.
Ezt a harmadikat egy fejlesztő cégnek nem érdeke leírni, mégis ez a legfontosabb a háromból. Ha egy ajánlatban nincs benne, kérdezz rá.
A tétel, ami szinte minden ajánlatból kimarad: az adatmigráció
Van egy régi rendszer, benne tizenöt év adata. Ügyfelek, cikkek, előzmények. Ezt át kell vinni.
Papíron ez egy sor a projekttervben. A gyakorlatban itt derül ki, hogy ugyanaz az ügyfél négyszer szerepel, hogy a régi rendszerben a telefonszám mezőbe sokan megjegyzést írtak, hogy három cikknek nincs mértékegysége, és hogy 2014 előtt más logikával rögzítettek mindent.
A migráció ilyenkor nem másolás, hanem adattisztítás, és ez emberi döntéseket igényel. Melyik a jó verzió a négy ügyfélből? Kell-e egyáltalán a 2014 előtti adat?
Két dolog segít. Az egyik, hogy a migráció külön tételként szerepeljen az ajánlatban, saját becsléssel, ne olvadjon bele a fejlesztésbe. A másik, hogy már az elején fussanak próbamigrációk, ne a projekt végén. Ha az első próbafuttatás a bevezetés előtt egy héttel történik, akkor a bevezetés csúszni fog.
A „még ezt az egyet” és miért nem a megrendelő hibája
Minden projektben eljön a pillanat, amikor jön egy kérés, ami félórásnak látszik, és két napot visz el.
A megrendelőt ezért hibáztatni értelmetlen. Természetes, hogy amikor valaki először látja élesben a rendszert, akkor jutnak eszébe a valódi igények. Addig papíron beszélgettetek, most meg használja.
Az a hibás felállás, ahol nincs erre kijelölt hely. Ha minden ötlet azonnal bekerül, a projekt sosem ér véget. Ha minden ötletet elutasítanak, akkor rossz rendszer épül.
Ami működik: legyen egy nyilvános lista a felmerülő kérésekre, ahova minden bekerül, kidobás nélkül. Aztán minden kérésnél egyetlen kérdés dönt: enélkül élesben tudunk indulni, vagy nem? Ha igen, akkor a második körbe megy. Így senkinek nem kell azt éreznie, hogy elveszett az ötlete, közben a határidő is tartható.
Mitől lesz jó egy első verzió?
Néhány jel, ami alapján megnézheted egy ajánlaton vagy egy terven, hogy reális-e:
- egyetlen folyamat van benne, az viszont végig
- van benne éles adat, nem tesztadat
- szerepel benne mentés, naplózás és export
- az adatmigráció külön tételként van becsülve
- van egy megnevezett ember a megrendelői oldalon, aki dönt
- szerepel benne párhuzamos futtatás: egy ideig a régi és az új is megy
- van benne betanítás, nem csak átadás
- a képernyők száma egyszámjegyű
És egy ökölszabály: ha az első verzió terve hosszabb tíz oldalnál, akkor az nem első verzió, hanem a teljes rendszer.
Nálunk hogyan néz ki ez?
Az ajánlatainkban a fejlesztés, a migráció és a bevezetés külön tételként szerepel, mert így látszik, mi mennyi. Az első verziót egyetlen folyamatra tervezzük, és leírjuk azt is, mi az, ami abban a körben még kézzel marad.
Ez néha kellemetlen beszélgetés az elején, mert kevesebbnek tűnik, mint amit a megrendelő várt. Cserébe abból, ami elkészül, tényleg lehet dolgozni, és a második kör már arra épül, amit közben megtanultatok, nem arra, amit fél évvel korábban gondoltatok.
Amit egy fejlesztési ajánlat előtt érdemes tisztázni
Mennyi idő egy egyedi szoftver első verziója?
Erre nincs általános időtartam. Az első verzió elkészülését a kiválasztott folyamat összetettsége, a kapcsolódó rendszerek, az adatmigráció és a döntések sebessége határozza meg. Reális becslés csak a hatókör tisztázása után adható, és a fejlesztés mellett a tesztelést, a betanítást, valamint a bevezetést is bele kell számolni.
Fix áras vagy óradíjas legyen?
Az első verzióra a fix ár működik jobban, mert ott pont az a lényeg, hogy le legyen határolva, mi kerül bele. A folyamatos továbbfejlesztésre viszont a keretes vagy óradíjas felállás életszerűbb, mert ott előre nem lehet tudni, mi jön.
Mennyivel drágább, ha menet közben módosítunk?
Attól függ, mikor. Amíg a terv szintjén van, szinte semmi. Amikor már megépült, akkor újra kell gondolni, ami sokszor több munka, mint az eredeti fejlesztés volt. Ezért éri meg az elején tesztelni, még ha lassabbnak is tűnik.
Honnan tudom, hogy jó-e az ajánlat, amit kaptam?
Nézd meg, mi nincs benne. Ha nincs benne migráció, tesztelés, betanítás, üzemeltetés és az, hogy mi történik hiba esetén, akkor az ajánlat nem a projekt ára, csak a fejlesztésé. A különbség később szokott előkerülni.
