Hogyan válassz fejlesztő céget?

Szerző: Kormos János (fixaidea munkatársa)

Pénztárcánkhoz mérten, minél jelentősebb kiadásra készülünk, annál inkább megfontoljuk a döntést. Ugye, te is így csinálod? Egy szerkesztői rendszerrel ellátott és teljes körűen menedzselhető website vagy internetes alkalmazás nem néhány 10 ezer forintos költség. Éppen ezért célszerű megfontolni, hogy kitől és mit veszünk. Cikksorozatunkban igyekszünk végigvenni azokat a szempontokat, melyek megfontolásra érdemesek mielőtt döntenél. Előzetesen, felsorolásszerűen vegyük végig ezeket:

  • Elkészült munkáik megfelelnek-e a kor szabványainak?
  • Egyetlen böngészőre vagy felbontásra dolgoznak?
  • Használnak-e hibabejelentő rendszert?
  • A megbeszéléseket követi-e írott feljegyzés közreadása?
  • Árajánlatuk egyösszegű vagy részekre bontott?
  • Kész megoldást kínálunk! Csak testre kell szabni. Valóban?
  • Milyen dokumentáltságot biztosítanak a termékükhöz?
  • Akadálymentesítettségre törekednek, támogatják? (hamarosan)
  • Termékük megfelel-e jogszabályi, kormányzati ajánlásoknak? (hamarosan)
  • Munkájuk során használnak-e verziókövető, csoportmunka rendszert? (hamarosan)
  • Specifikáció alapján fejlesztenek? Változás-kérelmeket dokumentálják? (hamarosan)

Vegyük most sorra ezeket:
(cikkünk folyamatosan bővül, látogass vissza később is!)

Megfelelnek-e elkészült munkáik a kor szabványainak?

Egész életünk behálózzák az ilyen-olyan szabványok. Az eszközöknek amiket használunk, az ételnek amit megveszünk a sarki boltba, mind mind számtalan szabványnak, előírásnak kell megfelelniük. Hogy miért van erre szükség? Hogy garantálja minőségüket, használhatóságukat, működésüket. Vegyünk egy konkrét példát. Nézzük a nappalink középpontjában lévő házimozi rendszert. Ha nem felelnének meg a számtalan elektronikai eszközökre vonatkozó szabványoknak és előírásnak, akkor hogyan tudná megjeleníteni televíziónk a DVD-ről lejátszott filmet? A kedvenc sorozatunk – videónkkal rögzített – legfrissebb epizódját, hogy tudná lejátszani barátunk más gyártótól származó videója? Ugye, hogy szabványok nélkül ezek egyike se menne? Miért lenne ez másképpen az internetes technológiák területén? Ezért kövessük a web szabványait!

Egyetlen böngészőre vagy felbontásra dolgoznak?

Kérdezzük meg, hogy leendő weboldalunk milyen felbontásra és böngészőkre lesz jó, mit ajánlanak. Ha azt a választ kapjuk, hogy az Internet Explorer annyira elterjedt, hogy mással nem érdemes foglalkozni, már meg se várjuk a mondat végét, hagyjuk ott őket azonnal, mert hiba lenne erre a fejlesztő cégre bízni oldalunk elkészítését.

Ha a válaszban több böngésző neve is előkerül (IE, Mozilla, Opera, Safari) és hogy ezekben közel azonosan jelenik meg, akkor az már két fokkal jobb, de még mindig nem biztos, hogy az, amire ma pénzt érdemes áldozni. Nézzük meg a cég saját honlapját és vessük őket „szabványügyi vizsgálat” alá. Először is keressünk a szabványok követésére utaló ikonokat a honlapon, persze ha ezeket megtaláljuk, még nem garancia, hogy meg is felelnek a szabványoknak. Második lépésként keressük fel a http://validator.w3.org/ honlapot. Itt adjuk meg a vizsgált weboldal címét. Ha a teszt azzal zárul, hogy: „This page is not valid”, akkor bizony nem felel meg a szabványoknak. Bár hozzáértés és szakértelem nélkül nem tudjuk meghatározni a hibák fajsúlyát, de a hibák mennyiségéből, sokféleségéből áttételesen következtethetünk munkájuk minőségére. Próbáljunk letesztelni több oldalt, ne csak a címlapot, hanem belső oldalakat is. Ha a tesztek alapján úgy találjuk, hogy nem a szabványok szerint dolgoznak, álljunk tovább!

