Azaz miért kevés az akarat és a jó szándék a sikeres informatikai projekthez? Mi akadályoz meg bennünket a jó szoftver elkészítésében?

Azaz miért kevés az akarat és a jó szándék a sikeres informatikai projekthez? Mi akadályoz meg bennünket a jó szoftver elkészítésében?

Holden vetette fel a kérdést az egyik cikkére adott megjegyzések során. Nézőpontja érthető: minden szakma különböző, de mégis minden szakmától elvárjuk, hogy jól végezze a munkáját – a péktől hogy finom ropogós kenyeret süssön, a festőtől hogy csíkmentesen fesse le a lakást, és hogy a programozó által megírt program jól számolja a túlórapénzt. Valamiért ez utóbbi nem mindig sikerül.

Aludva egyet a kérdésre, a következő tényezőket látom:

Szakmai tudás
Ahhoz, hogy a szoftver megüsse a szakmai szintet, megfelelő tudásra, megfelelő programozóra van szükség. Egy amatőr is pont ugyanúgy meg tud írni egy szoftvert, esetleg pont ugyanolyan szállítási határidővel, mint a profi. A különbség a minőség lesz.
Sajnos azt nehéz mérni, hogy az adott fejlesztő milyen szinten áll és mit ad majd ki a kezéből.
Nincs elfogadott, szakmán belüli mérce arra, hogy mi a szükséges tudás szint. Még az sem egységes, hogy kell-e és mennyi elméletet kell egy leendő programozónak megtanulnia.

Sok amatőr
Tény, hogy programozó végzettség nélkül is lehet programozni. Rengeteg „hogyan tanuljunk meg programozni 5 nap alatt” jellegű könyv van. Az ember megveszi, elolvassa, elkészíti élete első Hello World programját, aztán megy sok pénzt keresni. Mert hiszen ő tud programozni.
A jogászok és az orvosok például szigorúan szabályozzák, ki végezhet jogi, illetve orvosi munkát. Ilyen szabályozás az informatikában nincs, és bizony vannak kontárok.

Mi a jó szoftver?
Már csak azért sem lehet jó szoftvert csinálni, mert a „jó szoftver” nem definiálható. Mert milyen is a jó szoftver?
Az ügyfél azt szeretné, hogy jól/könnyen használható legyen, és benne legyenek a kért funkciók. Arra viszont cseppet sem gondol, hogy a szoftver karbantartható, könnyen továbbfejleszthető, alacsony kapacitásigényű, stabil vagy bolondbiztos legyen. A többi 100 kitételt le sem írom…
Az az igazság, hogy az ügyfél általában nem ért az IT-hoz (pont ezért keres egy IT céget), tehát nem tudja definiálni a szoftver „jóságát”.

A szoftver jósága nehezen mérhető
Ha az ügyfél valahogyan mégis tudta definiálni igényeit és a szoftver „jóságát”, akkor hogyan fogja azt mérni? Mert ezek nagy részéhez informatikai tudásra lenne szüksége. Amihez meg nem ért.

Ellenérdek
A tipikus fejlesztési projektben a megrendelő a saját üzletéhez ért, és azért van szüksége az IT vállalkozóra, hogy a szükséges informatikai tudást behozza. Tehát ne csak szoftvert fejlesszen, hanem tanácsadó is legyen egyben.
Rövid és középtávon azonban az IT vállalkozó ellenérdekelt abban, hogy a szakmai nívót lobogtassa, hiszen neki pont az lenne előnyös, ha minél kevesebb ellenőrzés után minél kevesebb hiba megtalálásával az ügyfél átvenné a programot.
Nyilván az IT vállalkozó – már csak szakmai tisztességből – fenntart egy szakmai nívót, és igyekszik az ipari szabványoknak megfelelni, de ezt mindenki a saját belügyének tekinti. És miért vitatná meg egy IT-hoz nem értő emberrel?

Nem csak egy jó megoldás létezik
A szoftver fejlesztés tipikusan az a terület, ahol nem csak egyféle jó út van, és sok egymástól szögesen eltérő módon, technikával vagy technológiával lehet tökéletesen jó szoftvert írni. Még arról is nagy vita zajlik, hogy melyik szoftver fejlesztési módszertant használjuk – van egy pár.
Amikor dönteni kell az egyes megoldások között, az sok apróságon múlik, esetleg szubjektív szempontok alapján, pl. a fejlesztő melyik technológiát érzi jobbnak az adott feladatra.
Mire kiderül, hogy a döntés jó vagy rossz volt, addigra már úgyis késő.

