Sovelluskehityksen todellinen aikataulu: ideasta julkaisuun

Jos kysyt kymmeneltä toimistolta, kuinka kauan sovelluksen tekeminen kestää, saat kymmenen itsevarmaa vastausta, eikä yksikään niistä pidä paikkaansa. Rehellinen vastaus on, ettei kukaan voi kertoa sinulle tarkasti ensimmäisenä päivänä — mutta jokainen, joka on oikeasti julkaissut ohjelmistoja, voi kertoa sinulle sen muodon: mitkä vaiheet ovat olemassa, mitkä niistä syövät hiljaa kalenteria ja missä omat päätöksesi nopeuttavat asioita tai pysäyttävät ne kokonaan. Tämä on juuri se muoto, selkeästi kirjoitettuna.

Olen nähnyt monen pienyrittäjän lähtevän sovellusprojektiin odottaen siistiä, suoraviivaista etenemistä luonnoksesta App Storeen. Sen sijaan he saavat sarjan tasanteita ja äkillisiä harppauksia. Viikkoja, jolloin näyttää siltä, ettei mitään tapahdu, ja sitten päivän, jolloin kaikki loksahtaa yhtäkkiä paikoilleen. Mikään tästä ei ole merkki siitä, että jokin olisi vialla. Näin ohjelmistoja vain tehdään — ja kun osaat nimetä vaiheet, koko prosessi lakkaa tuntumasta mustalta laatikolta, johon maksat ja toivot parasta.

Asetetaan siis realistiset odotukset. Liiketoimintasovelluksen kohdennetulle ensimmäiselle versiolle — ei rönsyilevälle alustalle, vaan ensimmäiselle versiolle, joka tekee yhden asian hyvin — puhutaan yleensä jostakin kolmen ja viiden kuukauden haarukasta tosissaan aloittamisesta oikeaan julkaisuun. Se, mihin kohtaan haarukkaa osut, riippuu vähemmän teknologiasta kuin siitä, kuinka selkeä olet, kuinka nopeasti teet päätöksiä ja kuinka paljon yrität tunkea mukaan ennen julkaisua. Käydään se läpi.

Miksi saamasi arvio on luultavasti väärä

Kuuden viikon luku ei ole täysin valhe — se on aika, joka kuluu sen osan rakentamiseen, jonka kaikki osaavat kuvitella. Näkymät. Painikkeet. Se, mitä voit esitellä. Mitä tuo luku hiljaa sivuuttaa, on kaikki näkyvän sovelluksen ympärillä: päätökset, data, integraatiot jo käyttämiisi työkaluihin, testaus, sovelluskaupan tarkistus ja väistämätön kierros ”itse asiassa, voisiko se myös tehdä tämän?”

Hyödyllinen tapa ajatella asiaa: koodaus on harvoin pullonkaula. Pullonkaula on selkeys. Jokainen tunti, jonka kehittäjäsi odottaa päätöstä — mikä maksupalvelu, mitä tapahtuu kun varaus peruutetaan, kuka näkee mitä — on tunti, jolloin aikataulu venyy. Nopeasti valmistuvat projektit eivät ole niitä, joissa on parhaat insinöörit. Ne ovat niitä, joissa omistaja vastaa kysymyksiin päivässä eikä kahdessa viikossa.

Kun siis luet alla olevat vaiheet, tarkkaile hetkiä, joissa pallo on sinun kentälläsi. Ne ovat kohtia, joissa projekti joko säilyttää vauhtinsa tai pysähtyy hiljaa kolmeksi viikoksi, koska yksi sähköposti jäi vastaamatta. Aikataulu on jaettu vastuu, ja sen asiakaspuoli on se, jonka ihmiset aliarvioivat.

Vaihe 1: Kartoitus ja rajaus (1–3 viikkoa)

Ennen kuin kukaan suunnittelee yhtäkään näkymää, on vaihe, joka ei näytä edistykseltä mutta määrää kaiken: sen selvittäminen, mitä oikeasti rakennat ja, mikä tärkeämpää, mitä et rakenna. Tässä epämääräisestä ideasta (”sovellus asiakkailleni”) tulee konkreettinen, valmiiksi saatava ominaisuuslista ensimmäiselle versiolle.

Hyvin tehtynä kartoitus on enimmäkseen keskustelua ja vaikeita kysymyksiä. Kuka tätä käyttää, ja millä laitteella? Mikä on se yksi asia, joka sen on tehtävä loistavasti? Mikä voi odottaa versioon kaksi? Hyvä kumppani haastaa sinua tässä, ja niin sinä haluatkin — jokainen ominaisuus, jonka karsit nyt, on viikkoja, jotka saat takaisin. Tuloksena on yleensä lyhyt kirjallinen rajaus ja karkea rautalankamalli, jotain jonka voit pitää kädessäsi ja sanoa kyllä, juuri tuo se on.

Vaihe 2: Suunnittelu ja prototyyppi (2–4 viikkoa)

