Szoftverfejlesztő cég választása: 12 kérdés, mielőtt aláírsz

Egy egyedi szoftver évekig a céged működésének része lesz: rajta futnak az ajánlatok, a megrendelések, a terepi munka vagy az ügyfélkapcsolatok. A fejlesztőpartner kiválasztása ezért inkább hasonlít egy hosszú távú együttműködés megkötésére, mint egy termék megvásárlására. Az ajánlatok első ránézésre nehezen összevethetők: más-más terjedelem, eltérő szóhasználat, eltérő vállalások. Az alábbi tizenkét kérdés abban segít, hogy minden jelöltet ugyanazzal a mércével mérj — és hogy időben kiderüljön, ha valami hiányzik.

Átláthatóság kedvéért: mi magunk is szoftverfejlesztéssel foglalkozunk Miskolcon. Ezeket a kérdéseket nekünk is nyugodtan tedd fel — a lista épp azért készült, hogy bárkivel szemben használhasd.

Mielőtt ajánlatot kérsz: a saját házi feladat

A legjobb fejlesztő sem tud pontos ajánlatot adni egy félmondatos igényre. Írd le röviden, egy-két oldalban:

• milyen problémát old meg a rendszer, és mi lesz jobb, ha elkészül;
• kik fogják használni, hány fő, milyen eszközön (irodai gép, telefon, tablet a terepen);
• milyen meglévő rendszerekhez kell kapcsolódnia (számlázó, webshop, könyvelés, levelezés);
• mi az a minimum, ami nélkül nem indulhat, és mi az, ami ráér egy második körre.

Jelölj ki egy belső kapcsolattartót is, aki ismeri a folyamatot és dönteni tud. Ha ugyanezt a leírást küldöd el minden jelöltnek, az ajánlatok végre összehasonlíthatók lesznek — és az is kiderül, ki mennyire figyelt oda rájuk.

1–3. Szakmai illeszkedés: érti a problémádat?

1. Milyen hasonló problémát oldottatok már meg?

Nem feltétlenül ugyanabból az iparágból kell referencia, hanem hasonló összetettségű feladatból: hasonló számú felhasználó, hasonló integrációk, hasonló offline vagy jogosultsági igények. Kérd meg, hogy vázolja fel, hogyan fogna hozzá a te esetedhez. A jó fejlesztő az első beszélgetésen sokat kérdez — ha végig ő beszél, és már az elején tudja a megoldást, az intő jel.

2. Hogyan jutunk el a homályos igénytől a pontos ajánlatig?

Egy összetett rendszerre húszperces telefon után senki sem tud felelősen fix árat mondani. A komoly partner vagy felmérést javasol, vagy kimondott feltételezésekkel adott sávot ad. Kérdezd meg, mi a felmérés kézzelfogható eredménye: fontossági sorrendbe állított funkciólista, a kulcsképernyők vázlata, ütemterv és tételes ajánlat? Ha a felmérés után sem tudod, pontosan mit fogsz kapni, a fejlesztés alatt sem fogod.

3. Mit nem építenél meg a helyünkben?

Ez a kérdés az őszinteséget teszteli. Egy jó fejlesztő megmondja, ha egy funkcióra elég egy kész eszköz, ha valamit érdemes későbbre hagyni, vagy ha az egész igényt jobban szolgálja egy bérelhető szoftver. Ügyfélkezelésnél például az egyedi CRM kisvállalkozásnak cikkünkben írtuk le, mikor elég a táblázat vagy a kész CRM. Aki mindenre egyedi fejlesztést javasol, az nem a te érdekedet nézi.

4–6. Kié lesz, ami elkészül?

4. Kié a forráskód, és milyen jogokat kapunk?

