Postari cu eticheta: client

Clientul nu e inamicul tau

Spuneam intr-unul din articolele anterioare ca – in IT si nu numai – clarificarea cerintelor clientului este o parte importanta a procesului de PM.
De multe ori (de cele mai multe ori, din pacate) materialul primit de la clienti se rezuma la cateva fraze aruncate intr-un document.

PM-ul va trebui sa faca analiza ideii de business a clientului, s-o dezvolte si s-o clarifice suficient de mult incat rezultatul sa permita emiterea unor specificatii extinse si a unei estimari cat mai exacte.

Ideal ar fi ca – cel putin in cazul proiectelor web – la finalul sesiunii de clarificare a specificatiilor sa ai si un wireframe, care va fi de un real ajutor atat echipei de design cat si programatorilor care se vor ocupa de implementarea propriu-zisa.

Revenind la cele cateva fraze aruncate in documentul clientului – trebuie sa ai mare grija la abordarea lor initiala.
Marea majoritate a clientilor nu sunt oameni tehnici. Asta inseamna ca daca incepi procesul de clarificare cu intrebari tehnice, omul va fi in ceata.
Si fie-ti va raspunde cu “nu stiu, spune-mi tu – ca tu ai experienta in domeniu”, fie se va stradui sa-si reaminteasca cele cateva notiuni tehnice invatate cu ani in urma (pe care le va considera probabil actuale) si sa-ti dea un raspuns pe baza lor.

Oricum – va trebui sa tii minte un lucru. Pentru client, acele specificatii au sens. Pentru el, sunt logice. Sigur, logica lui va fi – foarte probabil – diferita de a ta. Dar nu trebuie sa uiti niciodata ca asa cum tie ti se par logice diverse lucruri, tot asa si lui i se par logice acele citeste mai departe


Asumare, justificare, rezolvare

Dezvoltarea unui proiect (in IT si nu numai) are la baza o estimare de timp. In functie de domeniu, aceasta estimare se da in ore, zile sau saptamani. In IT, unitatea de masura pentru asa ceva e ora.

Estimarea va cuprinde de regula si o anumita marja de eroare. Un factor de risc, o asigurare in plus ca procesul de dezvoltare se va incadra in numarul de ore estimat. Acest factor de risc e calculat in functie de complexitatea proiectului, gradul sau de dificultate, nivelele de pregatire a oamenilor implicati, numarul oamenilor implicati, etc.

Oricum, ideea e ca se ajunge la un numar de ore. Pe baza acestuia se elaboreaza un calendar de dezvoltare, cu date exacte de livrare pentru fiecare stagiu de dezvoltare si – implicit – pentru intregul proiect.

Marja de eroare despre care vorbeam mai sus se reflecta si in acest calendar. Un exemplu foarte simplu ar fi urmatorul.

Sa presupunem ca ai un task estimat la 32 de ore. Adica – 4 zile de lucru.
Daca – in calendar – data inceperii taskului este luni dimineata, atunci (conform citeste mai departe


Despre perfectiune

Ati intalnit vreodata un om perfect? Sau un obiect, un produs perfect? Si – daca da – s-a intamplat ca aceasta perfectiune sa prinda contur doar in ochii vostri? Iar altii – din jur – sa aiba pareri (radical) diferite?

Sunt convins ca da. Ca o paranteza – se spune ca frumusetea e in ochii privitorului. La fel sta situatia si in cazul perfectiunii. Depinde de personalitatea si criteriile celui care analizeaza.

Daca obiectul discutiei e un anumit produs – care se cere a fi perfect – atunci exigenta celui care analizeaza creste direct proportional cu pretul care trebuie platit pentru produsul in cauza.

Domenii din care se pot da exemple ar fi destule – dar voi vorbi in special despre cel in care-mi desfasor activitatea. Si anume IT-ul.

Se primesc asadar specificatiile pentru un nou proiect. Se analizeaza/clarifica. In mod normal – la finalul procesului de clarificare – viziunea clientului despre proiectul care tocmai s-a analizat trebuie sa fie foarte apropiata de a celui care a facut analiza. “Foarte apropiata” inseamna in procent de vreo 90%. In cazurile fericite – aceste viziuni aproape coincid. Dar cazurile fericite sunt mai rare decat preotii cinstiti, asa ca citeste mai departe