8 kallista sovelluskehityksen virhettä, joita pk-yritykset toistavat

Tässä on epämukava totuus pieleen menevistä sovellusprojekteista: siihen mennessä kun koodi alkaa näyttää väärältä, projekti oli jo menetetty viikkoja sitten. Pienyritysten sovelluskehityksen kalliit virheet eivät juuri koskaan tapahdu näppäimistön ääressä. Ne tapahtuvat ohimennen käydyissä keskusteluissa — toimeksiannossa jota ei koskaan kirjattu ylös, ominaisuudessa jonka joku lisäsi ‘kun nyt kuitenkin tehdään’, kehittäjässä joka valittiin koska kaveri suositteli. Mikään niistä ei tunnu päätökseltä sillä hetkellä. Kaikki ne maksavat sinulle myöhemmin.

Olen nähnyt monen pienyrityksen tilaavan ensimmäisen sovelluksensa, ja minut on kutsuttu pelastamaan moni niistä jälkikäteen. Yrittäjät eivät juuri koskaan ole huolimattomia ihmisiä. He ovat teräviä, harkitsevia, hyviä liiketoiminnan pyörittäjiä. Mutta ohjelmistoissa on oma ansansa, joita ei ole missään muualla heidän työelämässään, eikä kukaan varoittanut heitä. Niinpä he kävelevät suoraan samaan kahdeksaan sudenkuoppaan, suurin piirtein samassa järjestyksessä, joka kerta.

Tämä on lista jonka soisin jokaisella yrittäjällä olleen ennen kuin he käyttivät senttiäkään. Ei teoriaa — todelliset, toistuvat virheet ja ne pienet kurssikorjaukset, jotka olisivat pelastaneet jokaisen projektin. Jos olet rakentamassa sovellusta tai olet jo kesken rakennusvaiheen ja jokin tuntuu olevan pielessä, lue tämä ensin. Useimmat näistä ovat yhä korjattavissa, jos huomaat ne ajoissa.

Virhe 1: Rakennat ennen kuin olet todistanut että joku haluaa sitä

Yksittäinen kallein virhe on myös yleisin: sitoutuminen täyteen toteutukseen ennen kuin on mitään todellista näyttöä siitä, että sovellus ratkaisee ongelman josta ihmiset maksavat tai jota he käyttävät. Idea tuntuu yrittäjästä itsestäänselvältä — totta kai asiakkaat haluavat tämän — ja juuri tuo varmuus on vaarallista. Varmuus tuntuu validoinnilta. Se ei ole sitä.

Validointi ei tarkoita sitä, että kysyt kymmeneltä kaverilta pitävätkö he ideasta; kaikki sanovat kyllä kohteliaisuuttaan. Se tarkoittaa pienimmän mahdollisen version asettamista oikeiden käyttäjien eteen oikeassa tilanteessa ja sen seuraamista, mitä he todella tekevät. Klikattava prototyyppi, laskeutumissivu joka mittaa rekisteröitymisiä, manuaalinen ‘conciérge’-versio jossa väärennät automaation käsin — mikä tahansa näistä kertoo enemmän kuin valmis sovellus joka on rakennettu aavistuksen varaan. Järjestyksellä on väliä: todista kysyntä halvalla, rakenna sitten kalliisti. Käännä se toisin päin, ja voit kuluttaa koko budjettisi kiillottamalla jotain, jota kukaan ei avaa toista kertaa.

Virhe 2: Laajuuden hivuttaminen kunnianhimoksi naamioituna

Jokainen sovellus alkaa hoikkana ja siistinä. Sitten alkaa ‘kun nyt kuitenkin tehdään’. Kun nyt rakennetaan varausnäkymää, voisiko se hoitaa myös lahjakortit? Ja kanta-asiakaspisteet? Ja suosittelujärjestelmän? Jokainen lisäys kuulostaa yksinään järkevältä. Yhdessä ne kolminkertaistavat hiljaa aikataulun ja laskun — ja työntävät julkaisun niin kauas, että alkuperäinen vauhti kuolee.

