În continuarea articolului „Antecedente, consecințe, penalizări și managementul performanței.”.
Unul din cele mai apreciate exerciții la cursurile de Scrum este crearea unui produs aplicând valorile și principiile agile. Pe lângă faptul că ne jucăm cu lego, descoperim empirismul într-un mod simplu și plăcut:
- arta de a da vizibilitate altfel asupra progresului,
- gestiunea simplă a schimbărilor,
- inspectarea și adaptarea.
Printre multe cunoștințe pe care le dobândim în acest mod, participanților le este ciudat să constate că deși toate echipele au avut parte de aceeași sursă de informații, pe mine în calitate de responsabil de produs, rezultatul este mereu diferit.
Exercițiul l-am făcut de zeci de ori. În medie am avut cam cinci echipe în paralel cu câte cinci sau șase persoane în fiecare echipă. Mereu am obținut rezultate diferite.
De ce?
Creierului nostru îi place într-atât de mult să facă noi și noi conexiuni încât va încerca adesea să umple golurile deși nu dispune de toate informațiile. În afară de niște sugestii comunicate simultan către toate echipele nu le spuneam ce mărime trebuie să aibă roțile, ce culori să folosească, ce piese sau ce formă trebuie să aibă produsul final. Mintea fiecărui membru al echipei începe să creeze. Membrii echipei își imaginează produsul finit bazându-se pe cunoștințele existente, sau mai bine zis, bazându-se pe experiențele trăite anterior. Exact din același motiv, atunci când vedem o pisică mergând după gard o vedem întreagă. În acel moment creierul aproximează, completând astfel informația lipsă.
Totodată, creierului îi place să arhiveze informațiile eliminând redundanțele. Din acest motiv nu se poate defini o linie clară între cunoștințele tacite și cele explicite, acestea întrepătrunzându-se mult în procesul de creație. Așa s-a ajuns la conceptul de cunoaștere personală. Michael Polanyi, a fost primul care a asociat acest mod de funcționare al creierului cu cunoașterea tacită.
Cunoștințele tacite nu pot fi codificate pentru a fi transmise ulterior. Cele mai eficiente metode de transmitere a acestora rămân:
- intervievarea,
- ucenicia, practicând alături de un mentor
- observația, constatând și imitând experții
Codificarea și transferul cunoștințelor tacite reprezintă în continuare un subiect de mare interes în lumea științifică.
Ce trebuie să reținem ?
Distanța până la măiestrie o reprezintă tocmai informațiile tacite. Avem mai multe șanse să parcurgem această distanță dând dovadă de perseverență și cu muncă alături de adevărați maeștrii.
Pe proiectele IT, echipa de dezvoltare înțelege rareori funcționalitatea produsului la fel de bine ca responsabilul de produs. Transferul de cunoștințe este vital proiectului. Codificarea cerințelor exclude informații esențiale îndeplinirii obiectivelor responsabilului de produs. Motiv pentru care acesta poate fi nemulțumit. Depășirea unui anumit nivel de detalii în descrierea cerințelor este inutilă. Lipsa implicării active a responsabilului de produs în proiect este un obstacol major în reușita proiectului. Șansele de a avea un proiect de succes cresc considerabil:
- cu cât există mai puțin intermediari între responsabilul de produs și echipa de dezvoltare,
- cu cât există mai multă comunicare între aceștia și
- cu cât responsabilul de produs este implicat mai mult în definirea așteptărilor și inspectarea rezultatului.
Termin acest articol cu o scurtă paranteză față de ultimul punct: cu cât responsabilul de produs este implicat mai mult în definirea așteptărilor și inspectarea rezultatului. Mulți din cei cu care am avut ocazia să discut despre acest subiect îmi spun că este evident. Dacă acest aspect era într-adevăr evident, atunci nu s-ar mai găsi pe proiecte:
- un responsabil cu întreg proiectul, implicit și cu produsul, un șef de proiect.
- o altă persoană care definește produsul, definirea așteptările la nivelul corect de detalii, un analist funcțional (business analyst)
- o altă persoană care inspectează produsul, un tester.
Bunul simț ne spune că cel mai bine ar fi să avem o singură persoană care să se ocupe de toate aspectele de mai sus, dar este suficient să căutăm pe site-urile de job-uri să vedem că rolul de responsabil cu produsul (Product Owner) este aproape inexistent în timp ce ticsește de joburi pentru analiști, șefi de toate culorile și tester-i.
Cum funcționează creierul nostru? Importanța implicării active a responsabilului de produs.
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 2774 ori