Cronologia reală a dezvoltării unei aplicații: de la idee la lansare

Dacă întrebați zece agenții cât durează să construiască o aplicație, veți primi zece răspunsuri sigure pe ele și niciunul nu va fi adevărat. Răspunsul sincer e că nimeni nu vă poate spune cu precizie în prima zi — dar oricine a livrat cu adevărat software vă poate spune forma lucrurilor: ce etape există, care dintre ele înghit pe tăcute calendarul și unde propriile dumneavoastră decizii grăbesc sau blochează totul. Aceasta e forma respectivă, scrisă pe șleau.

Am văzut mulți proprietari de afaceri mici intrând într-un proiect de aplicație așteptându-se la un marș ordonat și liniar de la schiță la App Store. În schimb, ceea ce primesc seamănă cu o serie de platouri și salturi bruște. Săptămâni în care pare că nu se întâmplă nimic, apoi o zi în care totul se așază dintr-odată la locul lui. Niciunul dintre aceste lucruri nu e un semn că ceva e în neregulă. Pur și simplu așa se face software-ul — și odată ce puteți numi etapele, întregul proces încetează să mai pară o cutie neagră în care plătiți sperând la ce e mai bine.

Așadar, să stabilim așteptări realiste. Pentru o primă versiune concentrată a unei aplicații de afaceri — nu o platformă vastă, o primă versiune care face un singur lucru bine — vorbim de obicei despre ceva în intervalul de trei până la cinci luni de la un început serios până la o lansare reală. Unde anume vă încadrați în acest interval ține mai puțin de tehnologie și mai mult de cât de clari sunteți, cât de repede luați decizii și cât de multe încercați să înghesuiți înainte de lansare. Să le parcurgem.

De ce estimarea pe care ați primit-o e probabil greșită

Cifra de șase săptămâni nu e chiar o minciună — e timpul necesar pentru a construi partea pe care și-o poate imagina toată lumea. Ecranele. Butoanele. Lucrul pe care îl puteți prezenta. Ceea ce ignoră pe tăcute acea cifră e tot ce ține de jurul aplicației vizibile: deciziile, datele, integrările cu instrumentele pe care le folosiți deja, testarea, evaluarea în magazinul de aplicații, inevitabila rundă de „de fapt, poate să facă și asta?”

Un mod util de a gândi: programarea propriu-zisă e rareori blocajul. Blocajul e claritatea. Fiecare oră în care dezvoltatorul așteaptă o decizie — ce procesator de plăți, ce se întâmplă când o rezervare e anulată, cine poate vedea ce — e o oră în care cronologia alunecă. Proiectele care se termină repede nu sunt cele cu cei mai buni ingineri. Sunt cele în care proprietarul răspunde la întrebări într-o zi, nu în două săptămâni.

Așa că, pe măsură ce citiți etapele de mai jos, fiți atenți la momentele în care mingea e în terenul dumneavoastră. Acelea sunt punctele în care un proiect fie își păstrează avântul, fie se blochează pe tăcute trei săptămâni pentru că un e-mail a rămas fără răspuns. Cronologia e o responsabilitate comună, iar jumătatea care revine clientului e jumătatea pe care oamenii o subestimează.

Etapa 1: Descoperire și definirea domeniului (1–3 săptămâni)

Înainte ca cineva să proiecteze un singur ecran, există o etapă care nu pare progres, dar determină totul: să stabiliți ce construiți de fapt și, mai important, ce nu construiți. Aici o idee vagă („o aplicație pentru clienții mei”) devine o listă concretă și realizabilă de funcționalități pentru prima versiune.

Făcută bine, descoperirea înseamnă mai ales conversație și întrebări dificile. Cine o folosește și pe ce dispozitiv? Care e singurul lucru pe care trebuie să-l facă strălucit? Ce poate aștepta până la versiunea a doua? Un partener bun va contraargumenta aici, și v-o doriți — fiecare funcționalitate pe care o tăiați acum înseamnă săptămâni pe care le recuperați. Rezultatul e de obicei un scurt domeniu scris și o schiță aproximativă, ceva ce puteți ține în mână și spune da, ăsta e lucrul.

Etapa 2: Design și prototip (2–4 săptămâni)

