8 költséges alkalmazásfejlesztési hiba, amelyet a kkv-k újra meg újra elkövetnek

Íme a kényelmetlen igazság a félresikló alkalmazásprojektekről: mire a kód rosszul kezd kinézni, a projekt már hetekkel korábban elveszett. A kisvállalkozói alkalmazásfejlesztés költséges hibái szinte sosem a billentyűzetnél történnek. Hétköznapi beszélgetésekben történnek – a brief, amelyet sosem írtak le, a funkció, amelyet valaki „ha már itt tartunk” alapon hozzátett, a fejlesztő, akit azért választottak, mert egy barát ajánlotta. Akkor egyik sem tűnik döntésnek. Mindegyik később kerül pénzbe.

Sok kisvállalkozást láttam megrendelni az első alkalmazását, és nem keveset hívtak már, hogy mentsem meg utólag. A tulajdonosok ritkán hanyag emberek. Élesek, körültekintők, jól vezetnek céget. A szoftvernek azonban megvan a maga csapdakészlete, amely sehol máshol nem létezik a munkás életükben, és senki sem figyelmeztette őket. Így minden alkalommal egyenesen ugyanabba a nyolc buktatóba sétálnak bele, nagyjából ugyanabban a sorrendben.

Ez az a lista, amelyet azt kívántam volna, hogy minden tulajdonos kézbe kapjon, mielőtt egy fillért is költ. Nem elmélet – a valódi, ismétlődő hibák és azok az apró irányhelyesbítések, amelyek minden projektet megmentettek volna. Ha most készül alkalmazást építeni, vagy már a fejlesztés közepén jár, és valami nem stimmel, először ezt olvassa el. A legtöbbjük még javítható, ha időben elkapja.

1. hiba: Építeni, mielőtt bizonyítaná, hogy bárki akarja

A legköltségesebb hiba egyben a leggyakoribb is: elkötelezni magát egy teljes fejlesztés mellett, mielőtt bármilyen valódi bizonyíték lenne arra, hogy az alkalmazás olyan problémát old meg, amelyért az emberek fizetnek vagy amelyet használni fognak. Az ötlet a tulajdonosnak nyilvánvalónak tűnik – persze hogy az ügyfelek akarni fogják –, és pontosan ez a bizonyosság a veszélyes. A bizonyosság olyan, mint a validálás. De nem az.

A validálás nem azt jelenti, hogy tíz barátot megkérdez, tetszik-e nekik az ötlet; mindenki igent mond, hogy kedves legyen. Azt jelenti, hogy a lehető legkisebb verziót valódi felhasználók elé teszi egy valódi helyzetben, és figyeli, mit tesznek valójában. Egy kattintható prototípus, egy regisztrációkat mérő céloldal, egy manuális „concierge” verzió, amelyben kézzel hamisítja az automatizálást – bármelyik többet mond, mint egy megérzésre épített, kész alkalmazás. A sorrend számít: bizonyítsa a keresletet olcsón, aztán építsen drágán. Fordítva, az egész költségvetését elköltheti valami olyasmi csiszolására, amit senki sem nyit meg kétszer.

2. hiba: Ambíciónak álcázott hatókör-elcsúszás

Minden alkalmazás karcsún és rendezetten indul. Aztán jönnek a „ha már itt tartunk”-ok. Ha már a foglalási képernyőt építjük, nem tudná kezelni az ajándékutalványokat is? És a hűségpontokat? És egy ajánlórendszert? Minden egyes kiegészítés önmagában ésszerűen hangzik. Együtt csendben megháromszorozzák a határidőt és a számlát – és olyan messzire tolják az indulást, hogy az eredeti lendület elhal.

A megoldás nem az, hogy nemet mondunk a jó ötletekre. Hanem hogy félretesszük őket. Vezessen egy látható „második verzió” listát, ahová minden csillogó ötlet bevárja a sorát. Ez a gyakorlati mellett pszichológiai dolgot is tesz: az emberek abbahagyják a harcot, hogy funkciókat zsúfoljanak az első kiadásba, amint megbíznak abban, hogy az ötletüknek később valódi helye lesz. Az első verziójának egy dolgot kell igazán jól csinálnia, nem tíz dolgot elfogadhatóan. Az az alkalmazás, amely egyetlen munkafolyamatot tökéletesen old meg, használatban marad. Az, amelyik mindent félig csinál, elhagyatottá válik.

3. hiba: Nincs leírt brief – csak egy közös fejben élő kép

Ez a hiba láthatatlan, amíg meg nem harap. A tulajdonosnak van egy világos alkalmazás a fejében. A fejlesztőnek van egy világos alkalmazás a fejében. A kezdő megbeszélésen mindenki bólogat. Senki sem írja le rendesen – és kiderül, hogy a két kép sosem volt ugyanaz a kép. Ezt félúton fedezi fel, amikor az épülő dolog nem az, amit elképzelt, és most már vita van arról, ki mit mondott.

