L’analista

Escrit per Aaloy a 25 de November , 2007 a les 6:32 p.m.

Tret del llibre Software requirements,

L'analista és la persona que ajuda als qui han demanat el projecte [1] a trobar la diferència entre el que ells diuen que volen i el que realment necessiten.

[1] stakeholders a l'original

M'ha feta gràcia la definició perquè és quelcom que sovint és perd al rol d'analista. L'analista ha de poder dir la seva en el projecte, proposar solucions, millores i expressar sense por el perquè troba que el que s'està demanant no funcionarà, o no és necessari.

Encara que se pugui dir que el client sempre té raó, si duim aquesta frase a les seves darreres conseqüències en el desenvolupament de programari, estarem pervertint la feina de l'analista.

És potser el mateix que quan un demana un disseny web i li diu al dissenyador des de com vol el format, les fotos, els colors i la tipografia. Llavors per a què vols un dissenyador web?

Pel que es veu aquest tipus de situacions no és sols pròpia d'analistes o dissenyadors web. Parlant amb un arquitecte em deia que té clients que ja li venen amb els plànols fets i que no atenen a raons, són els que solen acabar amb el bany aferrat a la cuina. També vaig viure una situació semblant amb un interiorista, el client li deia com ho volia tot, col·locació, llums, decoració, fins que l'home l'hi va tenir que dir que aquells temes eren precisament la seva feina.

Potser ens ho tendríem que plantejar de tant en tant allò de dir: "escolta, això és la meva feina, si la vols fer tu endavant però després també t'has de responsabilitzar dels resultats".

5 comentaris, 0 trackbacks (URL) , Tags: Gestió de projectes

Hòsties Toni, jo ja fa més de 10 anys que me les veig de tots els colors...

Lo que dius no deia de ser cert, però ja saps que comparar àtoms amb bits és mal negoci.

Jo he viscut més casos de fracàs de software per mor de no fer lo que volia el client (algú altre pensava que les coses eren d'una altra manera) que per mor de que fer lo que volia el client contradeia alguna norma o estàndar.

Sempre i quan no facem animalades i actuem amb seny, quasi qualsevol cosa és possible al software i no hi ha por de que la cuina faci olor de merda ni el halògens enlluernin ;-)

El més comú, sobretot amb gent que comença, és dir si a tot el que demana el client. El darrer cop que vaig dir que el que demanava un client no era útil me van dir: Sí, però si el client ho vol jo que vols que faci???

Sí el que es fa quan és va a parlar amb un client és dir que sí a tot per guanyar quatre duros al final surt un projecte infumable, inmantenible i en que les hores te surten a preu de patató.

La cosa va de que si es contracta a un professional és per a deixar-ho fer la seva feina. Aquest professional pot ser un analista, un dissenyador, un arquitecte, etc.
El que estam contractant és algú que té una opinió, habilitat o coneixements que nosaltres o tenim. Si tanmateix no te l'has d'escoltar al professional llavors el que no pots fer és demanar-li explicacions.
El que sí té el professional és l'obligació de dir-te el que pensa, el que creu que estàs fent bé o malament, o perquè la teva idea de disseny, plànol o funcionalitat pot anar malament, avisar-te. Si després no l'escoltes és cosa teva però n'has d'assumir les conseqüències.
Aquesta obligació també l'han de tenir els analistes. Sovint he vist gent que diu que si a tot per no fer el contrari al client, sense pensar en la responsabilitat que té com a professional.
En aquest cas els bits i els àtoms no són tan diferents, ja que en ambdós casos parlam de com les persones fan (o no fan) la seva feina.

Doncs a mi l'experiència hem guia en sentit contrari.

Quan ens enfrontem a una anàlisi, parlem amb els clients intentant representar amb els nostres diagrames els seus requeriments. Els clients solen dur molts d'anys i molts de coneixements en el seu àmbit, però habitualment no són capaços d'expresar-ho en la forma que nosaltres ho necessitem : amb tots els conceptes importants explícitament destacats i amb les regles sense ambiguetats.

Aquesta incapacitat no ens ha de cegar. Les 3, 6 o 15 hores parem amb les clients no el convertiran a ell amb un analista ni a nosaltres en un expert en el seu domini. El que surti d'aquesta feina no és més que una primera aproximació, molt inexacte, incompleta a un bon anàlisi. Sovint no reconeixem això. A vegades, encara que ho reconeguem, canalitzem la frustració culpant només al client.

Entenguem que l'anàlisi és un procés que mai acaba. Intentem entendre que hi ha al darrera de "les coses sense sentit" que ens diu el client. Reconeguem que estem parlant amb una persona que en sap moltíssim més que nosaltres del domini. Pensem que si duen funcionant tant d'any d'una determinada manera, encara que nosaltres no l'hi vegem el sentit, pot ser en tengui. Pot ser ens en dugem una sorpresa.

Si i no. És a dir, el client és l'expert en el seu domini i sap com es fan les coses, però el que dic, i el que diu la definició, és que part de la feina de l'analista és poder plantejar-li solucions i alternatives.
És a dir, no val dir que sí a tot sinó que el valor afegit de l'analista és a més proposar noves maneres de fer les coses - si les veu, clar-.
Per una altra banda, hi ha tota una sèrie de requeriments que són implícits i que l'analista ha de fer explícits quan fa l'anàlisi, és a dir, coses que el client dona per suposat que l'aplicació farà o no farà.
El client és qui demana l'aplicació i per tant se l'ha d'escoltar, és un dels seus drets, però per mi, un analista, arquitecte, dissenyador, que sols escolta i no aporta perd part del seu valor.
No se tracta de donar la culpa al client, al contrari, es tracta de responsabilitzar-nos de la feina que ens toca fer i d'aportar-li valor.