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 specificatii.

Sigur – e foarte posibil ca si incapatanarea sa intre in ecuatie. Iar asta ingreuneaza exponential lucrurile. Dar incearca mereu sa pastrezi totul la un nivel simplu. Si anume : clientul dispune de niste fonduri si de o idee oarecum neclara / tu trebuie sa clarifici ideea lui si sa facilitezi transpunerea ei in documente inteligibile (wireframe/specificatii extinse).

Daca insista ca “are dreptate”, atunci… din punctul lui de vedere, are. Poate ca dintr-al tau, nu. Dar el vede lucrurile intr-o alta lumina, pentru el totul e deja clar (chiar daca doar in mintea sa, nu si in documentatia pe care el o ofera).
Nu incerca sa-l convingi ca n-are dreptate. Nu sunteti intr-un razboi, la urma-urmei – ci de aceeasi parte a problemei. Clientul nu e inamicul tau, iar tu nu esti inamicul lui. Aveti un interes comun – proiectul in sine. Clientul e interesat sa plateasca si sa-si vada proiectul realizat. Tu esti interesat de realizarea corecta a proiectului (pe care-l poti trece in portofoliu) si – desigur – de suma pe care clientul o va plati pentru rezultat. Deci, luptati pentru aceeasi cauza – chiar daca aveti puncte de vedere diferite asupra aceluiasi aspect.

Asadar, nu incerca sa-l convingi ca greseste. Incearca in schimb sa intelegi de ce anume considera el ca are dreptate. Plaseaza-te pe aceeasi lungime de unda ca si el. E vital sa reusesti asta.

Porneste intotdeauna de la general spre particular, nu invers. Adica – daca in specificatii scrie “as dori un magazin online”, nu-l intreba din prima ce tipuri de autentificare si ce clase de utilizatori doreste pentru serviciul respectiv. N-o sa obtii mare lucru. Il poti intreba in schimb la ce structura (ce categorii de pagini) si eventual la ce modele existente s-a gandit pentru magazinul sau online. Iar in functie de raspunsurile sale – canalizeaza discutia spre detaliile pe care vrei sa le obtii, dar fara a sari peste etapele intermediare. Daca omiti ceva ce se va dovedi important mai tarziu, poti pune in pericol intreg deadline-ul proiectului.

In cazul asta, argumentul tau va fi – probabil – ca “nu s-a clarificat suficient partea respectiva”. Argumentul clientului va fi ca “el s-a gandit la acest detaliu de la bun inceput, de cand a scris specificatiile – si a considerat ca detaliul respectiv e de la sine inteles, chiar daca n-a fost adus in mod special in discutie”. Iar odata ajuns aici… ai deja o problema.

Insista deci pe detalii. Dar fa-o cu masura. Margineste-te la clarificarea specificatiilor, nu te grabi sa le complici. Clientul iti va aprecia ideile, cata vreme nu ies din sfera a ceea ce s-a gandit el initial. Iar aceasta sfera o poti delimita doar prin intelegerea logicii sale – asa cum spuneam la inceput. Adica – daca magazinul online dorit de client va fi unul de haine, ii poti sugera o functionalitate pentru (sa zicem) gestionarea comenzilor anterioare. Dar o functionalitate care sa livreze si cartofi prajiti nu-i va fi de niciun folos. Stiu, exemplul e exagerat (si comun, in jargonul web development-ului) – dar ati prins oricum ideea 😉

Inchei cu acelasi indemn de mai sus : sub nicio forma, nu incerca sa convingi clientul ca n-are dreptate. Gandeste-te doar ca ceea ce sustine e logic pentru el si ca logica ta poate fi diferita. Asta nu inseamna ca unul dintre punctele voastre de vedere e corect si celalalt e gresit – ci ca fiecare idee e corecta prin prisma celui care-o enunta. Si – din nou – tine minte ca nu sunteti inamici, ci aliati pentru indeplinirea unui scop comun : realizarea proiectului. Straduieste-te sa-i intelegi logica, pune-te in papucii lui. Priveste din punctul lui de vedere – fara insa a-ti pierde insa propriile idei. Adu-ti propria contributie – fara a depasi granitele conceptului initial – si imbunatateste ideea de business a clientului. Asta va fi mereu de apreciat. Si mai ales – nu sugera functionalitati pe care nu le poti livra, avand in vedere restrictiile (de timp si resurse) aferente proiectului.

