Skutočný časový plán vývoja aplikácie: od nápadu po spustenie

Ak sa opýtate desiatich agentúr, ako dlho trvá vývoj aplikácie, dostanete desať sebavedomých odpovedí a ani jedna z nich nebude pravdivá. Úprimná odpoveď znie, že nikto vám nedokáže prvý deň povedať presný čas — no každý, kto naozaj dodal softvér, vám vie opísať jeho tvar: ktoré fázy existujú, ktoré ticho ujedajú z kalendára a kde vaše vlastné rozhodnutia veci urýchlia alebo úplne zastavia. Toto je ten tvar, napísaný jednoducho.

Videl som mnoho majiteľov malých firiem vstupovať do projektu aplikácie s očakávaním úhľadného, lineárneho pochodu od skice po App Store. Namiesto toho dostanú niečo, čo pôsobí ako séria plošín a náhlych skokov. Týždne, počas ktorých to vyzerá, akoby sa nedialo nič, a potom deň, keď celá vec zrazu zapadne. Nič z toho nie je znakom, že je niečo zle. Tak sa softvér jednoducho tvorí — a len čo dokážete fázy pomenovať, celý proces prestane pôsobiť ako čierna skrinka, do ktorej platíte a dúfate v najlepšie.

Stanovme si teda realistické očakávania. Pri zameranej prvej verzii podnikovej aplikácie — nie rozvetvenej platforme, ale prvej verzii, ktorá robí jednu vec dobre — zvyčajne hovoríme o rozpätí troch až piatich mesiacov od vážneho začiatku po skutočné spustenie. Kde sa v rámci tohto rozpätia ocitnete, súvisí menej s technológiou a viac s tým, ako jasno máte, ako rýchlo sa rozhodujete a koľko sa snažíte natlačiť pred spustenie. Prejdime si to.

Prečo je odhad, ktorý ste dostali, pravdepodobne nesprávny

Číslo šesť týždňov nie je celkom lož — je to čas potrebný na vytvorenie tej časti, ktorú si každý dokáže predstaviť. Obrazoviek. Tlačidiel. Veci, ktorú možno predviesť. To, čo toto číslo ticho ignoruje, je všetko okolo viditeľnej aplikácie: rozhodnutia, dáta, integrácie s nástrojmi, ktoré už používate, testovanie, kontrola v obchode s aplikáciami a nevyhnutné kolo otázok „vlastne, zvládne to aj toto?“

Užitočný spôsob, ako o tom premýšľať: kód je len zriedka úzkym hrdlom. Úzkym hrdlom je jasnosť. Každá hodina, počas ktorej váš vývojár čaká na rozhodnutie — ktorý poskytovateľ platieb, čo sa stane pri zrušení rezervácie, kto čo vidí — je hodina, o ktorú sa časový plán posúva. Projekty, ktoré sa dokončia rýchlo, nie sú tie s najlepšími inžiniermi. Sú to tie, kde majiteľ odpovedá na otázky do jedného dňa namiesto za dva týždne.

Keď teda budete čítať fázy nižšie, všímajte si momenty, keď je lopta na vašej strane. To sú body, v ktorých si projekt buď udrží tempo, alebo sa ticho zastaví na tri týždne, lebo zostal e-mail bez odpovede. Časový plán je spoločnou zodpovednosťou a klientskú polovicu ľudia podceňujú.

Fáza 1: Mapovanie a vymedzenie rozsahu (1 – 3 týždne)

Skôr než ktokoľvek navrhne čo i len jednu obrazovku, existuje fáza, ktorá nevyzerá ako pokrok, no určuje všetko: ujasniť si, čo vlastne staviate, a ešte dôležitejšie, čo nestaviate. Tu sa z hmlistého nápadu („aplikácia pre mojich zákazníkov“) stáva konkrétny, dokončiteľný zoznam funkcií pre prvú verziu.

Keď sa robí dobre, mapovanie je hlavne rozhovor a ťažké otázky. Kto to používa a na akom zariadení? Čo je tá jedna vec, ktorú musí robiť skvele? Čo môže počkať na druhú verziu? Dobrý partner vám tu bude oponovať a vy to chcete — každá funkcia, ktorú teraz vyškrtnete, sú týždne, ktoré získate späť. Výstupom je zvyčajne krátky písomný rozsah a hrubý wireframe, niečo, čo môžete držať v ruke a povedať áno, to je ono.

Fáza 2: Dizajn a prototyp (2 – 4 týždne)

