8 nákladných chyb při vývoji aplikací, kterých se malé firmy stále dopouštějí

Tady je nepříjemná pravda o projektech aplikací, které se zvrtnou: v okamžiku, kdy kód začne vypadat špatně, byl projekt ztracen už před týdny. Nákladné chyby při vývoji aplikací pro malé firmy se téměř nikdy nestávají u klávesnice. Stávají se v běžných rozhovorech — v zadání, které nikdo nesepsal, ve funkci, kterou někdo přidal „když už jsme u toho“, ve vývojáři vybraném proto, že ho doporučil kamarád. V tu chvíli nic z toho nepůsobí jako rozhodnutí. A všechno vás to stojí později.

Viděl jsem spoustu malých firem zadávat svou první aplikaci a nejednu jsem byl povolán zachraňovat, když už bylo pozdě. Majitelé bývají málokdy nedbalí lidé. Jsou bystří, opatrní, schopní vést firmu. Software má ale svou vlastní sadu pastí, které nikde jinde v jejich pracovním životě neexistují, a nikdo je nevaroval. A tak vejdou rovnou do týchž osmi nástrah, zhruba ve stejném pořadí, pokaždé.

Tohle je seznam, který bych přál mít každému majiteli dřív, než utratil jedinou korunu. Žádná teorie — skutečné, opakující se chyby a drobné korekce kurzu, které by každý projekt zachránily. Pokud se chystáte stavět aplikaci, nebo už jste uprostřed stavby a něco vám nesedí, přečtěte si nejdřív tohle. Většinu z toho lze ještě napravit, pokud to zachytíte včas.

Chyba 1: Stavět dřív, než dokážete, že to někdo chce

Nejnákladnější chyba je zároveň ta nejčastější: zavázat se k plné stavbě dřív, než existuje jakýkoli skutečný důkaz, že aplikace řeší problém, za který lidé zaplatí nebo který budou používat. Majiteli ten nápad připadá samozřejmý — zákazníci to přece budou chtít — a právě ta jistota je nebezpečná. Jistota působí jako ověření. Ale není to ověření.

Ověření neznamená zeptat se deseti kamarádů, jestli se jim nápad líbí; každý řekne ano, aby byl milý. Znamená to postavit nejmenší možnou verzi před skutečné uživatele ve skutečné situaci a sledovat, co doopravdy dělají. Klikatelný prototyp, vstupní stránka měřící registrace, ruční „concierge“ verze, kde automatizaci falšujete vlastní rukou — kterákoli z nich vám řekne víc než hotová aplikace postavená na tušení. Záleží na pořadí: poptávku dokažte levně, pak stavte draze. Obraťte to a můžete celý rozpočet utratit za leštění něčeho, co nikdo neotevře dvakrát.

Chyba 2: Bobtnání rozsahu převlečené za ambici

Každá aplikace začíná štíhlá a úhledná. Pak začnou „když už jsme u toho“. Když už stavíme rezervační obrazovku, nemohla by zvládat i dárkové poukazy? A věrnostní body? A doporučovací systém? Každý přídavek zní sám o sobě rozumně. Dohromady tiše ztrojnásobí harmonogram i účet — a odsunou spuštění tak daleko, že původní rozjezd zemře.

Řešením není říkat dobrým nápadům ne. Je jím je odložit. Veďte si viditelný seznam „verze dvě“, kam každý třpytivý nápad jde počkat, až na něj přijde řada. To dělá kromě praktického i psychologickou věc: lidé přestanou bojovat o nacpání funkcí do prvního vydání, jakmile uvěří, že pro jejich nápad je později skutečné místo. Vaše první verze by měla dělat jednu věc opravdu dobře, ne deset věcí obstojně. Aplikace, která dokonale zvládá jediný pracovní postup, se používá. Aplikace, která dělá všechno napůl, se opouští.

Chyba 3: Žádné písemné zadání — jen sdílená představa v hlavě

Tahle chyba je neviditelná, dokud nekousne. Majitel má v hlavě jasnou aplikaci. Vývojář má v hlavě jasnou aplikaci. Na úvodní schůzce všichni přikyvují. Nikdo to pořádně nesepíše — a ukáže se, že ty dvě představy nikdy nebyly tatáž představa. Zjistíte to v půlce cesty, když to, co se staví, není to, co jste si představovali, a teď je tu hádka o tom, kdo co řekl.

