[ x ]

Faig servir les cookies de Google Analytics per al control de visites i estadístiques..
És una pardalada, però la llei diu que us he d'avisar, ja veus. Així que si visitau aquest blog donau-vos per informats o sortiu ara mateix i netejau les cookies del vostre navegador. Si continuau llegint, suposaré que ja us està bé. Si vols saber com llevar les cookies del teu navegador: aquí ho pots trobar

Tot són estils de gestió

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.

Comentaris
  1. Jordi Cabot Jordi Cabot on 26/02/2010 15:33 #

    Crec que el tema de prendre decisions és segurament el més important. Un cap de projecte s'ha de mullar i decidir cap on tirar (en la majoria dels casos sense tenir tota la informació que caldria per decidir en plè coneixement de causa).

    El no decidir és sempre menys productiu que decidir amb el risc d'equivocar-se. Un cap de projecte no es pot amagar ni excusar en el seu equip quan van maldades.

  2. Juan Lladó Juan Lladó on 27/02/2010 15:37 #

    <quote>
    Crec que el tema de prendre decisions és segurament el més important. Un cap de projecte s'ha de mullar i decidir cap on tirar (en la majoria dels casos sense tenir tota la informació que caldria per decidir en plè coneixement de causa).
    </quote>

    Un poco temerario que lo más importante sea decidir aunque, en algunos casos, no se disponga de toda la información necesaria...

    Saludos

  3. aaloy aaloy on 27/02/2010 16:19 #

    #juan Segurament el saber evaluar situacions i prendre decisions és una de les tasques més importants del cap de projecte. No és temerari, és necessari, i tenir consciència de que mai es tendrà tota la informació necessaria i obrar en conseqüència és el que farà avançar el projecte.

    S'ha de saber quan es té prou informació, quan no se'n té prou i es pot obtenir i quan no se'n té prou però no se'n pot obtenir més. Voler tenir tota la informació abans de prendre una decisió implica arribar una situació de paràlisi per anàlisi. El projecte no s'acabarà i segurament el que hi haurà fet no respondrà a les expectatives del client, però això sí, tendrem tota la informació al nostre abast.

Els pingbacks estan tancats.