După ani de lucru cu clienți de la mici afaceri locale până la organizații naționale, am învățat să distingem între ce cere un brief și ce face de fapt un proiect să reușească. Cele două coincid rareori, și asta nu e vina nimănui. Cei care scriu brief-ul nu sunt, de obicei, cei care vor lucra zi de zi cu rezultatul. Clienții sunt experți în propria lor afacere. Noi suntem experți în Drupal. Cea mai utilă parte din munca noastră se petrece în spațiul dintre cele două.
Iată ce căutăm dincolo de un brief și ce încercăm să oferim fiecărui client, fie că a cerut-o explicit, fie că nu.
Discuția sinceră de la început
Majoritatea cererilor de proiect vin cu specificații: o listă de funcționalități, un sitemap, un site de referință, uneori un wireframe. Toate sunt utile, dar nouă ne place să începem cu un pas mai devreme, cu o întrebare simplă. De ce facem asta, de fapt, și cum o să știm că a mers?
Prima discuție, de obicei o oră sau două, o dedicăm rezultatelor, nu tehnologiei. Cum arată succesul peste douăsprezece luni? A cui muncă devine mai ușoară în ziua lansării? A cui devine mai grea dacă lansarea întârzie? Răspunsurile schimbă de multe ori forma proiectului cum n-ar face-o niciodată o listă de funcționalități, și ne țin onești în privința locului unde ar trebui să se ducă bugetul.
Cererea de redesign
Cea mai frecventă cerere pe care o primim e o variantă de "avem nevoie de un redesign". De cele mai multe ori, când ne uităm îndeaproape, problema reală e alta, mai concretă. Site-ul e lent, editorii nu pot actualiza conținutul fără un dezvoltator, pe telefon e greu de folosit sau nu apare bine în căutări.
Problemele astea nu cer neapărat un redesign. Cer optimizări de performanță, o modelare mai bună a conținutului, ajustări responsive sau SEO tehnic. Un redesign le-ar putea rezolva pe parcurs, dar de obicei e cel mai scump și mai deranjant drum până acolo. Așa că ne place să punem o întrebare simplă. Dacă site-ul tău actual ar arăta exact la fel, dar s-ar încărca rapid, echipa ta l-ar putea actualiza fără ajutor și ar apărea bine în căutări, ai mai vrea un redesign? Răspunsul e adesea nu. Nu vrem să convingem pe nimeni să renunțe la un proiect. Vrem ca bugetul să se ducă pe ce te ține de fapt pe loc.
Estimări oneste, în scris
Estimările le facem pe baza propriului istoric de proiecte comparabile, rotunjite în sus pentru riscurile pe care le vedem și pentru cele pe care nu le vedem, și scriem ipotezele lângă cifră. Dacă ceva se schimbă pe parcursul proiectului, îți spunem pe loc, în aceeași discuție, cu opțiunile pe masă. Nu există niciun contor ascuns și nicio surpriză cu orele în săptămâna a cincea.
Tot ce avea oricum nevoie proiectul e în ofertă de la bun început, așa că cifra pe care o aprobi e cifra pe care poți să îți faci planurile.
Problema listei de funcționalități
Clienții vin adesea cu o listă de funcționalități pe care și le-ar dori. O secțiune de știri, un calendar de evenimente, un portal pentru clienți, un newsletter, suport multilingv. Adună-le pe toate și poate ieși un proiect de șase luni cu un buget de trei.
Treaba noastră e să înțelegem ce obiectiv de business stă în spatele fiecărui punct și să propunem cea mai simplă soluție care îl atinge. Uneori calendarul de evenimente înseamnă de fapt două evenimente pe an, și un tip de conținut cu un câmp de dată face treaba unui sistem întreg de calendar. Uneori integrarea cu newsletter-ul e un formular de înscriere, nu un modul făcut la comandă. Disciplina specificațiilor e unul dintre cele mai valoroase lucruri pe care le aducem într-un proiect. Lăsate de capul lor, listele de funcționalități cresc până când proiectul nu mai încape nici în termen, nici în buget. Fiecare funcționalitate pe care o ținem în afara specificațiilor înseamnă timp și bani care rămân la tine.
Un om cu nume și prenume, nu o coadă de tichete
Fiecare client de-al nostru are un nume și un număr de telefon la care ne găsește. Un om care știe proiectul, știe site-ul și îți răspunde în aceeași zi când contează. Nu o adresă de e-mail generică, nu o coadă care trece prin triaj. Am rămas dinadins destul de mici ca să putem lucra așa, și așa vrem să rămânem. Dacă lucrezi cu noi, știi mereu cine are grijă de site-ul tău.
Comunicarea contează mai mult decât livrabilele
Proiectele care merg bine nu sunt neapărat cele cu execuția tehnică cea mai șlefuită. Sunt cele cu comunicarea cea mai clară. Un client care primește regulat vești oneste despre progres, blocaje reale și termene realiste stă liniștit chiar și într-o săptămână grea. Tăcerea urmată de un demo pe lângă subiect face exact opusul, oricât de bună ar fi munca din spate.
Așa că fiecare colaborare e construită în jurul unor întâlniri regulate, nu al unei singure prezentări la final. Un ritm obișnuit: o informare scrisă scurtă în fiecare săptămână, un demo la câteva săptămâni și o revizuire o dată pe lună. Informările scrise îți respectă timpul, demo-urile ne țin pe toți cu aceleași așteptări, iar revizuirea lunară verifică dacă proiectul încă rezolvă problema potrivită.
Promisiunea tăcută: site-ul tău merge mai departe și când nu vorbim
Cel mai bun feedback pe care îl primim nu e "proiect grozav" sau "echipă faină". E tăcerea. Trec luni fără să se întâmple nimic, pentru că nu e nevoie să se întâmple nimic. Actualizările de securitate ajung înainte să citești despre ele. Backup-urile sunt verificate înainte să îți aduci aminte că există. Performanța rămâne unde era în ziua lansării, sau mai bună.
Asta e partea din relație pe care e ușor să uiți s-o pui în buget. E firesc să planifici dezvoltarea și să presupui că după aceea site-ul se descurcă singur. Nu se descurcă. Drupal lansează actualizări de securitate cu regularitate, modulele contribuite se actualizează și mai des, iar versiunile de PHP ajung, una după alta, să nu mai fie susținute, indiferent dacă se uită cineva sau nu. Lăsat fără mentenanță, un site nu se strică la o dată fixă, dar în timp ajunge pe o versiune de PHP care nu mai e susținută, adună vulnerabilități și alunecă spre o reconstrucție completă care costă mult mai mult decât ar fi costat întreținerea. Preferăm să avem discuția asta devreme, ideal înainte să înceapă proiectul, decât să vină ca o surpriză mai târziu. E o muncă făcută să fie invizibilă, și tocmai ea face ca prelungirea colaborării cu noi să vină de la sine, nu din negocieri.
Respect pentru oamenii din echipa ta
Editorii, autorii, traducătorii și managerii de conținut din echipa ta sunt oamenii care vor folosi site-ul în fiecare zi după ce noi plecăm. Timpul lor e pentru noi cea mai scumpă resursă din proiect, pentru că, pe parcursul câtorva ani, chiar asta e. Așa că gândim interfața de administrare după felul în care lucrează ei de fapt, îi instruim ca lumea, înregistrăm clipuri scurte pentru fluxurile greu de explicat în scris și le lăsăm un ghid de o pagină pentru ziua de după lansare. Dacă ajung vreodată să predea site-ul unui coleg nou, predarea ar trebui să dureze o oră, nu o săptămână.
Adevăratul livrabil
La sfârșitul unui proiect, ce contează pentru un client e rareori versiunea de Drupal, arhitectura modulelor sau fluxul de lansare. Contează trei lucruri. Poate echipa mea să îl folosească fără ajutor, e rapid și de încredere și putem să îl dezvoltăm mai departe?
Tot ce facem, modelarea conținutului, optimizarea performanței, codul curat, documentația, instruirea, duce spre aceste trei rezultate. Dacă le ții în față, construiești instrumente care fac o organizație mai bună la ce face ea. Dacă le pierzi din vedere, construiești ceva impresionant tehnic pe care nu îl folosește nimeni.
Dacă asta cauți
Organizațiile cu care lucrăm cel mai bine sunt cele care vor un partener pe termen lung, nu o tranzacție punctuală, și cărora le pasă la fel de mult de anii de după lansare ca de lansarea în sine. Dacă asta cauți, stăm de vorbă cu plăcere. Prima discuție e din partea noastră, așa a fost mereu și așa va rămâne.