8 greșeli costisitoare în dezvoltarea de aplicații pe care IMM-urile le fac mereu

Iată adevărul incomod despre proiectele de aplicații care o iau razna: până când codul începe să arate prost, proiectul era deja pierdut cu săptămâni în urmă. Greșelile costisitoare din dezvoltarea aplicațiilor pentru firme mici aproape niciodată nu se întâmplă la tastatură. Se întâmplă în conversații banale — brief-ul care n-a fost niciodată scris, funcția pe care cineva a adăugat-o „cât tot suntem la asta”, dezvoltatorul ales pentru că l-a recomandat un prieten. Niciuna nu pare o decizie în acel moment. Toate vă costă mai târziu.

Am văzut multe firme mici comandându-și prima aplicație și am fost chemat să salvez destule după ce era prea târziu. Proprietarii rareori sunt oameni neglijenți. Sunt isteți, atenți, pricepuți la condus o afacere. Dar software-ul are propriul set de capcane care nu există nicăieri altundeva în viața lor profesională, și nimeni nu i-a avertizat. Așa că dau drept în aceleași opt capcane, în aproximativ aceeași ordine, de fiecare dată.

Aceasta este lista pe care mi-aș fi dorit s-o aibă orice proprietar înainte să cheltuiască un ban. Nu teorie — greșelile reale, repetabile, și micile corecții de traseu care ar fi salvat fiecare proiect. Dacă sunteți pe cale să construiți o aplicație, sau sunteți deja la mijlocul construcției și ceva nu e în regulă, citiți întâi asta. Cele mai multe dintre acestea încă pot fi reparate dacă le prindeți devreme.

Greșeala 1: Construirea înainte de a dovedi că cineva o vrea

Cea mai costisitoare greșeală este și cea mai răspândită: angajarea într-o construcție completă înainte să existe vreo dovadă reală că aplicația rezolvă o problemă pentru care oamenii vor plăti sau pe care o vor folosi. Ideea i se pare evidentă proprietarului — sigur că vor clienții asta — și tocmai acea certitudine este periculoasă. Certitudinea seamănă cu o validare. Dar nu este.

Validarea nu înseamnă să întrebați zece prieteni dacă le place ideea; toți spun da ca să fie drăguți. Înseamnă să puneți cea mai mică versiune posibilă în fața unor utilizatori reali, într-o situație reală, și să urmăriți ce fac de fapt. Un prototip pe care se poate da clic, o pagină de destinație care măsoară înscrierile, o versiune manuală „de tip concierge” în care falsificați automatizarea cu mâna — oricare dintre acestea vă spune mai mult decât o aplicație finită construită pe o presimțire. Ordinea contează: dovediți cererea ieftin, apoi construiți scump. Inversați asta și vă puteți cheltui tot bugetul șlefuind ceva ce nimeni nu deschide de două ori.

Greșeala 2: Extinderea scopului deghizată în ambiție

Orice aplicație începe suplă și ordonată. Apoi încep „cât tot suntem la asta”. Cât construim ecranul de rezervări, n-ar putea gestiona și vouchere cadou? Și puncte de fidelitate? Și un sistem de recomandări? Fiecare adăugare sună rezonabil de una singură. Împreună triplează pe nesimțite calendarul și factura — și împing lansarea atât de departe încât elanul inițial moare.

Soluția nu e să spuneți nu ideilor bune. E să le parcați. Țineți o listă vizibilă „versiunea a doua” unde fiecare idee strălucitoare merge să-și aștepte rândul. Asta face ceva psihologic, nu doar practic: oamenii încetează să se lupte ca să înghesuie funcții în prima versiune odată ce au încredere că există un loc real pentru ideea lor mai târziu. Prima versiune ar trebui să facă un singur lucru cu adevărat bine, nu zece lucruri acceptabil. O aplicație care stăpânește perfect un singur flux de lucru este folosită. O aplicație care face totul pe jumătate este abandonată.

Greșeala 3: Niciun brief scris — doar o imagine mentală comună

Aceasta este invizibilă până când mușcă. Proprietarul are o aplicație clară în cap. Dezvoltatorul are o aplicație clară în cap. Toți dau din cap la ședința de start. Nimeni n-o scrie ca lumea — și cele două imagini, se dovedește, n-au fost niciodată aceeași imagine. Descoperiți asta la jumătatea drumului, când lucrul care se construiește nu e lucrul pe care vi l-ați imaginat, și acum e o ceartă despre cine ce a spus.