Acum aplicația devine ceva ce puteți vedea și pe care puteți face clic, înainte ca un rând de cod real să vă angajeze la ceva. Designerii transformă schița în ecrane propriu-zise — culorile, fluxul, senzația reală de a o folosi — de obicei sub forma unui prototip interactiv pe care îl puteți atinge pe propriul telefon.

Această etapă e de aur dintr-un singur motiv: schimbarea unui design e ieftină, schimbarea software-ului construit e scumpă. Mutarea unui buton într-un prototip durează cinci minute. Mutarea lui după ce funcționalitatea e programată, testată și conectată la datele dumneavoastră poate dura o zi. Deci acesta e momentul să fiți pretențioși, să-l arătați câtorva clienți sau angajați reali și să prindeți problemele de tip „a, nimeni n-o să înțeleagă asta” cât timp sunt încă nedureros de remediat.

Cel mai frecvent mod în care această etapă se prelungește nu e designerul — e indecizia din partea dumneavoastră. Runde nesfârșite de mici ajustări sau trei persoane cu drept de veto care nu cad niciodată de acord. Decideți devreme cine aprobă, oferiți feedback în loturi, nu picătură cu picătură, și etapa rămâne strânsă.

Etapa 3: Construcție (6–12 săptămâni)

Aceasta e partea pe care și-o imaginează toată lumea când se gândește la „a face o aplicație”, și e cel mai lung segment unic — dar rareori cel mai imprevizibil, dacă primele două etape au fost făcute cum trebuie. Dezvoltatorii construiesc aplicația pe bucăți, de obicei în cicluri scurte în care vedeți piese funcționale la fiecare o săptămână sau două, în loc să dispară trei luni și să reapară cu un produs finit.

Acest ritm contează. Vreți să reacționați devreme la software real și funcțional, nu la un raport de stare. Când puteți chiar folosi fluxul de rezervare în săptămâna a patra, veți observa lucruri pe care nicio specificație nu le-ar fi putut surprinde — iar remedierea lor în săptămâna a patra e mult mai ieftină decât în săptămâna a zecea. Un proces bun de construcție face aplicația vizibilă pentru dumneavoastră continuu, nu doar la final.

Ce prelungește pe tăcute construcția

Două lucruri extind o construcție mai mult decât orice altceva. Primul sunt integrările — fiecare sistem extern cu care aplicația trebuie să comunice (procesatorul de plăți, instrumentul existent de rezervări, software-ul de contabilitate, un serviciu de livrare) adaugă muncă, și fiecare poate aduce propriile surprize. Al doilea e extinderea domeniului: picurarea constantă de mici adăugiri care fiecare par minuscule, dar împreună amână lansarea cu o lună. Ambele sunt gestionabile, dar numai dacă le vedeți venind.

• Fiecare integrare externă adaugă zile, uneori săptămâni — bugetați-le explicit, nu presupuneți că sunt gratis.
• „Doar încă o mică funcționalitate” e cea mai frecventă cauză unică a unei date de lansare ratate.
• Datele reale sunt mai dezordonate decât cele de test; planificați timp pentru cazurile-limită pe care foaia de calcul le tolera pe tăcute.
• Conturile de utilizator, plățile și notificările sunt înșelător de complexe — costă întotdeauna mai mult decât par.
• Aprobările și conținutul pe care îl datorați echipei (logo-uri, texte, texte juridice) pot bloca o construcție la fel de sigur ca o eroare.

Etapa 4: Testare și remediere (2–4 săptămâni)

Iată o etapă pe care oamenii uită că există, și apoi o resimt când apare. Odată construită, aplicația trebuie pusă la încercare — pe telefoane diferite, cu internet prost, de către oameni care nu au construit-o și care vor face lucruri pe care nimeni nu le-a anticipat. Testarea nu e o formalitate. E diferența dintre o aplicație în care clienții au încredere și una pe care o dezinstalează după prima blocare.

Așteptați-vă ca aici să iasă la iveală o listă de erori și asperități. Asta nu e un semn că s-a construit prost; e chiar scopul etapei. Unele sunt remedieri rapide, altele dezvăluie o decizie care trebuie reconsiderată. Echipele care gestionează asta bine o tratează ca pe o parte normală și planificată a muncii — nu o urgență și nu ceva de sărit pentru că lansarea se apropie. Sărirea testării nu economisește timp. Doar mută erorile de pe telefonul dumneavoastră de test pe telefoanele clienților, unde costă de zece ori mai mult de remediat.