Ratkaisu ei ole sanoa ei hyville ideoille. Se on pysäköidä ne. Pidä näkyvillä ‘versio kaksi’ -listaa, jonne jokainen kimaltava idea menee odottamaan vuoroaan. Tämä tekee jotain psykologista käytännöllisen lisäksi: ihmiset lakkaavat taistelemasta ominaisuuksien tunkemisesta ensimmäiseen julkaisuun, kun he luottavat siihen että heidän ideallaan on oikea paikka myöhemmin. Ensimmäisen versiosi pitäisi tehdä yksi asia aidosti hyvin, ei kymmentä asiaa välttävästi. Sovellus joka osuu yhteen työnkulkuun naulan kantaan tulee käytetyksi. Sovellus joka tekee kaiken puolittain hylätään.

Virhe 3: Ei kirjallista toimeksiantoa — vain jaettu mielikuva

Tämä on näkymätön kunnes se puree. Yrittäjällä on selkeä sovellus päässään. Kehittäjällä on selkeä sovellus päässään. Kaikki nyökkäilevät aloituspalaverissa. Kukaan ei kirjaa sitä kunnolla ylös — ja ne kaksi mielikuvaa, kuten käy ilmi, eivät koskaan olleet sama mielikuva. Huomaat tämän puolivälissä, kun se mitä rakennetaan ei ole se mitä kuvittelit, ja nyt on kiista siitä kuka sanoi mitä.

Et tarvitse sadan sivun määrittelyä. Tarvitset muutaman sivun, jotka kuka tahansa uusi tulokas voisi lukea ja ymmärtää: kuka käyttää tätä sovellusta, mitkä ovat ne kolme tai neljä asiaa jotka heidän pitää tehdä sillä, miltä onnistunut lopputulos näyttää. Lisää karkea luonnos keskeisistä näkymistä. Siinä se. Toimeksiannon tarkoitus ei ole byrokratia — se on jaettu kiintopiste, johon molemmat voitte osoittaa, kun muisti ja todellisuus alkavat erkaantua, mitä ne aina tekevät.

Virhe 4: Kehittäjän valitseminen väärällä tavalla

Useimmat yrittäjät valitsevat ensimmäisen kehittäjänsä yhden kahdesta hatarasta signaalista perusteella: halvimman tarjouksen tai henkilökohtaisen suosituksen joltakulta aivan eri alalta. Molemmat voivat toimia tuurilla. Kumpikaan ei ole luotettava tapa valita joku, jolle uskot merkittävän summan rahaa ja useita kuukausia yrityksesi tulevaisuutta.

Halvin tarjous on erityisen petollinen ohjelmistoissa, koska ero tarjouksen ja valmiin kustannuksen välillä on valtava ja näkymätön. Halpa kehittäjä joka tarvitsee kolme kierrosta uudelleentyöstöä, katoaa kahdeksi viikoksi ja jättää sinulle koodia jota kukaan muu ei osaa ylläpitää, on paljon kalliimpi kuin hieman kalliimpi joka tekee sen oikein. Hinta on se mitä näet; kokonaiskustannus on se mitä maksat.

Mitä oikeasti kannattaa tarkistaa

Pyydä nähdä asioita jotka he ovat julkaisseet ja jotka ovat yhä käytössä, ja jos voit, puhu noille asiakkaille ilman kehittäjää huoneessa. Kysy miten he hoitavat muutokset kesken projektin, koska muutoksia tulee. Kysy kuka omistaa koodin ja tilit kun se on valmis — vastauksen pitäisi aina olla sinä. Ja kiinnitä huomiota siihen, kysyvätkö he itse hyviä kysymyksiä takaisin. Kehittäjä joka vain ottaa vastaan tilauksia rakentaa juuri väärän asian hyvin tehokkaasti. Hyvät haastavat, osoittavat aukkoja ajattelussasi ja kohtelevat toimeksiantoa keskustelun lähtökohtana, eivät kiinteänä ostoslistana.

Virhe 5: Budjetoit rakentamiseen, unohdat lopun

