Kóklerek kíméljenek!

avagy hogyan érdemes egyedi szoftvert készíttetni?

Nagy a megrendelő és a megbízott öröme a szerződés aláírásakor. Aztán elkezdődnek a dolgos hétköznapok: lezajlanak a részletes egyeztetések, elkészülnek a véglegesnek hitt igénylisták, nekiveselkednek a programozók. Telik az idő, ám a program csak közelítőleg tudja azt, amit a megrendelő várt tőle. Elmúlt a harmadik halasztott átadási dátum, de a végeredmény mégsem az lett, amire a két fél számított. Hogyan kerülhetik el kisvállalatok tulajdonosai – leendő megbízók – ezeket a helyzeteket? Hogyan adhatnak kis kockázatviselés mellett megbízást kisebb egyedi szoftverek elkészítésére? Biztosan segít, ha mélyebben belelátnak a programkészítés rejtelmeibe.

Néhány évvel ezelőtt egy kisvállalkozás vezetője elhívott egy megbeszélésre, mert egy programot akart íratni saját használatra. A tárgyalást ezzel nyitotta: “Nézze, kétféle embert utálok. Az egyik az ügynök, a másik a programozó.” Elmesélte, hogy három-négy alkalommal adott már megbízást alvállalkozóknak szoftverkészítésre. Egyik program sem készült el határidőre, nem olyanra sikerült, amit szeretett volna és vitával zárult mindegyik kapcsolat. “De miért? Hiszen ott volt a rendszerterv meg egy projektütemezés, nem?” – kérdeztem. “Rendszerterv? Ilyesmit nem kaptam.” – válaszolta a cégtulajdonos.

Egyszer vidékről telefonált egy úr, mert gyártáslogisztikai programot szeretett volna vásárolni kis gyártócégének, és az Intrada1 után érdeklődött. Beszéltem neki a termékről, a végén persze az árak is szóba kerültek. Hüledezett, hogy ez milyen drága, majd elárulta, hogy kértek már ajánlatot egy programozótól, aki “ugyanezt az egészet” négyszázezer Ft-ért “leprogramozza” nekik… Megkértem az érdeklődőt, hogy most azonnal felejtse el az ajánlatot adó programozót, mert az ajánlata irreális, teljesen komolytalan. Megmondtam neki, hogy a program soha nem lesz olyan, mint amit ők akarnak, pénzüket pedig inkább tegye ki az ablakba, így legalább idegeskedés nélkül veszíthetik el.

A “kókler” kifejezést az IVSz2-ben használjuk szeretettel, azokra a cégekre, vállalkozásokra, akik nem csak simán “vállalkozók”, hanem “mindenre vállalkozók”: elvállalnak mindenféle feladatot irreális árakon, átverik a nem teljesen hozzáértő megrendelőt, aztán köd előttem, köd mögöttem.

Szoftverprojekt – felügyelettel, fokozatokban

Az a baj a megrendelőkkel, hogy nincs kedvük a szoftverprojektekkel foglalkozni. Legtöbben úgy képzelik a dolgot, hogy elhívnak egy programozót, elmondják neki, hogy körülbelül mit szeretnének, és várják az árajánlatot. Megjön az ajánlat, kérnek egypár referenciát, az alaposabbak még elmennek a programozó irodájába körülnézni, aztán döntenek – az egész projektről. Pedig lehet másképpen is.

Az első javaslatom, hogy kérjünk fel egy projektfelügyelőt: ő az, aki szakmailag képben van és képviselni tudja a megrendelő érdekeit. Ez az ember praktikusan egy szoftveres legyen, és annyi a feladata, hogy folyamatosan ellenőrizze a munkát és annak szakszerűségét, no és persze sajtolja ki a határidőket. A projektfelügyelői státuszra pályáztatással választhatjuk ki a megfelelő embert, de ha a cégünkben van egy rátermett “behajtós” típusú informatikus, akkor neki is odaadhatjuk ezt a szerepet.

A másik, amit javasolok, hogy ne egy projektben gondolkozzunk, hanem legalább kettőben:

  1. projekt: funkcionális rendszerterv3, követelményspecifikáció elkészítése
  2. projekt: a terv alapján a megvalósítás

