Surprizele din proiectele web sunt aproape întotdeauna scumpe și aproape întotdeauna evitabile. O funcționalitate care durează mult mai mult decât s-a estimat. O dependență pe care nimeni nu a observat-o până în săptămâna a șasea. Un stakeholder care vede site-ul pentru prima dată la lansare și cere modificări de fond. Niciuna dintre ele nu se întâmplă pentru că munca ar fi imposibilă. Se întâmplă pentru că proiectul nu a fost structurat astfel încât să le scoată la iveală devreme.
În anii în care am condus proiecte Drupal, unele mici, altele întinse pe mai mulți ani, altele operațiuni de salvare, am ajuns la un model de livrare care reduce surprizele la minimum. Nu e complicat. Cere doar disciplina de a pune întrebările incomode la început, în loc să dăm explicații la final. Scopul e simplu: să luăm deciziile mici mai devreme, cât timp încă e ieftin să le schimbăm.
Faza zero: aliniere înainte să înceapă munca
Înainte de orice dezvoltare, ne luăm o săptămână sau două pentru ceea ce numim faza zero. Nu e o fază de descoperire, în care explorăm posibilități fără capăt. E o fază de aliniere, în care punem pe masă câteva întrebări precise și le răspundem cu voce tare.
Prima parte e despre ce vrei să obții: rezultate de business, audiențe, constrângeri, termene pe care nu le poți muta și oamenii a căror aprobare contează. A doua parte e despre ce există deja: site-ul actual, echipa editorială, integrările, datoria tehnică și istoricul proiectelor web anterioare.
Două lucruri fac ca faza asta să fie concretă, nu abstractă:
- Stabilim împreună o singură persoană din partea ta care poate aproba designul, modelele de conținut și specificațiile în cel mult câteva zile. Aprobările lente lungesc calendarul, așa că o identificăm de la început și convenim în cât timp ne putem aștepta la un răspuns.
- Scriem negru pe alb ce înseamnă "gata": un set de criterii de acceptanță testabile, nu o specificație stufoasă. "Un editor fără pregătire tehnică poate crea, edita și publica o pagină simplă în câteva minute" e testabil. "CMS-ul ar trebui să fie ușor de folosit" nu e.
Din aceste discuții iese un document scurt de specificații, de obicei patru sau cinci pagini, niciodată un roman, care consemnează ce am convenit, ce rămâne explicit în afara proiectului și presupunerile pe care se sprijină calendarul. Îl vezi înainte să semnezi ceva. Dacă ceva din el e greșit, îl rescriem. Nimic nu intră în contract fără să fi fost discutat deschis.
Prima versiune funcțională ajunge live devreme
Nu credem în marea dezvăluire. Fiecare proiect al nostru ajunge în primele săptămâni pe un URL de staging protejat cu parolă, cu conținut real, navigare reală și cel puțin câteva pagini reale care funcționează de la cap la coadă. Arată neșlefuit. Așa și trebuie. Singurul lui rol e să vă pună în față, ție, echipei tale și stakeholderilor, ceva concret la care să reacționați, într-un stadiu în care reacția e încă ieftină.
Deciziile care ies din această primă reacție sunt de obicei cele care salvează proiectul. "De fapt, pagina principală ar trebui să facă altceva." "Editorii noștri se vor chinui cu structura asta." "Am uitat să spunem că avem nevoie de conținutul ăsta și în germană." Toate se rezolvă ușor la început și dureros spre final.
Un ritm de două săptămâni și o singură întâlnire fixă
De aici încolo, proiectul merge într-un ritm de două săptămâni. Fiecare ciclu are specificații clare, convenite la început, un demo la final și o scurtă trecere în revistă a ce s-ar putea îmbunătăți. O vineri din două, la finalul zilei, îți arătăm ce am construit, parcurgem ce a rămas deschis și stabilim ce facem în următoarele două săptămâni.
E singura întâlnire fixă din procesul nostru de livrare. Fără standup zilnic la care să participi. Fără rapoarte de stare pe care nu le citește nimeni. O oră la obiect, o dată la două săptămâni, cu ecrane reale pe care dai clic și decizii reale de luat. Principiul din spate e că fiecare ciclu produce ceva ce poți vedea și folosi, nu wireframe-uri sau diagrame de arhitectură, ci software funcțional. În primul ciclu, asta poate fi un site de bază cu tipuri de conținut și conținut de probă. Până la al treilea ciclu, arată deja ca un site adevărat.
Între aceste întâlniri, ai mereu acces la site-ul de staging. Îl poți arăta oricui din organizația ta, autori de conținut, marketing, juridic, consiliul de administrație, și poți strânge feedback în ritmul tău. Preferăm feedbackul scris, într-un singur loc, pentru că de obicei e mai precis decât ce rămâne după un apel telefonic, dar le acceptăm pe amândouă.
O supapă de siguranță pentru specificații
În orice proiect apare, la un moment dat, presiunea de a lărgi specificațiile. Vezi site-ul prinzând contur și te gândești la funcționalități în plus. Un stakeholder care nu a fost implicat la început vine cu cerințe noi. Prioritățile se schimbă. E normal și nu trebuie să dea calendarul peste cap.
Regula noastră e simplă: se poate adăuga orice, dar ca să-i facem loc, ceva de mărime asemănătoare iese sau coboară într-un backlog prioritizat. Fiecare cerere nouă ajunge în acel backlog. La începutul fiecărui ciclu luăm în lucru elementele cu prioritatea cea mai mare care încap. Cele cu prioritate mai mică așteaptă.
Regula nu e bătută în cuie. Dacă o cerință nouă e cu adevărat critică, urcă în capul listei. Dar simplul fapt că prioritizăm scoate compromisul la vedere. "E mai important decât funcția de căutare planificată pentru ciclul următor?" e o întrebare care ține specificațiile în frâu fără ca cineva să trebuiască să le păzească.
Lansarea e o listă de verificare, nu un eveniment
O lansare cu emoții e o lansare care nu a fost pregătită destul. Când ajungem să apăsăm butonul, site-ul nou rulează de ceva vreme pe infrastructura de producție, fiecare URL important a fost verificat, fiecare integrare a fost testată de la cap la coadă, iar un plan de revenire deja exersat stă într-un document partajat. Trecerea efectivă pe live e o fereastră scurtă, undeva între un sfert de oră și două ore, în funcție de complexitate, și e plictisitoare cu bună știință.
Ziua de după lansare nu e "predarea". E prima zi de suport, cu aceiași oameni, aceleași instrumente și aceeași claritate ca în timpul dezvoltării. Numărul de telefon nu se schimbă.
Primele săptămâni după lansare fac parte din proiect
Planificăm primele săptămâni de după lansare ca parte din proiect, nu ca pe o anexă adăugată la final. Asta înseamnă să urmărim cum se comportă site-ul sub trafic real, să rezolvăm problemele care apar doar cu utilizatori reali, să-i familiarizăm pe editori cu fluxurile pe care nu le-au folosit încă și să facem ajustări mici pe baza datelor reale de utilizare.
Proiectele care se termină în ziua lansării te lasă singur exact în momentul în care ai cea mai mare nevoie de sprijin. Când primele săptămâni rămân parte din proiect, rezultatele ies de regulă mai bune, iar colaborările durează mai mult.
De ce funcționează
Nimic din toate astea nu e revoluționar. E doar aplicarea disciplinată a câtorva principii de bază din managementul de proiect: rezultate clar definite, progres la vedere, decizii luate din timp, specificații ținute explicit sub control și o echipă care rămâne lângă tine la lansare și în săptămânile de după.
Proiectele care eșuează sunt rareori cele cu probleme tehnice grele. Sunt cele în care cineva a plecat de la o presupunere falsă și nimeni nu a aflat până când reparația a devenit scumpă. Modelul ăsta de livrare există tocmai ca să scoată presupunerile la iveală cât mai devreme și să le transforme în decizii cât încă sunt ieftine. Restul proiectului îl putem dedica lucrului bine făcut.
Dacă ai un proiect în minte și te-ai săturat de surprize, spune-ne cum arată în linii mari. Îți spunem cum ar arăta primele săptămâni, iar de acolo decizi tu.