7 hiba, amit a kisvállalkozások egyedi szoftver vásárlásakor elkövetnek

A legtöbb kisvállalkozás, amely megégette magát egy egyedi szoftverprojekten, nem a rossz programozók miatt égette meg magát. Hetekkel a programozás megkezdése előtt égették meg magukat, egy nyitóértekezleten, egy e-mail-szálban, egy kézfogásban, egy döntéssel, amely akkor apróságnak tűnt. Mire megérkezik a kód, a hiba már beleépült. A jó hír, hogy ezek a hibák unalmasan ismétlődnek, ami azt jelenti, hogy elkerülhetők, ha tudja, hogyan néznek ki.

Sok ilyen projektet láttam belülről, az asztal mindkét oldaláról. Némelyik olyan eszközzé vált, amely nélkül egy cég el sem tudja képzelni a munkát. Mások egy félkész belépőképernyővé, egy feszült számlavitává és egy alapítóvá váltak, aki esküdözik, hogy soha többé nem vág bele egyedibe. Az a bosszantó, milyen kevés választotta el a két végkimenetelt. Ritkán a technológia volt a baj. A technológia körüli döntések szinte mindig azok voltak.

Íme tehát az a hét hiba, amelyet újra és újra látok, amikor egy kisvállalkozás egyedi szoftvert rendel. Egyik elkerüléséhez sem kell műszaki háttér. Csupán annyi kell, hogy tudja, léteznek, mielőtt bármit is aláírna.

1. hiba: Megoldást venni, mielőtt megértené a problémát

A legdrágább hiba elsőként történik, és ártalmatlanul hangzik: „Kell egy alkalmazás, ami X-et csinál.” Mire valaki ezt hangosan kimondja, általában már eldöntötte a megoldás formáját, egy irányítópultot, egy portált, egy mobilalkalmazást, anélkül, hogy bárki leírta volna a tényleges problémát egyszerű nyelven. A fejlesztés aztán hűségesen leszállítja a rossz dolgot, méghozzá gyönyörűen.

A jó szoftver egy problémaleírásból indul ki, nem egy funkciólistából. „Az irodai csapatunk minden rendelést újra begépel az e-mailből a könyvelőrendszerbe, és ez két embernek fél napjába kerül” – ez egy probléma. „Kell egy egyedi CRM” – ez egy találgatás egy olyan probléma megoldására, amelyet senki sem fáradt megnevezni. Az első olcsón megoldható és mérhető. A második nyitott meghívó a pénzköltésre.

2. hiba: Egyszerre mindent megépíteni

Az egyedi szoftver úgy hat, mint egy évtizedenként egyszeri beszerzés, ezért az emberek egy évtized kívánságait próbálják belezsúfolni az első verzióba. Minden részleg hozzátesz egy kérést. Minden „ha már itt vagyunk” igent kap. A terjedelem felduzzad, az ütemterv megháromszorozódik, és a projekt összeomlik a saját ambíciója alatt, jóval azelőtt, hogy bárki használhatná.

A sikeres cégek épp az ellenkezőjét teszik. Kiválasztják a probléma egyetlen, legfájdalmasabb szeletét, és először azt építik meg, egy valódi, működő dolgot, élesben, néhány hónapon belül. Aztán hagyják, hogy a tényleges használat mondja meg, mi következik. Ez nemcsak olcsóbb, hanem biztonságosabb is. Akkor derül ki, működik-e az ötlet, amikor a tét még kicsi, ahelyett, hogy fél év és egy nagy számla után fedezné fel, hogy a rossz dolgot tervezte meg.

Ez alatt egy kemény igazság húzódik: valójában még nem tudja, mire van szüksége. Az elején senki sem tudja. A problémáról alkotott megértése abban a pillanatban megváltozik, amint valódi emberek valódi eszközhöz nyúlnak. Ha mindent előre megépít, az a legkorábbi, legkevésbé tájékozott találgatásait rögzíti. A szeletekben építés rugalmasan tartja, és kordában tartja a költségvetést, miközben még tanul.

3. hiba: Pusztán ár alapján választani