Sovellus ei ole kertaluonteinen hankinta kuten painettu esite. Se on elävä olento joka tarvitsee ruokkimista. Yrittäjät budjetoivat rutiininomaisesti rakentamiseen eivätkä mihinkään muuhun, ja sitten kustannukset jotka saapuvat jälkikäteen yllättävät heidät: palvelintila, sovelluskauppojen maksut, ylläpito joka pysyy puhelinten käyttöjärjestelmäpäivitysten perässä, ja väistämätön kierros korjauksia ja pieniä parannuksia kun oikeat ihmiset alkavat käyttää sitä.

Järkevä nyrkkisääntö: mitä rakentaminen maksaakin, varaa siitä merkittävä siivu uudelleen ensimmäistä käyttövuotta varten. Tarkka luku vaihtelee, mutta virhe on yleismaailmallinen — julkaisupäivän kohteleminen maalina, kun se itse asiassa on lähtöviiva. Sovellus joka julkaistaan ja sitten hiljaa hylätään, koska ei ole budjettia sen ylläpitoon, on yksi tämän koko alan surullisimmista ja yleisimmistä lopputuloksista, ja se on täysin vältettävissä rehellisellä etukäteissuunnittelulla.

Virhe 6: Suunnittelet itsellesi etkä käyttäjällesi

Tunnet liiketoimintasi läpikotaisin, mikä tekee sinusta huonoimman mahdollisen arvioijan sille onko sovelluksesi helppokäyttöinen. Asiat jotka ovat sinulle ilmeisiä — ammattisanasto, järjestys jossa teet tehtävät, oikopolut jotka teet ajattelematta — ovat hämmentäviä ensikertalaiselle käyttäjälle. Sovellus joka on täysin järkeenkäypä yrittäjälle ja hämmentää kaikkia muita on epäonnistunut, oli se kuinka nokkela tahansa.

Lääke on halpa ja hieman nöyryyttävä: katso miten oikeat ihmiset käyttävät sitä ennen kuin julkaiset. Ei tiimisi, joka jo tietää miten sen on tarkoitus toimia — oikeat asiakkaat tai työntekijät jotka eivät ole koskaan nähneet sitä. Anna heille sovellus, anna heille tehtävä, äläkä sano mitään. Missä he epäröivät, napauttavat väärää kohtaa tai huokaisevat, siinä on suunnittelupalautteesi. Viisi ihmistä riittää nostamaan pinnalle pahimmat ongelmat. Tämän vaiheen ohittaminen on syy siihen, että sovelluksia julkaistaan ‘lähetä’-painikkeella jota kukaan ei löydä ja rekisteröitymispolulla joka menettää puolet sitä yrittävistä.

• Anna testaajalle todellinen tehtävä, ei kierrosta — ‘varaa aika ensi tiistaiksi’, ja pysy sitten hiljaa.
• Katso heidän käsiään ja kasvojaan, ei vain sitä onnistuvatko he lopulta.
• Merkitse muistiin jokainen epäröinti; tauko on suunnitteluongelma jota et näe sisältäpäin.
• Vastusta halua selittää — jos sinun täytyy selittää se, sovelluksen olisi pitänyt tehdä se.
• Testaa viidellä ihmisellä, korjaa ilmeiset epäonnistumiset, testaa sitten uudelleen.

Virhe 7: Rakennat natiivit iOS ja Android vaikka et tarvinnut

On olemassa refleksi rakentaa ‘kunnollinen’ sovellus sekä iPhonelle että Androidille ensimmäisestä päivästä lähtien, täysin natiivina, samaan tapaan kuin suuret brändit tekevät. Useimmille pienyrityksille se on kaksin- tai kolminkertainen kustannus ja monimutkaisuus hyötyä varten jota käyttäjäsi eivät koskaan huomaa. Pahempaa, nyt ylläpidät kahta erillistä koodikantaa ikuisesti, kaksinkertaistaen jokaisen tulevan korjauksen.

