ITÉlet

Ha a szoftverfejlesztés nem is innováció, de vonható-e valamiféle párhuzam?

Ha a szoftverfejlesztés nem is innováció, de vonható-e valamiféle párhuzam?

Az első részben arról volt szó, hogy definíció szerint innováció-e a szoftverfejlesztés. A konklúziót idézném: „Egy jó ötlet szoftverbe öntése innováció, de a szoftver készítés önmagában véve még nem biztos hogy innováció, sőt bizonyára nem az.”

Jó, jó, de találunk-e párhuzamokat? Attól hogy nem az, még lehet hasonló. Lehet-e az innovációra jellemző módszereket alkalmazni a szoftverfejlesztésben?

(Szoftverfejlesztés alatt üzleti célú szoftverfejlesztést értek. Azok a cégek, ahol az innováció célja IT jellegű, ott nyilván a kérdés értelmetlen, hiszen egyértelműen igen. Ilyen cégek például a Microsoft, Apple vagy Google. Engem az érdekel, hogy a többi cégnél, a nagy átlagban mi a helyzet.)

Ehhez vegyünk elő egy ábrát az innováció folyamatáról.

(Forrás: http://tanulokozosseg.mindentudo.hu/s_doc_server.php?id=2886 )

Röviden összefoglalva a folyamatot: Ötlet -> Terméktervezés -> Termékfejlesztés -> Termelés -> Piaci bevezetés

Az egész persze nagyon iteratív, rengeteg visszacsatolással és piaci teszteléssel.

Messziről nézve számtalan, IT-ban felbukkanó elemet találunk. Az IT-ban is a fejlesztés az ötlettől indul, stim. Van tervezés, stim. Aztán jön a fejlesztés, stim. A termelés maga a szoftver lekódolása, stim. Piaci bevezetés az a release, stim. Iteratív fejlesztés is létezik, stim. Végül pedig tesztelés is van, sőt a piaci tesztelés egész konkrétan olyannak tűnik, mint amikor egy iteratív/agilis fejlesztésben a kulcsfelhasználók visszajelzést adnak a következő iterációhoz.

Messziről nézve ez 1:1-ben szoftverfejlesztés.

Tegyünk egy lépést közelebb és nézzük meg a részleteket!

Ötletgyűjtés: Fura egy szókapcsolat, hiszen informatikai fejlesztésben nem kell ötleteket gyűjteni. Az ötletek jönnek maguktól. Miért is? Hiszen az informatikai fejlesztés egy üzleti projekt része, az üzleti projekt az üzleti célokból következik, ami pedig az üzleti stratégiából. Vagyis itt nem az ötleteket van a hangsúly, hanem az üzleti stratégián és annak végrehajtásán.

Ötleteket már csak ezért sem kell gyűjteni, mert a felhasználók mindig tele vannak javaslatokkal, mit hogy lehetne jobban csinálni. Nem az ötletek gyűjtése a probléma, hanem éppen ellenkezőleg: túl sok ötlet van, túl sok a munka, de csak korlátozott mennyiségű az erőforrás.

A felhasználóktól érkező változáskérelem a legtöbb esetben hasznos. Igen, akadnak értelmetlen fejlesztési igények, de a többség értelmes és hasznos, a haszon forintban mérhető. Még az ergonómiai igényeknek is van pénzben kifejezhető haszna: a felhasználók kevesebb idő alatt vagy kevesebb hibázással képesek végrehajtani ugyanazt a feladatot. Tehát az ötletek nagy része valós és értékes, szemben a termékfejlesztéssel, ahol erősen szűrni kell az értelmetlen, nem racionális ötleteket. Az arányok egészen mások.

Terméktervezés: Itt rögtön belefutottunk egy terminológiai problémába. Az IT-ban is ismerjük és használjuk a „tervezés” kifejezést, de egészen másra. A Terméktervezés nem azt jelenti, hogy a termék konkrét műszaki kialakítását tervezzük meg, hanem csak még a terméket, azaz magát a koncepciót. Ez az a fázis, amikor a kulcsfelhasználó összeül a rendszerszervezővel, és közösen kitalálják, hogy akkor mi hogy legyen – rajzasztalon, elvi szinten.

Informatikai szempontból ez még az igények meghatározása – félreértés volt rögtön a tervezésre asszociálni.

Termékfejlesztés: Prototípus készül, amit a technikusok felmérnek és tesztelnek. Szoftver területen azt mondanám, hogy ez a fázis a prototípus készítés vagy a megvalósíthatósági tanulmány elkészítése – ami még a szoftver fejlesztés előtt van, amolyan pre-sales fázis. Súlyos tévedés volt elsőre párhuzamot vonni a szoftverfejlesztéssel.

A Terméktervezés és a Termékfejlesztés között láthatunk egy iteratív visszacsatolás, amolyan Go-NoGo döntés. A tapasztalatom az, hogy informatikai projektekben ilyen nincs. Ha a vezetőség az ötletre rábólintott, akkor az Go. Olyat még nem nagyon láttam, hogy a rendszerszervező a felhasználókkal való beszélgetés után úgy állt fel, hogy a szoftver nem megvalósítható és a projekt leáll. Biztos ilyen is létezik, az esetek 0,1%-ában.

A szoftver valamilyen módon mindig megvalósítható, legfeljebb az árról, a határidőről és a kapacitásról lehetnek viták. Sosem az a kérdés, hogy létezik-e műszaki megoldás, hanem az, hogy melyik a legjobb, és hogyan alkalmazhatjuk a technológiát. (Mellesleg ha sub-optimális megoldást találunk, az is fog működni. Rengeteg rosszul tervezett, de működő szoftver létezik.)

A Termékfejlesztés után is látható egy iteratív visszacsatolás, ami IT-ban nem használatos. A prototípus és a megvalósíthatóság tanulmány után ritka az, amikor műszaki okok miatt leáll egy munka.
Legfeljebb arról lehet szó, hogy a fejlesztés túl drága, túl sok ideig tart vagy elfogyott a pénzkeret, és ezért kell másik megoldást. Ezek a kényszerek azonban már az ötlet felvázolásakor ismertek, tehát a valóságban ritka lesz, amikor a rendszerszervezőnek vissza kell dobni egy tervet.

(Tipikus példa: ajánlatot kérek x szoftver kifejlesztésére. Beszállító azt mondja hogy 100 zsák aranyért megcsinálja. Mondom neki, hogy nekem csak 50 zsák aranyam van. Beszállító mondja: jó, akkor legyen 50 zsák. A projekt nem áll le.)

És ha a terv vissza is lesz dobva, akkor is csak az előző fázisba iterálunk vissza (kijavítjuk a hibát), nem pedig „fejlesztés leáll”.

Termelés: Ez a fázis, amikor előállítjuk a terméket. Itt a termék a szoftver, tehát akkor definíció szerint itt történik a fejlesztés és annak minden szükséges tevékenysége: tervezés, kódolás, tesztelés, dokumentálás.

Összességében tehát az innováció folyamat messziről hasonló a szoftverfejlesztéshez, azonban annak sajátosságai miatt és a más arányok miatt a lényeg és a súlypontok máshol vannak. Ezek miatt az innovációs folyamat nem szoftverfejlesztés, és az innovációs „legjobb gyakorlatok” csak kellő körültekintéssel alkalmazhatók az IT-ban.