El Blog de Trespams

Blog personal sobre tecnologia, gestió de projectes i coses que se me passen pel cap

Death March - Me too!

En una entrada anterior parlava dels projectes Death March i de la classificació que en fa n'Edward Yourdon al seu llibre Death March. Ara escric això alegrant-me d'haver comprat i llegit el llibre: estam enbarcats en un death march project.

Quan un s'embarca en un projecte d'aquests, el primer que ha de saber és en quin tipus de projecte s'està embarcant i quina és la companyia. Jo aquest, i segons la classificació de Yourdon, ho classificaria com un projecte de "Missió impossible", és a dir, es compta amb un equip altament motivat i capaç, però els riscs que poden fer fracassar el projecte són motls i variats.

Si als projectes normals ja s'ha de dur molta cura amb la gestió, als death march encara és molt més crític. Es pot pensar que en un projecte on les premures de temps són important no s'hauria de dedicar temps a la planificació, control d'errors, de versions, al la comunicació, res més allunyat de la realitat. Les estratègies de "codifica com un boig" [1], potser estan bé per fer veure ques es fa molta feina, el problema però, es que sovint aquesta feina és poc productiva i no garanteix que el projecte arribi a bon port.

La planificació i el control en aquests tipus de projectes és doncs tant important o més que en els projectes "més tranquilets", el que potser haurem de fer és no entrar a tant nivell de detall en alguns aspectes, si està un 80% bé ja és suficient, el 20% restant, que marcaria l'excel·lència en un altre projecte, és massa costós en termes de temps i cal evitar-ho si volem tenir èxit. Per exemple, tant fa si l'anàlisi de casos d'ús està fet amb la darrera eina de disseny UML, amb tots els colorins del món i enquadernat a tapa dura, potser amb un troç de paper que exmplique el que es vol fer és suficient. La cosa és que hi ha d'haver aquest troç de paper i hi ha d'haver una estratègia de feina orientada no a fer moltes hores i molta feina, sinó a fer feina efectiva.

Tanmateix, algunes vegades ni tota l'estratègia i planificació del món salvarà el projecte, senzillament està condemnat al fracàs: el temps és massa curt, el recursos insuficients, el que s'ha de fer no està clar, els riscs del projectes són massa o qualsevol combinació de les anteriors. El problema és que normalment un no sap que passaran coses d'aquestes fins que ja ha començat el projecte. Davant això, la planificació i la comunicació són importants. No serveix de res dir allò de "està al 90% acabat" quan sabem positivament que el 10% restant és el bessó del projecte. Val més ser realistes i dir les coses clares. Tanmateix si la continuïtat de la feina depén de l'èxit del projecte i aquest no té cap possibilitat d'acabar bé, al manco n'haurem informat a temps i es podrà, si es vol, reaccionar.

Quan un projecte s'ha de fer en un temps molt curt, per mi, el més important és disposar d'un bon equip de gent. I per "bon equip" no vull dir un equip gran de gent, sinó un equip de gent molt qualificada, acostumada a fer feina plenada i molt motivada. Això i moltes hores extres, clar. El problema és que un ritme de 10 o 12 hores diàries, difícilment es pot mantenir durant més que un parell de mesos, així que a partir d'una certa durada del projecte convé començar a fer comptes i veure si posar més gent al projecte compensa el retràssos que implica tenir que formar al personal nou i la complexitat adicional de comunicació que hi ha quan l'equip de feina es fa més gran

Per projectes de curta durada, entre un i tres mesos, és molt més eficient un equip petit, tirant d'hores extres fetes amb seny, que un equip amb el doble de gent. La durada del projecte sovint marca també el nombre de tasques que s'han de fer i el grau de paralel·lització que es difícil que arribir a ser l'òptim [2]. A vegades es pot aconseguir que el projecte faci més via si malbaratam recursos, és a dir, si tenim gent sense fer res, esperant a que li toqui fer el seu trocet. Sigui com sigui, ens duu sempre al mateix, s'ha de planificar, s'ha de saber l'abast del projecte i s'ha de dissenyar una estratègia amb probabilitats d'èxit. D'altra manera no sabríem mai si amb més recursos s'hagués pogut arribar a temps o al contrari, si s'hagués tingut que tirar de treball extra per acabar el projecte

Tornant al nostre projecte, crec que serà complicat, els riscs són grans, però l'equip és molt bó. Les meves estimacions diuen que en condicions normals podem doblar o triplicar la productivitat estandard. Tot aquest optimisme sempre cal estar atents als riscs, al seu control i a la seva minimització. Controlar els riscs és costós, s'hi han de dedicar temps i recursos, però no fer-ho pot suposar que un projecte de "Missió impossible" es convertesqui en un projecte suicida. Yourdon diu que les estadístiques estan al nostre favor [4], i si Yourdon ho diu ho haurem de creure.

Ja sent la musiqueta: tan-tan-tan-tan-tant-ta ta ta ta, tiruriii [3]


[1] Code like hell
[2] Quin mal que han fet aquí les eines com M$Project que suposen que qualsevol recurs és intercanviable!
[3] La música mai ha estat e meu fort. Deduïu el nom de la cançò pel context. I no, no hi ha premi pel qui ho adivini. :)
[4] Els death march projects que tenen més probabilitat d'èxit són aquells on el projecte és de curta durada i l'equip és petit i està molt motivat. En aquests tipus de projectes és molt més bo de fer que la gent pugui "aparcar la seva vida" durant el temps de durada del projecte. En projectes amb molta gent o de durada molt més gran, hi ha tan dificultats per a que tothom "doni el call", pels motius que siguin o que pugui deixar-ho tot durant tant de temps (el més normal). Això per no parlar de l'esgotament físic i mental o de que en casos així molts dels integrants del projete s'estima que deixaran l'empresa dins el proper any, amb la qual cosa l'empresa es pot trobar amb un projecte fracassat i amb el capital humà perdut.

blog comments powered by Disqus