Meg kell említeni, hogy mivel manapság már egyre több honlapot maguk az ügyfelek szerkesztenek a különböző tartalomkezelő eszközök révén, amelyek bár törekszenek rá, hogy hibátlan és érvényes kódot generáljanak, mégis a nem kellően felkészült használójuk képes érvénytelen kódot kifacsarni belőlük, érvénytelenné téve vele az egész oldat. Ezért azt javasoljuk, hogy szakértelem nélkül csak a webfejlesztő cég saját honlapját teszteljük a fent megjelölt eszközzel.

Használnak-e hibabejelentő rendszert?

A hibabejelentő rendszer elsősorban a weboldal, illetve alkalmazás kifejlesztését követő tesztelés közben fellelt hibákat és kisebb arányban a később, üzemeltetés közben kiütköző hibák rögzítésére, életútjának figyelemmel kísérésére szolgál. Azok a fejlesztő cégek, melyek ilyet nem üzemeltetnek, illetve nem követelik meg az ügyfelektől ennek használatát, egészen egyszerűen nem professzionális művelői szakmájuknak. Az e-mailben rendszertelenül küldözgetett hibabejelentések elkallódhatnak, a problémáról folytatott esetleges diskurzus pedig (pláne ha az telefonon folyt) nem követhető mindenki által. Ez különösen akkor veszélyes, ha többen is dolgoznak az adott projekten.

A megbeszéléseket követi-e írott feljegyzés közreadása?

Számtalan olyan megbeszélés résztvevője voltam, melyek során a projektet bonyolító felek a megbeszélésen elhangzottakat, illetve eldöntött dolgokat, feladatokat nem rögzítették írásban. Ez igen nagy hiba, mert később már senki nem fog pontosan emlékezni, mi és hogy hangzott el. Az ilyen feljegyzéseket természetesen nem a megrendelőnek tisztsége elkészíteni, hanem a szállítónak. Bár mindkét fél érdekeit szolgálja e feljegyzések megléte, mégis, mivel általában mindenki utál dokumentálni, ezért el szokták hanyagolni ezt a dolgot. Ez viszont nem szolgálja a megrendelő javát! Éppen ezért a referencia listában lévő korábbi megrendelőktől érdeklődjünk, hogy történt ez az ő projektjük során.

Árajánlatuk egy összegű vagy részekre bontott?

Komoly, nagy volumenű tenderre befutó ajánlatok között is láttam már egyösszegű árajánlatot. Vajon mennyire átgondolt az az ajánlat? Bizton állíthatom, semennyire! Természetesen vannak olyan apró funkciók, vagy módosítások, melyek nem igényelnek részletezést vagy tovább bontást. Azonban már egy több funkcióból álló site mindenképp. Hiszen még a legegyszerűbb ajánlat elkészítése is több eltérő jellegű részből tevődik össze: a látványterv, a testreszabás, a programozás, a késztermék ára.

Miért csak részekre bontott ajánlatot fogadjunk el?

  • mert így meg tudjuk határozni, melyek azok a funkciók, amelyek preferenciáinkhoz képes relatíve drágák, ergo elhagyandók,
  • mert jobban becsülhetők az egyes funkciók, részfeladatok ráfordításai, esetleg ezeket egymással össze is tudjuk vetni,
  • kisebb, átlátható, jobban becsülhető részekre bontás esetén hamarabb kibukik az eltúlzott árazás,
  • mert gyakori stratégia az egyösszegű árazást alkalmazóknál, hogy amikor az árajánlat véglegesítésére kerül sor, a részfeladatok boncolgatásával, nem fontos részek elhagyásának taglalásával, akkor valahogy mindig a számunka fontos részek a drágábbak és a nem fontosak alig kerülnek valamibe. Valahogy „átcsoportosul” azokra a munka dandárja. Ami nem feltétlenül igaz.
  • mert a rendelkezésre álló büdzsénket a leghatékonyabban tudjuk felhasználni a megfelelő komponensek vásárlására.

