Teoria spune că 90% din munca unui manager de proiect este comunicare. Ceea ce este cu adevărat important este faptul că pentru un manager de proiect comunicarea se află peste tot în jurul lui. Ceea ce nu remarcăm noi întotdeauna este că cizelarea abilităților noastre de comunicare începe mult mai devreme și este parte integrantă a mediului nostru de lucru și a vieții noastre mai mult decât ne dăm seama în mod conștient. Dacă ne referim strict la locul de muncă, comunicarea se desfășoară în toate direcțiile și are loc între persoane cu diferite abilități de comunicare și cu diferite specializări cum ar fi: developer-i, testeri, administratori, persoanele de pe resurse umane. Dintre toate aceste posibile conexiuni cred că cel mai sensibil canal de comunicare este cel cu clientul și asupra acestuia mi-am propus să mă focalizez în acest articol.
În contextul actual al dezvoltării de software, când trendul este dat de metodologiile Agile, întreaga echipă este expusă interacțiunii cu clientul. Acest fapt deschide un canal de comunicare destul de complex între oamenii ce au un background tehnic și oamenii orientați înspre afaceri. Dacă pentru un manager de proiect stăpânirea acestui canal de comunicare este obligatorie și face parte din munca de zi cu zi, oamenii orientați spre tehnic ar putea întâmpina dificultăți în construirea acestei punți ce tranzitează limbajul tehnic spre limbajul cotidian. Când este important să livrăm un mesaj, trebuie să avem în vedere, printre altele, două aspecte foarte importante:
Valoarea conținutului: în primul rând, dacă vrem să demonstrăm ceva, dacă vrem să ne facem înțeleși, trebuie să scoatem în evidență foarte clar valoarea adusă de ideea noastră. În consecință, primul aspect important este să putem explica valoarea conținutului.
Valoarea conținutului nu numai că este un lucru dificil de explicat, dar în același timp trebuie procedat total diferit în funcție de publicul vizat. Pentru a ne alege strategia corect trebuie să înțelegem exact ce este important, ce anume aduce valoare celorlalte părți participante la discuție. Pentru persoanele tehnice valoarea este dată de expresii la modă cum ar fi extensibilitate, tehnologie de ultimă oră, ultimele framework-uri. Pentru clienți cea mai importantă valoare este dată de rata de recuperare a investiției. Într-o traducere liberă ar fi “Cum îmi vor aduce aceste tehnologii de vârf din care nu înțeleg o iotă mai mulți clienți, mai mulți bani?“. Pentru echipa de la resurse umane valoarea se traduce în fericirea oamenilor și păstrarea lor în firmă. Pentru a putea exemplifica acest lucru mai bine să încercăm să ne jucăm cu o posibilă situație.
Să presupunem că o echipă vrea să aducă unul dintre framework-urile externe folosite pe proiectul curent la ultima versiune. Bineînțeles că va trebui făcut un studiu, s-ar putea să fie nevoie chiar de un prototip și în final vor rezulta tone de argumente care mai de care mai valide ce vor susține această necesitate. Totuși beneficiile acestei schimbări vor fi explicate total diferit celor implicați (sau doar interesați) în această schimbare. Echipa de implementare va discuta despre faptul că noua versiune va permite o mai ușoară integrare cu modulul de securitate; va discuta despre ușurința cu care noul framework poate fi personalizat în funcție de nevoile curente și va discuta despre suportul pe care noul framework îl oferă în mod nativ pentru scrierea unit testelor, suport inexistent în versiunea ce se vrea a fi înlocuită. În schimb când echipa va merge în fața clientului lucrurile se complică. Ei trebuie să știe cât timp va lua schimbarea și câți dintre membrii echipei vor fi implicați, iar această combinație va da costul operațiunii. Odată puse cărțile pe masă, echipa are nenumărate variante pentru a motiva beneficiile pe care schimbareai. Unit testele vor asigura o stabilitate mai mare a aplicației, deci vor reduce costurile de întreținere. În același timp cu noua versiune de framework implementarea noilor funcționalități este mult mai rapidă astfel încât după câteva iterații timpul investit în upgrade va fi amortizat. Echipa nu va avea întotdeauna câștig de cauză, dar înțelegând ce aduce valoare clientului cu siguranță va avea mai multe șanse de reușită. și după multe discuții între membrii echipei, între echipă și client, într-o pauză de țigară, cineva de la resurse umane se va apropia conspirativ de managerul de proiect și va întreba: “Am auzit că v-ați încins la discuții nu glumă … e totul în regulă?”; ”Da, vrem doar să aducem un framework la ultima versiune și să convingem clientul că a fost o treabă destul de dureroasă”; ”Dar de ce vreți schimbarea asta?”; ”Pentru că-i ține pe oameni în priză și motivați”. Trei grupuri țintă diferite, trei moduri diferite de a motiva același lucru: banala schimbare a versiunii unui framework.
Conținutul s-ar putea să fie și mai greu de explicat. S-ar putea să avem nevoie de și mai multe abilități pentru a putea face acest lucru așa cum ne dorim. De obicei bariera de limbaj se instalează între persoanele tehnice și cele non tehnice. Am participat în suficiente discuții care ar fi trebuit să dureze zece minute și s-au întins mult peste o oră. În timpul acestor discuții de multe ori microfoanele au fost oprite (când aveau loc între locații diferite) pentru ca acei implicați sa se liniștească. Am fost și în câteva discuții în care una dintre părți doar a avut impresia ca microfoanele au fost oprite în timp ce se descărca și nu a ieșit prea bine. Ceea ce ar ajuta ca aceste discuții sa fie mai relaxate ar fi ca lumea să fie conștientă de specializarea fiecărei părți implicate în discuție și să fie concentrată și pe acest lucru. Odată ce conștientizăm acest lucru putem să ne adaptăm argumentele astfel încât să fie înțelese rapid și corect de ceilalți implicați. Ce credeți că este mai ușor? Pentru o persoană non tehnică să găsească argumente tehnice sau invers? Am văzut persoane non tehnice care cu bune intenții au folosite cuvinte cheie pentru a se integra într-o anume discuție. Sunt situații foarte haioase. Poți depista când cineva nu știe exact ce spune de la un kilometru. E ca și cum aș încerca eu să povestesc cu cineva de la contabilitate despre salariul brut și salariul net. Cred cu convingere că cel mai ușor e pentru o persoană tehnică să găsească exemple care să aibă legătură cu viața de zi cu zi. Ceva ce toată lumea înțelege, ceva la care se pot raporta cu toții. Pentru că discuțiile cu clienții sunt aproape întotdeauna mici vânzări , trebuie să ne alegem cuvintele și analogiile cu mare grijă. Haideți să încercăm iar un mic joc imaginativ.Să ne imaginăm că trebuie să explicăm avantajele testării continue de-a lungul unei iterații cuiva care nu știe nimic despre Agile și Scrum. Vom începem să povestim despre integrarea rapidă a testării și a fixării erorilor în procesul de dezvoltare, vom continua să povestim despre reducerea numărului de erori și vom termina prin a povesti despre o aplicație mai stabilă la sfârșitul fiecărui sprint. Clientul va asculta cu interes, va sorbi fiecare explicație mai mult decât validă a cum se va desfășura procesul și în același timp în mintea lui va avea loc următorul monolog: “Sprint … sprint … unde am auzit eu de sprinturi? … Usain Bolt e super tare la sprinturi ...“. Va zâmbi la propria-i glumă și noi vom pleca cu convingerea că l-am făcut să ne mănânce din palmă. Peste două zile vom avea aceeași discuție. O altă abordare ar fi să facem o analogie cu gătitul. Nu spun asta doar pentru că sunt gurmand. Toată lumea știe, mai mult sau mai puțin, cum se pregătește mâncarea. Să comparăm planificarea unei noi versiuni cu un plan de gătit pe șapte zile. Fiecare zi va fi o iterație și în fiecare zi va trebui să facem ceva diferit de mâncare. Testarea și fixarea erorilor o vom asemăna cu spălatul vaselor. Dacă nu spălăm vasele în fiecare zi, bucătăria s-ar putea să fie plină de vase murdare încă din ziua a cincea. Iar la sfârșitul zilei a șaptea când ne vom apuca de spălat vasele, vom ajunge cu siguranță în ziua a opta. Astfel, deși am terminat de gătit după șapte zile, am lăsat bucătăria curată de-abia în ziua a opta și ne-am ratat termenul limită deoarece la sfârșitul celor șapte zile, munca noastră era plină de mizerie. Dacă în schimb de fiecare dată când așteptăm după ceva, cum ar fi să dospească un aluat sau să se coacă ceva în cuptor, spălăm vasele folosite până în acel moment, la sfârșitul fiecărei zile vom avea bucătăria curată, mâncarea făcută și planul nostru va evolua impecabil. Iar scopul nostru după cele șapte zile va fi atins cu succes. Bineînțeles că mâncarea din prima zi va fi aproape expirată și vom vrea să o refacem, mai ales că între timp am și primit un cuptor mai performant, dar asta-i cu totul altă poveste.
Exemplul anterior a fost unul simplu, dar în munca de zi cu zi ne întâlnim cu siguranță cu situații mult mai complicate. Gândiți-vă cum ați explica unui client non tehnic ce înseamnă un load balancer sau ce înseamnă un index compus pe o tabelă din baza de date. Acuma îmi vine în minte un exemplu amuzant din experiența proprie: cu câteva săptămâni în urmă, una dintre echipele cu care lucrez se delecta cu un release. Am întrebat dacă sunt probleme și răspunsul scurt, concis și profesionist a fost: sunt probleme cu generarea unui bundle. Vreme de două secunde am stat și m-am uitat la ei cu un aer ca și cum le-aș înțelege perfect durerea, după care mi-am călcat pe mândrie și am întrebat ce-i ăla. Din nou un răspuns scurt și la obiect cu niște termeni pe care nu i-am putut ține minte. Deși cândva în vremuri de glorie demult apuse am fost o persoană tehnică (pe vremea când pointer-ul era cea mai tare chestie inventată după roată) în momentul de față am cam pierdut trenul și mi-a fost destul de greu să prind explicațiile. Gândiți-vă cam ce simte o persoană care chiar n-are nici o treabă cu programarea când aude acești termeni. În cazul meu, unul dintre colegi a realizat că încă aștept explicații și mai în glumă, mai în serios a început sa-mi explice ca și unui copil mic: ,,Știi , Bogdan, fișierele acestea sunt toate puse la un loc într-unul singur. Apoi, un mic vrăjitor din calculator (unul bun, nu unul rău) face fișierul acela mic de tot astfel încât să ajungă mai repede unde e nevoie de el”. Așadar, câteodată este nevoie ca un om tehnic să explice ceea ce face ca și cum s-ar adresa unui copil.
Știm că este în natura noastră, în codul nostru genetic, să acționăm întotdeauna în acele circumstanțe în care ne simțim confortabili. Dacă toată ziua ne învârtim într-un anturaj ce vorbește aceeași limbă ca și noi și povestim fără restricții, ne va fi foarte greu să ne schimbăm modul de a ne pregăti argumentele în acea jumătate de oră pe zi în care povestim cu clientul. Acest lucru vine de obicei cu experiența, cu multă muncă dar și cu o mentalitate adecvată. E important de menționat că din cauza evoluției în domeniu, din cauza metodologiilor Agile care încurajează interacțiunea continuă între oamenii tehnici și client (mai ales în lumea outsourcing-ului, a exportului de servicii) este de dorit să fim măcar conștienți de acest mod de a gândi. Contextul în care ne manifestăm, în care au loc discuțiile ne obligă la utilizarea unui anumit tip de limbaj. Dar o dată ce știm să jonglăm cu cuvintele, cu situațiile, jocul devine mult mai ușor de jucat, mai apetisant și chiar mai distractiv.
de Ovidiu Mățan
de Mircea Vădan
