Skutečný harmonogram vývoje aplikace: od nápadu k uvedení

Když se zeptáte deseti agentur, jak dlouho trvá vytvořit aplikaci, dostanete deset sebejistých odpovědí a ani jedna nebude pravdivá. Upřímná odpověď zní, že vám to první den nikdo nedokáže říct přesně — ale každý, kdo software skutečně dodal, vám umí popsat jeho tvar: jaké fáze existují, které z nich tiše ujídají z kalendáře a kde vaše vlastní rozhodnutí věci urychlují nebo zadrhávají. Tohle je právě ten tvar, sepsaný na rovinu.

Viděl jsem spoustu majitelů malých firem vstupovat do projektu aplikace s očekáváním úhledného, přímočarého pochodu od náčrtu k App Store. Místo toho dostávají něco, co připomíná řadu plošin a náhlých skoků. Týdny, kdy to vypadá, že se nic neděje, a pak den, kdy celé to najednou zapadne dohromady. Nic z toho není známkou, že je něco špatně. Prostě tak se software dělá — a jakmile dokážete fáze pojmenovat, celý proces přestane působit jako černá skříňka, do které platíte a doufáte v nejlepší.

Pojďme si tedy nastavit realistická očekávání. U soustředěné první verze firemní aplikace — ne rozlehlé platformy, ale první verze, která jednu věc dělá dobře — se obvykle bavíme o něčem v rozsahu tří až pěti měsíců od seriózního startu ke skutečnému uvedení. Kde v tomto rozmezí přistanete, souvisí méně s technologií a více s tím, jak jste jasní, jak rychle rozhodujete a kolik se toho snažíte nacpat před uvedení. Pojďme to projít.

Proč je odhad, který jste dostali, nejspíš špatně

Šestitýdenní číslo není tak úplně lež — je to čas potřebný k vytvoření té části, kterou si dokáže představit každý. Obrazovky. Tlačítka. To, co můžete předvést. Co to číslo tiše ignoruje, je všechno kolem viditelné aplikace: rozhodnutí, data, integrace s nástroji, které už používáte, testování, schvalování v obchodě s aplikacemi a nevyhnutelné kolo „vlastně, mohla by dělat ještě tohle?“

Užitečný způsob, jak o tom přemýšlet: úzkým hrdlem je málokdy programování. Úzkým hrdlem je jasnost. Každá hodina, kdy váš vývojář čeká na rozhodnutí — který platební poskytovatel, co se stane při zrušení rezervace, kdo co uvidí — je hodina, o kterou se harmonogram posouvá. Projekty, které skončí rychle, nejsou ty s nejlepšími inženýry. Jsou to ty, kde majitel odpovídá na otázky za den místo za čtrnáct dní.

Až tedy budete číst níže uvedené fáze, všímejte si okamžiků, kdy je míč na vaší straně. To jsou body, kde si projekt buď udrží tempo, nebo tiše uvázne na tři týdny, protože zůstal e-mail bez odpovědi. Harmonogram je sdílená odpovědnost a klientská polovina je ta, kterou lidé podceňují.

Fáze 1: Zmapování a vymezení rozsahu (1–3 týdny)

Než někdo navrhne jedinou obrazovku, existuje fáze, která nevypadá jako pokrok, ale určuje všechno: ujasnit si, co vlastně stavíte a, což je důležitější, co nestavíte. Tady se z vágního nápadu („aplikace pro mé zákazníky“) stává konkrétní, dokončitelný seznam funkcí pro první verzi.

Když se dělá dobře, je zmapování hlavně rozhovor a těžké otázky. Kdo to používá a na jakém zařízení? Co je ta jedna věc, kterou to musí umět skvěle? Co může počkat do druhé verze? Dobrý partner se tu bude ohrazovat, a vy si to budete přát — každá funkce, kterou teď vyškrtnete, jsou týdny, které získáte zpět. Výstupem je obvykle krátký písemný rozsah a hrubý drátěný model, něco, co můžete vzít do ruky a říct ano, tohle je ono.

Fáze 2: Design a prototyp (2–4 týdny)