Nepotřebujete stostránkovou specifikaci. Potřebujete pár stránek, které si kterýkoli nováček přečte a pochopí: kdo tuhle aplikaci používá, jaké tři nebo čtyři věci s ní potřebuje dělat, jak vypadá úspěšný výsledek. Přidejte hrubý náčrt klíčových obrazovek. A to je vše. Smyslem zadání není byrokracie — je to společný odkaz, na který oba můžete ukázat, když se paměť a realita začnou rozcházet, což se vždycky stane.

Chyba 4: Volba vývojáře špatným způsobem

Většina majitelů si vybírá svého prvního vývojáře podle jednoho ze dvou chatrných signálů: nejnižší nabídky, nebo osobního doporučení od někoho z jiného oboru. Obojí může fungovat náhodou. Ani jedno není spolehlivý způsob, jak vybrat někoho, komu svěříte slušnou částku peněz a několik měsíců budoucnosti své firmy.

Nejnižší nabídka je v softwaru obzvlášť zrádná, protože propast mezi nabídkou a konečnou cenou je obrovská a neviditelná. Levný vývojář, který potřebuje tři kola přepracování, na dva týdny zmizí a zanechá vám kód, který nikdo jiný nedokáže udržovat, je mnohem dražší než ten o trochu dražší, který to udělá hned napoprvé správně. Cena je to, co vidíte; celkové náklady jsou to, co platíte.

Co skutečně prověřit

Požádejte, ať vám ukáže věci, které dodal a které stále běží, a pokud můžete, promluvte si s těmi klienty bez vývojáře v místnosti. Zeptejte se, jak řeší změny uprostřed projektu, protože změny přijdou. Zeptejte se, komu po dokončení patří kód a účty — odpověď by měla být vždy vám. A všímejte si, jestli se zpětně sám ptá na dobré otázky. Vývojář, který jen plní příkazy, postaví přesně tu špatnou věc velmi efektivně. Ti dobří oponují, ukazují mezery ve vašem uvažování a berou zadání jako výchozí bod pro rozhovor, ne jako pevný nákupní seznam.

Chyba 5: Rozpočet na stavbu, zapomenutý zbytek

Aplikace není jednorázový nákup jako tištěná brožura. Je to živá věc, kterou je třeba krmit. Majitelé běžně rozpočtují stavbu a nic dalšího, a pak je zaskočí náklady, které přijdou potom: hosting, poplatky obchodu s aplikacemi, údržba kvůli aktualizacím operačních systémů telefonů a nevyhnutelné kolo oprav a drobných vylepšení, jakmile to začnou používat skuteční lidé.

Rozumné orientační pravidlo: ať stavba stojí cokoli, vyhraďte si stejně velký podstatný díl znovu na první rok provozu. Přesné číslo se liší, ale chyba je univerzální — brát den spuštění jako cílovou pásku, když je to ve skutečnosti pásek startovní. Aplikace, která se spustí a pak je tiše opuštěna, protože není rozpočet na její údržbu, patří k nejsmutnějším a nejčastějším koncům v celém oboru, a je zcela odvratitelná poctivým plánováním předem.

Chyba 6: Navrhovat pro sebe místo pro uživatele

Svou firmu znáte skrz naskrz, což z vás dělá nejhoršího možného soudce toho, zda je vaše aplikace snadno použitelná. Věci, které jsou vám samozřejmé — žargon, pořadí, v jakém úkoly děláte, zkratky, které volíte bez přemýšlení — jsou pro prvouživatele matoucí. Aplikace, která dává majiteli dokonalý smysl a všechny ostatní mate, selhala, ať je sebechytřejší.

Lék je levný a trochu pokořující: sledujte skutečné lidi, jak ji používají, ještě před spuštěním. Ne svůj tým, který už ví, jak to má fungovat — skutečné zákazníky nebo zaměstnance, kteří ji nikdy neviděli. Dejte jim aplikaci, dejte jim úkol a nic neříkejte. Tam, kde zaváhají, klepnou na špatnou věc nebo si povzdechnou, tam máte zpětnou vazbu k designu. Pět lidí stačí, aby vyplavaly nejhorší problémy. Vynechání tohoto kroku je důvod, proč se aplikace spouštějí s tlačítkem „odeslat“, které nikdo nenajde, a s registračním tokem, který ztratí polovinu těch, kdo to zkusí.

