30 de octubre de 2011

No hay “team building”, sólo hay “team growing”


En su célebre obra Peopleware: Productive Projects and Teams, los autores Tom DeMarco y Timothy Lister inventaron el término "Teamicide" (¿podemos decir “teamicidio”, en español?). Esta palabra expresa muy gráficamente lo que les pasa a los equipos cohesionados y sinérgicos que acaban muriendo por causas externas.
También sirve para identificar las causas por las que muchos equipos nunca llegan a formarse realmente como equipos. A este respecto, proponen cambiar el término "team building" por "team growing". En español, diríamos que hay que cambiar el término "formar al equipo" por "hacer crecer al equipo". A mí me gusta más el término "sembrar equipo", me recuerda mejor la ley de la cosecha.
  

26 de octubre de 2011

El overtime se compensa con undertime

Muchos jefes se consideran mejores cuanto más "exprimen" a los programadores. Siendo el desarrollo de software un trabajo intelectual, pensar así es claramente un error. 

Ciertos estudios demuestran que trabajar más de 80 horas semanales no aumenta la productividad neta. 



23 de octubre de 2011

Programar es un trabajo intelectual

En su célebre obra Peopleware: Productive Projects and Teams, los autores Tom DeMarco y Timothy Lister comparan la actividad de “programar” con otra actividad altamente industrializable, como es el negocio de la comida rápida. El siguiente cuadro resume los puntos de comparación:



16 de octubre de 2011

Receta para Gestionar Riesgos

Este texto se ha traducido del libro:
Slack. Getting past burnout, busywork, and the myth of total efficiency
Editorial: Broadway Books. Autor: Tom DeMarco.



Un riesgo es algo negativo que puede ocurrir o no (o quizá ocurra en algún grado). Es negativo porque si ocurre, sus probabilidades globales de éxito disminuyen. Cuando un riesgo sucede, decimos que se materializa.
Gestionar riesgos significa declarar explícitamente la incertidumbre provocada por esas posibles materializaciones, pero antes de llegar a esto, es necesario trabajar individualmente sobre cada una de las incertidumbres identificadas. Hay dos clases de riesgos, que exigen diferente tipo de gestión: los riesgos agregados y los riesgos individuales. 



14 de octubre de 2011

Planificando el Fracaso

Este texto se ha traducido del libro: 
Slack. Getting past burnout, busywork, and the myth of total efficiency
Editorial: Broadway Books. Autor: Tom DeMarco.


Los cambios radicales en nuestra economía global nos han traído nuevos modelos para hacer negocios, nuevos mercados y competencia sin fronteras. Todo esto genera oportunidades, pero toda oportunidad implica riesgo. Nadie tiene éxito si no arriesga, todo el mundo lo sabe. Incluso las organizaciones más serias de hoy en día saben que el riesgo es algo de lo que no se pueden escapar.

Una definición interesante de éxito en muchas organizaciones actuales es esta: Tome usted un montón de riesgos y supere todos y cada uno de ellos. Cuando los detalles de todos estos pequeños triunfos se oficializan, el resultado es un enfoque llamado “Planificar el Éxito”. Planificar el Éxito es un principio de filosofía de gestión muy frecuente, especialmente en el sector tecnológico. Este principio de gestión consiste en contar con que se materializan todos los resultados deseados, y aceptar compromisos basados en la consecución de dichos objetivos.

Planificar el Éxito es el equivalente intelectual de: Fórrese usted después de ganar 15 manos consecutivas al blackjack, sin retirar dinero de la mesa hasta el final. Esto funciona cuando funciona, pero le dejará hundido cuando no (la mayoría de las veces). También favorece la aversión al riesgo. Una organización que se espera supere todas las adversidades sólo puede permitirse tomar los riesgos más triviales. De la misma manera, una organización que no ha sufrido perjuicios importantes, en realidad no ha tomado riesgos de verdad.

La gestión de riesgos es casi lo contrario a Planificar el Éxito. La gestión de riesgos es –respire hondo, esto va a ser desconcertante- una disciplina para Planificar el Fracaso. Las empresas que practican gestión de riesgos prevén un montón de fallos pequeños (pero caros) a lo largo del camino antes del éxito global. El éxito global consiste en retirarse de la mesa con mucho dinero al final.

Tomar riesgos significa exponerse a sobrecostes y retrasos potenciales. Si usted toma un montón de riesgos, algunos terminarán costándole y otros no. La cuenta final le puede salir favorable. Suponga que sólo se materializa un 10% de los riesgos, con sobrecostes y retrasos. Usted no debe esperar sortear todas las consecuencias negativas. Debe reservarse algunas holguras de tiempo y dinero para hacer frente a estas consecuencias. La gestión de riesgos es la ciencia que le guiará a la hora de determinar estas holguras.

6 de septiembre de 2011

Gestionar Proyectos: Más Sociología y menos Tecnología


Los proyectos fracasan la mayoría de las veces no por la innovación tecnológica que suponen. ¡A veces, un proyecto fracasa sencillamente porque Pepe no se habla con Juan! La ausencia de “habilidades humanas” explica muchas veces el porqué de la imposibilidad de cerrar los requisitos, de superar las pruebas de aceptación, de la baja productividad, del excesivo retrabajo, retrasos, sobrecostes, etc. ¿No será la nuestra  una profesión donde la Sociología tiene más peso que la Tecnología?