A megrendelő (vagyis a projektfelügyelő) első feladata, hogy az 1. projekthez összeállítson valamiféle ajánlatkérő anyagot. Nem kell ennek túl hosszúnak lennie, 2-3 oldal elegendő. Ha ezt kiküldi egy szoftvercégnek, akkor ebből a szoftveresek már el tudják dönteni, hogy vállalni tudják-e a feladatot vagy sem. Ha bizonytalanok, akkor érdemes telefonon vagy személyesen átmenni a részleteken.

Világos célok, közérthetően

Eddig semmi új nem történt, most viszont fontos, hogy az ajánlatkérő ne a program megírására kérjen ajánlatot, hanem “csak” a funkcionális rendszerterv (vagy a követelményspecifikáció) elkészítésére. Ez a feladat elég jól behatárolható, a kézzel fogható eredmény szinte garantált – a hozzáértő projektfelügyelőt nehéz megtéveszteni.

A funkcionális rendszerterv nagyon részletesen leírja majd, hogy mit várunk el a leendő szoftvertől, tekinthetjük a majdani rendszer felhasználói és technikai kézikönyvéből készített valamiféle keveréknek. Lényeg, hogy értsen belőle a cégvezetésben helyet foglaló nem informatikai végzettségű tag, és a megvalósításra ajánlatot adó IT-s cég se sokat kérdezzen majd a birtokában. Hozzá lehet csapni a majdani vállalkozási szerződéshez: íme, ezek a céljaink.

A funkcionális rendszertervben ki kell térni az alábbiakra:

  • Az üzleti probléma felvázolása, folyamatok részletes bemutatása
  • Konkrét számok (adottságok, elvárások) megadása (pl. 350 ezerféle cikk kezelése, 7800 partner, napi 10 ezer számla, max. 3 mp alatt el kell készülnie a szállítólevélnek stb.)
  • Célok, kívánságok meghatározása
  • A leendő szoftverrészek (“modulok”) logikai leírása (mi micsoda, mit csinál, mivel dolgozik össze)
  • A leendő adatbázis logikai leírása (szerkezete, adatmezők és adattípusok, hivatkozások)
  • A főbb dialógusdobozok felépítése (működése)
  • A listák, grafikonon bemutatása (kinyerésük módja az adatbázisból)
  • A majdani futtatókörnyezet bemutatása, felépítése (hálózat, hardver-, szoftverkörnyezet, folyamatos működés feltételei, adatmentés -helyreállítás)

Kisebb feladat esetén egy ilyen dokumentáció néhány hét alatt elkészíthető. A terv elkészítéséhez sok időt kell tölteni az ügyfélnél, gyakorlati szinten kell megismerni a problémákat. (A leglelkesebbek ilyenkor beállnak dolgozni a megbízóhoz, például segítenek a raktárosoknak a gyártáshoz összekészíteni az anyagokat.) Természetesen szükség van a menedzsmenttel is egyeztetni, végül is ők irányítják a céget. (Akik gyakran ilyenkor rájönnek, hogy mennyire rosszul működik a cég és ezért hirtelen egy átszervezés mellett döntenek, a szoftverprojekt pedig vár addig…)

Amit a megbízótól a szerződésben mindenképpen ki kell sajtolni, az az “effektív konzultációs órák száma”, ugyanis a megbízó hajlamos arra, hogy “ő most nem ér rá”, nem ad meg minden tudnivalót részletesen, később pedig erre hivatkozik (“Dehogynem beszéltem erről! Emlékezz, épp összefutottunk a liftben, akkor említettem neked!”). Minden megbeszélésről feljegyzés készül (tételek, amikről beszéltünk; ki volt jelen; mettől meddig tartott), amit a felek aláírásukkal igazolnak. Amiről pedig nincs feljegyzés, az elszállt, nincs, nem hangzott el … senki nem hivatkozhat rá!

