Pe scurt, o aplicație web personalizată aduce multe beneficii unei companii. Chiar dacă un astfel de software poate fi mai scump (ați fi surprinși să aflați că de multe ori poate fi chiar mai ieftin), acesta cu siguranță se va potrivi ca o mănușă.
Când construim o aplicație web de la zero, noi ca agenție de dezvoltare software facem ceea ce știm mai bine, iar clientul face ceea ce știe el cel mai bine. Noi oferim consultanță și programăm, iar clientul ne oferă feedback și ne ajută să înțelegem modelul de business pentru a livra cele mai bune produse și servicii.
În calitate de client, o astfel de aplicație web este 100% customizabil și făcut doar pentru compania ta. Nu va trebui să îți ajustezi modelul de business sau elementele de contabilitate pentru a te încadra în framework-ul ERP-ului sau al CRM-ului stock pe care l-ai fi achiziționat de pe piață. De asemenea, este aplicabil pentru orice tip de software, nu doar pentru aceste două soluții pentru back-office și management (să le numim).
Astfel, când lucrezi cu o echipă mixtă de oameni, de la programatori la consultanți și designeri, vei lucra într-un sistem bine pus la punct care include feedback, consultanță, comunicare ușoară și rapidă, implementări și schimbări prompte. De aceea vei avea control asupra livrabilelor în oricare punct al procesului.
Cu toate acestea, drept client este greu să vezi în spatele cortinei. Știi care sunt motivele pentru care dorești digitalizare sau update-ul infrastructurii digitale curente (să nu mai vorbim de cei până la € 100.000 nerambursabili oferiți de UE). Dar cum se întâmplă fructificarea ideii tale doar prin niște discuții săptămânale? Deși pare magic, nu folosim magia, ci o serie întreagă de procese și operațiuni pe mai multe nivele, de la management la design și programarea în sine. Scopul meu în acest articol este de a descrie această magie.
Cine Suntem noi?
Înainte de a continua, aș dori să împărtășesc mai multe despre noi. Noi suntem 360design, o agenție de software development. Cu toate acestea, suntem mult mai mult de atât. Pe lângă crearea de aplicații web și cloud la comandă pentru partenerii noștri, avem două start-up-uri proprii. Acestea sunt Panorender, un serviciu pentru crearea tururilor virtuale interactive și al evenimentelor virtuale și 360configurator, cel mai avansat configurator de ferestre de termopan și aluminiu de pe piață.
Cum ajungem de la idee la o aplicație web ca produs final?
Aș putea spune că ajungem la un produs final prin planificare, dezvoltare, feedback constant și comunicare, însă răspunsul real este mult mai complicat de atât.
În principiu, acestea sunt fazele structurale ale procesului. De fapt, procesele noastre sunt următoarele: planificare, design, dezvoltare, lansarea Beta, lansarea oficială și mentenanță. Deși nu neapărat într-o ordine liniară, ci în diverse cicluri între ele deoarece fiecare client sau proiect e diferit de oricare altul și în realitate, lucrurile sunt mai complicate.
De asemenea mi-aș dori să spun că folosim o metodologie Agile sau Scrum. În realitate, folosim mai multe.
După cum am menționat, fiecare proiect este diferit. De la scop la maturitate și relația cu clientul. Iar fiecare metodologie este diferită și potrivită pentru un anumit tip de proiect. Există proiecte în care a trebuit să personalizăm una dintre aceste metodologii pentru a fi mai eficienți și pentru a se plia mai bine pe nevoile noastre.
Pentru un proiect care presupune aducerea pe piață a unui nou produs, cel mai probabil vom merge cu o metodologie Agile mai adaptivă și orientată către construirea rapidă a acestuia. În schimb, pentru un proiect matur, pe care l-am construit de ceva timp, vom alege o metodologie tip Waterfall, iar dacă vrem să reiterăm sau să ducem proiectul la un nou nivel sau la o variantă x.0, ne vom reorienta către o metodologie Scrum, sau chiar Agile sau un hibrid dintre cele două.
Menționasem cele 6 faze ale procesului nostru de la 0 la un produs finit. Urmează să detaliez mai multe despre fiecare dintre acestea pentru a înțelege procesele și de ce spun că este mai complicat în realitate.
Planificarea, scopul proiectului și caietul de sarcini
Planificarea este fundația oricărui proiect. Alegerea și obținerea resurselor necesare împreună cu înțelegerea aprofundată a proiectului sunt factori de success.
Primul lucru pe care îl facem după ce un client își arată interesul în serviciile noastre, este să clarificăm scopul, ce presupune proiectul în materie de timp și resurse și bugetul. Aceasta presupune o serie de ședințe inițiale ale căror scop este să înțelegem nevoile clientului, dar și operațiunile și modelul de business. Drept livrabile, aici creăm Caietul de Sarcini și cotația noastră pentru acest proiect.
Chiar dacă această etapă poate părea simplă, trebuie luată foarte în serios și poate dura de la 2 săptămâni până la mai multe luni din varii motive. Unele proiecte poate au nevoie de mai multă înțelegere sau trebuie să treacă prin diverse procese și protocoale cum ar fi aprobări, studii de fezabilitate, concursuri (precum Start-up Nation), fonduri, etc. De asemenea, unele proiecte pot necesita mai multă cercetare pentru resursele și tehnologiile necesare pentru crearea software-ului costumizat și chiar oamenii potriviți pentru detaliile specifice proiectului.
Design pentru aplicația web
Înainte de a începe să scriem codul per se, este mai logic și mai puțin riscant să creăm un „mockup” al aplicației web. Facem asta printr-un tool digital numit Figma. Această aplicație web ne permite să creăm o variantă interactivă a produsului final, însă lipsit de funcționalitate.
De exemplu, pentru un CRM personalizat vom crea în această etapă sistemul de design precum tipografie, brand book, culori și componente (sau le adaptăm pe cele existente) și vom crea fiecare „screen” (fiecare pagină a aplicației) începând cu un wireframe care conține elementele de paginație și structură, cum ar fi așezarea elementelor de bază în pagină, natura acestora (poze, text, card, buton, tabel, grafic, etc.) și traseul utilizatorului prin platformă.
(Puteți interacționa cu exemplul de mai jos prin a glisa în jos. De asemenea, puteți da click pe el și să vedeți celelalte pagini. Din colțul din dreapta sus puteți modifica dimensiunea afișării)
Pe acestea le vom transforma într-o machetă plină de culori, umbre, animații și interacțiuni care va fi 100% interactivă — un prototip. Puteți naviga între pagini, apăsa butoane și vedea tot traseul, dar nu vor fi afișate date în timp real și nu vor exista răspunsuri de la platformă.
Bineînțeles, această etapă este plină de ședințe săptămânale sau bilunare pentru feedback și optimizarea experienței utilizatorului. De asemenea comunicăm zilnic pentru mici schimbări prin WhatsApp deoarece e-mailul este prea încet.
(Puteți interacționa cu exemplul de mai jos. Puteți începe prin apăsarea butonului „Start Managing”. Puteți da click pe titlul acestei previzualizări pentru a o deschide într-un ecran complet.)
În același timp, de îndată ce bazele sunt decise, începem să programăm infrastructura și arhitectura digitală a proiectului. Acest lucru ne fluidizează procesele deoarece ne permite să facem 2 lucruri în același timp. Până când finalizăm toate detaliile elementelor de interfața și experiența utilizatorului, infrastructura (servere, cloud, arhitectura digitală și a bazelor de date, etc.) este finalizată. Astfel putem economisi sute de ore de programare, poate chiar mai mult în unele cazuri.
Dezvoltarea și programarea aplicației web
După ce avem infrastructura și interfața finalizate, suntem gata să implementăm funcționalitățile în design.
Deși pare simplu, odată ce avem deja o fundație solidă să mai adăugăm niște linii de cod pentru interacțiune cu platforma.
Însă, aici intervine procesul Agile (presupunem proiectul fiind unul nou), în care intervin 3 elemente volatile: timpul dezvoltării, ideile noi, testarea și implementarea feedback-ului.
Timpul dezvoltării reprezintă timpul efectiv de codare de care are programatorul nevoie. Aici intervine de asemenea pregătirea infrastructurii aplicației web. Deși unele cerințe pot părea simple, acestea pot avea nevoie de schimbări signifiante ale infrastructurii ceea ce poate dura câteva zile sau chiar mai mult.
Ideile noi apar mereu, în fiecare stagiu al proiectului software. Acestea pot fi schimbări micuțe (poziții schimbate, stilizare, culori, așezare în pagină, afișare) sau schimbări mari (schimbarea parcursului unei întregi funcționalități). Aceste idei noi au cel mai mare potențial de a încetini proiectul, deoarece trebuie încadrate în programul nostru Agile. Poate părea ușor, însă deseori există o dorință de a implementa aceste idei noi cât de curând din partea clientului, sau poate chiar sunt necesare în momentul respectiv. Acest lucru, anume chiar și 10 idei mici care apar într-o ședință, chiar dacă fiecare durează 20 de minute pentru a fi implementată, toate pot lua jumătate de zi de programare. Când apar astfel de dorințe zilnic, devine dificil. De aceea, planificarea cu grijă a ideilor pe timeline este critică, împreună cu înțelegerea impactului acestor idei în timeline, prin prioritizarea lor în funcție de importanță și urgență.
Testarea și implementarea feedback-ului este al treilea element volatil, din varii motive. De cele mai multe ori, în această parte din proces revenim la design pentru a economisi timp și resurse și pentru a planifica mai în detaliu noile modificări și ce presupun acestea pentru interfață și interacțiunea utilizatorului. În primul rând, testarea implică 2 lucruri: optimizare și bug-uri. Când testăm o aplicație, apar noi metode de a aborda anumite situații sau interacțiuni pe care le putem optimiza. De asemenea, apar bug-uri — probleme în cod care împiedică funcționalitățile din a merge corespunzător. Acestea pot fi subtile sau nu, iar rezolvarea lor poate dura câteva minute sau chiar zile, în funcție de dificultatea problemei.
De aceea, nu testăm și implementăm în producție (pe aplicația web live), ci într-un duplicat offline, unde putem să ne asumăm orice risc dorim. O dată ce am creat optimizarea sau am reparat bugul și ne-am asigurat că soluțiile și implementările nu au efecte negative asupra platformei, suntem gata să o publicăm pe varianta live. În caz contrar, dacă am lucra la toate aceste lucruri în varianta live, riscurile pot fi enorme. Platforma ar putea deveni inutilizabilă zile întregi.
Pe lângă toate acestea, repararea sau implementarea de noi funcționalități într-o aplicație web este mai mult sau mai puțin ca repararea/renovarea oricărui alt lucru. Pentru a repara ceva, va trebui să îl „desfaci” întâi pentru a identifica problema mai în detaliu și cauza ei.
Lansarea Beta
Fie că e vorba de o aplicație web publică sau un software dedicat companiei tale și oamenilor parte din aceasta, înainte de a lansa platforma, aceasta trebuie pusă în mâna unui grup restrâns de utilizatori care să testeze aplicația în cazuri reale.
Bazat pe această perioadă de lansare beta, adunăm tot feedback-ul utilizatorilor, îl centralizăm și îl discutăm într-o serie de ședințe pentru a păstra cele mai bune idei și pentru a le pune într-un cadru facil timeline-ului pentru a fi implementat. Deseori, în acest stagiu trebuie să ne întoarcem din nou la planificare și design.
Lansarea Oficială
Odată ce am acumulat, sintetizat, planificat și implementat feedback-ul în această perioadă beta, suntem gata să punem produsul pe piață pentru toată lumea sau să-l facem disponibil întregii companii.
Deși pare că aici munca s-a terminat, de fapt, aici abia începe.
Mentenanță și update-uri pentru noua aplicație web
După ce produsul este livrat, există încă 3 elemente volatile care trebuie avute în grijă: buguri, idei noi (din nou) și update-uri.
Chiar dacă platforma este pusă la punct, nu există un sfârșit al acesteia. Mai ales când este disponibilă tuturor, încă mai pot apărea bug-uri și feedback, idei de optimizare.
De aceea, de multe ori aici pregătim planificarea pentru următoarea versiune evoluată 2.0 sau doar planificăm calendarul pentru implementarea următoarelor funcționalități și optimizări.
De altfel, în acest stagiu suntem nevoiți (deseori) să schimbăm și metodologia folosită în Scrum, sau o abordare mai iterativă și mai puțin flexibilă Agile, deoarece variabilele s-au schimbat așa cum și abordarea noastră asupra procesului dezvoltării trebuie să o facă.
Cum menținem pasul cu vechile și noile tehnologii când construim o aplicație web?
Ce e un sprint?
Am menționat de mai multe ori framework-uri precum Scrum, Agile și am vorbit despre sprinturi, dar ce sunt acestea și cum impactează procesul dezvoltării aplicației web?
În primul rând, un sprint este o perioadă de 2 săptămâni sau mai mult în care implementăm cele mai importante, critice și urgente modificări. Divizându-ne activitatea în astfel de perioade, ne ajută să prioritizăm și planificăm eficient calendarul implementărilor.
Agile, Scrum, Waterfall, Kanban și altele sunt filosofii pentru managementul de proiect. Fiecare are propriile metode și este potrivit pentru un anumit tip de proiect. De asemenea, au mai multe subtipuri.
De exemplu, Scrum este mai potrivit pentru un proiect lansat al căror cerințe se va schimba și vor evolua în timp, unde echipa trebuie să fie mai autonomă și unde multe dintre lucruri sunt noi pentru programatori. Totodată, Agile este mai potrivit pentru proiectele noi (până în faza de lansare), care încep de la zero, unde produsul final nu este încă 100% definit și unde rapiditatea implementării este prioritizată. De asemenea, există mai multe abordări pentru această metodologie, cum ar fi una orientată către adaptabilitatea cerințelor sau una orientată către dezvoltarea iterativă a fiecărei funcționalități în parte.
Există multe alte lucruri specifice fiecărei metodologii și multe subtipuri, ba chiar abordări hibride între 2 sau mai multe și chiar metodologii „personalizate” fiecărui proiect în parte. Din fericire, tu, clientul nu trebuie să te îngrijorezi pentru acestea; e partea noastră de muncă.
Tehnologii de ultimă generație sau opțiuni vechi și stabile pentru aplicația web?
Din păcate, nici aici nu există un răspuns alb-negru precum:
„Tehnologii noi, deoarece ne oferă cele mai eficiente și optimizate funcționalități, plus că ne oferă posibilitatea de a programa de 3 ori mai rapid”.
sau
„Tehnologii vechi, deoarece sunt foarte stabile, vast utilizate și înțelese, cu o comunitate mare care ne poate ajuta imediat să rezolvăm rapid orice problemă ar putea apărea”.
Tot ce pot spune este că preferăm Vue.JS ca framework de programare, deoarece este printre cele mai noi și ușor de utilizat, cu o gamă largă de opțiuni și configurabilitate, plus viteza dezvoltării și ușurința acesteia, dar și o comunitate mare, cu cea mai mare creștere de membrii în ultimii 5 ani. De asemenea, documentația este extinsă și ușor de înțeles, ilustrată atât prin videoclipuri oficiale, cât și prin text și exemple de cod. Pentru noi, aceasta ne oferă echilibrul dorit între viteză, stabilitate și comunitate.
Pentru partea de backend (servere, framework de back-end și arhitectură digitală), folosim exclusiv infrastructura Google Cloud care ne oferă viteză de răspuns ridicată, flexibilitate și ușurința de a identifica și rezolva probleme, bug-uri sau pentru a optimiza rapid diverse procese.
Mai mult decât atât, fiecare framework de front-end are un limbaj de programare propriu, iar fiecare limbaj de programare este unic și dedicat unei game de soluții pentru anumite probleme. De exemplu, un joc video poate folosi C#, o aplicație web poate folosi Javascript, un software desktop poate folosi C++, iar cineva care programează servere va folosi Java. Limitele între ele sunt destul de gri, situaționale și foarte tehnice.
În realitate, fiecare proiect are o natură specifică. Uneori putem folosi alte servicii precum Digital Ocean, React, Laravel sau altele. Această alegere depinde cel mai mult de natura proiectului, prioritățile clientului și resursele disponibile. Uneori putem folosi chiar opțiuni mai exotice cum ar fi tehnologiile blockchain utilizate de jucătorii mari precum Google, Meta, Microsoft, Intel, precum NEAR, Matic, Hedera Hashgraph, Solana, dacă este mai potrivit pentru proiectul nostru.
Concluzie
Sperăm că citind acest articol aveți o înțelegere mai bună asupra procesului de dezvoltare. Acesta presupune planificare atentă împreună cu clientul, alegerea uneltelor și a resurselor necesare, alegerea sau crearea unui framework potrivit, nenumărate meetinguri și runde de feedback, etc.
Toate aceste complexități discutate în articol doar pentru ca tu, clientul, să beneficiezi de magia care se întâmplă între ședințe; cum cuvintele și ideile tale devin realitate.
Dacă ai ajuns până aici, probabil vrei să afli chiar mai multe despre acest proces sau ai nevoie de o aplicație web pentru compania ta și ești destul de convins că un software la comandă este potrivit pentru tine. Nu ezita să ne contactezi pe site. Alternativ, ne poți trimite un 💌email sau ne poți suna pe 📞 telefon. De asemenea, ne poți trimite direct un mesaj rapid pe WhatsApp.