Három árajánlatot kap. Az egyik drámaian olcsóbb a többinél. Megkönnyebbülés, azt választja. Ez az egyik legmegbízhatóbb módja annak, hogy egy kis projektet drágává tegyen, mert az olcsó ajánlat szinte sosem jelenti azt, hogy a munka olcsóbb. Általában azt jelenti, hogy a két fél másképp értelmezte a feladatot.

Egy alacsony szám gyakran néhány dolog egyikét jelzi: a beszállító alulbecsülte a terjedelmet, mert nem tett fel elég kérdést, később a változtatási kéréseken tervezi kihozni a haszonkulcsát, vagy tapasztalatlan, és még nem tudja, mit nem tud. Egyik sem végződik jól az ön számára. A főcímben szereplő ár a legkevésbé hasznos szám az ajánlatban. Az számít, hogy a beszállító világosan érti-e a problémáját, feltesz-e kényelmetlen kérdéseket, és őszinte-e azzal kapcsolatban, ami nincs benne.

4. hiba: Elfelejteni, hogy a szoftver nem egyszeri vásárlás

Az egyedi szoftvert gyakran úgy kínálják és veszik meg, mint egy bútordarabot: fizet egyszer, és örökre az öné. Pedig nem így van. A szoftver egy mozgó világban él, az operációs rendszerek frissülnek, a böngészők változnak, biztonsági javítások érkeznek, az ön üzlete eltolódik, az eszközök, amelyekhez kapcsolódik, megváltoztatják a szabályaikat. Egy eszköz, amelyet senki sem karbantart, lassan abbahagyja a működést, majd a lehető legrosszabb pillanatban elromlik.

Ez csúnyán elkapja a kisvállalkozásokat, mert a karbantartási költség aláíráskor láthatatlan. Két ajánlatot a fejlesztési ár alapján hasonlít össze, és sosem teszi fel a kérdést, amely fontosabb: mennyibe kerül évente életben és egészségesen tartani ezt? Tárhely, frissítések, apró javítások, az alkalmankénti változtatás, ahogy üzlete fejlődik, tervezzen vele mint normális, folyamatos tétellel, ahogy a biztosítással vagy a könyveléssel teszi. Általában szerény, de csak akkor, ha számít rá.

5. hiba: Homályosan és felelős nélkül hagyni a követelményeket

„Önök a szakértők, csak építsenek valami jót” – nagyvonalúan hangzik. Valójában így sodródnak el a projektek. Akik a legjobban értik az üzletét, azok ön és a csapata, nem a fejlesztők. Ha átad egy homályos kiírást, és eltűnik, a beszállító a legjobb találgatásaival tölti ki a hézagokat, és ezeket a találgatásokat a legrosszabb időpontban fedezi fel: az átadáskor, amikor a megváltoztatásuk a legdrágább.

Az ön oldalán két szerepet kell betölteni, és a kisvállalkozások rendszerint egyiket sem töltik be. Az első egy egyetlen döntéshozó, egy ember, aki tud igent mondani, el tudja simítani a részlegek közötti nézeteltéréseket, és nem annyira elfoglalt, hogy heteken át ne válaszoljon kérdésekre. A második a hajlandóság, hogy konkrét legyen a számító részeknél: a szélső esetek, az a furcsa kivétel, amelyet az üzlete mindig kézzel kezelt, a szabály, amelyet mindenki ismer, de senki sem írt le. Pontosan ezeket kell a szoftvernek eltalálnia.

6. hiba: Nem megkérdezni, kié a kód és az adat

Ez a csendes hiba, és ez az, amelyik évekkel később a legjobban fáj. Fizet az egyedi szoftverért, és feltételezi, hogy az öné. Aztán megromlik a kapcsolat a beszállítóval, vagy árat emel, vagy egyszerűen eltűnik, és ön rájön, hogy nem tud továbblépni. Nincs meg a forráskódja. Az adat egy olyan rendszerben él, amelyhez csak ő fér hozzá. Az egész működése most egy olyan cégtől függ, amelyben már nem bízik, és önnek nincs semmilyen alkupozíciója.