A rendesen elkészített anyag kellően terjedelmes lesz, kicsinek tűnő feladatnál is hamar összejön 80-100 oldal. De a lényeg az, hogy végre megvan a kapaszkodó: a megbízó írásba tudja adni, hogy mit akar, a leendő kivitelező pedig viszonylag pontosan megismeri a megbízó vágyait. Lehet ajánlatot kérni, a vállalási feltételeken gondolkodni és ajánlatot adni.

A funkcionális rendszerterv birtokában ki lehet írni a pályázatot. Ki kell küldeni az anyagot a meghívottaknak, konzultációs lehetőséget kell biztosítani nekik. A konzultáción természetesen jelen van a terv készítője, a projektfelügyelő és a megbízó embere is.

A megvalósulás felé, de óvatosan

Elkészült a funkcionális rendszerterv, jöhet a versenyeztetés! Az ajánlatokat ne napra kérjük be, hanem napra és órára! Ne azt írjuk, hogy március 19-ig várjuk az ajánlatokat, hanem azt, hogy március 19-én délelőtt 10 óráig kell leadni őket.

A kivitelező kiválasztásánál elsődleges szempontok:

  • igazolható, élő referenciák hasonló témakörben (termékeik, megoldásaik itt-ott, felhívható vezetőkkel a megjelölt helyen)
  • vállalási árak, feladat határidők és ütemezésük

Ennél többet lehet, de nem érdemes firtatni: egyes cégek szokták kérni a projektben résztvevők szakmai önéletrajzát, a projektszervezet majdani felépítését, az ISO 9001-es kézikönyvet, mindenféle cégbírósági igazolásokat stb., de ezek valódiságát a munka közben már senki sem ellenőrzi, akkor meg minek?

Olvastam egy kimutatást, hogy döntéshozatalkor a vállalatok nagy többsége elsősorban a referenciákat veszi figyelembe, ez azért elég megnyugtató. Itt nem lehet kamuzni: vagy tudok működés közben mutatni valami hasonlót vagy nem. Ehhez képest tényleg lényegtelen, hogy milyen projektszervezet mellett készítettük az adott információs rendszert.

Az ár és az időütemezés nagyon sarkalatos pontja a dolognak, egy baj van vele, hogy szinte sohasem teljesül. Ez nem feltétlenül úgy jelentkezik, hogy a megrendelőnek újabb pénzeket kell kivennie a kasszából, hanem úgy, hogy a kivitelező azt érzi, hogy sokkal többet teljesített, mint ami az eredeti cél volt és ezért nem kapta meg a díjazást. Egy nagyvállalat vezetője mondta, hogy azért szereti a projektterveket, mert így tudja, hogy mi az, ami biztosan nem fog bekövetkezni. Nyilván a szerződést úgy kell megszerkeszteni, hogy a felek titkon tudják ezeket a dolgokat, pénzben és időben belefér további öt-tíz százalék az eredmény érdekében.

És ha már a pénznél tartunk: Kedves Megbízók! Nyugodtan el lehet árulni, hogy mekkora a projekt költségvetése! Ez óriási segítség a pályázóknak! Ha kicsi az összeg, a jobb étvágyúak rögtön legyinteni tudnak, ha túl nagy, akkor meg úgyis egymás alá fognak ígérni a pályázók (t.i. a fogolydilemma kiválóan működik gazdasági versenyhelyzetekben)! Ha az ember bemegy egy használt autó kereskedésbe, akkor ott is megkérdezi az eladó, hogy mégis mennyit szánok a kocsira és a megfelelő autókhoz tud vezetni. Nevetséges helyzetek alakulhatnak ki, mi indultunk már olyan projektben, ahol ugyanarra a feladatra a két ajánlott szélső összeg 30 millió és 1.2 milliárd Ft volt! (A tendereztető 140 milliót szánt a projektre.) A lényeg tehát: ne titkoljuk a költségvetést!

Ne lepődjünk meg azon, ha a funkcionális rendszertervben leírtak a munka során módosulnak: természetes dolog, hogy változhatnak elképzelések, vagy megváltozik egy vagy több vállalati folyamat. A lényeg, hogy a szerződéshez mi van csatolva, a megbízó ezt akarta, a megbízott pedig ezt vállalta. Ha bármilyen új kívánság van, akkor annak mikéntjét kiegészítő szerződésben kell szabályozni. És persze az sem hátrány, ha kicsit rugalmasak és segítőkészek a felek.

