8 dragih napak pri razvoju aplikacij, ki jih mala podjetja vedno znova delajo

Tukaj je neprijetna resnica o projektih aplikacij, ki gredo narobe: ko koda začne izgledati napačno, je bil projekt že izgubljen tedne prej. Drage napake pri razvoju aplikacij za mala podjetja se skoraj nikoli ne zgodijo za tipkovnico. Zgodijo se v mimobežnih pogovorih — opis, ki ni bil nikoli zapisan, funkcija, ki jo je nekdo dodal »ko smo že pri tem«, razvijalec, izbran, ker ga je priporočil prijatelj. Nič od tega v tistem trenutku ne deluje kot odločitev. Vse vas stane pozneje.

Videl sem veliko malih podjetij, kako naročajo svojo prvo aplikacijo, in poklicali so me, da sem jih precej rešil naknadno. Lastniki redko so malomarni ljudje. So bistri, previdni, dobri v vodenju podjetja. Toda programska oprema ima svoj nabor pasti, ki ne obstajajo nikjer drugje v njihovem delovnem življenju, in nihče jih ni opozoril. Tako stopijo naravnost v istih osem pasti, vsakič v približno istem vrstnem redu.

To je seznam, ki bi si ga želel, da ga ima vsak lastnik, preden porabi en sam cent. Ne teorija — dejanske, ponavljajoče se napake in majhni popravki smeri, ki bi rešili vsak projekt. Če se pripravljate zgraditi aplikacijo ali ste že sredi gradnje in se vam zdi, da nekaj ni v redu, najprej preberite to. Večino teh je še vedno mogoče popraviti, če jih ujamete dovolj zgodaj.

Napaka 1: Gradite, preden ste dokazali, da jo kdo želi

Najdražja napaka je hkrati najpogostejša: zavezati se k polni gradnji, preden obstaja kakršen koli resničen dokaz, da aplikacija rešuje težavo, za katero bodo ljudje plačali ali jo uporabljali. Ideja se zdi lastniku očitna — seveda jo bodo stranke želele — in prav ta gotovost je tisto, kar je nevarno. Gotovost deluje kot potrditev. Ni.

Potrditev ne pomeni vprašati deset prijateljev, ali jim je ideja všeč; vsi rečejo da iz vljudnosti. Pomeni postaviti najmanjšo možno različico pred resnične uporabnike v resnični situaciji in opazovati, kaj dejansko počnejo. Klikljiv prototip, pristajalna stran, ki meri prijave, ročna »concierge« različica, kjer avtomatizacijo ponaredite z lastnimi rokami — karkoli od tega vam pove več kot dokončana aplikacija, zgrajena na slutnji. Vrstni red je pomemben: poceni dokažite povpraševanje, nato gradite drago. Obrnite to in lahko porabite ves svoj proračun za loščenje nečesa, česar nihče ne odpre dvakrat.

Napaka 2: Širjenje obsega, preoblečeno v ambicijo

Vsaka aplikacija se začne vitka in urejena. Nato se začne tisto »ko smo že pri tem«. Ko že gradimo zaslon za rezervacije, bi lahko obravnaval tudi darilne bone? In točke zvestobe? In sistem priporočil? Vsak dodatek zveni sam zase razumno. Skupaj tiho potrojijo časovnico in račun — ter potisnejo zagon tako daleč, da prvotni zagon zamre.

Rešitev ni reči ne dobrim idejam. Rešitev je parkirati jih. Vodite viden seznam »različica dve«, kamor gre vsaka bleščeča ideja čakati na svojo vrsto. To deluje psihološko in praktično: ljudje nehajo siliti, da bi v prvo izdajo natlačili funkcije, takoj ko zaupajo, da za njihovo idejo pozneje obstaja resnično mesto. Vaša prva različica naj eno stvar opravi resnično dobro, ne deset stvari povprečno. Aplikacija, ki obvlada en delovni potek, se uporablja. Aplikacija, ki vse opravi na pol, se opusti.

Napaka 3: Brez pisnega opisa — le skupna miselna slika

Ta je nevidna, dokler ne ugrizne. Lastnik ima v glavi jasno aplikacijo. Razvijalec ima v glavi jasno aplikacijo. Vsi prikimavajo na uvodnem sestanku. Nihče tega ne zapiše kot je treba — in obe sliki, kot se izkaže, nikoli nista bili ista slika. To odkrijete na polovici poti, ko tisto, kar se gradi, ni tisto, kar ste si predstavljali, in zdaj je prepir o tem, kdo je kaj rekel.

