8 nákladných chýb pri vývoji aplikácií, ktoré malé firmy stále opakujú

Tu je nepríjemná pravda o projektoch aplikácií, ktoré sa pokazia: kým kód začne vyzerať zle, projekt bol stratený už týždne predtým. Nákladné chyby pri vývoji aplikácií pre malé firmy sa takmer nikdy nestávajú pri klávesnici. Stávajú sa v nezáväzných rozhovoroch — zadanie, ktoré sa nikdy nezapísalo, funkcia, ktorú niekto pridal „keď už pri tom sme“, vývojár vybraný preto, lebo ho odporučil kamarát. Nič z toho v danej chvíli nepôsobí ako rozhodnutie. Všetko vás to stojí neskôr.

Videl som veľa malých firiem zadávať svoju prvú aplikáciu a privolali ma, aby som ich nemálo zachránil dodatočne. Majitelia zriedka bývajú nedbalí ľudia. Sú bystrí, obozretní, dobrí v riadení firmy. No softvér má vlastnú sadu nástrah, ktoré v ich pracovnom živote nikde inde neexistujú, a nikto ich nevaroval. Tak vchádzajú rovno do tých istých ôsmich pascí, zakaždým zhruba v rovnakom poradí.

Toto je zoznam, ktorý by som prial mať každému majiteľovi skôr, než minie čo i len cent. Nie teória — skutočné, opakujúce sa chyby a malé korekcie kurzu, ktoré by každý projekt zachránili. Ak sa chystáte postaviť aplikáciu, alebo ste už uprostred vývoja a niečo vám nesedí, prečítajte si najprv toto. Väčšinu z nich sa stále dá napraviť, ak ich zachytíte včas.

Chyba 1: Staviate skôr, než ste dokázali, že to niekto chce

Najnákladnejšia chyba je zároveň najčastejšia: zaviazať sa k plnému vývoju skôr, než existuje akýkoľvek skutočný dôkaz, že aplikácia rieši problém, za ktorý ľudia zaplatia alebo ho budú používať. Nápad sa majiteľovi zdá zrejmý — samozrejme, že to zákazníci budú chcieť — a práve táto istota je nebezpečná. Istota pôsobí ako overenie. Nie je ním.

Overenie neznamená opýtať sa desiatich priateľov, či sa im nápad páči; všetci povedia áno, aby boli milí. Znamená to postaviť najmenšiu možnú verziu pred skutočných používateľov v skutočnej situácii a sledovať, čo naozaj robia. Klikateľný prototyp, vstupná stránka, ktorá meria registrácie, manuálna „concierge“ verzia, kde automatizáciu predstierate vlastnými rukami — čokoľvek z toho vám povie viac než hotová aplikácia postavená na tušení. Na poradí záleží: dopyt dokážte lacno, potom stavajte draho. Obráťte to a môžete minúť celý rozpočet na vyleštenie niečoho, čo nikto neotvorí dvakrát.

Chyba 2: Rozrastanie rozsahu vydávané za ambíciu

Každá aplikácia začína štíhla a usporiadaná. Potom sa začne to „keď už pri tom sme“. Keď už staviame obrazovku na rezervácie, mohla by zvládať aj darčekové poukazy? A vernostné body? A systém odporúčaní? Každý prídavok znie sám o sebe rozumne. Spolu ticho strojnásobia časový plán aj účet — a odsunú spustenie tak ďaleko, že pôvodná dynamika zomrie.

Riešením nie je povedať dobrým nápadom nie. Je ním odložiť ich. Veďte viditeľný zoznam „verzia dva“, kam ide každý lesklý nápad čakať na svoj rad. To pôsobí psychologicky aj prakticky: ľudia prestanú bojovať o napchanie funkcií do prvého vydania, len čo uveria, že pre ich nápad existuje neskôr skutočné miesto. Vaša prvá verzia má robiť jednu vec naozaj dobre, nie desať vecí priemerne. Aplikácia, ktorá zvládne jeden pracovný postup, sa používa. Aplikácia, ktorá robí všetko spolovice, sa opúšťa.

Chyba 3: Žiadne písomné zadanie — len spoločná predstava v hlave

Táto je neviditeľná, kým nezahryzne. Majiteľ má v hlave jasnú aplikáciu. Vývojár má v hlave jasnú aplikáciu. Na úvodnom stretnutí všetci prikyvujú. Nikto to poriadne nezapíše — a tie dva obrazy, ako sa ukáže, neboli nikdy ten istý obraz. Zistíte to v polovici cesty, keď to, čo sa stavia, nie je to, čo ste si predstavovali, a teraz sa hádate o tom, kto čo povedal.