Nyt sovelluksesta tulee jotain, jonka voit nähdä ja jota voit napauttaa, ennen kuin rivikään oikeaa koodia sitoo sinua mihinkään. Suunnittelijat muuttavat rautalankamallin kunnollisiksi näkymiksi — värit, kulku, se todellinen tuntuma käytöstä — yleensä interaktiivisena prototyyppinä, jota voit napautella omalla puhelimellasi.

Tämä vaihe on kultaa yhdestä syystä: suunnittelun muuttaminen on halpaa, valmiin ohjelmiston muuttaminen on kallista. Painikkeen siirtäminen prototyypissä vie viisi minuuttia. Sen siirtäminen sen jälkeen, kun ominaisuus on koodattu, testattu ja kytketty dataasi, voi viedä päivän. Tämä on siis se hetki olla tarkka, näyttää se muutamalle oikealle asiakkaalle tai työntekijälle ja napata ”ai, kukaan ei tule ymmärtämään tuota” -ongelmat, kun niiden korjaaminen on vielä kivutonta.

Yleisin tapa, jolla tämä vaihe venyy, ei ole suunnittelija — vaan päättämättömyys sinun puolellasi. Loputtomia kierroksia pieniä hienosäätöjä tai kolme veto-oikeuden omaavaa henkilöä, jotka eivät koskaan ole samaa mieltä. Päätä ajoissa, kuka hyväksyy, anna palaute erissä tihkumisen sijaan, niin tämä vaihe pysyy tiukkana.

Vaihe 3: Rakentaminen (6–12 viikkoa)

Tämä on se osa, jonka kaikki kuvittelevat ajatellessaan ”sovelluksen tekemistä”, ja se on pisin yksittäinen jakso — mutta harvoin arvaamattomin, jos kaksi ensimmäistä vaihetta tehtiin kunnolla. Kehittäjät rakentavat sovelluksen paloissa, yleensä lyhyissä sykleissä, joissa näet toimivia osia parin viikon välein sen sijaan, että he katoaisivat kolmeksi kuukaudeksi ja ilmestyisivät valmiin tuotteen kanssa.

Tuolla rytmillä on merkitystä. Haluat reagoida oikeaan, ajossa olevaan ohjelmistoon varhain, et tilanneraporttiin. Kun voit oikeasti käyttää varausprosessia neljännellä viikolla, huomaat asioita, joita mikään määrittely ei olisi voinut tavoittaa — ja niiden korjaaminen neljännellä viikolla on paljon halvempaa kuin kymmenennellä. Hyvä rakennusprosessi tekee sovelluksesta sinulle näkyvän jatkuvasti, ei vain lopussa.

Mikä venyttää rakentamista hiljaa

Kaksi asiaa laajentaa rakentamista enemmän kuin mikään muu. Ensimmäinen on integraatiot — jokainen ulkoinen järjestelmä, jonka kanssa sovelluksen on juteltava (maksupalvelusi, olemassa oleva varaustyökalusi, kirjanpito-ohjelmistosi, toimituspalvelu) lisää työtä, ja jokainen voi heittää omat yllätyksensä. Toinen on laajuuden ryömintä: pienten lisäysten tasainen tihkuminen, joista jokainen tuntuu mitättömältä mutta jotka yhdessä työntävät julkaisua kuukaudella eteenpäin. Molemmat ovat hallittavissa, mutta vain jos näet niiden tulevan.

• Jokainen ulkoinen integraatio lisää päiviä, joskus viikkoja — varaa niille aikaa erikseen, älä oleta niiden olevan ilmaisia.
• ”Vain yksi pieni ominaisuus lisää” on yleisin yksittäinen syy myöhästyneeseen julkaisupäivään.
• Oikea data on sotkuisempaa kuin testidata; varaa aikaa niiden erikoistapausten käsittelyyn, joita taulukkosi hiljaa sieti.
• Käyttäjätilit, maksut ja ilmoitukset ovat petollisen syviä — ne maksavat aina enemmän kuin miltä näyttävät.
• Hyväksynnät ja tiimille velkaa oleva sisältö (logot, tekstit, juridinen teksti) voivat pysäyttää rakentamisen yhtä varmasti kuin bugi.

Vaihe 4: Testaus ja korjaus (2–4 viikkoa)

Tässä on vaihe, jonka olemassaolon ihmiset unohtavat ja jota sitten harmittelevat, kun se ilmaantuu. Kun sovellus on rakennettu, se on pantava koetukselle — eri puhelimilla, huonolla netillä, ihmisten toimesta, jotka eivät rakentaneet sitä ja tekevät asioita, joita kukaan ei osannut ennakoida. Testaus ei ole muodollisuus. Se on ero sovelluksen, johon asiakkaasi luottavat, ja sellaisen välillä, jonka he poistavat ensimmäisen kaatumisen jälkeen.

Odota, että lista bugeja ja rosoja nousee tässä pintaan. Se ei ole merkki siitä, että rakentaminen meni huonosti; se on koko vaiheen tarkoitus. Osa on nopeita korjauksia, osa paljastaa päätöksen, jota on tarkasteltava uudelleen. Tiimit, jotka hoitavat tämän hyvin, kohtelevat sitä normaalina, suunniteltuna osana työtä — ei hätätilanteena eikä jonain, joka ohitetaan koska julkaisu lähestyy. Testauksen ohittaminen ei säästä aikaa. Se vain siirtää bugit testipuhelimestasi asiakkaidesi puhelimiin, joissa niiden korjaaminen maksaa kymmenkertaisesti.

