Am luat în calcul, în această lecție, mai multe tipuri de situații pe care le parcurgi atunci când dezvolți un proiect cu componență IT (website, aplicație etc.). Am considerat că e util să vorbim, mai întâi, despre mersul contractului, să fie foarte clară ideea din spatele pașilor logici de urmat, iar apoi să dezvoltăm cinci motive pentru care e nevoie de specificații tehnice detaliate atunci când vorbim despre astfel de proiecte.

::: Care este mersul logic al unui contract de dezvoltare web?

Părțile se întâlnesc și stabilesc ce anume își dorește Clientul de la cel care îi produce websiteul / aplicația ori proiectul cu componenta IT (furnizorul, să îi zicem). Toate cerințele clientului sunt trecute într-un document, care va deveni ulterior Anexa privitoare la specificațiile tehnice și artistice pe care trebuie să le îndeplinească furnizorul atunci când execută contractul. 
De la acest moment, lucrurile pot avea o desfășurare de genul celei de mai jos (cu mențiunea că mulți dintre pașii menționați aici să fie incluși drept clauze în contract, pentru a avea efect):

1. Odată ce sunt stabilite specificațiile tehnice și artistice ale noului website, acestea devin Anexă a contractului.
2. Se negociază obiectul contractului, prețul contractului, termenul de predare, modalitățile de plată a prețului etc.
3. Se semnează contractul de dezvoltare web.
4. Uneori, se plătește chiar la momentul semnării contractului o primă tranșă din prețul contractului.
5. În maximum x zile de la momentul semnării, furnizorul trebuie să îi prezinte clientului propuneri de interfață grafică (layout-uri) pentru diferite pagini ale viitorului website / aplicație, dacă proiectul implică o astfel de componentă (de obicei se fac trei - cinci propuneri cu privire la pagina principală, dar ar fi bine să se propună și un layout pentru alte tipuri de pagini ale website-ului).
6. În maximum y zile de la data la care a primit propunerile de layout, clientul trebuie să își exprime opinia cu privire la modul în care acesta respectă specificațiile tehnice și artistice ale contractului.
7. Dacă acel client nu spune nimic în termenul de mai sus, atunci contractul se poate considera ca fiind reziliat, iar suma oferită cu titlu de avans nu se mai restituie (bineînțeles, părțile pot agrea, prin contract acest curs al lucrurilor sau altul, mai aplicabil situației lor particulare).
8. Dacă opinia clientului este una favorabilă și găsește layout-ul ca fiind acceptabil (chiar dacă părțile decid să îl modifice în anumite aspecte), atunci furnizorul va avea z zile pentru a dezvolta website-ul bazat pe propunerile de layout. Pentru liniștea clientului, ar fi bine ca acest termen să fie împărțit în cât mai multe termene intermediare, care să îl oblige pe furnizor să “dea raportul” cu privire la activitatea sa.
9. La momentul la care furnizorul a finalizat website-ul, îi comunică clientului locul unde acesta poate fi vizualizat (de regulă, este o locație din internet la care furnizorul își găzduiește websiteurile aflate în curs de dezvoltare).
10. De la comunicarea furnizorului, clientul are un număr de zile pentru a-și exprima opinia cu privire la respectarea de către produs a specificațiilor contractuale.
11. Dacă în termenul convenit clientul nu își manifestă în niciun fel opinia, atunci website-ul se consideră a fi recepționat cu calificativul “corespunzător”, iar clientul trebuie să achite ultima tranșă din prețul contractului.
12. În cazul în care clientul își manifestă nemulțumirea față de modul în care a fost executat websiteul, atunci părțile pot conveni că termenul de execuție să se prelungească pană la momentul rezolvării doleanțelor clientului. De regulă, aceasta este etapa cea mai tensionată a contractelor de dezvoltare web. Furnizorul își dorește banii, iar clientul amână plata pană la momentul la care websiteul este întocmai așa cum și-a dorit. Fiecare dintre părți are propriile derapaje: furnizorul n-a respectat chiar toate specificațiile website-ului, iar clientul și-ar dori să fie rezolvate și niște specificații noi, nediscutate la semnarea contractului. Până la urmă, însă, un eventual diferend ar fi câștigat de partea care își situează pretențiile cel mai aproape de modul în care au fost redactate specificațiile tehnice și artistice ale contractului. 
13. Părțile semnează un proces verbal de predare-primire (fizic ori virtual), în care clientul se declară mulțumit de munca furnizorului. 
14. Se face plata ultimei tranșe a contractului (dacă așa s-a făcut negocierea).