Nepotrebujete stostranovú špecifikáciu. Potrebujete pár strán, ktoré si každý nováčik prečíta a pochopí: kto túto aplikáciu používa, ktoré tri alebo štyri veci s ňou potrebuje robiť, ako vyzerá úspešný výsledok. Pridajte hrubý náčrt kľúčových obrazoviek. To je všetko. Zmyslom zadania nie je byrokracia — je to spoločná referencia, na ktorú obaja môžete ukázať, keď sa pamäť a realita začnú rozchádzať, čo sa stáva vždy.

Chyba 4: Výber vývojára nesprávnym spôsobom

Väčšina majiteľov si vyberá svojho prvého vývojára na základe jedného z dvoch chatrných signálov: najnižšej ponuky alebo osobného odporúčania od niekoho z iného odvetvia. Oboje môže vyjsť zo šťastia. Ani jedno nie je spoľahlivý spôsob, ako si vybrať niekoho, komu zveríte poriadny kus peňazí a niekoľko mesiacov budúcnosti svojej firmy.

Najnižšia ponuka je v softvéri obzvlášť zradná, lebo rozdiel medzi ponukou a konečnou cenou je obrovský a neviditeľný. Lacný vývojár, ktorý potrebuje tri kolá prepracovania, na dva týždne zmizne a nechá vás s kódom, ktorý nikto iný nedokáže udržiavať, je oveľa drahší než o čosi drahší, ktorý to spraví správne. Cena je to, čo vidíte; celkové náklady sú to, čo platíte.

Čo si naozaj overiť

Vypýtajte si ukážky vecí, ktoré dodali a stále bežia, a ak môžete, porozprávajte sa s tými klientmi bez vývojára v miestnosti. Opýtajte sa, ako riešia zmeny uprostred projektu, lebo zmeny budú. Opýtajte sa, kto vlastní kód a účty, keď je hotovo — odpoveď má vždy znieť vy. A všímajte si, či kladú dobré otázky späť. Vývojár, ktorý len prijíma príkazy, veľmi efektívne postaví presne tú nesprávnu vec. Tí dobrí oponujú, poukazujú na medzery vo vašom uvažovaní a zadanie berú ako východisko pre rozhovor, nie ako pevný nákupný zoznam.

Chyba 5: Rozpočtujete vývoj, zabúdate na zvyšok

Aplikácia nie je jednorazový nákup ako tlačená brožúra. Je to živá vec, ktorá potrebuje kŕmenie. Majitelia bežne rozpočtujú vývoj a nič iné, a potom ich zaskočia náklady, ktoré prídu potom: hosting, poplatky obchodov s aplikáciami, údržba, aby držali krok s aktualizáciami operačného systému telefónov, a nevyhnutné kolo opráv a malých vylepšení, len čo aplikáciu začnú používať skutoční ľudia.

Rozumné orientačné pravidlo: nech vývoj stojí čokoľvek, vyhraďte si výrazný kus toho istého znova na prvý rok prevádzky. Presné číslo sa líši, ale chyba je univerzálna — brať deň spustenia ako cieľovú čiaru, keď je v skutočnosti štartovacou čiarou. Aplikácia, ktorá sa spustí a potom sa ticho opustí, lebo niet rozpočtu na jej údržbu, je jedným z najsmutnejších a najčastejších výsledkov v celej tejto oblasti a poctivým plánovaním vopred sa jej dá úplne vyhnúť.

Chyba 6: Navrhujete pre seba namiesto pre svojho používateľa

Svoju firmu poznáte do špiku kosti, čo z vás robí najhoršieho možného posudzovateľa toho, či sa vaša aplikácia ľahko používa. Veci, ktoré sú pre vás samozrejmé — žargón, poradie, v akom úlohy robíte, skratky, ktoré beriete bez rozmýšľania — sú pre prvého používateľa mätúce. Aplikácia, ktorá má pre majiteľa dokonalý zmysel a všetkých ostatných mätie, zlyhala, nech je akokoľvek dômyselná.

Liek je lacný a trochu pokorujúci: pred spustením sledujte, ako ju používajú skutoční ľudia. Nie váš tím, ktorý už vie, ako to má fungovať — skutoční zákazníci alebo zamestnanci, ktorí ju nikdy nevideli. Dajte im aplikáciu, dajte im úlohu a nič nehovorte. Tam, kde zaváhajú, ťuknú na nesprávnu vec alebo si vzdychnú, máte spätnú väzbu k dizajnu. Päť ľudí stačí, aby vyplávali najhoršie problémy. Preskočenie tohto kroku je dôvod, prečo sa aplikácie spúšťajú s tlačidlom „odoslať“, ktoré nikto nevie nájsť, a registračným postupom, ktorý stratí polovicu tých, čo to skúsia.