Amiket a vállalkozónak mindenképpen el kell végeznie:

  • Rendszerterv elkészítése: ez lehet a funkcionális rendszerterv kiegészítése, részletezése
  • Programozás: ahogy mondani szokás, “a szakmailag elvárható legjobb minőségben”
  • Tesztelés: a megrendelővel együtt tesztelési tervet kell készíteni. Ez a teljes fejlesztői munka kb. 25%-át jelenti! Nagy tudású információs rendszerek tesztelésénél ez igen összetett feladatot jelent! De mi itt most egyszerűbb fejlesztésekről értekezünk, egy ilyen szoftverben van 8-10 főér, ezek helyes működését egyszerűbb lekövetni.
  • Bevezetési és migrációs terv: hát igen, néha elég nehéz önmagában az, hogy a régi programból átvegyük az adatokat, ráadásul úgy, hogy időnként a régi és az új programnak munkaszervezési adottságok miatt párhuzamosan kell futnia jó ideig. Az ideális eset, ha egyik napról a másikra lehetséges az áttérés, mert ekkor előbb kell tartani egy migrációs tesztet: ilyenkor átvesszük az új programba az adatokat és teszt szinten elkezdünk ezekkel dolgozni, de közben a régi program fut és az dolgozik élesben. Aztán ha az új program jó eredménnyel vizsgázik, akkor ki lehet tűzni az éles áttérés időpontját (pl. egy hétvégére vagy a teljes karácsonyi szünetre), aztán neki lehet rugaszkodni.
  • Oktatás, dokumentálás: Nekem az a tapasztalatom, hogy olyan embert kell az adott cégnél nagyon alaposan megtanítani a kezelésre, aki stabil munkaerő, ilyen lehet egy megbecsült rendszergazda vagy gyártásvezető: ez az ember mindig oda tud menni ahhoz, akinek valami gondja van és tovább tudja lökni, továbbá az új alkalmazottakat is fel tudja készíteni a program használatára.
    Előfordult már, hogy oktatás után fél évvel az oktatott személyek közül mindenkinek felmondott a cégvezetés, emiatt lehet gyakran visszajárni oktatni, de az is tapasztalat, hogy azért sem árt az újraoktatás, mert sok mindent elfelejtenek a felhasználók, nincs kedvük/idejük a felhasználói dokumentációt olvasgatni, na persze a programozók sem grafomániájukról híresek.

A munka haladását a megrendelő részéről a projektfelügyelő tudja ellenőrizni. Ennek egy lehetséges módja, ha a kivitelező legalább egy héten egyszer beszámol, esetleg a gyakorlatban is bemutatja hova jutott. Ez szoftver esetében azért nehéz, mert lehet, hogy az egyheti munka nem hoz semmi látványosat. A beszámolós ellenőrzés elég sok bizalmat feltételez a megrendelő részéről, mert nem tudja tisztán például a programkód mennyiségéből megállapítani, hogy mennyit is dolgozott a megbízott programozó (a minőségről nem is beszélve): valami átlagos adatkezelő feladathoz több ezer programsort is lehet írni ennyi idő alatt, ugyanakkor egy bonyolultabb képfeldolgozási feladat néhány száz programsora csak többszöri ötletelés-kísérletezés után tud összejönni. Tehát hinni kell a beszámolóban, és ha esetleg mégsem az igazat mondta a programozó, akkor azért az pár hét alatt csak kiderül, nem lehet a végtelenségig handabandázni. A projekt ütemezési tervében kell rögzíteni a mérföldköveket, ahol azért valamit a gyakorlatban fel kell mutatnia a vállalkozónak. Ha ehhez részletfizetési pontokat kötünk, akkor biztosan látni is fogunk valamit. És nagyjából határidőre, nagyjából a megadott költségvetéssel befejeződik a projekt.

