Kevés olyan egyedi szoftverterméket használó vállalkozást láttam, akinek ne lett volna baja a szoftvere működtetésével és karbantartásával. Ez kiemelten igaz azokra az esetekre, amikor egyedileg fejlesztet ki a vállalat egy szoftvert a saját céljaira.

• Az egyénileg megrendelt szoftverfejlesztés nem készül el határidőre, és az átadási határidő folyton kitolódik.
• A nagy sokára elért indítás csak kompromisszumok árán lehetséges. (funkcionális hiányosságok, tesztelési elégtelenségek, hibák, ráfizetések, …)
• Az átadáskor nem működik úgy, ahogy kellene.
• A hibák kijavítása eltolódik, a későbbi működés során újabb és újabb hibák jönnek elő.
• A kijavított hibák újabb hibákat szülnek, úgy, mint amikor a hétfejű sárkánynak ha levágod az egyik fejét, három újabb nő a helyébe.
• A rendszerhez adott felhasználói dokumentáció hiányos (már ha van egyáltalán ilyen), és a változtatásokkor nincs aktualizálva.
• Ki vagy szolgáltatva a fejlesztő kénye-kedvének. Csak ő nyúlhat hozzá a rendszerhez, ha vele valami történik vagy netalán megharagszik rád, akkor veszélybe kerülhet a fő üzleti működésed, vagy a teljes adatbázisod.
• Stb…

Voltál már Te is ilyen helyzetben? Ismerősek a problémák?

Hogyan tudnád ezeket a problémákat elkerülni?

A szoftverfejlesztő sem más és nem több mint egy alvállalkozód! Természetesen az adott termék (szoftver) és szolgáltatás (szoftver karbantartása és esetleg üzemeltetése) egy speciális termék illetve szolgáltatás.

Ennek a terméknek és hozzá kapcsolódó szolgáltatásnak a speciális minőségbiztosítási követelményei sajnos a szoftverfejlesztési szakmán belül is kevéssé ismertek, és kevéssé elterjedtek. Szomorú tapasztalat az is, hogy az ISO 9001 tanúsítványt szerzett szoftverházak többsége nem értette meg az ISO 9001 lényegét, és nem tudta lefordítani azokat az alapelveket a saját működése követelményeire. (Talán nem is akarta igazán mindenki.) Nagyon kevés az olyan felkészítő és tanácsadó is, aki a szoftver-minőségbiztosítás terén is valódi tudással és tapasztalattal rendelkeznek.

Mit tehetsz egy ilyen helyzetben, ha nem akarsz Te is „áldozat” lenni?

Először is tedd helyre magadban a dolgot: Ha szoftveres, ha nem: egy alvállalkozóval állsz szemben, és ennek megfelelően eljárni:

• Igyekezz az alvállalkozót jól kiválasztani, külön odafigyelve az alvállalkozó referenciáira és folyamataira is (a hogyant illetően lásd cikksorozatunk előző írásait),
• Kiemelt gonddal készítsd elő az alvállalkozóval megkötendő szerződést, mert ez utána a számonkérés alapja. Mire kell a szerződés során különösen odafigyelni?

1. Előre pontosan tudnod kell, hogy mit tudjon a termék. Ezalatt értem, hogy minden részét, részletét, futási ágát, lehetőségeit ki kell találnod és meg kell határoznod. Minél több bizonytalanság, pontatlanság vagy meghatározatlanság marad a követelményeidben, annál több helyen fogod nem azt kapni, amit szerettél volna. (Ezt egyébként könnyebb mondani, mit megcsinálni…)
2. Jó előre megmondanod, hogy milyen minőségi körülmények (próbák, tesztek, futtatási körülmények) esetén fogod átvenni a terméket.
3. Építs be a fejlesztési projekt menetébe minél több ellenőrzési pontot.
4. Kérj meg minél több dokumentációt a rendszeredről.
5. Egyezzetek meg a fejlesztés és a karbantartás során az új igények, változtatások végrehajtási, és elszámolási módjáról is. Hagyd magadnak nyitva a kiskaput, hogy Te is változtathass utólag az elképzeléseiden, legyen meg a módosítási és továbbfejlesztési lehetőséged. Ez természetesen plusz pénzbe fog kerülni, de nem mindegy, hogy mik ennek a megállapodott keretei. (Ha voltál már ilyen helyzetben, akkor érteni fogod, hogy miért tanácsoljuk ezt. Ha még nem: szánd rá még a szerződés kiegészítésére azt a néhány percet, ennél biztosabban megtérülő befektetésed nem igen lesz!)
6. Egyezzetek meg a hibajavítás módjában is. Nem mindegy, hogy mi módon történik a hibák bejelentése, nyilvántartása, kijavítása. Sokat segíthet például, ha van jól használható segédprogram, amin keresztül bejelentheted a hibákat, és azon keresztül nyomon is követheted azok sorsát (életútját) egészen a hiba megszűnéséig.
7. Egyezzetek meg a hibajavításkor a kapcsolódó dokumentáció frissítésének módjában is. (Enélkül az egy éve karbantartott és folyamatosan változtatott rendszer dokumentációja elavul, és már fabatkát sem ér.)

• Az együttműködés során a folyamatos kontrollinggal tartsd kézben az előre haladást – erre akkor van esélyed, ha világos ütemterv készült előre, hogy mit mikorra kell elkészíteni!

A cikksorozat következő részében a beszerzés másik különleges területének problémáit mutatjuk be. Ezek az olyan nagyobb méretű termelő és / vagy kereskedő cégek esete, ahol a beszerzés az anyaggazdálkodási logisztika szerves részeként működik. Itt a beszerzés szabályozása is a logisztikai folyamatokba épül be.

Dr Horváth Zsolt