ITÉlet

Avagy fapados megoldás és fapados megoldás között nagy különbség van! (Nem mindegy, hol van benne szálka…)

Avagy fapados megoldás és fapados megoldás között nagy különbség van! (Nem mindegy, hol van benne szálka…)

Az egyik nap hozzám fordultak egy rég elfeledett szoftverrel kapcsolatban. A szoftver valami nagyon egyszerű nyilvántartóprogram web-es alapon, mögötte adatbázis. Klasszikus, pofonegyszerű felépítés. A felhasználó böngészővel megnyitja, böngészik az adatok között, újat felvisz illetve meglévőt módosít. Nincs css, nincs grafika, nincs háttérkép, nincs webform, nincs AJAX, semmi sincs csak egy teljesen béta igénytelen, funkcionális felület.

A fejlesztő annak idején 1 hét alatt dobta össze, plusz volt néhány utólagos igény.

Először meglepődtem, mert azt hittem, ezt a szoftvert már senki sem használja. Annak idején ideiglenesnek készült, meg hogy majd idővel átállunk valami komolyra. Aztán a dolog elmaradt, a felhasználók továbbra is használták a programot. Nem is kicsit: része lett a napi rutinnak (Run-The-Business-nek), állandóan belépnek, kb 15 fős a felhasználó bázis és valaki mindig online.

Most megint hozzá kellett nyúlni.

Először megijedtem, hogy nem fog menni, hiszen a kódot régen írták, a fejlesztő már rég nincs itt. Aztán kiderült, hogy a programban van törzsadat karbantartás is, és amit a felhasználók kérnek, az simán törzsadat hozzáadással megvalósítható. Kb 5 percig tartott.

Belegondoltam: hogyan lehet az, hogy van egy ennyire fapados, teljesen minimalista program, amivel nincs semmi baj, és nincsenek fejlesztési igények? Hogyan lehet az, hogy az évek alatt senki sem feszegette a program lecserélését és újraírását?

Mert ezzel szemben a drága pénzen, 6-12 hónap alatt megírt „professzionális” alkalmazásokra állandó a panasz, rengeteg a fejlesztési igény. És azokat nem lehet fejlesztői óra kifizetési nélkül „átállítani” semmire.

Talán azért van ez így, mert mást értünk „fapados” alatt.

Az informatikusok azt értik fapados alatt, ami műszakilag egyszerű programot kevés munkával összeütnek. A „műszakilag egyszerű” azt jelenti, hogy a programozónak egyszerű, vagy legalábbis kedve van hozzá. Például műszakilag egyszerű dolog képeket felrakni a menüre, vagy egy ketyegő órát implementálni a status bar-ban – a forrás kódja copy-paste módszerrel megszerezhető bárhonnan.

Ezzel szemben műszakilag nem egyszerű azokat az eseteket lefedni egy input mezőben, amit a felhasználó oda be akar ütni (véletlenül, figyelmetlenségből vagy rossz szándékkal).

A felhasználó szemében a fapados azt jelenti, hogy a program az üzleti folyamat fő lépéseit pofonegyszerűen lefedi. Be lehet ütni adatokat, elmenteni azokat, aztán egy táblázatból visszakeresni. Nincs szükség komplex kereső funkcióra, nincs szükség intelligens validálásra vagy begépelés közben felbukkanó kulcsszavakra. Csak egy egyszerű felületre, kevés mezővel, világos információkra, kevés nyomógombra. Ha ezeket tudja a rendszer, az összes többi már kezelhető a rendszeren kívül.

A rendszer nem kér több információt, mint amennyire feltétlenül szükség van, és nincs is benne több funkció, mint amennyi kell.

Amikor ez a program készült, a fejlesztő nagy gondot fordított az igények PONTOS megismerésére. Természetesen amikor elkészült a fejlesztés, a felhasználóknak további ötletei „támadtak” mit lehetne a programba tenni. Szerencsére sikerült kompromisszumot kötni: a felhasználók megértették, hogy nem kérhetnek akármennyit (hiszen a szoftver csak „átmenetileg” lesz), a másik oldalról viszont a fejlesztő belefektette a munkát, hogy az igényeknek megfeleljen – a legegyszerűbb, de leghatásosabb módon.

Ha úgy nézzük, a szoftver teljesen minimalista, viszont a minimális felhasználói igények teljesítésében maximalista. És mivel a legegyszerűbb, legvilágosabb módon ellátja a munkáját, ezért könnyű volt használni, megérteni és dolgozni vele. A felhasználók nem is kértek többet.

És hogy ne legyen probléma, az alkalmazás be lett tolva a standard alkalmazás támogatási folyamatba, rendszeresen mentés készült róla, és a rendszergazdák időnként ellenőrizték, hogy minden rendben megy-e.

Az évek alatt túlélt egy szerver konszolidációt – amikor át kellett telepíteni egy másik szerverre. Minden simán ment, a felhasználók számára észrevétlenül.

Feltehetőleg még néhány évig elketyeg az egyik félreeső szerveren anélkül, hogy bármilyen probléma legyen. És jó lenne, ha a többi esetben is így tudnánk fejleszteni, ennyire kevés erőfeszítéssel ennyire stabil rendszert kialakítva.

A felhasználók a legtöbb esetben megalkudnának egy minimalista felülettel, amennyiben az mindent tud, amire szükségük van. Nincs szükségük tanácsadóra, képekre, animációra