A szoftverprojekt kockázatát csökkenteni lehet, ha sikerül találni olyan szoftvert, amely nagyjából megfelel az igényeinknek és a program módosítását (testreszabását) kérjük a fejlesztőtől, vagy mi visszük lejjebb igényeinket, és akkor ahogy van, úgy tudjuk használni a programot. Ez sem tökéletes megoldás, mert ha testreszabott programmal dolgozunk és az alapszoftverből újabb jön ki, akkor arra csak újabb testreszabással tudunk áttérni, utóbbi esetben pedig azt érezzük, hogy na jó, gyorsan és olcsón bevezettük, de mégsem olyan igazi.

Ráadásul itt van még ez a fránya szoftverevolúció: egy Lehman nevű matematikus 1980-ban leírta4, hogy a jó szoftver szükségképpen elavul, újra kell azt írni. Ez bizonyára nem jó hír azoknak, akik tényleg elégedettek az üzembehelyezett szoftverrel: mivel napi szinten használják, még több feladatot szeretnének rábízni a programra, ezt a zseniális programozó újra és újra megoldja, de a végeredmény egy (programozói szempontból) kezelhetetlen, átláthatatlan programkódhalmaz lesz, egyszerűen gány. Újabb kérés esetén előbb a programozó a száját húzza, aztán már felteszi a kezeit, hogy ő mostmár tényleg nem mer ebbe belenyúlni, írjuk át az egészet. Aztán jön a szoftverprojekt, minden veszedelmével és lehetséges dicsőségével.

Meg kell említeni, hogy a megbízottnak lehetnek indokolt csúszásai: velünk néhányszor már előfordult, hogy a használt fejlesztőeszközben vagy adatbáziskezelőben bukkantak fel olyan hibák, amiket nyakatekert módon kellett végülis kikerülnünk. Nem volt belőle gond, mert jeleztük a megrendelőnek, sőt be is mutattuk a jelenséget és belefért pár nap elmaradás emiatt.

Mennyi? Száz. Mi száz? Miért, mi mennyi?

Igen, mindenkinek tudnia kell, mi mennyi. Egy kicsit is komoly szoftvercég milyen nettó óradíjakkal számol? Minden elismerésem a karosszérialakatosoké, hihetetlen dolgokat tudnak csinálni összetört autókból, négyezer Ft-os munkadíj mellett. A programozók is hihetetlen termelékennyé tudnak tenni vállalkozásokat, ezért ők minimum megérdemelnek nyolc-tízezer Ft-ot óránként. Szerintem ez a belépő egy komoly szoftverfejlesztő esetén, de a piaci ár igazából tizenkétezer Ft, ja igen, az ár nem tartalmazza az ÁFA-t. Ezt a pénzt nem a programozó teszi zsebbe, olyan felesleges kiadásai vannak még, mint jövedelemadó, járulékok, hordozható számítógép, telefonhasználat, irodabérlet, irodai rezsi, szakkönyvek, évi két-három továbbképző tanfolyam, szoftverlicence-k stb. De nem is ezek az érdekesek, hiszen ezeket mindenki fizeti, inkább az a lényeg, hogy ha valaki ezután egy keményen átdolgozandó mondjuk 100 órás munkára négyszázezer Ft-os ajánlatot ad, akkor azon – Kedves Megbízók – tessenek nagyon komolyan elgondolkodni.

Inkább gondolkodni, mint csalódni és veszekedni.

o o o

1 Az Intrada az AKTÍV REKORD Kft. ipari logisztikai komponenscsaládja volt, amellyel egyedi ipari logisztikai megoldásokat lehetett készíteni.

2 Informatikai Vállalkozások Szövetsége, a hazai informatikai cégek legnagyobb érdekképviseleti szervezete, “kvázi kamarája”

3 A funkcionális rendszerterv leírja a majdani rendszer működését olyan formában, hogy azt nem informatikai szakemberek is meg tudják érteni.

4 Meir M. Lehman: “Programs, Life Cycles and Laws of Software Evolution”. Proceedings of the IEEE, Vol.68. No.9. September 1980, p.1060