N-am zis ca va fi usor. Dar – cu timpul – s-ar putea sa-ti placa.

Bafta.

Sursa imaginii – link.


5 Comments

  • Reply NumaIo |

    Pai da. Ideile si sfaturile acestea functioneaza in cazul in care vorbim de ‘average client’, (de ala de care ne lovim zi de zi, adica unul care se comporta normal, nu trage inspre nici una din extreme) si in principiu, e cam asa cum zici tu. Dar in cazul in care clientul incepe sa devieze de la clientul mediu/uzual intr-o oarecare extremitate, lucrurile incep sa devina un pic mai complicate 🙂 Mai ales cind ore de discutii duc inevitabil la aceasi finalitate, indiferent de modul in care incerci sa ‘te apropii’ de client, indiferent daca incerci intr-un mod mai mult sau mai putin tehnic, incercand cumva sa te ‘sincronizezi’ cu interlocutorul. Da, se poate spune si faptul ca poate inca nu ai gasit abordarea potrivita. Dar dupa sirul lung de incercari de abordare, inevitabil iti pui si tu intrebarea:

    – “Daca clientul nu doreste sa gasesti abordarea potrivita?”

    intreb si eu, un pic ca avocat al diavolului si cu niste cazuri de genul lasate in spate 🙂

  • Reply admin |

    Prin definitie, clientul e o persoana care plateste pentru un serviciu. Un stakeholder cu influenta mare si atitudine “pro” – daca vrei sa vorbim in termeni mai specifici.
    In momentul in care atitudinea lui migreaza spre cealalta extremitate (contra) – atunci nu mai e client, ci o piedica in realizarea proiectului.
    Insa trebuie sa stii sigur ca migrarea asta nu s-a produs din cauza ta – ci din cauze independente de tine. E clar ca e o problema la mijloc – dar gandeste-te daca problema in sine nu e tocmai abordarea folosita de tine. Sau – ma rog – abordarile. Gandeste-te bine. Iar daca ai analizat fiecare posibilitate in parte si totusi – partea negativa din ecuatie ramane respectivul stakeholder (care – dupa cum spuneam – din moment ce e “contra”, si-a pierdut calitatea de client) – atunci poti dezbate problema cu un nivel mai sus (upper management).
    Cum o sustii/rezolvi acolo – asta e deja o cu totul alta problema.

  • Reply NumaIo |

    exact aici voiam sa ajung si eu. In unele cazuri ‘clientul’ este ‘impus’ de upper layer, din vari motive, desi e clar pentru toata lumea ca totul in cel mai fericit caz ‘scartaie’. Ori in acest caz (cel ‘impus’) cam degeaba incerci tu sa faci pe dracul in patru. Marog .. citeodata merge, citeodata nu ..:)

  • Reply Nicu |

    Sa nu uitam ca sunt multi clienti ce tin detalii referitoare la proiect si le aduc in discutie la sfarsit ca o simpla tactica de marketing.
    Te intelegi cu el la o sarcina, si la sfarsit intreaba: “Pai nu face si X si Y ?” si zici: “Pai astea sunt cerintele la care ne-am inteles”, la care zice, “Pentru asta platesc numai jumate”.

    Am intalnit situatie de genul, in care in timpul proiectului e fericit si multumit, iar la sfarsit se plange si arata o “lista ascunsa” de cerinte ce nu s-au facut. Asta mai ales cu clienti straini ce au un singur scop, sa lucrezi mult, si sa plateasca jumate.

  • Reply admin |

    @NumaIo : Cum spuneam, modul in care iti sustii cauza in upper layer e deja o alta poveste. O dezbatem si pe asta probabil, candva.

    @Nicu : Tocmai de-asta exista contracte si alte referinte scrise. Ca sa elimini situatiile de acest gen.

Lasa un comentariu