Usein oikea ensimmäinen siirto ei ole natiivisovellus lainkaan. Hyvin rakennettu web-sovellus joka toimii minkä tahansa puhelimen selaimessa, tai alustariippumaton lähestymistapa joka tuottaa molemmat sovelluskauppaversiot yhdestä koodikannasta, vie sinut markkinoille nopeammin ja halvemmalla — ja voit aina siirtyä täysin natiiviksi myöhemmin, jos todellinen käyttö osoittaa sen olevan sen arvoista. Kysymys jonka pitäisi esittää ei ole koskaan ‘natiivi vai web’ abstraktisti. Se on: mikä on pienin, halvin asia joka antaa oikeiden käyttäjien tehdä ydintehtävän? Rakenna se, opi siitä, käytä sitten isot rahat näytön etkä oletuksen varassa.

Virhe 8: Julkaisun kohteleminen työn loppuna

Kahdeksas virhe on uskoa, että projekti on valmis kun sovellus julkaistaan. Se ei ole — silloin todellinen projekti alkaa. Sovellus jolla ei ole suunnitelmaa siitä miten se päätyy käyttäjien käsiin, ei tapaa kuulla mitä he ajattelevat, eikä aikomusta parantaa sitä oppimansa perusteella, on sovellus joka haalistuu kuukausissa. Rakentaminen oli helppo osa. Käyttöönotto on vaikea osa, eikä juuri kukaan suunnittele sitä.

Ennen kuin julkaiset, tiedä kolme asiaa: miten ihmiset saavat tietää että sovellus on olemassa, miten mittaat käyttävätkö he sitä todella, ja miten keräät sen mitä he kertovat sinulle, jotta seuraava työkierros ohjautuu todellisuuden eikä arvausten mukaan. Mikään näistä ei ole kallista. Se on vain erilainen ajattelutapa — sovellus ei ole asia jonka teet valmiiksi ja kävelet pois, se on suhde jota ylläpidät. Yrittäjät jotka ymmärtävät tämän saavat sovelluksia jotka muuttuvat ajan myötä hyödyllisemmiksi. Ne jotka eivät ymmärrä saavat julkaisupäivän piikin ja pitkän, hiljaisen alamäen.

Miten pysyä erossa kaikista kahdeksasta yhdellä kertaa

Yhdessä luettuina näillä virheillä on yksi juuri: nopea eteneminen oletusten varassa hitaan etenemisen sijaan näytön varassa. Jokainen niistä on paikka jossa tuntui halvemmalta ohittaa huolellinen vaihe. Ja jokainen niistä on paljon halvempi hoitaa ennen rakentamista kuin sen jälkeen. Tässä on järjestys joka väistää hiljaa kaikki kahdeksan.

1. 1
   Todista kysyntä ennen kuin rakennat

   Prototyyppi, laskeutumissivu tai manuaalinen versio. Hanki todellinen näyttö siitä että joku haluaa tämän ennen budjetin sitomista.
2. 2
   Kirjoita toimeksianto ja versio kaksi -lista

   Muutama selkeä sivu jonka kuka tahansa ymmärtää, plus pysäköintialue jokaiselle ‘kun nyt kuitenkin tehdään’ -idealle, jottei se kaada v1:tä.
3. 3
   Valitse kehittäjä näyttöjen perusteella, ei hinnan

   Julkaistut työt, suosittelijapuhelut, selkeä koodin ja tilien omistus, ja joku joka kysyy hyviä kysymyksiä takaisin.
4. 4
   Budjetoi koko ensimmäiselle vuodelle, ei vain rakentamiselle

   Palvelintila, ylläpito, korjaukset ja tuki. Julkaisupäivä on lähtöviiva, joten rahoita asian pyörittäminen.
5. 5
   Valitse pienin alusta joka tekee työn

   Web tai alustariippumaton ensin useimmissa tapauksissa. Siirry täysin natiiviksi myöhemmin, näytön kanssa, vain jos käyttö sitä vaatii.
6. 6
   Testaa oikeilla käyttäjillä, suunnittele sitten julkaisu

   Katso viiden tuntemattoman käyttävän sitä, korjaa ilmeiset epäonnistumiset ja päätä etukäteen miten ihmiset löytävät sen ja miten mittaat käyttöä.

Yleisiä kysymyksiä