A magyar szerzői jogi törvény a szoftvert szerzői műként védi, ezért a kifizetett díj önmagában nem jelenti, hogy minden jog automatikusan a tiéd. Hogy megkapod-e a forráskódot, módosíthatod-e más fejlesztővel, továbbadhatod-e, az a szerződésen múlik. Kérdezz rá arra is, használ-e a fejlesztő saját, korábban írt modulokat — ezekre jellemzően más feltételek vonatkoznak. A részleteket a Kié a forráskód? cikkünkben bontottuk ki.

5. Milyen dokumentációt kapunk az átadáskor?

Felhasználói leírás, üzemeltetési leírás, az architektúra áttekintése, a telepítés és élesítés lépései. A legjobb próbakérdés: ha holnap egy másik fejlesztőnek kellene átvennie a rendszert, miből tudna dolgozni? Ha erre a válasz bizonytalan, a céged egyetlen emberhez vagy céghez kötődik — és ez akkor is kockázat, ha most minden jól megy.

6. Kinek a nevén lesz a kódtár, a tárhely és a domain?

A forráskód tárolója, a felhőelőfizetés, a domain, mobilappnál az alkalmazásbolti fejlesztői fiók, valamint a külső szolgáltatások (e-mail-küldés, fizetés, térkép) ideális esetben a céged nevén vannak, a fejlesztő pedig meghívott hozzáféréssel dolgozik bennük. Ha ez nem megoldható, legalább adminisztrátori hozzáférésed legyen. Ezt sokkal könnyebb az elején rendezni, mint egy esetleges szakításkor.

7–9. Ki dolgozik rajta, és hogyan?

7. Ki írja ténylegesen a kódot?

Saját fejlesztők, alvállalkozók vagy egy külföldi csapat? Az alvállalkozó bevonása önmagában nem baj, de tudnod kell róla. Három okból is: ki fér hozzá a céged adataihoz, ki felel a hibáért, és eljutnak-e hozzád a jogok — ha a kódot egy alvállalkozó írta, a fővállalkozónak is rendelkeznie kell azokkal a jogokkal, amelyeket neked továbbad. Kérd el a kulcsemberek nevét, és kérdezd meg, a projekt végéig ők maradnak-e rajta.

8. Beszélhetek egy korábbi ügyfeletekkel?

A portfólió képernyőképei azt mutatják, mi készült el, de azt nem, hogyan. Kérj elérhetőséget legalább egy korábbi ügyfélhez, és kérdezd meg tőle: tartották-e a határidőket, hogyan kommunikáltak, mi történt, amikor hiba volt, és újra velük dolgozna-e. Ha titoktartás miatt nem lehet nevet mondani, kérj anonimizált esettanulmányt és élő demót egy működő rendszerről.

9. Milyen ritmusban egyeztetünk, és mit látok a munkából?

A legrosszabb forgatókönyv: három hónap csend, aztán egy kész rendszer, ami nem azt tudja, amire szükséged van. Kérdezd meg, milyen rendszerességgel mutatnak működő részeredményt, van-e tesztkörnyezet, ahol kipróbálhatod, kihez fordulsz kérdéssel, és hol követheted a feladatokat. Az iteratív, rövid körös fejlesztés lényege éppen az, hogy menet közben is lehessen irányt korrigálni.

10–12. Mi történik az átadás után?

10. Mi alapján mondjuk ki, hogy kész?

Az átadás-átvételnél ne az érzés döntsön. Legyenek előre leírt tesztforgatókönyvek, egy tesztelési időszak, amelyben jelezheted a hibákat, és egy közös hibabesorolás (blokkoló, súlyos, kozmetikai). Így egyértelmű, mi akadályozza az átvételt, és mi kerülhet egy későbbi javítási körbe.

11. Ki felel a hibákért és a frissítésekért élesítés után?

Tisztázd, meddig és milyen határidővel javítják díjmentesen az átadott funkciók hibáit, mi számít új igénynek, és milyen csatornán kérhetsz segítséget. Egy szoftvert élesítés után is frissíteni kell: a felhasznált könyvtárak biztonsági javításokat kapnak, a böngészők és operációs rendszerek változnak. Kérdezd meg azt is, ki üzemelteti a szervereket — ha a fejlesztő ezt is vállalja, mint nálunk az IT-üzemeltetés, egy kézben marad a felelősség.