Pocas profesiones hay más orientadas a objetivos que la del Director de Proyectos. Además, es extraordinariamente injusta, porque si el proyecto es un éxito nadie nos felicita, pero si es un fracaso, entonces la culpa es sólo nuestra. El inconveniente es que el trabajo del proyecto no cae en nuestra zona de control, sólo podemos coordinar lo que hacen otros.


3 de agosto de 2011

Evaluando a un Director de Proyectos ineficaz

Pensemos en un Director de Proyecto que no nos guste. ¿Qué suele decir un jefe cuando evalúa a esta persona? A continuación va una lista de defectos que yo recuerdo haber observado en compañeros y en mí mismo (hay mucha autocrítica en esta lista):
  • Siempre se está quejando de los procesos internos, de los recursos, del cliente, de los plazos, pero nunca propone soluciones.
  • No es proactivo. No se anticipa a los problemas. Avanza reactivamente, de crisis en crisis.
  • Tarda mucho en tomar cualquier decisión, no me parece que tenga criterios claros.
  • No tiene un plan completo del proyecto, ni por escrito ni en su cabeza. Cuando se lo pido, me hace un gantt, pero sospecho que es sólo para cubrir el expediente.
  • No gestiona bien el tiempo. Siempre anda desbordado. Nunca parece tener tiempo para nada nuevo. No responde a los correos. No devuelve las llamadas. Lo urgente no le deja tiempo para lo importante. Generalmente no cumple lo que promete.
  • No sabe delegar, todas las decisiones han de ser suyas. Se mete demasiado en las tareas técnicas.
  • Es demasiado autoritario. Ha quemado al equipo. He recibido muchas quejas de los responsables funcionales, del cliente, de los proveedores, etc. No mantiene buena relación con los interesados, no confían en él.
  • Le falta empuje para cerrar de una vez el proyecto. Siempre me dice que estamos al 90%.
  • Le veo cometer siempre los mismos errores. Tropieza con las mismas piedras una y otra vez. No le preocupa mejorar.
  • No lleva un registro de incidencias. No gestiona el alcance. Al cliente le dice a todo que sí.
  • No conoce el presupuesto, lo gastado, lo facturado, el margen comercial, etc.
  • No me da información ejecutiva. Por ejemplo, no es capaz de justificar el progreso real, qué retraso final acumulará el proyecto y cuál será el sobrecoste.
Si usted hace su propia lista, seguramente no coincidirá con la mía, pero apuesto a que tienen algo en común: Casi todos los defectos entran en el grupo de las llamadas "habilidades sociales", o soft-skills, en inglés. Como puede comprobar, en mi lista sólo los últimos tres puntos se refieren a técnicas y herramientas del tipo hard-skills. El resto tiene que ver con los elementos "sociológicos" del proyecto. Un proyecto puede resultar un fracaso sólo porque no se comprenda bien al cliente, porque la moral de los miembros del equipo esté baja, o porque dos personas en el equipo estén permanentemente enfrentadas.

27 de julio de 2011

El paradigma de los 7 hábitos adaptado a los Project Managers

... y esta es la adaptación que yo he pensado para los Directores de Proyectos:







El paradigma de los 7 hábitos

Estos son los 7 hábitos de la gente altamente efectiva, propuestos por Stephen Covey en 1989:


18 de julio de 2011

Conversando en el ascensor con un Director de Proyectos eficaz

Ahora démosle la vuelta a la escena. En ese mismo trayecto en ascensor ¿qué diría un Director de Proyectos eficaz?

-Patrocinador: ¡Hombre, ya tenía yo ganas de verte! ¿Cómo va mi proyecto?
-Director de Proyectos: Tienes un mail mío en tu inbox. El riesgo que se identificó hace dos semanas se ha materializado. Necesito tu aprobación para sustituir al experto en base de datos. Recordarás que habíamos aprobado una subcontratación por 2 meses, 10.000€. Este sobrecoste reducirá el margen final medio punto.
-Patrocinador: ¿Impactaba la fecha límite?
-Director de Proyectos: Si cuento con él el próximo lunes, como me aseguran, no habrá retraso por esta razón.
-Patrocinador: ¿Por esta razón? ¿Te preocupa otra cosa?
-Director de Proyectos: El nivel de retrabajo que estamos asumiendo. Este lunes nos han cambiado las especificaciones por tercera vez. Calculo que hemos producido 500 puntos función que hay que tirar a la basura. Esto son otros 10.000€.
-Patrocinador: ¿Qué sugieres que hagamos?
-Director de Proyectos: He preparado tres alternativas para reducir el alcance. Hay una presentación en el mail que te he enviado. ¿Tienes tiempo ahora? Me gustaría contártela bien. Creo que deberíamos ir mañana a ver al cliente...

¿Aprecian la diferencia? Este otro Director de Proyectos sí transmite una imagen de eficacia, desde luego. ¿Cuál es su secreto?