Teraz sa aplikácia stáva niečím, čo môžete vidieť a klikať naň, skôr než vás riadok skutočného kódu k čomukoľvek zaviaže. Dizajnéri premieňajú wireframe na poriadne obrazovky — farby, tok, skutočný pocit z používania — zvyčajne ako interaktívny prototyp, ktorým môžete preklikať na vlastnom telefóne.

Táto fáza je zlatom z jedného dôvodu: zmeniť dizajn je lacné, zmeniť hotový softvér je drahé. Presunúť tlačidlo v prototype trvá päť minút. Presunúť ho po tom, čo je funkcia nakódovaná, otestovaná a prepojená s vašimi dátami, môže trvať deň. Toto je teda chvíľa byť vyberavý, ukázať to pár skutočným zákazníkom alebo zamestnancom a podchytiť problémy typu „aha, tomu nikto nebude rozumieť“, kým je ich oprava ešte bezbolestná.

Najčastejším dôvodom, prečo sa táto fáza naťahuje, nie je dizajnér — je to nerozhodnosť na vašej strane. Nekonečné kolá drobných úprav alebo tri osoby s právom veta, ktoré sa nikdy nezhodnú. Rozhodnite včas, kto schvaľuje, dávajte spätnú väzbu v dávkach namiesto po kvapkách a táto fáza zostane zovretá.

Fáza 3: Stavba (6 – 12 týždňov)

Toto je tá časť, ktorú si každý predstaví, keď pomyslí na „tvorbu aplikácie“, a je to najdlhší súvislý úsek — no len zriedka najnepredvídateľnejší, ak boli prvé dve fázy urobené poriadne. Vývojári stavajú aplikáciu po kúskoch, zvyčajne v krátkych cykloch, v ktorých vidíte fungujúce časti každý týždeň či dva, namiesto toho, aby zmizli na tri mesiace a znova sa objavili s hotovým produktom.

Na tom rytme záleží. Chcete reagovať na skutočný, bežiaci softvér včas, nie na správu o stave. Keď naozaj môžete použiť rezervačný tok vo štvrtom týždni, všimnete si veci, ktoré žiadna špecifikácia nemohla zachytiť — a ich oprava vo štvrtom týždni je oveľa lacnejšia než v desiatom. Dobrý proces stavby robí aplikáciu pre vás priebežne viditeľnou, nielen na konci.

Čo ticho naťahuje stavbu

Dve veci naťahujú stavbu viac než čokoľvek iné. Prvou sú integrácie — každý externý systém, s ktorým musí aplikácia komunikovať (váš poskytovateľ platieb, váš existujúci rezervačný nástroj, váš účtovný softvér, doručovacia služba), pridáva prácu a každý môže priniesť vlastné prekvapenia. Druhou je rozrastanie rozsahu: stály prísun malých prídavkov, z ktorých sa každý zdá nepatrný, no spolu posúvajú spustenie o mesiac. Oboje sa dá zvládnuť, ale len ak ich vidíte prichádzať.

• Každá externá integrácia pridáva dni, niekedy týždne — počítajte s nimi výslovne, nepredpokladajte, že sú zadarmo.
• „Len ešte jedna malá funkcia“ je jednotlivo najčastejšou príčinou zmeškaného termínu spustenia.
• Skutočné dáta sú zmätenejšie než testovacie; naplánujte si čas na okrajové prípady, ktoré vaša tabuľka ticho tolerovala.
• Používateľské účty, platby a notifikácie sú klamlivo hlboké — vždy stoja viac, než vyzerajú.
• Schválenia a obsah, ktorý dlhujete tímu (logá, texty, právne formulácie), môžu zastaviť stavbu rovnako spoľahlivo ako chyba.

Fáza 4: Testovanie a opravy (2 – 4 týždne)

Tu je fáza, na ktorú ľudia zabúdajú, že existuje, a potom im prekáža, keď sa objaví. Keď je aplikácia hotová, musí prejsť skúškou — na rôznych telefónoch, so zlým internetom, ľuďmi, ktorí ju nestavali a urobia veci, ktoré nikto nečakal. Testovanie nie je formalita. Je to rozdiel medzi aplikáciou, ktorej vaši zákazníci dôverujú, a takou, ktorú po prvom páde odinštalujú.

Počítajte s tým, že sa tu vynorí zoznam chýb a drsných hrán. To nie je znak, že stavba dopadla zle; je to celý zmysel tejto fázy. Niektoré sú rýchle opravy, niektoré odhalia rozhodnutie, ktoré treba prehodnotiť. Tímy, ktoré to zvládajú dobre, to berú ako normálnu, naplánovanú súčasť práce — nie ako núdzový stav a nie ako niečo, čo treba preskočiť, lebo sa blíži spustenie. Preskočenie testovania nešetrí čas. Len presunie chyby z vášho testovacieho telefónu do telefónov vašich zákazníkov, kde stojí ich oprava desaťnásobne viac.

