El Blog de Trespams

Un link passat per Jordi Cabot al Twitter anomenat Asshole driven development em fa recordar el complexe que és la interacció humana en la gestió de projectes.

Quan més gran és una empresa més possibilitats hi ha de veure's reflexat en una de les definicions que fa Scott Berkun, més que res per una qüestió de probabilitats. Personalment m'he trobat molt amb el Cover Your Ass Engineering (CYAE) ja que és el típic que es presenta quan enfrontes una solució de codi obert amb una solució propietària a un gestor més preocupat pel seu lloc de feina i cobrir-se les esquenes si hi ha el mínim risc, que per les possibilitats de benefici real de l'empresa.

L'_Asshole Driven development (ADD)_ realment m'ho he trobat poques vegades, més que res perquè quan m'he trobat en situacions on els tirs anaven cap aquí he preferit anar cap a opcions alternatives. Ja sabeu que em costa molt combregar amb rodes de molí, i l'ADD és precisament això: fer les coses no perquè són tècnicament correctes o millors per l'empresa, sinó perquè qui mana (que no és normalment l'amo de l'empresa) diu que s'ha de fer ell que ell diu i punt.

El que sí m'he troba sovint són dos estils d'entendre la gestió de projectes i la pròpia feina del cap de projecte. M'explicaré:

Per mi l'objectiu d'un projecte informàtic és sempre aportar valor a l'empresa. És a dir hi ha d'haver un benefici mesurable en el projecte, ja sigui benefici en imatge, en menor temps de feina intern per fer les coses, en un major control o el millor de tot, un benefici real en termes de negoci.

Partint d'aquesta base entenc la feina d'un cap de projecte de desenvolupament com el d'aquella persona que s'ha d'encarregar de coordinar la feina, relacionar-se amb el client i sobre tot, de prendre decisions. L'important és estar focalitzat en que la feina surti i representi un benefici pel client i per això el cap de projecte ha d'eliminar els obstacles que es presentin per tal que la gent que fa feina en el projecte pugui fer la feina que millor sap fer.

Això vol dir no convocar a reunions multitudinàries als membres de l'equip quan aquestes no aporten res. És encarregar-se d'anar a parlar amb altres departaments, amb el negoci, dur el control administratiu del projecte, fer el reporting. És a dir, totes aquelles coses que formen part de la cerimònia del projecte i que mal duites poden impedir als membres "productius" fer la seva feina.

Amb aquesta filosofia entenc que el cap de projecte ha de posar tots els recursos a la seva disposició per dur bon terme el projecte. Si el programador té problemes amb una rutina o amb el llenguatge ha de mirar de solucionar-los, bé ell mateix o cercant algú que ho pugui fer. Alguna vegada m'han dit que donar suport als programadors no és la meva feina i n'estic en total desacord. La feina d'un cap de projecte és precisament aqueixa: donar suport, i si aquest suport significa resoldre un dubte de programació, depurar en conjunt un algorisme on algú s'ha quedat enrocat, s'ha de fer si es tenen els coneixements i l'oportunitat. Perquè per damunt de tot el cap de projecte està per eliminar obstacles i donar solucions. Si un projecte ha de sortir i no puc ajudar més que en dur els cafès doncs millor llevar-se d'enmig i demanar a la gent pel sucre que vol i si els vols sols o tallats.

L'altra estil de gestió és òbviament el contrari: reunions per pressionar la gent, reunions per repartir culpes i concentració del cap de projecte en la cerimònia, és a dir, gestionar concentrant-se amb el com i no amb l'objectiu final.

Perquè està clar que tot projecte pot fallar, per les causes que siguin. Però quan falla l'excusa no pot ser anar cap a un Cover Your Ass Engineering (CYAE) i establir mecanismes burocràtics i de control absurds per a que no tornin passar les coses, sinó cercar la causa de base del problema i solucionar-la de manera que afecti de manera mínima a la cerimònia del procés.

Si un programa falla perquè no s'ha pogut provar, la solució no és tenir que redactar un document a casa passi a producció on l'equip de programadors certifica que està bé, el testejador certifica que ha provat l'aplicació i el tècnic certifiqui que ha passat el pegat que li han dit; sinó demanar-se perquè no hi ha tests unitaris, perquè no hi ha (o han fallat) les integracions contínues. Potser el que ha fallat és que la gent no té prou formació per a realitzar bons tests. Massa cerimònia mata la creativitat i far perdre l'objectiu del projecte, formar a la gent fa millors professionals.

Tot són estils de gestió, jo sé el que m'agrada i intent posar en pràctica, adaptant l'estil de gestió al client, al projecte i a l'equip. Els programadors no són els curritos del cap de projecte de torn, és el cap de projecte el qui ha de fer feia pels tècnics i programadors i procurar que ells puguin fer la seva feina.