Teď se aplikace stává něčím, co můžete vidět a proklikat, dřív než vás jediný řádek skutečného kódu k čemukoli zaváže. Designéři promění drátěný model ve skutečné obrazovky — barvy, tok, samotný pocit z používání — obvykle jako interaktivní prototyp, který si můžete proklikat na vlastním telefonu.

Tahle fáze je zlatá z jednoho důvodu: změnit design je levné, změnit hotový software je drahé. Přesunout tlačítko v prototypu zabere pět minut. Přesunout ho poté, co je funkce naprogramovaná, otestovaná a napojená na vaše data, může trvat den. Tohle je tedy chvíle být vybíraví, ukázat to pár skutečným zákazníkům nebo zaměstnancům a zachytit problémy typu „aha, tohle nikdo nepochopí“, dokud jsou ještě bezbolestně řešitelné.

Nejčastější způsob, jak se tahle fáze protáhne, není designér — je to nerozhodnost na vaší straně. Nekonečná kola drobných úprav nebo tři lidé s právem veta, kteří se nikdy neshodnou. Rozhodněte brzy, kdo schvaluje, dávejte zpětnou vazbu v dávkách místo po kapkách, a fáze zůstane svižná.

Fáze 3: Stavba (6–12 týdnů)

Tohle je ta část, kterou si každý představí, když pomyslí na „tvorbu aplikace“, a je to nejdelší souvislý úsek — ale málokdy nejnepředvídatelnější, pokud byly první dvě fáze udělané pořádně. Vývojáři staví aplikaci po částech, obvykle v krátkých cyklech, kde každý týden nebo dva vidíte fungující kousky, místo aby na tři měsíce zmizeli a znovu se objevili s hotovým produktem.

Na tom rytmu záleží. Chcete reagovat na skutečný, běžící software brzy, ne na zprávu o stavu. Když ve čtvrtém týdnu skutečně použijete rezervační tok, všimnete si věcí, které by žádná specifikace nezachytila — a opravit je ve čtvrtém týdnu je mnohem levnější než v desátém. Dobrý proces stavby zviditelňuje aplikaci průběžně, ne až na konci.

Co stavbu tiše protahuje

Dvě věci protahují stavbu víc než cokoli jiného. První jsou integrace — každý externí systém, se kterým aplikace musí komunikovat (váš platební poskytovatel, váš stávající rezervační nástroj, váš účetní software, doručovací služba), přidává práci a každý si může vystřelit svá vlastní překvapení. Druhou je bobtnání rozsahu: ustálené odkapávání drobných přídavků, z nichž každý působí maličce, ale dohromady posunou uvedení o měsíc. Obojí se dá zvládnout, ale jen když to vidíte přicházet.

• Každá externí integrace přidá dny, někdy týdny — rozpočtujte je výslovně, nepředpokládejte, že jsou zadarmo.
• „Jen ještě jedna malá funkce“ je jednoznačně nejčastější příčinou nedodrženého termínu uvedení.
• Skutečná data jsou spletitější než testovací; naplánujte čas na ošetření okrajových případů, které vaše tabulka tiše tolerovala.
• Uživatelské účty, platby a notifikace jsou klamavě hluboké — vždy stojí víc, než vypadají.
• Schválení a obsah, který týmu dlužíte (loga, texty, právní texty), dokážou stavbu zastavit stejně jistě jako chyba.

Fáze 4: Testování a opravy (2–4 týdny)

Tady je fáze, na kterou lidé zapomínají, že existuje, a pak ji nesou nelibě, když se objeví. Jakmile je aplikace hotová, musí se prověřit — na různých telefonech, se špatným internetem, lidmi, kteří ji nestavěli a budou dělat věci, jež nikdo nepředvídal. Testování není formalita. Je to rozdíl mezi aplikací, které zákazníci důvěřují, a tou, kterou odinstalují po prvním pádu.

Počítejte s tím, že se tu vynoří seznam chyb a drsných hran. To není známka, že stavba dopadla špatně; je to celý smysl této fáze. Některé jsou rychlé opravy, jiné odhalí rozhodnutí, které je třeba přehodnotit. Týmy, které to zvládají dobře, k tomu přistupují jako k běžné, naplánované součásti práce — ne jako k pohotovosti a ne jako k něčemu, co se přeskočí, protože se blíží uvedení. Přeskočit testování čas neušetří. Jen to přesune chyby z vašeho testovacího telefonu do telefonů vašich zákazníků, kde jejich oprava stojí desetkrát víc.