• Dejte testérovi skutečný úkol, ne prohlídku — „rezervuj si schůzku na příští úterý“, a pak mlčte.
• Sledujte jeho ruce a obličej, ne jen to, zda nakonec uspěje.
• Zaznamenejte každé zaváhání; pauza je problém designu, který zevnitř nevidíte.
• Odolejte nutkání vysvětlovat — pokud to musíte vysvětlit, měla to udělat aplikace.
• Otestujte s pěti lidmi, opravte zjevná selhání a pak testujte znovu.

Chyba 7: Stavět nativní iOS a Android, když jste nemuseli

Existuje reflex postavit od prvního dne „pořádnou“ aplikaci pro iPhone i Android, plně nativní, jak to dělají velké značky. Pro většinu malých firem to znamená dvoj- až trojnásobné náklady a složitost za přínos, kterého si vaši uživatelé nikdy nevšimnou. Hůř, teď navždy udržujete dvě oddělené kódové základny a každou budoucí opravu zdvojnásobujete.

Často není správný první krok vůbec nativní aplikace. Dobře udělaná webová aplikace, která funguje v prohlížeči libovolného telefonu, nebo multiplatformní přístup, který z jedné kódové základny vytvoří obě verze pro obchody, vás dostane na trh rychleji a levněji — a kdykoli později můžete přejít plně na nativní, pokud reálné používání prokáže, že to stojí za to. Otázka, kterou si klást, nikdy nezní „nativní, nebo web“ v abstraktní rovině. Zní: co je nejmenší, nejlevnější věc, která skutečným uživatelům umožní udělat klíčovou práci? Tu postavte, poučte se z ní a pak velké peníze utraťte na základě důkazů, ne domněnek.

Chyba 8: Brát spuštění jako konec práce

Osmá chyba je věřit, že projekt je hotový, jakmile aplikace naběhne. Není — právě tehdy začíná skutečný projekt. Aplikace bez plánu, jak ji dostat do rukou uživatelů, bez způsobu, jak slyšet, co si myslí, a bez úmyslu zlepšovat ji podle toho, co se naučíte, je aplikace, která během měsíců vyšumí. Stavba byla ta snadná část. Osvojení je ta těžká část, a téměř nikdo s ním nepočítá.

Než spustíte, vězte tři věci: jak se lidé dozvědí, že aplikace existuje, jak změříte, zda ji skutečně používají, a jak posbíráte to, co vám řeknou, aby další kolo práce vedla realita, ne dohady. Nic z toho není drahé. Je to jen jiné nastavení mysli — aplikace není věc, kterou dokončíte a odejdete od ní, je to vztah, který udržujete. Majitelé, kteří to chápou, dostanou aplikace, které jsou časem užitečnější. Ti, kdo ne, dostanou špičku v den spuštění a dlouhý, tichý úpadek.

Jak se vyhnout všem osmi naráz

Čtené dohromady mají tyto chyby jediný kořen: jednat rychle na základě domněnek místo pomalu na základě důkazů. Každá z nich je místo, kde se zdálo levnější přeskočit pečlivý krok. A každá z nich je mnohem levnější vyřešit před stavbou než po ní. Tady je sled, který se tiše vyhne všem osmi.

1. 1
   Dokažte poptávku dřív, než postavíte

   Prototyp, vstupní stránka nebo ruční verze. Získejte skutečný důkaz, že to někdo chce, dřív, než zavážete rozpočet.
2. 2
   Sepište zadání a seznam verze dvě

   Pár jasných stránek, které každý pochopí, plus odstavné parkoviště pro každý nápad „když už jsme u toho“, aby nevykolejil v1.
3. 3
   Vybírejte vývojáře podle výsledků, ne podle ceny

   Dodaná práce, referenční hovory, jasné vlastnictví kódu a účtů a někdo, kdo se zpětně sám ptá na dobré otázky.
4. 4
   Rozpočtujte celý první rok, ne jen stavbu

   Hosting, údržba, opravy a podpora. Den spuštění je startovní pásek, takže financujte provoz té věci.
5. 5
   Zvolte nejmenší platformu, která splní úkol

   Ve většině případů nejdřív web nebo multiplatformní. Plně na nativní přejděte později, s důkazy, jen pokud to používání vyžaduje.
6. 6
   Testujte se skutečnými uživateli, pak naplánujte spuštění

   Sledujte pět cizích lidí, jak to používají, opravte zjevná selhání a předem rozhodněte, jak to lidé najdou a jak budete měřit používání.

Časté otázky