Nincs szüksége százoldalas specifikációra. Néhány oldalra van szüksége, amelyet bármely újonnan érkező el tud olvasni és megérteni: ki használja ezt az alkalmazást, mi az a három-négy dolog, amit tennie kell vele, hogyan néz ki a sikeres eredmény. Tegyen hozzá egy durva vázlatot a kulcsképernyőkről. Ennyi. A brief lényege nem a bürokrácia – hanem egy közös hivatkozás, amelyre mindketten rámutathatnak, amikor az emlékezet és a valóság elkezd elcsúszni egymástól, ami mindig megtörténik.

4. hiba: A fejlesztő rossz módon való kiválasztása

A legtöbb tulajdonos két ingatag jel egyike alapján választja ki az első fejlesztőjét: a legalacsonyabb árajánlat, vagy egy más iparágból érkező személyes ajánlás. Mindkettő működhet szerencséből. Egyik sem megbízható módja annak, hogy olyasvalakit válasszon, akire jelentős összegű pénzt és a vállalkozása jövőjéből több hónapot bíz.

A legalacsonyabb árajánlat a szoftverben különösen alattomos, mert az árajánlat és a végső költség közötti szakadék hatalmas és láthatatlan. Egy olcsó fejlesztő, akinek három kör átdolgozásra van szüksége, két hétre eltűnik, és olyan kóddal hagyja magára, amelyet senki más nem tud karbantartani, jóval drágább, mint egy kicsit borsosabb, aki elsőre jól csinálja. Az ár az, amit lát; a teljes költség az, amit fizet.

Mit ellenőrizzen valójában

Kérje, hogy lássa, milyen, még ma is működő dolgokat adott át, és ha lehet, beszéljen azokkal az ügyfelekkel a fejlesztő nélkül a szobában. Kérdezze meg, hogyan kezeli a projekt közbeni változásokat, mert lesznek változások. Kérdezze meg, kié a kód és a fiókok, amikor elkészül – a válasz mindig az öné kell legyen. És figyelje, hogy ő is feltesz-e jó kérdéseket. Az a fejlesztő, aki csak parancsokat fogad, nagyon hatékonyan építi meg pontosan a rossz dolgot. A jók ellentmondanak, rámutatnak a gondolkodásában lévő hézagokra, és a briefet egy beszélgetés kiindulópontjaként kezelik, nem rögzített bevásárlólistaként.

5. hiba: A fejlesztésre tervezni, a többit elfelejteni

Az alkalmazás nem egyszeri vásárlás, mint egy nyomtatott prospektus. Élő dolog, amelyet etetni kell. A tulajdonosok rendszeresen csak a fejlesztésre terveznek, semmi másra, aztán meglepik őket az utána érkező költségek: a tárhely, az alkalmazásbolti díjak, a karbantartás a telefonos operációs rendszerek frissítéseivel való lépéstartáshoz, és a javítások és apró fejlesztések elkerülhetetlen köre, amint valódi emberek elkezdik használni.

Egy ésszerű ökölszabály: bármibe is kerül a fejlesztés, tegyen félre annak jelentős szeletét újra az első év üzemeltetésére. A pontos szám változó, de a hiba egyetemes – az indulás napját célvonalnak tekinteni, miközben valójában a rajtvonal. Az az alkalmazás, amely elindul, majd csendben elhagyatottá válik, mert nincs költségvetés a karbantartására, az egész terület egyik legszomorúbb és leggyakoribb végkimenetele, és teljesen elkerülhető őszinte, előzetes tervezéssel.

6. hiba: Magának tervezni a felhasználó helyett

Kívülről ismeri a vállalkozását, ami a lehető legrosszabb bíróvá teszi abban, hogy az alkalmazása könnyen használható-e. Azok a dolgok, amelyek önnek nyilvánvalók – a szakzsargon, a sorrend, amelyben a feladatokat végzi, a rövidítések, amelyeket gondolkodás nélkül használ –, megzavarják az első alkalommal használót. Az az alkalmazás, amely a tulajdonosnak tökéletes értelmet ad, mindenki mást pedig összezavar, megbukott, bármilyen okos is.

A gyógymód olcsó és kissé megalázó: figyeljen valódi embereket, ahogy használják, mielőtt elindítja. Nem a csapatát, akik már tudják, hogyan kellene működnie – valódi ügyfeleket vagy munkatársakat, akik még sosem látták. Adja a kezükbe az alkalmazást, adjon nekik egy feladatot, és ne szóljon semmit. Ahol haboznak, rosszra koppintanak vagy felsóhajtanak, az a dizájn-visszajelzése. Öt ember elég a legrosszabb problémák felszínre hozásához. Ennek a lépésnek a kihagyása az oka annak, hogy az alkalmazások olyan „beküldés” gombbal indulnak, amelyet senki sem talál meg, és olyan regisztrációs folyamattal, amely a próbálkozók felét elveszíti.