Kész megoldást kínálunk! Csak testre kell szabni. Valóban?

Igen sokan – még nagy vállalatok is – alkalmazzák azt a taktikát, hogy valójában még el nem készült vagy nem kifejezetten az adott célra készült szoftvert próbálnak „kész megoldásként” eladni. Azonban ez a gyakorlatban a következő problémával jár: testreszabás címén kell eladni a fejlesztés idejét. Azonban e kettő nem azonos kaliber. Ezért feltűnően hosszú testreszabási időt kívánnak, azonban mivel a szállító maga is érzi, hogy túlságosan kilóg a lóláb, ezért önkéntelenül, vagy tudatosan, az elvégzendő munkához képest nagyon szűk határidőt szab. És ez általában azzal is jár, hogy rohammunkában, késve elkészült, nem átgondolt végterméket kap a megrendelő. Mivel a határidőből kicsúsznak, ezért a tesztelés időszakát is rejtett fejlesztői időnek tekintik. Ez azonban lehetetlenné teszi a valódi tesztelést. Az eredmény káosz, kapkodás, „bugos” szoftver, csalódott vevő és a szállítói oldalon frusztrált fejlesztő alkalmazottak.

Tehát ha valaki kész, csak testreszabást igénylő megoldást kínál, akkor annak valamilyen bemutató, demó oldallal kell rendelkeznie termékéről. Így működés közben szerzett benyomások alapján ítélhetjük meg termékét. Mindenképp nézzük meg megrendelés előtt!

Milyen dokumentáltságot biztosítanak a termékükhöz?

Leszögezhetjük, hogy a programozók utálnak dokumentálni! Éppen ezért nagyon jellemző, hogy nincs tisztességes írott dokumentáció az alkalmazásokról. Természetesen ez nem mindig probléma, hiszen egy egyszerű website vendégkönyvéhez nincs szükség különösebb dokumentációra. De vajon akarunk-e vásárolni egy olyan portál-motor által hajtott szerkesztői rendszert, amely dokumentálatlan?

Milyen dokumentumok megléte célszerű?

A felhasználói kézikönyvre mindenképp szükségünk van. Ezt nem helyettesíti a betanítás. Miért? Mert ha a betanított munkavállaló távozik, akkor megint be kell tanítani valakit. Ismét oktatást kell szervezni. Ez idő és pénz. Ami jóval több, mint ha egy jól megírt dokumentációból akár önállóan felkészülne. E rendszerek használata nem olyan bonyolult, hogy egy jól megírt kézikönyv alapján ne lehetne használatukat elsajátítani önállóan. De ne feledjük, ehhez rendelkeznünk kell ezzel a kézikönyvvel.

Ha a vásárolt rendszert saját szervereden fogod üzemeltetni, akkor szükséged lesz üzemeltetési dokumentációra. E dokumentáció részletezi a szoftver követelményeit, telepítésének folyamatát, a rendszeres karbantartási feladatokat és a váratlan, kritikus események helyreállítási forgatókönyvét is.

Ha magát a szoftvert szőröstől-bőröstől megvásároltuk, és mi rendelkezünk azzal, akár tovább is fejleszthetjük, módosíthatjuk, akkor mindenképp szükségünk lesz egy technikai dokumentációra, valamint megjegyzésekkel gazdagon teletűzdelt forráskódra. Erre most nem térek ki részletesen, mert igen ritka, hogy a megrendelő nem csak a használat jogát, hanem magát a szoftvert is megveszi. De ha ebben a cipőben jársz, gondolj erre is.

(folytatjuk)