12. Mi történik, ha egyszer elválnak útjaink?

A jó együttműködés nem a bezártságra épül. Kérdezd meg, hogyan kapod meg a teljes forráskódot és dokumentációt, milyen formátumban tudod kimenteni az adataidat, és ad-e a fejlesztő átmeneti segítséget egy új csapatnak. Ha erre a kérdésre kitérő választ kapsz, azt komolyan kell venni.

Mit tartalmaz egy jó ajánlat?

Vészjelek: mikor állj fel az asztaltól?

• Fix ár felmérés nélkül egy összetett rendszerre — a bizonytalanság árát vagy a végén fizeted meg, vagy a minőség sínyli meg.
• A teljes díj előre, mérföldkövekhez kötött részteljesítés nélkül.
• Kitérő válasz arra, hogy kié lesz a forráskód, és mit tehetsz vele.
• Nincs rálátásod semmire a fejlesztés alatt: se tesztkörnyezet, se rendszeres bemutató.
• Mindenre igent mond. Aki egyetlen funkciót sem kérdőjelez meg, az vagy nem érti a feladatot, vagy nem fogja tudni tartani a terjedelmet.
• Sürgetés: „csak ma érvényes” kedvezmény egy több hónapos projektnél.

Nézd meg a cég nyilvános adatait is. Az ingyenes céginformáció és az Elektronikus Beszámoló Portál közzétett beszámolói alapján képet kaphatsz a cég koráról, tevékenységéről és pénzügyi helyzetéről. Egy több hónapos együttműködésnél ez nem bizalmatlanság, hanem gondos beszerzés.

Számít, hogy miskolci a fejlesztő?

Röviden: néha nagyon, néha alig. A közelség akkor ér sokat, ha a munka egy része fizikailag a telephelyedhez kötődik:

• Helyszíni felmérés. Ha a folyamatot a raktárban, a műhelyben vagy a terepen kell megérteni, a személyes jelenlét felgyorsítja és pontosítja a felmérést. Miskolcon és Borsod-Abaúj-Zemplén településein ez nem külön utazási projekt, hanem a megszokott munkamenet része.
• Workshopok és betanítás. A kulcsfelhasználók személyes betanítása sokszor gördülékenyebb, főleg ott, ahol a csapat kevésbé szokott digitális eszközökhöz.
• Fizikai környezethez kötött rendszerek. Ha a szoftvernek gépekhez, helyi hálózathoz, saját szerverhez vagy épületautomatizáláshoz kell kapcsolódnia, sokat ér, ha egy hibánál valaki ki is tud menni.

Ha viszont a feladat jól körülhatárolt, tisztán webes, és a csapatod megszokta az online egyeztetést, a földrajzi közelség másodlagos. Ilyenkor a szakmai illeszkedés, a kommunikáció minősége és a fenti tizenkét kérdésre adott válaszok sokkal többet nyomnak a latban, mint a kilométerek. Egy jó távoli partner többet ér egy gyenge helyinél — és fordítva is igaz.

Mi Miskolcon dolgozunk, saját fejlesztőkkel és több mint 15 év mérnöki tapasztalattal. A felmérést és a kulcs-workshopokat a telephelyeden tartjuk, távolabbi ügyfeleinkkel online egyeztetünk; a fejlesztés alatt közvetlenül azokkal beszélsz, akik a rendszereden dolgoznak.

Ha a projekted ügyfélkezelésről szól, az egyedi CRM oldalunkon a bevezetés menetét is leírtuk. Ha mobilon dolgozó kollégáknak vagy ügyfeleknek készülne, a Mobilalkalmazás, webes alkalmazás vagy PWA? útmutatónk segít dönteni. Kérdésed van? Írj nekünk.