Ennek megelőzéséhez nem kell ügyvéd. Három egyszerű kérdés kell, amelyeket azelőtt tesz fel, hogy belekezdene, amíg még minden alkuereje megvan: Kié a forráskód, amikor ez elkészül? Ki tudom-e exportálni minden adatomat, használható formátumban, amikor csak akarom? És ha elválnak útjaink, pontosan mivel távozom? Egy tisztességes partner ezekre szemrebbenés nélkül válaszol. A habozás itt az egész folyamat legnagyobb intő jele.

• Kérje írásban, hogy öné a forráskód, vagy világos, méltányos licenccel rendelkezik rá.
• Erősítse meg, hogy saját adatait szabványos formátumban, igény szerint, engedély nélkül exportálhatja.
• Gondoskodjon róla, hogy a munka elég jól dokumentált legyen ahhoz, hogy egy másik fejlesztő átvehesse.
• Kerülje a szabadalmaztatott bezáródást ott, ahol egy egyszerű, jól ismert technológia ugyanazt a munkát elvégezné.
• Egyezzen meg előre arról, mi történik a tárhellyel és a fiókokkal, ha valaha beszállítót vált.

7. hiba: A bevezetést célvonalként kezelni

A szoftvert leszállítják, működik, mindenki megkönnyebbül. A projektet késznek nyilvánítják. Fél évvel később a csapat fele csendben visszasodródott a régi táblázathoz, a drága új eszközt pedig két ember használja egyetlen dologra. A fejlesztés sikerült. Az elfogadtatás kudarcot vallott, és a kettő teljesen különböző probléma.

Az emberek nem azért állnak ellen az új eszközöknek, mert buták vagy makacsak. Azért állnak ellen, mert az új mód ismeretlen, a régi mód pedig még mindig működik, valahogy. Ennek legyőzése olyan tudatos erőfeszítést igényel, amelyet senki sem tervezett be: egy kis képzést, egy világos okot arra, miért segít a változás kifejezetten nekik, valakit, aki az első hetekben ítélkezés nélkül válaszol a buta kérdésekre, és egy határozott döntést, hogy a régi módot nyugdíjazza, hogy ne maradjon menedék, amelybe vissza lehet csúszni.

1. 1
   Először egy kis csoportnak vezesse be

   Néhány lelkes embernek vezesse be az eszközt az egész csapat előtt. Megtalálják a durva éleket, és belső szószólóivá válnak.
2. 2
   A személyes nyereséget mutassa meg, ne a cégeset

   „Ez pénzt spórol a cégnek” senkit sem motivál. „Ez azt jelenti, hogy nem kell kétszer begépelned a címeket” megnyeri az embereket.
3. 3
   Nevezzen ki egy felelőst a kérdésekre

   Az első hónapban valaki vállalja a buta kérdéseket. Az első heti súrlódás az, ami az elfogadtatást örökre megöli.
4. 4
   Valóban kapcsolja ki a régi módot

   Amíg a régi táblázat létezik, az emberek tovább használják. Ha működik, nyugdíjazza a menedéket, finoman, de egyértelműen.

Összerakva: a vásárlói gondolkodásmód

Olvassa vissza azt a hetet, és egyetlen fonal húzódik végig rajtuk. Szinte egyik sem műszaki. A világosságról, a tulajdonlásról és a mértékletességről szólnak: ismerje a problémáját, mielőtt vásárol, építsen kis lépésekben, a beszállítókat a megértés alapján ítélje meg, ne az ár alapján, tervezzen az eszköz egész életére, ne csak a megszületésére, maradjon bevonva, védje a kiútját, és a bevezetést kezelje a valódi munka kezdeteként.

Az egyedi szoftver valóban az egyik legjobb befektetés, amelyet egy kisvállalkozás megtehet, miután kinőtte a dobozos eszközöket, amelyeken mindenki osztozik. Egy rendszer, amelyet pontosan az ön munkamódszerére szabtak, ahelyett, hogy az üzletét más termékéhez kéne tekergetnie, valódi és tartós előny. Azok a cégek, amelyek odaérnek, nem a legnagyobb költségvetésűek. Azok, amelyek elkerülték a fenti hét hibát, és ez ítélőképesség kérdése, nem pénzé.

Gyakori kérdések