Ne potrebujete stostranske specifikacije. Potrebujete nekaj strani, ki bi jih lahko vsak novinec prebral in razumel: kdo uporablja to aplikacijo, katere tri ali štiri stvari mora z njo početi, kako izgleda uspešen izid. Dodajte grobo skico ključnih zaslonov. To je to. Smisel opisa ni birokracija — je skupna referenca, na katero lahko oba pokažeta, ko se spomin in resničnost začneta razhajati, kar se vedno zgodi.

Napaka 4: Izbira razvijalca na napačen način

Večina lastnikov izbere svojega prvega razvijalca po enem od dveh majavih znakov: najnižji ponudbi ali osebnem priporočilu nekoga iz druge panoge. Oboje lahko uspe po sreči. Nobeno ni zanesljiv način, da izberete nekoga, ki mu boste zaupali znaten del denarja in več mesecev prihodnosti svojega podjetja.

Najnižja ponudba je pri programski opremi še posebej zahrbtna, saj je vrzel med ponudbo in končnim stroškom ogromna in nevidna. Poceni razvijalec, ki potrebuje tri kroge predelave, izgine za dva tedna in vas pusti s kodo, ki je nihče drug ne more vzdrževati, je veliko dražji kot nekoliko dražji, ki to opravi pravilno. Cena je tisto, kar vidite; skupni strošek je tisto, kar plačate.

Kaj dejansko preveriti

Prosite, da vidite stvari, ki so jih izdelali in še delujejo, in če lahko, se pogovorite s temi strankami brez razvijalca v prostoru. Vprašajte, kako obravnavajo spremembe sredi projekta, saj spremembe bodo. Vprašajte, kdo je lastnik kode in računov, ko je končano — odgovor naj bo vedno vi. In bodite pozorni, ali vam zastavljajo dobra vprašanja nazaj. Razvijalec, ki le sprejema ukaze, bo zelo učinkovito zgradil natanko napačno stvar. Dobri se uprejo, opozorijo na vrzeli v vašem razmišljanju in opis obravnavajo kot izhodišče za pogovor, ne kot fiksni nakupovalni seznam.

Napaka 5: Načrtujete proračun za gradnjo, pozabljate na ostalo

Aplikacija ni enkraten nakup kot tiskana brošura. Je živo bitje, ki ga je treba hraniti. Lastniki rutinsko načrtujejo proračun za gradnjo in nič drugega, nato pa jih presenetijo stroški, ki pridejo pozneje: gostovanje, pristojbine trgovin z aplikacijami, vzdrževanje, da sledijo posodobitvam operacijskega sistema telefonov, in neizogiben krog popravkov ter majhnih izboljšav, takoj ko jo začnejo uporabljati resnični ljudje.

Razumno okvirno pravilo: kolikor koli stane gradnja, dajte znaten delež tega znova na stran za prvo leto delovanja. Točna številka se razlikuje, vendar je napaka univerzalna — obravnavati dan zagona kot ciljno črto, ko je v resnici startna črta. Aplikacija, ki se zažene in nato tiho opusti, ker ni proračuna za njeno vzdrževanje, je eden najbolj žalostnih, najpogostejših izidov na celotnem tem področju in se mu je s poštenim načrtovanjem vnaprej povsem mogoče izogniti.

Napaka 6: Oblikujete zase namesto za svojega uporabnika

Svoje podjetje poznate do obisti, kar vas naredi za najslabšega možnega sodnika o tem, ali je vaša aplikacija enostavna za uporabo. Stvari, ki so vam očitne — žargon, vrstni red, po katerem opravljate naloge, bližnjice, ki jih ubirate brez razmišljanja — so za uporabnika ob prvem stiku zmedene. Aplikacija, ki ima za lastnika popoln smisel in vse druge zmede, je propadla, naj bo še tako domiselna.

Zdravilo je poceni in nekoliko ponižujoče: pred zagonom opazujte, kako jo uporabljajo resnični ljudje. Ne vaša ekipa, ki že ve, kako naj bi delovala — resnične stranke ali zaposleni, ki je nikoli niso videli. Dajte jim aplikacijo, dajte jim nalogo in ne recite ničesar. Tam, kjer obotavljajo, pritisnejo na napačno stvar ali zavzdihnejo, je vaša povratna informacija o oblikovanju. Pet ljudi zadošča, da na dan pridejo najhujše težave. Preskakanje tega koraka je razlog, zakaj se aplikacije zaženejo z gumbom »pošlji«, ki ga nihče ne najde, in prijavnim potekom, ki izgubi polovico tistih, ki ga poskusijo.