Szabványok nélkül
Az lenne a legjobb, ha létezne egységes szabvány a szoftver fejlesztésre – de nincs. Mert minden technológia más, minden módszertan más, ezért igazából nem az a kérdés, hogy követem-e a szabványt, hanem az, hogy melyiket.
Ráadásul ezek a szabványok nem közismertek. Lehet, hogy a fejlesztő nagyon jó, de nem ismeri a SCRUM-ot, vagy nem tudja, hogy mit jelent az ITIL szerinti szoftver támogatásban.

Folyamatos technológiai forradalom
Ami még rosszabbá teszi a helyzetet: a technológiák folyamatosan elavulnak, miközben újak jelennek meg. A legjobb gyakorlatok folyamatosan változnak. Ha valaki mestere egy technológiának ma, holnap megjelenik egy újabb, és holnapután a fejlesztő tudása már kevéssé releváns.
Nehéz naprakésznek lenni, nehéz eldönteni, hogy most per pillanat melyik műszaki megoldás a legjobb, és hogy megfelel-e a szoftverünk a ma érvényes legjobb gyakorlatnak.

Van igény selejtre
Az ügyfelek (különösen az ügyvezető igazgatók) úgy vesznek szoftvert, mint egy zsák krumplit: a legalacsonyabb ár nyer. Vagyis a korábban említett alacsony szaktudású, és emiatt olcsó informatikusok munkájára van igény. Mivel van rá igény, mindig is lesznek olcsó informatikusok. A kör bezárult.

Hibamentes szoftver nincs
A rossz szoftvert legtöbbször a hibáiról ismerik fel. Tény, hogy a szoftverben – gyártástechnológiától függetlenül – lesznek hibák, és hogy a hibák előfordulását nem lehet 0-ra csökkenteni. Ha 0-ra nem is de, egy elfogadható szint alá még lehet, ha megfelelő eljárásokat alkalmazunk. De hogy a szoftver fejlesztő alkalmazta-e ezeket az eljárásokat, megtett-e minden tőle telhetőt, ezt nehéz ellenőrizni. Mert ha meg is tett, hibák akkor is előfordulnak.

Vezetői kompetenciahiány
Holden vetette fel a vezetők felelősségét.
Mivel a szoftver fejlesztés komoly dolog, ezért úgy gondolom, a jó szoftver készítése, a minőség prioritás kell hogy legyen. A jó szoftver irányába mutató eljárások alkalmazása időt, pénzt és szaktudást igényel, amit vezetői szinten el kell fogadni és támogatni. Ha ez a támogatás nincs meg, akkor az óhatatlanul azt jelenti, hogy a határidő és az alacsony költségek előnyt élveznek – a szoftver nem lesz jó.
Miért nem támogatják a vezetők a minőséget? Mert esetleg gőzük sincs róla, hogy ez mit jelent, és mi lesz a következménye a rossz eljárásoknak. Mert ők nem veterán informatikusból nőttek ki, hanem mondjuk közgazdászból.
A „Határidőre kész kell lenni” kijelentést én nem a szándékos rosszakarás, hanem a kompetenciahiány és a gondatlanság számlájára írom.

Még mielőtt a Kedves Olvasó kétségbeesne, azért elmondom, hogy igenis lehet jó szoftvert csinálni. Íme néhány tipp:

- Tapasztalt informatikusokkal kell dolgoztatni. Kalandorok kíméljenek.

- A tapasztalt informatikusokat meg kell fizetni. Piaci árat adjunk, cserébe versenyképes minőséget várjunk el. Szoftvert lehet olcsón is venni, csak nem éri meg.

- Kipróbált vállalkozót használni, hosszú távú kapcsolatot építeni. Járt utat járatlanért el ne hagyj!

- Jó szoftverhez nem csak jó vállalkozó, hanem jó ügyfél is kell.

- A jó szoftver közös célunk, ehhez mindkét félnek (vállalkozó és ügyfél) sokat kell dolgoznia.

- Ne csak funkcionális igényeket, hanem módszertani és nem-funkcionális igényeket is határozzunk meg. A vállalkozónak is könnyebb ha tudja, mit várnak el tőle.

- Minőségbiztosítás!

- Ne az aktuális hibákra, hanem a hosszú távú kapcsolatra összpontosítsunk. Nem az a jó vállalkozó, aki nem hibázik, hanem az, aki mindent megtesz, hogy ne hibázzon.

- Cipőt a cipésztől – szoftvert csak attól vegyünk, aki tisztában van az IT szabványokkal és azok alkalmazásával a mindennapokban.

- Ne rendeljünk informatikai munkát informatikus segítsége nélkül. Új házat se veszünk szakértő nélkül.

- Hibák mindig lesznek. Nem az a kérdés, hogy van-e hiba, hanem az, hogy hol az elfogadható szint, és meg tudjuk-e a hibákat oldani.

- A problémákat ne „okosba” oldjuk meg, hanem a hivatalos úton. Megalkuvás nélkül. Szívességek helyett professzionális munkát!