Fejlesztőcég választásnál sokszor csak ár és szimpátia alapján döntünk, pedig több olyan szempont van, amit érdemes megértenünk és figyelembe vennünk.
Nézzünk azokat, amelyeket semmiképp sem érdemes félresöpörni:
Ha a felhívásban nem kötöttük ki pontosan milyen technológiát szeretnénk, akkor több, különböző megoldással fogunk találkozni az ajánlatokban.
A választott technológia kapcsán amit érdemes megfontolnunk:
2-3 év múlva mennyire lesz elavult a versenytársak javaslataival szemben? Komoly problémát okozhatunk magunknak a későbbiekben, ha kifutó technológiát választunk és túl korán nyugdíjba kell küldenünk az elkészült megoldást.
Bármennyire is körbejártuk az igényeket brief írás közben, olyan nincs, hogy új igények ne jelenjenek meg a fejlesztés közben vagy után. Olyan technológiát válasszunk, ami megfelel a cégünk és iparágunk igényeinek. Ha nagyon szeretünk kreatívan szárnyalni, egyedi megoldásokat alkalmazni, akkor egy dobozos, keretesebb megoldás sokkal kényelmetlenebb lehet mint egy egyedi fejlesztés.
A technológia amit választunk gyakran meghatározza azt is, hogy mennyire egyszerű másik fejlesztő után nézni, ha a kezdeti jó kapcsolat rosszra fordulna. Ha tudatos döntést hozunk, hogy számunkra mi az ideális működés, akkor nem érhetnek később kellemetlen meglepetések.
Ebben a cikkben jobban kifejtettem a szállítófüggetlenség kérdésének árakra gyakorolt hatásait.
Az egyik legizgalmasabb kérdés, hogy az adott fejlesztésnek mikorra kell elkészülnie ahhoz, hogy az üzleti célunkat szolgálja. (Pl: az esemény, amit hirdetünk, vagy a karácsonyi szezon, amire készülünk).
Ha a tervezett élesítés határideje akár picit is rugalmas akkor nem éri meg 1-2 hónap miatt a második vagy harmadik legjobb céget választani a kivitelezésre.
Fontos, hogy reálisak legyünk a határidő meghatározásánál, és időben kezdjük el az ajánlatkérés, és a brief írás folyamatát, beleszámítva a fejlesztés mellett, alatt és után a saját feladatainkat is. Komplex fejlesztések esetében a véghatáridők valóban rajtunk, az ügyfélen múlnak, így például az adatbázis készültségén vagy éppen a tesztelés sebességén.
Ahhoz, hogy az érdekeink védve legyenek, a toplistás ajánlattevőktől nyugodtan kérdezzük meg a kötbér feltételeket, kérjünk be egy minta szerződést, és legyünk tisztában azokkal a következményekkel is, amit a mi esetleges késedelmünk eredményezne a projekt költségvetésére.
Fontos már a nulladik ponton értenünk mi vár ránk, ha a fejlesztéssel valami baj van - akár mi okoztuk, akár a fejlesztés során ment valami félre. Ebben adhat segítséget a jótállás és az SLA (azaz Service Level Agreement) megismerése.
A jótállás - amit sok helyen, népnyelven garanciának hívnak - megmutatja, hogy amennyiben az átadott rendszer hibás, és a hiba nem a rossz használat, vagy külső okok miatt jelentkezett, meddig javítja ki a fejlesztő cég a hibát térítésmentesen.
Folyamatosan fejlesztett rendszerek esetében ez a jótállásos szakasz elég nehezen értelmezhető 3-4 hónapon túl a sok egymásra épülő funkció miatt, de sok cég 6 vagy 12 hónapos jótállásokat kínál.
Szorosan kapcsolódik ehhez az SLA, ami inkább már a support megállapodások része, és a gyakorlatban azt mutatja meg, hogy egy felmerülő probléma, incidens esetén milyen hamar reagál a cég és próbál megoldást szállítani.
A feladatok és megkeresések jellemzően 3 kategóriába kerülnek (sürgős, közepes ill. alacsony prioritás) amelyek ennek megfelelően pár órán vagy pár napon belül kerülnek felvételre (általában munkaidőben). Érdemes a valóságtól nem elrugaszkodott igényeket támasztani a fejlesztőcégek felé, például egy pár órás support megállapodásba biztosan nem fér bele az, hogy munkaidőn túl fix válaszidőkre szerződjenek, de közös érdek a problémamentes működés, így a szerződésnél sokszor gyorsabb megoldásokat várhatunk.