• Preizkuševalcu dajte resnično nalogo, ne ogleda — »rezervirajte termin za prihodnji torek«, nato molčite.
• Opazujte njegove roke in obraz, ne le, ali mu na koncu uspe.
• Zabeležite vsako obotavljanje; premor je oblikovalska težava, ki je od znotraj ne vidite.
• Uprite se nagonu po razlagi — če morate razložiti, bi morala aplikacija.
• Preizkusite s petimi ljudmi, popravite očitne napake, nato preizkusite znova.

Napaka 7: Gradite domorodni iOS in Android, ko vam ni bilo treba

Obstaja refleks zgraditi »pravo« aplikacijo za iPhone in Android že od prvega dne, povsem domorodno, kot to počnejo velike znamke. Za večino malih podjetij to pomeni dva- do trikratne stroške in zapletenost za korist, ki je vaši uporabniki nikoli ne bodo opazili. Še huje, zdaj za vedno vzdržujete dve ločeni kodni zbirki in podvajate vsak prihodnji popravek.

Pogosto prava prva poteza sploh ni domorodna aplikacija. Dobro zgrajena spletna aplikacija, ki deluje v brskalniku katerega koli telefona, ali medplatformski pristop, ki iz ene kodne zbirke ustvari obe različici za trgovine, vas spravi na trg hitreje in ceneje — in vedno lahko pozneje preidete na povsem domorodno, če resnična uporaba dokaže, da se splača. Vprašanje, ki si ga je treba zastaviti, nikoli ni abstraktno »domorodno ali splet«. Je: katera je najmanjša, najcenejša stvar, ki resničnim uporabnikom omogoča opraviti ključno nalogo? Zgradite to, učite se iz tega in nato porabite velik denar z dokazi namesto z domnevami.

Napaka 8: Obravnavanje zagona kot konca dela

Osma napaka je verjeti, da je projekt končan, ko gre aplikacija v živo. Ni — takrat se resnični projekt začne. Aplikacija brez načrta, kako jo spraviti v roke uporabnikov, brez načina, kako slišati, kaj mislijo, in brez namere, da bi jo izboljšali na podlagi tega, kar izveste, je aplikacija, ki v nekaj mesecih ugasne. Gradnja je bila lahki del. Sprejetje je težki del in skoraj nihče ga ne načrtuje.

Pred zagonom vedite tri stvari: kako bodo ljudje izvedeli, da aplikacija obstaja, kako boste merili, ali jo dejansko uporabljajo, in kako boste zbrali, kar vam povedo, da naslednji krog dela vodi resničnost namesto ugibanj. Nič od tega ni drago. Gre le za drugačno miselnost — aplikacija ni stvar, ki jo dokončate in odidete od nje, je odnos, ki ga vzdržujete. Lastniki, ki to razumejo, dobijo aplikacije, ki sčasoma postanejo bolj uporabne. Tisti, ki ne, dobijo skok na dan zagona in dolg, tih upad.

Kako se izogniti vsem osmim hkrati

Brane skupaj imajo te napake en sam koren: hitro premikanje na domnevah namesto počasi na dokazih. Vsaka od njih je mesto, kjer se je zdelo ceneje preskočiti previden korak. In vsako od njih je veliko ceneje obravnavati pred gradnjo kot po njej. Tukaj je zaporedje, ki se tiho izogne vsem osmim.

1. 1
   Dokažite povpraševanje, preden gradite

   Prototip, pristajalna stran ali ročna različica. Pridobite resničen dokaz, da nekdo to želi, preden zavežete proračun.
2. 2
   Napišite opis in seznam različice dve

   Nekaj jasnih strani, ki jih vsak razume, plus parkirišče za vsako idejo »ko smo že pri tem«, da ne iztiri v1.
3. 3
   Razvijalca izberite po dosežkih, ne po ceni

   Izdelano delo, klici z referencami, jasno lastništvo kode in računov ter nekdo, ki zastavlja dobra vprašanja nazaj.
4. 4
   Načrtujte proračun za celotno prvo leto, ne le za gradnjo

   Gostovanje, vzdrževanje, popravki in podpora. Dan zagona je startna črta, zato financirajte delovanje te stvari.
5. 5
   Izberite najmanjšo platformo, ki opravi nalogo

   V večini primerov najprej splet ali medplatformsko. Na povsem domorodno preidite pozneje, z dokazi, le če uporaba to zahteva.
6. 6
   Preizkusite z resničnimi uporabniki, nato načrtujte zagon

   Opazujte pet neznancev, kako jo uporabljajo, popravite očitne napake in vnaprej odločite, kako jo bodo ljudje našli in kako boste merili uporabo.

Pogosta vprašanja