Etapa 5: Lansare și așteptarea magazinului de aplicații (1–2 săptămâni, plus evaluarea)

Lansarea e mai puțin un singur moment și mai mult o desfășurare atentă. Dacă e o aplicație web, controlați complet momentul — apăsați butonul când sunteți gata. Dacă merge în App Store-ul Apple sau în Google Play, predați o parte din program lor: procesul lor de evaluare poate dura oriunde de la o zi la peste o săptămână, și ocazional o trimit înapoi cu ceva de remediat. Merită să știți asta dinainte ca să nu vă ia prin surprindere o dată de lansare promisă clienților.

Modul inteligent de a lansa nu e o dezvăluire cu surle și trâmbițe către întreaga bază de clienți. E o lansare discretă mai întâi către un grup mic — o mână de clienți binevoitori sau propriii angajați — ca să prindeți problemele din lumea reală înainte să le vadă toți. Apoi lărgiți ușa. O lansare care pare plictisitor de banală e o lansare care a mers bine.

1. 1
   Lansare discretă către un grup mic

   Lansați mai întâi către o mână de utilizatori binevoitori sau angajați. Utilizarea reală găsește ce a ratat testarea, cu miza redusă la minimum.
2. 2
   Trimiteți devreme dacă mergeți în magazinele de aplicații

   Apple și Google controlează ceasul evaluării, nu dumneavoastră. Trimiteți cu o rezervă de timp ca o evaluare lentă sau o respingere să nu vă dărâme data promisă.
3. 3
   Urmăriți îndeaproape prima săptămână

   Țineți pe cineva la îndemână ca să reacționeze rapid. Prima săptămână scoate la iveală cazurile-limită din lumea reală pe care niciun mediu de testare nu le aduce vreodată.
4. 4
   Planificați munca de a doua zi înainte de lansare

   O aplicație nu e niciodată „terminată” la lansare. Stabiliți din timp cine se ocupă de inevitabilele mici remedieri și de prima rundă de feedback.

Punând toată cronologia laolaltă

Așezate cap la cap, aceste etape vă oferă o imagine realistă. Niciuna nu e exotică; ceea ce îi încurcă pe oameni e că uită că cele nespectaculoase — descoperirea, testarea, așteptarea magazinului de aplicații — sunt timp real în calendar, nu erori de rotunjire. Iată aproximativ cum tinde să se distribuie pe luni o primă versiune concentrată.

Adunați totul și înțelegeți de ce trei până la cinci luni e intervalul sincer pentru o primă versiune reală, și de ce cei care promit șase săptămâni redefinesc pe tăcute ce înseamnă „o aplicație”. Nu e pesimism — e diferența dintre o dată pe care chiar o veți respecta și una pentru care vă veți cere scuze pe tot parcursul proiectului.

Cum să o accelerați cu adevărat (și cum nu)

Puteți merge mai repede, dar pârghiile reale nu sunt cele la care apelează oamenii. Aruncarea mai multor dezvoltatori într-un proiect pe jumătate definit îl face de obicei mai lent, nu mai rapid. Acceleratoarele sincere sunt nespectaculoase: decideți ce să lăsați deoparte, răspundeți repede la întrebări și rezistați tentației de a adăuga lucruri în mijlocul construcției.

Cea mai mare dintre toate e un domeniu necruțător. Cu cât prima versiune e mai mică și mai clară, cu atât se lansează mai devreme — iar o aplicație lansată care își câștigă pâinea vă învață mai mult în două săptămâni decât alte două luni de planificare. Puteți întotdeauna să adăugați. Nu puteți recupera lunile petrecute construind funcționalități pe care nimeni nu și le dorea.

Există un adevăr înrudit care merită spus cu voce tare: nu totul trebuie să fie o aplicație personalizată. Uneori adevărata problemă e o porțiune de muncă manuală pe care o bucată de automatizare ar putea-o gestiona discret, fără nicio aplicație. Un partener bun vă va spune când e cazul, în loc să vă vândă construcția mai mare — pentru că cea mai ieftină aplicație e cea pe care nu a trebuit să o faceți.

Întrebări frecvente