Vaihe 5: Julkaisu ja sovelluskaupan odotus (1–2 viikkoa plus tarkistus)

Julkaisu on vähemmän yksittäinen hetki ja enemmän huolellinen käyttöönotto. Jos kyseessä on web-sovellus, hallitset ajoituksen täysin — käännät kytkimen kun olet valmis. Jos se menee Applen App Storeen tai Google Playhin, luovutat osan aikataulusta heille: heidän tarkistusprosessinsa voi kestää päivästä yli viikkoon, ja joskus he palauttavat sen jonkin korjattavan kanssa. Tämä kannattaa tietää etukäteen, jottei se yllätä asiakkaille lupaamaasi julkaisupäivää.

Fiksu tapa julkaista ei ole suuri paljastus koko asiakaskunnallesi. Se on hiljainen julkaisu pienelle ryhmälle ensin — kourallinen ystävällismielisiä asiakkaita tai oma henkilökuntasi — jotta nappaat tosielämän ongelmat ennen kuin kaikki näkevät ne. Sitten avaat ovea leveämmälle. Julkaisu, joka tuntuu tylsän tapahtumaköyhältä, on julkaisu, joka meni hyvin.

1. 1
   Pehmeä julkaisu pienelle ryhmälle

   Julkaise ensin kourallisille ystävällismielisille käyttäjille tai henkilökunnalle. Oikea käyttö löytää sen, minkä testaus jätti huomaamatta, panokset täysin alas käännettyinä.
2. 2
   Lähetä ajoissa, jos menet sovelluskauppoihin

   Apple ja Google hallitsevat tarkistuskelloa, et sinä. Lähetä puskurilla, jottei hidas tarkistus tai hylkäys räjäytä lupaamaasi päivää.
3. 3
   Seuraa ensimmäistä viikkoa tarkasti

   Pidä joku käden ulottuvilla reagoimassa nopeasti. Ensimmäinen viikko nostaa pintaan tosielämän erikoistapaukset, joita mikään testiympäristö ei koskaan tee.
4. 4
   Suunnittele julkaisun jälkeinen työ ennen julkaisua

   Sovellus ei ole koskaan 'valmis' julkaisussa. Sovi etukäteen, kuka hoitaa väistämättömät pienet korjaukset ja ensimmäisen palautekierroksen.

Koko aikataulun kokoaminen

Peräkkäin pinottuna nuo vaiheet antavat sinulle realistisen kuvan. Yksikään niistä ei ole eksoottinen; se mikä kompastuttaa ihmiset, on unohtaa että ne vähemmän loisteliaat — kartoitus, testaus, sovelluskaupan odotus — ovat oikeaa aikaa kalenterissa, ei pyöristysvirheitä. Tässä on suunnilleen, miten kohdennettu ensimmäinen versio yleensä jakautuu kuukausien yli.

Laske yhteen, niin näet miksi kolme–viisi kuukautta on rehellinen haarukka oikealle ensimmäiselle versiolle ja miksi ne, jotka lupaavat kuusi viikkoa, määrittelevät hiljaa uudelleen mitä ”sovellus” tarkoittaa. Se ei ole pessimismiä — se on ero päivän, jonka oikeasti saavutat, ja sellaisen välillä, jota pyytelet anteeksi koko projektin ajan.

Miten oikeasti nopeuttaa sitä (ja miten ei)

Voit edetä nopeammin, mutta oikeat vivut eivät ole niitä, joihin ihmiset tarttuvat. Useamman kehittäjän heittäminen puolittain määriteltyyn projektiin tekee siitä yleensä hitaamman, ei nopeamman. Rehelliset kiihdyttäjät ovat epäloisteliaita: päätä mitä jätät pois, vastaa kysymyksiin nopeasti ja vastusta houkutusta lisätä asioita kesken rakentamisen.

Suurin yksittäinen on armoton rajaus. Mitä pienempi ja selkeämpi ensimmäinen versiosi on, sitä pikemmin se julkaistaan — ja julkaistu, leipänsä ansaitseva sovellus opettaa sinulle enemmän kahdessa viikossa kuin kaksi kuukautta lisäsuunnittelua koskaan. Voit aina lisätä. Et voi saada takaisin kuukausia, jotka käytettiin sellaisten ominaisuuksien rakentamiseen, joita kukaan ei osoittautunut haluavan.

On läheinen totuus, joka kannattaa sanoa ääneen: kaiken ei tarvitse olla räätälöity sovellus lainkaan. Joskus oikea ongelma on pätkä manuaalista työtä, jonka pala automaatiota voisi hiljaa hoitaa, ilman sovellusta. Hyvä kumppani kertoo sinulle, milloin näin on, sen sijaan että myisi sinulle suuremman rakennusurakan — koska halvin sovellus on se, jota sinun ei tarvinnut tehdä.

Yleisiä kysymyksiä