Pe vremea aceea, era oarecum un haos total dacă vorbim despre
implementarea soluțiilor web pentru client, dar nu în sensul că nu i
se livra acestuia exact ce își dorea și ce avea nevoie. Haosul venea din
situația că fiecare programator dezvolta respectiva aplicație, cum știa
el mai bine, dar evident, sub îndrumarea oamenilor de vânzări și a
programatorilor care erau deja în firmă de ceva timp.
Frumusețea în programarea web este că poți obține același lucru
utilizând între două și patru abordări diferite, la nivel de scriere a
codului sursă. Ca să știi care-i cea mai bună, ține doar de experiența ta
în domeniul de activitate al respectivului proiect, o bună comunicare
și înțelegere a cerințelor manifestate de client, dar și de abilitatea de a
intui, încă de la început, atât eventuale probleme care pot apărea sau
nu în timp, dar și de capacitatea respectivei abordări de a adresa cu
succes o serie de modificări ulterioare care pot fi cerute sau nu.
Iată cum experiența unui programator nu constă strict în abilitatea
acestuia de a scrie cod și calitatea acestui cod, ci mai mult în abilitatea
de a intui, din timp, anumite aspecte care poate nu vor apărea niciodată
la un anume proiect. Din punctul nostru de vedere, aceasta este una din
principalele diferențe între un programator junior și unul senior.
Iată cum venea proiectul X cu specificațiile corespunzătoare și
trebuia să fie gata într-un deadline corespunzător.
Pornind de la specificațiile și cerințele clientului, designerii
întocmeau un layout grafic, proprietarul aproba acel layout. Apoi se
trecea la implementarea propriu-zisă. Primul programator liber, sau
mai liber, începea să lucreze la implementare.
Cum știa el că este mai bine pentru proiect, dar și pentru respectarea
deadline-ului.
Una dintre problemele des întâlnite apărea în momentul în
care programatorul, care a dezvoltat proiectul X, era deja implicat
în dezvoltarea unui alt proiect aflat pe deadline, iar clientul cerea
efectuarea unor modificări urgente la proiectul său deja finalizat de
respectivul programator. Unele modificări veneau și la peste două
săptămâni după livrare.
Imaginează-ți apoi perioada concediilor.
Majoritatea proiectelor începuseră a fi dinamice. Un website static
este relativ ușor de modificat de orice programator cu o minimă
experiență în domeniu.
Magazinele online erau însă ceva prohibitiv pentru România de
atunci datorită realității că mentalitatea, infrastructura, dar și situația
economică nu ofereau beneficii reale nici consumatorului de rând, dar
nici eventualilor proprietari de afaceri, doritori de o astfel de soluție.
Primul magazin online din România a apărut prin 1997 și comercializa
CD-uri cu muzică.
După anii 2000, foarte puțini aveau internet în propriile case.
Majoritatea celor care doreau acces la internet erau nevoiți să-l acceseze
utilizând celebrele "internet café-uri" sau "net café-uri". Majoritatea
însă utilizau aceste locații doar pentru jocuri şi mai puţin pentru
internet, de achiziţii de produse online nici nu se punea problema.
Abia după 2004, RomCard împreună cu Visa şi MasterCard, au
implementat standardul de securitate 3D Secure, ceea ce a condus
piaţa românească la posibilitatea plății cu cardul, direct online.
De aceea, focusul agențiilor web de atunci era axat doar în direcția
strictă a prezenței online. Majoritatea website-urilor create erau doar
website-uri corporate, cărți de vizită online prin intermediul cărora
proprietarii își comunicau portofoliul de servicii și/sau produse.
Principalele provocări ale agențiilor web de atunci erau
următoarele:
• Rapiditatea cu care se putea livra un proiect clientului la
standardul de calitate cerut de acesta. În mod evident, cu cât
mai repede finaliza echipa un proiect, cu atât mai repede putea
începe lucrul la următorul.
• Problema factorului uman, în speță a programatorului care
trebuia să preia un proiect, aflat într-un anumit stadiu de
dezvoltare, sau abilitatea acestuia de a efectua modificări la un
proiect care nu a fost dezvoltat de acel programator.
Website la cheie
În acest caz, apărea problema curbei de învățare, unde un
programator avea nevoie de o anumită perioadă de timp
pentru a se familiariza cu proiectul, atât la nivel de cod sursă,
dar și la nivel de idee generală. Oricât de bine te-ai pricepe la
programare, tot trebuie să știi ce s-a făcut și ce se dorește și,
cel mai important, dacă ce se dorește este compatibil cu ce s-a
făcut deja.
Iată de ce atunci s-a simțit nevoia unei soluții. Era clar că
era nevoie de o platformă proprie care să adreseze, la nivel de
funcționalități, cât mai multe din cerințele întâlnite până atunci de la
clienți. Această platformă trebuia să ne permită să micșorarea timpului
implementării unui proiect, dar în același timp, prin standardizarea
logicii din spatele codului sursă, proiectul să nu mai depindă de un
programator anume.
Dacă, la început, aveam mai multe astfel de soluții, cu timpul acestea s-au într-un un framework propriu, un șasiu de bază care însuma
cam toate cerințele întâlnite până atunci de la clienți. Și cum era de
așteptat, au beneficiat continuu de îmbunătățiri.
Sigur, exista problema timpului necesar ca un programator
nou-venit să se familiarizeze cu platforma, dar acel timp era
infinit mai mic decât alternativa.
De ce am vorbit despre lucrurile de mai sus?
Am făcut-o deoarece aceste probleme există și astăzi în majoritatea
agențiilor web prezente în piață. Iar website-urile "la cheie" au venit
tocmai pentru rezolvarea acestor probleme inițiale.

Cereți detalii despre Website la cheie - motivele apariției
Completarea şi trimiterea formularului de mai jos nu te implică financiar şi/sau contractual, scopul fiind stabilirea contactului.
Datele sunt expediate la adresa de e-mail office@, nefiind stocate în baza de date.
toate câmpurile sunt obligatorii