• Adjon a tesztelőnek valódi feladatot, ne körbevezetést – „foglalj időpontot jövő keddre”, aztán hallgasson.
• Figyelje a kezét és az arcát, ne csak azt, hogy végül sikerül-e neki.
• Jegyezzen fel minden tétovázást; a szünet olyan dizájnprobléma, amelyet belülről nem lát.
• Álljon ellen a magyarázat késztetésének – ha el kell magyaráznia, az alkalmazásnak kellett volna.
• Teszteljen öt emberrel, javítsa a nyilvánvaló hibákat, aztán teszteljen újra.

7. hiba: Natív iOS-t és Androidot építeni, amikor nem kellett volna

Van egy reflex, hogy az első naptól „rendes” alkalmazást építsünk iPhone-ra és Androidra egyaránt, teljesen natívan, ahogy a nagy márkák teszik. A legtöbb kisvállalkozásnak ez két-háromszoros költséget és bonyolultságot jelent egy olyan előnyért, amelyet a felhasználói soha nem fognak észrevenni. Sőt, most már örökre két különálló kódbázist tart karban, megkétszerezve minden jövőbeli javítást.

Gyakran a helyes első lépés egyáltalán nem egy natív alkalmazás. Egy jól megépített webalkalmazás, amely bármely telefon böngészőjében működik, vagy egy platformfüggetlen megközelítés, amely egyetlen kódbázisból állítja elő mindkét bolti verziót, gyorsabban és olcsóbban juttatja a piacra – és később bármikor áttérhet a teljesen natívra, ha a valós használat bebizonyítja, hogy megéri. A kérdés sosem absztrakt értelemben „natív vagy web”. Hanem: mi a legkisebb, legolcsóbb dolog, amely lehetővé teszi a valódi felhasználóknak, hogy elvégezzék a lényegi feladatot? Azt építse meg, tanuljon belőle, aztán a nagy pénzt bizonyíték alapján költse, ne feltételezésre.

8. hiba: Az indulást a munka végének tekinteni

A nyolcadik hiba azt hinni, hogy a projekt kész, amikor az alkalmazás élesedik. Nincs kész – akkor kezdődik a valódi projekt. Egy alkalmazás, amelynek nincs terve arra, hogyan jusson a felhasználók kezébe, nincs módja meghallani, mit gondolnak, és nincs szándéka fejleszteni a tanultak alapján, hónapok alatt elhalványuló alkalmazás. A fejlesztés volt a könnyű rész. Az elfogadtatás a nehéz rész, és szinte senki sem tervez vele.

Mielőtt elindítja, tudjon három dolgot: hogyan tudják meg az emberek, hogy az alkalmazás létezik, hogyan méri, hogy valóban használják-e, és hogyan gyűjti össze, amit mondanak, hogy a munka következő körét a valóság vezérelje, ne a találgatás. Ezek egyike sem drága. Csak egy másfajta gondolkodásmód – az alkalmazás nem olyasmi, amit befejez és otthagy, hanem egy kapcsolat, amelyet ápol. Azok a tulajdonosok, akik ezt megértik, idővel egyre hasznosabbá váló alkalmazásokat kapnak. Akik nem, azok egy indulásnapi csúcsot és egy hosszú, csendes hanyatlást.

Hogyan kerülje el mind a nyolcat egyszerre

Együtt olvasva ezeknek a hibáknak egyetlen közös gyökerük van: gyorsan haladni feltételezésekre építve, ahelyett hogy lassan haladna bizonyítékokra építve. Mindegyikük olyan hely, ahol olcsóbbnak tűnt kihagyni a gondos lépést. És mindegyiket sokkal olcsóbb a fejlesztés előtt kezelni, mint utána. Íme a sorrend, amely csendben elkerüli mind a nyolcat.

1. 1
   Bizonyítsa a keresletet, mielőtt építene

   Egy prototípus, egy céloldal vagy egy manuális verzió. Szerezzen valódi bizonyítékot, hogy valaki akarja ezt, mielőtt elkötelezi a költségvetést.
2. 2
   Írja meg a briefet és a második verzió listáját

   Néhány világos oldal, amelyet bárki megért, plusz egy parkoló minden „ha már itt tartunk” ötletnek, hogy ne térítse el a v1-et.
3. 3
   A fejlesztőt a teljesítmény alapján válassza, ne ár alapján

   Átadott munka, referenciahívások, a kód és a fiókok egyértelmű tulajdona, és valaki, aki ő is jó kérdéseket tesz fel.
4. 4
   Tervezzen az egész első évre, ne csak a fejlesztésre

   Tárhely, karbantartás, javítások és támogatás. Az indulás napja a rajtvonal, úgyhogy finanszírozza a dolog üzemeltetését.
5. 5
   Válassza a legkisebb platformot, amely elvégzi a feladatot

   A legtöbb esetben először web vagy platformfüggetlen. A teljesen natívra később térjen át, bizonyítékkal, csak ha a használat megköveteli.
6. 6
   Teszteljen valódi felhasználókkal, aztán tervezze meg az indulást

   Figyeljen öt idegent, ahogy használják, javítsa a nyilvánvaló hibákat, és döntse el előre, hogyan találják meg az emberek, és hogyan méri a használatot.

Gyakori kérdések