Fáze 5: Uvedení a čekání na obchod s aplikacemi (1–2 týdny plus schvalování)

Uvedení není ani tak jediný okamžik, jako spíš pečlivé nasazování. Pokud jde o webovou aplikaci, načasování ovládáte úplně sami — přepnete přepínač, až budete připraveni. Pokud míří do Apple App Store nebo na Google Play, předáváte část harmonogramu jim: jejich schvalovací proces může trvat od jednoho dne přes víc než týden a občas ji pošlou zpět s něčím k opravě. To je dobré vědět předem, aby vás to nezaskočilo u termínu uvedení, který jste zákazníkům slíbili.

Chytrý způsob uvedení není velkolepé odhalení celé vaší zákaznické základně. Je to tiché vydání nejprve malé skupině — hrstce vstřícných zákazníků nebo vašim vlastním zaměstnancům — abyste zachytili problémy reálného světa dřív, než je uvidí všichni. Pak otevřete dveře doširoka. Uvedení, které působí nudně bez událostí, je uvedení, které dopadlo dobře.

1. 1
   Tiché uvedení malé skupině

   Vydejte to nejprve hrstce vstřícných uživatelů nebo zaměstnanců. Skutečné používání najde to, co testování minulo, s rizikem staženým na minimum.
2. 2
   Odešlete brzy, pokud míříte do obchodů s aplikacemi

   Hodiny schvalování ovládá Apple a Google, ne vy. Odešlete s rezervou, aby pomalé schvalování nebo zamítnutí neshodilo váš slíbený termín.
3. 3
   Pečlivě sledujte první týden

   Mějte někoho po ruce, aby rychle reagoval. První týden vynese na povrch okrajové případy reálného světa, které žádné testovací prostředí nikdy nepřinese.
4. 4
   Naplánujte práci na další den ještě před uvedením

   Aplikace není při uvedení nikdy „hotová“. Dohodněte se předem, kdo se postará o nevyhnutelné drobné opravy a první kolo zpětné vazby.

Skládáme celý harmonogram dohromady

Poskládané za sebou vám tyhle fáze dají realistický obraz. Žádná z nich není exotická; co lidi zaskočí, je zapomenutí, že ty neefektní — zmapování, testování, čekání na obchod s aplikacemi — jsou skutečný čas v kalendáři, ne zaokrouhlovací chyby. Takhle se zhruba soustředěná první verze rozkládá do měsíců.

Sečtěte to a uvidíte, proč jsou tři až pět měsíců upřímným rozmezím pro skutečnou první verzi a proč ti, kdo slibují šest týdnů, tiše předefinovávají, co znamená „aplikace“. Není to pesimismus — je to rozdíl mezi termínem, který skutečně dodržíte, a tím, za který se budete celý projekt omlouvat.

Jak ji opravdu urychlit (a jak ne)

Můžete jít rychleji, ale skutečné páky nejsou ty, po kterých lidé sahají. Přidat víc vývojářů k napůl definovanému projektu ho obvykle spíš zpomalí než urychlí. Upřímné urychlovače jsou neefektní: rozhodněte, co vynechat, odpovídejte na otázky rychle a odolejte nutkání přidávat věci uprostřed stavby.

Tou jednoznačně největší je nemilosrdný rozsah. Čím menší a jasnější je vaše první verze, tím dřív se uvede — a uvedená aplikace, která si na sebe vydělá, vás za dva týdny naučí víc než další dva měsíce plánování. Přidat můžete vždy. Měsíce strávené stavěním funkcí, o které nakonec nikdo nestál, zpět nezískáte.

Stojí za to říct nahlas jednu související pravdu: ne všechno musí být aplikace na míru. Někdy je skutečným problémem kus ruční práce, který by mohl tiše obstarat kousek automatizace, žádná aplikace netřeba. Dobrý partner vám řekne, kdy to tak je, místo aby vám prodal větší stavbu — protože nejlevnější aplikace je ta, kterou jste nemuseli dělat.

Časté otázky