::: De ce este nevoie de precizarea specificațiilor tehnice și artistice ale contractului?

Iată patru motive pentru care specificațiile tehnice trebuie prevăzute cât mai în amănunt cu putință:

→ Gustul e personal. Și incă nu s-a inventat un aparat de identificat gusturile unei persoane. Orice om dorește să aibă cel mai frumos website din lume. Cele mai frumoase culori, cele mai frumoase forme și așa mai departe. Dacă o să întrebăm doi oameni cum ar desena ei acest website, probabil că o să ne arate două desene diferite. 

→ Nu există un gentleman’s agreement perfect. Oricât de bine v-ați fi înțeles la semnarea contractului, probabil că după câteva zile amintirile se schimbă în funcție de interesul părților. Furnizorul își va aduce aminte mai mult de lucrurile pe care le-a agreat el decât de lucrurile pe care le-a cerut clientul. Iar clientul se va gândi doar la cerințele pe care este sigur că le-a exprimat cum trebuie. Dacă părțile nu au scris pe hârtie ce anume se dorește de la website-ul respectiv, au toate șansele să aibă așteptări diferite. 

→ Un buton poate schimba totul. Autorul lui “Alice în Țara Minunilor” spunea că, “dacă nu știi încotro mergi, orice drum te va duce acolo”. E genul de adevăr pe care probabil că o să îl vezi repetat de mai multe ori în aceste pagini. Sunt foarte puțini clienții care știu exact la ce să se aștepte de la website-ul pe care l-au plătit. Cei mai mulți așteaptă un design care să “ii dea pe spate” și funcționalități nemaivăzute. 

Atunci când compari imaginația cu realitatea, ești deseori dezamăgit și ai tendința să mai ceri “un buton acolo”, “o linie nouă aici” și așa mai departe. Am văzut clienți care spuneau că ar vrea un buton care “să le genereze un raport”, fără să-și imagineze că generarea acelui raport înseamnă o muncă de săptămâni întregi pentru dezvoltator. Dacă vrei ca butonul în cauză să nu-ți provoace insomnii, încearcă să îi scrii pe hârtie funcționalitatea. Scrie ce se întâmplă când este apăsat, scrie ce ai vrea să se întâmple în viitor, etc. 

→ Instanța hotărăște pe baza unor probe concrete. Dacă vreodată o să ajungi în instanță cu contractul de dezvoltare a website-ului, pretențiile părților nu se pot dovedi decât pe baza unor probe de necontestat. Dacă într-o anexă a contractului scria că butonul x din website trebuie să aibă o anumită funcționalitate și nu o îndeplinește, atunci e clar faptul că dezvoltatorul este în culpă. Bineînțeles, dezvoltatorul poate susține că, pe parcursul contractului, clientul i-a cerut să renunțe la acest buton. Dacă are acte doveditoare în acest sens, atunci culpa sa este eliminată. 

De regulă, însă, cele mai dese litigii au la bază întârzierile de livrare. Părțile convin ca website-ul să fie gata la un anumit moment, iar dezvoltatorul lungește nepermis de mult perioada de execuție a contractului. În acest caz, specificațiile pot fi de ajutor în măsura în care una dintre părți susține că acestea au fost modificate pe parcursul contractului și există probe care să ateste această modificare.