Aplicație web personalizată: când are sens pentru compania ta

O aplicație web personalizată are sens când regulile companiei cer funcții pe care sistemele disponibile nu le acoperă suficient. Poate fi un instrument intern, un portal pentru clienți sau o platformă care leagă mai multe operațiuni.

Alegerea începe cu procesul de lucru. Ce trebuie să poată face oamenii? Ce sistem funcționează deja? Unde se pierd informațiile? Răspunsurile arată dacă ai nevoie de dezvoltare de la zero, de adaptarea Odoo sau de o integrare.

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.

O aplicație construită pentru compania ta poate acoperi reguli pe care un produs standard nu le tratează suficient: de la calculul ofertelor până la organizarea comenzilor. Dezvoltarea de la zero trebuie comparată cu adaptarea unui sistem existent; nu este automat varianta mai potrivită sau mai ieftină.

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. 

Între o idee și o aplicație folosită zilnic sunt decizii despre procese, date, interfață și implementare. Acest articol explică etapele dezvoltării și rolul feedback-ului. Pentru programele de finanțare și condițiile lor actuale, vezi AccessGrant.

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, o platformă de configurare și ofertare a produselor.

 

De la zero sau pe bazele Odoo?

La Windows&More am construit un configurator 2D pentru ferestre și uși PVC și aluminiu, ofertarea și matricile de prețuri pe client, împreună cu ERP-ul și CRM-ul. La Rentguard am creat de la zero platforma de property management și site-ul.

Pentru AMRP Wood am pornit de la Odoo Manufacturing și am dezvoltat sistemul de producție și productivitate pentru procesele fabricii. Alegerea a păstrat bazele platformei și a permis construirea logicii specifice.

Un proiect poate combina funcții existente, dezvoltare proprie și integrări. Pentru a compara variantele, trebuie clarificate regulile, datele și oamenii care vor folosi sistemul.

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.

Etapele și feedback-ul se organizează în funcție de proiect. Un produs nou poate necesita validări frecvente, iar modificarea unui sistem folosit deja trebuie să țină cont de funcționarea lui zilnică. Maturitatea produsului, singură, nu stabilește metodologia.

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ă. Această suprapunere poate reduce așteptarea dintre etape, în funcție de proiect.

 

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.

După lansare, schimbările trebuie planificate ținând cont de utilizatorii care lucrează deja în aplicație. Feedback-ul poate conduce la o versiune nouă sau la îmbunătățiri treptate.

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?

Un sprint este o perioadă scurtă, cu o durată stabilită în avans, în care echipa lucrează la un obiectiv. În Scrum, durata este de cel mult o lună. Ritmul permite verificarea progresului și adaptarea pașilor următori.

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. 

Scrum este un cadru de lucru din familia abordărilor Agile. Alegerea lui nu depinde exclusiv de faptul că produsul este nou sau deja lansat. Cerințele, echipa și felul în care se poate verifica progresul contează în organizarea proiectului.

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ă.

Context istoric: exemplele tehnologice din secțiunea următoare descriu abordarea prezentată în articolul original din 2022. Nu reprezintă o regulă obligatorie pentru proiectele noi.

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 în minte o aplicație pentru compania ta, începe cu o situație concretă de lucru. Arată-ne cum se desfășoară acum și ce ai nevoie să poată face sistemul. Pentru exemple, vezi proiectele de software personalizat și implementările Odoo.

Discută despre aplicația ta sau scrie-ne la office@360design.ro.