Nu vă trebuie o specificație de o sută de pagini. Vă trebuie câteva pagini pe care orice nou-venit le-ar putea citi și înțelege: cine folosește această aplicație, care sunt cele trei sau patru lucruri pe care trebuie să le facă cu ea, cum arată un rezultat reușit. Adăugați o schiță sumară a ecranelor-cheie. Atât. Rostul brief-ului nu e birocrația — e o referință comună spre care amândoi puteți arăta când memoria și realitatea încep să se îndepărteze, ceea ce se întâmplă întotdeauna.

Greșeala 4: Alegerea dezvoltatorului în modul greșit

Cei mai mulți proprietari își aleg primul dezvoltator pe baza unuia dintre două semnale firave: cea mai mică ofertă, sau o recomandare personală de la cineva dintr-un alt domeniu. Ambele pot funcționa din noroc. Niciuna nu e un mod fiabil de a alege pe cineva căruia îi veți încredința o bună parte din bani și câteva luni din viitorul afacerii.

Cea mai mică ofertă este deosebit de înșelătoare în software, fiindcă prăpastia dintre o ofertă și costul final este enormă și invizibilă. Un dezvoltator ieftin care are nevoie de trei runde de refacere, dispare două săptămâni și vă lasă cu un cod pe care nimeni altcineva nu-l poate întreține este mult mai scump decât unul puțin mai pricos care îl face bine din prima. Prețul este ce vedeți; costul total este ce plătiți.

Ce să verificați de fapt

Cereți să vedeți lucruri pe care le-au livrat și care încă funcționează, și, dacă puteți, vorbiți cu acei clienți fără dezvoltator în încăpere. Întrebați cum gestionează modificările la mijlocul proiectului, fiindcă vor exista modificări. Întrebați cine deține codul și conturile când e gata — răspunsul ar trebui să fie întotdeauna dumneavoastră. Și fiți atent dacă pun la rândul lor întrebări bune. Un dezvoltator care doar primește comenzi va construi exact lucrul greșit foarte eficient. Cei buni contrazic, vă arată lacunele din gândire și tratează brief-ul ca punct de plecare pentru o conversație, nu ca o listă de cumpărături fixă.

Greșeala 5: Bugetarea construcției, uitând restul

O aplicație nu este o achiziție unică precum o broșură tipărită. Este un lucru viu care trebuie hrănit. Proprietarii bugetează în mod obișnuit construcția și nimic altceva, apoi sunt luați prin surprindere de costurile care sosesc după aceea: găzduirea, taxele magazinului de aplicații, mentenanța pentru a ține pasul cu actualizările sistemelor de operare ale telefoanelor, și runda inevitabilă de remedieri și mici îmbunătățiri odată ce oameni reali încep s-o folosească.

O regulă de bun-simț: oricât costă construcția, puneți deoparte o felie semnificativă din asta din nou pentru primul an de funcționare. Cifra exactă variază, dar greșeala este universală — a trata ziua lansării ca linia de sosire când de fapt este linia de start. Aplicația care se lansează și apoi este abandonată pe tăcute fiindcă nu există buget pentru a o întreține este unul dintre cele mai triste și frecvente deznodăminte din tot acest domeniu, și este complet evitabilă cu o planificare onestă de la bun început.

Greșeala 6: A proiecta pentru dumneavoastră în loc de utilizator

Vă cunoașteți afacerea pe de rost, ceea ce vă face cel mai prost judecător posibil al faptului dacă aplicația e ușor de folosit. Lucruri care vă sunt evidente — jargonul, ordinea în care faceți sarcinile, scurtăturile pe care le luați fără să gândiți — sunt nedumeritoare pentru un utilizator la prima folosire. O aplicație care are perfect sens pentru proprietar și îi încurcă pe toți ceilalți a eșuat, oricât de inteligentă ar fi.

Leacul este ieftin și ușor umilitor: urmăriți oameni reali folosind-o înainte de lansare. Nu echipa, care deja știe cum ar trebui să funcționeze — clienți sau angajați adevărați care n-au văzut-o niciodată. Dați-le aplicația, dați-le o sarcină și nu spuneți nimic. Acolo unde ezită, ating lucrul greșit sau oftează, acela este feedback-ul dumneavoastră de design. Cinci oameni sunt de ajuns ca să scoată la iveală cele mai grave probleme. Sărirea peste acest pas este motivul pentru care aplicații se lansează cu un buton „trimite” pe care nimeni nu-l găsește și cu un flux de înscriere care pierde jumătate dintre cei care încearcă.

