Vizibilitate tuturor!

Sunt adeptul suprimării formelor fără fond cu precădere prin educație, viziune comună, focalizarea energiilor, obiectivism și foarte multă răbdare.

Negocierea contractuală și regulile jocului


În continuarea articolului „Negocierile cu echipa de dezvoltare”.

Dacă tot suntem la capitolul negociere, cred că merită să zic câteva vorbe și despre negocierea contractuală. În 2009 eram foarte preocupat de acest subiect. Nu înțelegeam cum poți să vinzi un proiect agil cu preț fix. Am văzut tot felul de variațiuni pe aceeași temă. La un moment dat, mi-am dat seama că mai puțin contează tipul contractului, cât timp toate părțile înțeleg și acceptă regulile jocului.


– Vreau să împărțim proiectul în loturi forfetare. Noi pregătim specificațiile lotului, voi faceți estimarea și creăm pentru fiecare lot un contract nou. Asta înseamnă că fiecare lot va avea specificații, buget și durată fixe.
– Bun! zic eu, știind că am mai auzit premize de proiect asemănătoare. Acum, înainte să ajungeți într-o discuție cu responsabilul de vânzări, pentru că nu cu mine veți face negocierea contractuală, trebuie să vă explic beneficiile și dezavantajele voastre într-o astfel de colaborare. Să începem cu câteva beneficii. Din câte știu, aprobarea bugetului se face mult mai ușor când veți prezenta un angajament contractual, care implică bineînțeles, și penalizările de rigoare. Iar un astfel de contract va fi cu mult mai ușor de înțeles de un jurist.

– Da. Și eu caut un furnizor care să-și respecte angajamentele, nu să-și schimbe estimarea la fiecare pas, fără să țină cont și de constrângerile mele.

– Revin la acest punct imediat. Să spunem și câteva dezavantaje:

  • Un astfel de contract nu necesită doar devotament din partea echipei de dezvoltare, ci și niște angajamente din partea companiei. Ceea ce se va traduce prin riscuri. Riscurile le veți regăsi în tarife mai mari.
  • Agilitatea trebuie să vină din ambele părți. Pentru fiecare schimbare, fie ea cât de mică, va avea loc o nouă negociere. Să fii agil, înseamnă în primul rând să poți răspunde rapid unor astfel de schimbări, fără ca schimbările să ne facă rău (nouă sau vouă). Noi nu putem să acceptăm schimbări, mai ales când știm că urmează niște penalizări.
  • Și acum urmează, din punctul meu de vedere, cel mai mare dezavantaj dintre toate. Ca orice echipă, și a noastră va învăța alături de voi. Va face greșeli și-și va da seama c-ar putea să prevină diferite probleme pe viitor. Dar nu va face acest lucru fiind descurajată de constrângerile contractuale. De multe ori aceste oportunități de îmbunătățire nici nu vor mai fi exprimate. Pentru că echipa va fi cea mai afectată de ceea ce veți pune în contract. Toată presiunea se va răsfrânge indiscutabil asupra lor.

– Și cum pot eu să mă protejez de un furnizor neserios? Înțeleg că veți face tot posibilul, dar compania mea va pierde dacă lucrurile nu merg bine.

– Iar noi vom rămâne fără un client, cu oameni neproductivi o perioadă de timp. Cred că vom fi și noi afectați. Eu vă explic doar regulile jocului. Mai departe, cereți ce vreți de la responsabilul de vânzări. Să revenim la constrângerile voastre. Aveți un caiet de sarcini. Noi am împărțit primul lot într-o listă de cerințe pe care ați agreat-o. Corect?

– Da.

– Să luăm una dintre ele – cerința am inventat-o pentru articol – „Adăugare produs”.

– Așa…

– Un produs are trei câmpuri: cod, denumire și etichetă, ceea ce ar necesita un efort de programare, testare, livrare, etc. Dar, ca să ne fie mai simplu, să ne referim doar la testare. Până aici mă urmăriți?

– Da.

– Cum ați testa această funcționalitate?

– Ca administrator, intru în aplicație (login), merg la meniul „produse”, click pe „adaugă produs nou”, introduc un produs și apăs „salvează”. Undeva în interfață îmi arată o confirmare, urmând să merg în lista de produse să văd dacă mi l-a adăugat.

– Cât de des ați face acest test?

– Nu știu. Probabil că voi adăuga vreo 3 produse.

– Bun. Acum, în timpul testelor, vă dați seama că produsul trebuie să fie unic.

– Bineînțeles că produsul trebuie să fie unic!

– Corect! și râd. Dar ce ați face în plus când ați testa?

– Păi, mai intru încă o dată, adaug același produs și mă aștept la o atenționare din partea sistemului.

– Credeți că ar putea fi util să putem adăuga deja din acest moment poza produsului?

– De ce nu?!

– Și iar s-ar schimba efortul?

– Da.

– Suntem de acord că cu cât adăugăm mai multe condiții, efortul va crește?

– Da.

– De fiecare dată există măcar o condiție uitată undeva, care poate fi un detaliu. Din păcate, cel mai des se uită lucruri importante.

– Bine că mi-ați spus. Voi atenționa analiștii noștri să pună toate detaliile în specificații.

– Am mai auzit asta, dar n-a funcționat niciodată. Vă pot vorbi despre un exercițiu pe care-l fac în cursuri despre agilitate, exercițiu pe care l-am derulat cu zeci de echipe. Eu sunt clientul și vreau să creez un produs. Eu sunt singura persoană care definește cerințele. Dacă o echipă îmi pune o întrebare mă asigur că mesajul este auzit de toți. Cu toate acestea, de fiecare dată iese un produs diferit. Chiar și pentru echipele care au lucrat concomitent. Am avut și șase echipe în paralel și niciun produs nu semăna cu celălalt. De unde credeți că vine diferența?

sursa https://www.slideshare.net/CornelFATULESCU/pm-days-sofia-14-november-2014?qid=38f82164-b92a-4e9f-929b-09558bb1a714&v=&b=&from_search=4

– Nu știu.

– Așa funcționează creierul nostru, aproximează. Așa cum vedem pisica după gard și ni se pare că o vedem întreagă, așa și programatorul va aproxima informația primită de la voi și-și va imagina ceva diferit față de ce-și imaginează analiștii voștri. Mai adăugăm și un grad de informație tacită rareori capturată în specificații și începem să înțelegem o parte din nevoia de inspecție și de adaptare frecvente, deci de schimbare.

Au trecut câțiva ani de când nu am mai vândut unui client echipe cu specificații, buget și durată fixe. Doi din trei clienți acceptă un contract agil în urma unei astfel de discuții, iar o treime încearcă niște variațiuni precum SLA cu bonus-malus. Scopul meu nu este vreodată să nu se facă astfel de proiecte, ci să înțeleagă toate părțile regulile jocului. Să le conștientizăm și să le adaptăm astfel încât să trecem de la un contract pierzător-pierzător la unul câștigător-câștigător.

Negocierea_contractuală_și_regulile_jocului

Citește în continuare…

Negocierea contractuală și regulile jocului 

Cornel FătulescuDacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți ca voluntar pe pagina membrilor AgileHub, asociație în care sunt cofondator, ca mentor la ScriuCod, ca CTO la Pentalog sau să citiți unul dintre primele articole despre mine și să mă contactați la pagina de contact.

Acest articol a fost citit de 1205 ori