Fáza 5: Spustenie a čakanie na obchod s aplikáciami (1 – 2 týždne plus kontrola)

Spustenie je menej jediným okamihom a viac opatrným postupným zavádzaním. Ak ide o webovú aplikáciu, načasovanie ovládate úplne vy — prepnete vypínač, keď ste pripravení. Ak smeruje do Apple App Store alebo Google Play, časť harmonogramu odovzdávate im: ich proces kontroly môže trvať od jedného dňa po vyše týždeň a občas vám ju vrátia s niečím na opravu. Toto je dobré vedieť dopredu, aby to neprekvapilo termín spustenia, ktorý ste sľúbili zákazníkom.

Šikovný spôsob spustenia nie je veľkolepé odhalenie celej vašej zákazníckej základni. Je to tiché vydanie najprv malej skupine — hŕstke ústretových zákazníkov alebo vašim vlastným zamestnancom — aby ste podchytili problémy reálneho sveta skôr, než ich uvidia všetci. Potom dvere otvoríte dokorán. Spustenie, ktoré pôsobí nudne bezudalostne, je spustenie, ktoré dopadlo dobre.

1. 1
   Tiché spustenie malej skupine

   Vydajte to najprv hŕstke ústretových používateľov alebo zamestnancov. Skutočné používanie nájde to, čo testovanie minulo, pričom riziko je stiahnuté na minimum.
2. 2
   Odošlite včas, ak smerujete do obchodov s aplikáciami

   Apple a Google ovládajú hodiny kontroly, nie vy. Odošlite s rezervou, aby pomalá kontrola alebo zamietnutie nerozbili váš sľúbený termín.
3. 3
   Pozorne sledujte prvý týždeň

   Majte niekoho po ruke, aby rýchlo reagoval. Prvý týždeň vynesie na povrch okrajové prípady reálneho sveta, aké žiadne testovacie prostredie nikdy nevynesie.
4. 4
   Naplánujte prácu na deň po pred spustením

   Aplikácia nie je pri spustení nikdy 'hotová'. Dohodnite sa vopred, kto sa postará o nevyhnutné drobné opravy a prvé kolo spätnej väzby.

Poskladanie celého časového plánu

Naskladané za sebou vám tieto fázy dávajú realistický obraz. Žiadna z nich nie je exotická; ľudí podráža to, že zabúdajú, že tie nelákavé — mapovanie, testovanie, čakanie na obchod s aplikáciami — sú skutočným časom v kalendári, nie chybami zaokrúhlenia. Tu je zhruba, ako sa zameraná prvá verzia zvykne rozložiť do mesiacov.

Spočítajte to a uvidíte, prečo sú tri až päť mesiacov úprimným rozpätím pre skutočnú prvú verziu a prečo tí, čo sľubujú šesť týždňov, ticho menia definíciu toho, čo „aplikácia“ znamená. Nie je to pesimizmus — je to rozdiel medzi termínom, ktorý naozaj stihnete, a takým, za ktorý sa budete celý projekt ospravedlňovať.

Ako to skutočne urýchliť (a ako nie)

Môžete sa pohybovať rýchlejšie, no skutočné páky nie sú tie, po ktorých ľudia siahajú. Nahádzať viac vývojárov na napoly definovaný projekt ho zvyčajne spomalí, nie zrýchli. Úprimné urýchľovače sú nelákavé: rozhodnite, čo vynechať, rýchlo odpovedajte na otázky a odolajte nutkaniu pridávať veci uprostred stavby.

Najväčšou pákou je nemilosrdný rozsah. Čím menšia a jasnejšia je vaša prvá verzia, tým skôr sa spustí — a spustená aplikácia, ktorá si na seba zarába, vás za dva týždne naučí viac, než vás kedy naučia ďalšie dva mesiace plánovania. Pridať môžete vždy. Nemôžete získať späť mesiace strávené stavaním funkcií, ktoré napokon nikto nechcel.

Existuje súvisiaca pravda, ktorú treba povedať nahlas: nie všetko musí byť vôbec aplikáciou na mieru. Niekedy je skutočným problémom úsek manuálnej práce, ktorý by kúsok automatizácie dokázal ticho vybaviť, bez aplikácie. Dobrý partner vám to povie, keď to tak je, namiesto toho, aby vám predal väčšiu stavbu — pretože najlacnejšia aplikácia je tá, ktorú ste nemuseli vytvoriť.

Časté otázky