Cu acest articol intenționăm să ajutăm atât echipele de web designeri și programatori din toată țara, cât și clienții vorbitori de limbă română care au proiecte web în desfășurare. Cu alte cuvinte, vrem să ușurăm viața tuturor (și pe a noastră și a clienților noștri!), în ideea că toți ne dorim să lucrăm repede și bine, fără enervări inutile și cu cât mai puține obstacole. Și, pentru asta, vom vorbi despre un subiect rar abordat pe site-urile și blogurile firmelor de web design și development:

Cum oferi feedback?

Ce este feedbackul?

Să începem cu o scurtă definiție, ca să fie clar despre ce vorbim: când este vorba de servicii de web design, feedbackul este reacția Clientului la prestația firmei contractate, în vederea finalizării proiectului.

Feedbackul este de obicei solicitat de către Prestator după finalizarea unei etape bine stabilite sau pe parcursul lucrării în momente-cheie, și are un singur scop: remedierea oricărei probleme înainte de trecerea la etapa următoare.

Așadar, feedbackul are un singur scop: remedierea oricărei probleme – înainte – de trecerea la etapa următoare.

Ce nu este feedbackul?

Feedbackul nu reprezintă o ocazie de a solicita operațiuni noi, neprevăzute în contract. Desigur, pe parcursul oricărui proiect pot apărea idei noi, care sunt binevenite, dar numai după finalizarea lucrării. Este neplăcut pentru ambele părți atunci când Clientul solicită executarea de operațiuni care nu au fost prevăzute în planul de lucru inițial, din mai multe motive:

  • nerespectarea planificării inițiale afectează planificarea pentru timpul alocat dezvoltării proiectului și, implicit, alte proiecte aflate în lucru (nu vrem asta! toți clienții noștri merită să primească lucrările finalizate în timpul stabilit!), iar termenul de livrare este, și el, afectat;
  • apariția unor solicitări noi pune Prestatorul într-o poziție ingrată: pe de o parte, nu vrem să refuzăm o solicitare; pe de alta, nu putem oferi ca bonus decât un timp limitat pentru rezolvarea solicitărilor extra și, fiind vorba despre un proces de lucru, este dificil de cuantificat timpul efectiv petrecut pentru a rezolva cerințe suplimentare contractului. O solicitare extra sau chiar două nu ar fi o problemă, dar experiența ne-a arătat că o solicitare suplimentară onorată ca bonus tinde să atragă după ea multe solicitări suplimentare și așteptarea de a fi onorate ca bonus. Nu vrem astfel de tensiuni între noi și Client, așadar notăm toate solicitările suplimentare și estimăm timpul (și costurile) după finalizarea contractului!

Feedbackul nu reprezintă o ocazie de a relua o etapă anterioară de lucru. Orice reluare a unei etape aprobate anterior reprezintă, de fapt, o solicitare suplimentară. Cel mai adesea, simpla schimbare a locului unui element în pagină poate presupune ore întregi de lucru, și poate afecta secvențe întregi de cod, adesea aflate în fișiere separate, care trebuie identificate și modificate cu atenția încordată la maxim, pentru a evita erorile.

Știați că aproximativ 80% din bug-uri apar la 20% din module (1)? În 15 ani de lucru, am observat că cea mai mare parte din disfuncții apar din cauza modificărilor operate pe etape anterior aprobate.

Feedbackul nu este un prilej să spui: “Nu-mi place, încercați altceva”. Feedbackul presupune interesul pe care Clientul este dator să-l arate propriului proiect și trebuie să aibă un caracter constructiv. Nu este nimic constructiv în a spune “nu-mi place” – acesta este feedbackul copiilor mici în fața lingurii cu ciorbă! Dacă plasezi firmei de web design întreaga răspundere pentru găsirea soluției perfecte, trebuie să renunți la dreptul tău firesc la feedback, ceea ce nu se poate; așadar, trebuie să depui efortul de a arăta celor care muncesc la proiectul tău ce îți place, ce îți dorești, cu exemple, cu desene, cu tot ce te poți gândi – este în primul rând interesul tău ca proiectul să iasă bine!

Feedbackul nu înseamnă să dai refresh site-ului aflat în lucru la fiecare 5 minute și să scrii e-mailuri Prestatorului cu tot ce observi (și, eventual, marcate cu “URGENT”). Un site în lucru este în lucru – până când nu se finalizează o etapă, site-ul aflat în dezvoltare poate arăta inutilizabil, se poate comporta eratic, poate să dispară, cu totul, fiind înlocuit în browser de diverse mesaje text. Este normal.

Feedbackul nu înseamnă să bombardezi Prestatorul cu e-mailuri de genul: “A, am văzut și problema X, vă rog remediați” urmat aproape imediat de  “A, am văzut că problema Y era de la mine, nu luați în seamă mesajul anterior” și, în nici cinci minute, de “Știți, m-am răzgândit. Faceți cum era înainte”. În primul rând, lucrul la un site nu este o joacă, deși viteza cu care lucrăm și faptul că putem rezolva orice solicitare face să pară astfel. În al doilea rând, dacă cel care lucrează primește câte un mesaj la cinci minute și își întrerupe lucrul ca să răspundă, care mai este eficiența lui? Va lucra mai mult, va fi mai obosit și mai neatent, iar programarea cere, pe lângă cunoștințe solide, un singur lucru extrem de important: atenție, 100% orientată pe codul de pe ecran. Dacă vrei să știi cum este o întrerupere dintr-o astfel de activitate, ia din bibliotecă o carte complicată, ceva deosebit de tehnic, poate și în altă limbă decât cea maternă, și roagă pe cineva să te întrerupă din 5 în 5 minute. Frustrat? Da. Acum înmulțește sentimentul de enervare pe care îl trăiești (și pierderea treptată a atenției – trebuie să reiei același paragraf de 20 de ori) cu… 5. Sau 10, depinde de cât de complicat este codul.

Știai că poate dura până la 23 de minute și 15 secunde pentru ca cineva care a fost întrerupt să poată să reia ce făcea exact de unde rămăsese în momentul întreruperii (2)?

*

După ce am făcut lista de “Așa NU”, urmează și lista de “Așa DA”. Urmărește blogul e-studio.ro și săptămâna viitoare.

_____________________

Bibliografie:

(1) Software Defect Reduction Top 10 List, Barry Boehm, University of Southern California / Victor R. Basili, University of Maryland (pdf)

(2) Work interruptions can cost you 6 hours a day. An efficiency expert explains how to avoid them.

Advertisements