În continuarea articolului „Negocierea contractuală și regulile jocului”.
Fie că vrem sau nu vrem, majoritatea proiectelor IT încep înaintea creării echipei. Era extraordinar să avem mereu oameni care să aștepte ideea noului proiect, și împreună cu ei să facem toate pregătirile:
- să creăm o viziune pe baza unor nevoi;
- să creăm obiectivele și o foaie de parcurs;
- să creăm o listă cu cerințele inițiale (ce nevoi va adresa produsul? care sunt caracteristicile cheie?, …);
- să stabilim ipotezele tehnice (ce tehnologie să folosim? ce arhitectură? poate facem și un prototip, …);
- să exprimăm diferitele constrângeri (să meargă în X medii de producție, Y navigatoare, Z conexiuni în paralel, …);
- să evaluăm riscurile (pozitive sau negative, care sunt incertitudinile? …);
- să agreăm cadrul colaborativ (roluri? Scrum? Kanban?, structura ideală a echipei? …);
- să facem o estimare inițială de buget și o primă planificare (cât ne va costa echipa? dar diferite alte resurse? când vom livra? …) ;
- să participăm la negocieri;
- etc.
Până la urmă, asta înseamnă să pornim la drum cu o viziune, cu niște obiective și o cu strategie. Și este bine să avem o strategie. Îmi aduc aminte de un client grăbit care voia doar niște oameni să-i treacă la treabă. Când i-am pus întrebări legate de punctele de mai sus a rămas șocat de cât de nepregătit era. De fapt, întrebarea nu se pune niciodată dacă avem nevoie sau nu de o strategie. Strategia nu este opțională, iar dacă vrem să facem mai mult decât să executăm niște ordine, trebuie s-o cunoaștem și să contribuim la ea.
Ca strategia să fie cât mai utilă, am învățat să fiu atent la câteva aspecte:
- să facem lucrurile la timpul lor,
- să adaptăm strategia în permanență,
- să evaluăm bine cine definește strategia
Să facem lucrurile la timp
Să facem lucrurile la timp (Just-In-Time production, sau JIT) este un concept ce-și găsește originile în sistemul de producție de la Toyota (Toyota Production System), premergătorul sistemului de producție Lean. De exemplu, să încercăm să planificăm cine va lucra pe un anumit task peste trei luni de zile s-ar putea să fie prea devreme, mai ales când nu cunoaștem încă echipa.
Să adaptăm strategia în permanență
Așa cum răspunsurile vin în întâmpinarea întrebărilor, așa și soluțiile vin în întâmpinarea problemelor. În faza incipientă identificăm niște cerințe, iar înaintea pornirii proiectului, pentru realizarea strategiei, ne fixăm niște ipoteze. Însă pe măsură ce învățăm, aceste ipoteze pot fi invalidate. De exemplu, tehnologia este aleasă să adreseze niște nevoi. Dacă aceste nevoi se schimbă, probabil că se va schimba și tehnologia. Am decis să folosim Symfony. S-a modificat mult din perimetrul aplicației și ne dăm seama că ar fi mai bine să utilizăm Magento. Sau, ne-am gândit să trecem la o abordare responsive web design și vom utiliza bootstrap. Un alt exemplu este revizuirea estimărilor. Mai puțin contează de ce viteza de implementare a cerințelor este diferită de cea inițială. Cât timp aceasta este realitatea și noi nu schimbăm nimic, trebuie să ținem cont de ea în prognozele noastre. Echipa care trebuie să ducă la bun sfârșit implementarea strategiei trebuie să fie împuternicită s-o poată adapta de câte ori este nevoie.
Câteodată putem crede că dacă avem o strategie urmează doar s-o asamblăm ca într-un joc de lego și să lansăm proiectul. Este doar o iluzie. Echipa nou creată, are și ea nevoile ei de pregătire și va rafina strategia:
- pregătirea mediului de dezvoltare – echipa trebuie să-și (re)seteze mediul de lucru pentru noul proiect,
- formarea echipei – oamenii vor fi aduși la un minim de cunoștințe cât mai devreme,
- asimilarea strategiei – toate ipotezele sunt înțelese și agreate cu echipa, ceea ce implică și revizuirea strategiei.
- etc.
Aceste activități sunt regrupate de obicei în etapa de lansare a proiectului (sprint 0).
Să evaluăm bine cine definește strategia
Cu cât participă mai mulți oameni din echipa de realizare la definirea strategiei, cu atât mai bine. Cert este că s-ar putea să nu fi ales cele mai bune persoane în acest proces dacă nu-i mai regăsim nicăieri în foaia de parcurs a proiectului. O altă greșeală des întâlnită este ca persoanele cheie (responsabilul de produs, Scrum Master-ul, etc.) să nu facă parte din acest proces, ceea ce ar putea duce la o cu totul altă strategie în momentul introducerii lor pe proiect sau la lipsa asimilării strategiei.
Importanța strategiei
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 2696 ori