• Dați-i celui care testează o sarcină reală, nu un tur — „rezervă o programare pentru marțea viitoare”, apoi tăceți.
• Urmăriți-i mâinile și fața, nu doar dacă reușește până la urmă.
• Notați fiecare ezitare; o pauză este o problemă de design pe care n-o puteți vedea din interior.
• Rezistați impulsului de a explica — dacă trebuie să explicați, aplicația ar fi trebuit s-o facă.
• Testați cu cinci oameni, reparați eșecurile evidente, apoi testați din nou.

Greșeala 7: A construi iOS și Android native când n-aveați nevoie

Există un reflex de a construi o aplicație „ca lumea” atât pentru iPhone, cât și pentru Android din prima zi, complet nativă, așa cum fac marile branduri. Pentru cele mai multe firme mici, asta înseamnă de două-trei ori costul și complexitatea pentru un beneficiu pe care utilizatorii dumneavoastră nu-l vor observa niciodată. Mai rău, întrețineți acum două baze de cod separate pentru totdeauna, dublând fiecare remediere viitoare.

Adesea prima mișcare corectă nu este deloc o aplicație nativă. O aplicație web bine făcută care funcționează în browserul oricărui telefon, sau o abordare cross-platform care produce ambele versiuni de magazin dintr-o singură bază de cod, vă duce pe piață mai repede și mai ieftin — și puteți oricând trece complet pe nativ mai târziu, dacă utilizarea reală dovedește că merită. Întrebarea de pus nu este niciodată „nativ sau web” în abstract. Este: care e cel mai mic, cel mai ieftin lucru care le permite utilizatorilor reali să facă treaba esențială? Construiți asta, învățați din ea, apoi cheltuiți banii mari pe dovezi, nu pe presupuneri.

Greșeala 8: A trata lansarea ca sfârșitul muncii

A opta greșeală este să credeți că proiectul s-a terminat când aplicația intră în funcțiune. Nu s-a terminat — abia atunci începe proiectul adevărat. O aplicație fără un plan de a ajunge în mâinile utilizatorilor, fără o cale de a afla ce cred ei și fără intenția de a o îmbunătăți pe baza a ce învățați este o aplicație care se stinge în câteva luni. Construcția a fost partea ușoară. Adoptarea este partea grea, și aproape nimeni nu o planifică.

Înainte de lansare, știți trei lucruri: cum vor afla oamenii că aplicația există, cum veți măsura dacă o folosesc cu adevărat și cum veți aduna ce vă spun, astfel încât următoarea rundă de muncă să fie ghidată de realitate, nu de presupuneri. Nimic din asta nu e scump. Este doar o altă mentalitate — aplicația nu e un lucru pe care îl termini și pleci, e o relație pe care o întreții. Proprietarii care înțeleg asta obțin aplicații care devin mai utile în timp. Cei care nu obțin un vârf în ziua lansării și un declin lung și tăcut.

Cum să le ocoliți pe toate opt deodată

Citite împreună, aceste greșeli au o singură rădăcină: a merge repede pe presupuneri în loc de încet pe dovezi. Fiecare dintre ele este un loc unde a părut mai ieftin să sari peste pasul atent. Și fiecare dintre ele este mult mai ieftin de gestionat înainte de construcție decât după. Iată succesiunea care le ocolește pe tăcute pe toate opt.

1. 1
   Dovediți cererea înainte să construiți

   Un prototip, o pagină de destinație sau o versiune manuală. Obțineți dovezi reale că cineva vrea asta înainte de a angaja bugetul.
2. 2
   Scrieți brief-ul și lista versiunii a doua

   Câteva pagini clare pe care le poate înțelege oricine, plus un loc de parcare pentru fiecare idee „cât tot suntem la asta”, ca să nu deraieze v1.
3. 3
   Alegeți dezvoltatorul după istoric, nu după preț

   Lucrări livrate, apeluri de referință, proprietate clară asupra codului și conturilor, și cineva care pune la rândul lui întrebări bune.
4. 4
   Bugetați tot primul an, nu doar construcția

   Găzduire, mentenanță, remedieri și suport. Ziua lansării este linia de start, deci finanțați funcționarea lucrului.
5. 5
   Alegeți cea mai mică platformă care face treaba

   Web sau cross-platform mai întâi, în cele mai multe cazuri. Treceți complet pe nativ mai târziu, cu dovezi, doar dacă utilizarea o cere.
6. 6
   Testați cu utilizatori reali, apoi planificați lansarea

   Urmăriți cinci străini folosind-o, reparați eșecurile evidente și decideți din timp cum o vor găsi oamenii și cum veți măsura utilizarea.

Întrebări frecvente