• Dajte testerovi skutočnú úlohu, nie prehliadku — „rezervujte termín na budúci utorok“, a potom mlčte.
• Sledujte jeho ruky a tvár, nielen to, či sa mu to nakoniec podarí.
• Zaznamenajte si každé zaváhanie; pauza je problém dizajnu, ktorý zvnútra nevidíte.
• Odolajte nutkaniu vysvetľovať — ak to musíte vysvetliť, mala to spraviť aplikácia.
• Otestujte s piatimi ľuďmi, opravte zjavné zlyhania, potom otestujte znova.

Chyba 7: Staviate natívny iOS aj Android, hoci ste to nepotrebovali

Existuje reflex postaviť „poriadnu“ aplikáciu pre iPhone aj Android hneď od prvého dňa, plne natívnu, ako to robia veľké značky. Pre väčšinu malých firiem sú to dvoj- až trojnásobné náklady a zložitosť za úžitok, ktorý si vaši používatelia nikdy nevšimnú. Horšie, teraz navždy udržiavate dve samostatné kódové základne a každú budúcu opravu zdvojnásobujete.

Často správny prvý krok vôbec nie je natívna aplikácia. Dobre postavená webová aplikácia, ktorá funguje v prehliadači akéhokoľvek telefónu, alebo multiplatformový prístup, ktorý z jednej kódovej základne vyprodukuje obe verzie pre obchody, vás dostane na trh rýchlejšie a lacnejšie — a vždy môžete neskôr prejsť na plne natívne, ak skutočné používanie dokáže, že sa to oplatí. Otázka, ktorú si treba klásť, nikdy nie je abstraktne „natívne alebo web“. Je to: aká je najmenšia, najlacnejšia vec, ktorá skutočným používateľom umožní spraviť kľúčovú prácu? Postavte to, poučte sa z toho a potom miňte veľké peniaze s dôkazmi namiesto domnienok.

Chyba 8: Brať spustenie ako koniec práce

Ôsma chyba je veriť, že projekt je hotový, keď aplikácia ide naživo. Nie je — vtedy sa skutočný projekt začína. Aplikácia bez plánu, ako ju dostať do rúk používateľov, bez spôsobu, ako počuť, čo si myslia, a bez úmyslu zlepšovať ju na základe toho, čo sa dozviete, je aplikácia, ktorá do pár mesiacov vyhasne. Vývoj bol tá ľahká časť. Osvojenie je tá ťažká časť a takmer nikto ho neplánuje.

Pred spustením vedzte tri veci: ako sa ľudia dozvedia, že aplikácia existuje, ako budete merať, či ju naozaj používajú, a ako pozbierate, čo vám povedia, aby ďalšie kolo práce riadila realita namiesto dohadov. Nič z toho nie je drahé. Je to len iné nastavenie mysle — aplikácia nie je vec, ktorú dokončíte a odídete od nej, je to vzťah, ktorý udržiavate. Majitelia, ktorí to chápu, dostávajú aplikácie, ktoré sú časom čoraz užitočnejšie. Tí, čo to nechápu, dostanú výkyv v deň spustenia a dlhý, tichý úpadok.

Ako sa vyhnúť všetkým ôsmim naraz

Čítané spolu majú tieto chyby jediný koreň: pohyb rýchlo na domnienkach namiesto pomaly na dôkazoch. Každá z nich je miesto, kde sa zdalo lacnejšie preskočiť opatrný krok. A každú z nich je oveľa lacnejšie riešiť pred vývojom než po ňom. Tu je postupnosť, ktorá ticho obíde všetkých osem.

1. 1
   Dokážte dopyt skôr, než staviate

   Prototyp, vstupná stránka alebo manuálna verzia. Získajte skutočný dôkaz, že to niekto chce, skôr než sa zaviažete k rozpočtu.
2. 2
   Napíšte zadanie a zoznam verzie dva

   Pár jasných strán, ktorým každý porozumie, plus odstavné miesto pre každý nápad „keď už pri tom sme“, aby nevykoľajil v1.
3. 3
   Vyberte vývojára podľa výsledkov, nie ceny

   Dodaná práca, telefonáty s referenciami, jasné vlastníctvo kódu a účtov a niekto, kto kladie dobré otázky späť.
4. 4
   Rozpočtujte celý prvý rok, nielen vývoj

   Hosting, údržba, opravy a podpora. Deň spustenia je štartovacia čiara, tak financujte prevádzku tej veci.
5. 5
   Vyberte najmenšiu platformu, ktorá splní úlohu

   Vo väčšine prípadov najprv web alebo multiplatformové. Na plne natívne prejdite neskôr, s dôkazmi, len ak si to používanie vyžiada.
6. 6
   Otestujte so skutočnými používateľmi, potom naplánujte spustenie

   Sledujte piatich cudzincov, ako ju používajú, opravte zjavné zlyhania a vopred rozhodnite, ako ju ľudia nájdu a ako budete merať používanie.

Časté otázky