Culpable de “teamicidio” Nº 6: Los plazos imposibles

A veces, imponer fechas límite ajustadas es desmotivador para el equipo. Por el contrario, imponer plazos ajustados pero no imposibles, muchas veces también constituye un desafío, una oportunidad para el logro conjunto y el desarrollo del equipo. 

Lo que nunca va a ayudar, sin embargo, es imponer plazos imposibles de cumplir.

Cuando el jefe dice: “Es imperativo que el proyecto finalice necesariamente tal día…” los miembros del equipo experimentados no lo pueden evitar: Levantan las cejas, cierran los ojos y suspiran. Ya han pasado por ello antes. Ya conocen la rutina.

Culpable de “teamicidio” Nº 5: La reducción autoimpuesta de la calidad

Nadie quiere realmente reducir la calidad de los productos, sino su coste. Habitualmente, sin embargo, el significado es el mismo. Los pasos que se dan para entregar el producto en menos tiempo implican menor calidad. A menudo son los usuarios finales quienes consienten una menor calidad a cambio de una entrega en menos tiempo y con menos coste.

Pero estas concesiones pueden ser muy dolorosas para los programadores. Su autoestima y disfrute del trabajo salen perjudicados ante la necesidad de construir un producto de una calidad claramente inferior a la que son capaces.

Culpable de “teamicidio” Nº 4: La multitarea

Muchas veces, la dirección impone políticas de fragmentación del tiempo porque consideran que las habilidades y el conocimiento de los profesionales les hacen indispensables en otros proyectos, aparte del que supone su asignación principal.

La multitarea es perjudicial para la formación de equipos, pero también es perjudicial para la eficiencia. Por lo general, las personas no estamos diseñadas para seguir muchas interacciones humanas al mismo tiempo. Si alguien trata de formar parte de 4 equipos de trabajo a la vez, se pasará el tiempo cambiando de marcha. Nadie puede formar parte de varios equipos cohesionados al mismo tiempo. Las estrechas interacciones que ocurren en los equipos cohesionados y sinérgicos son exclusivas. 

Culpable de “teamicidio” Nº 3: El papeleo (la burocracia)

En las décadas de los 70 y 80, Caper Jones dirigió una serie de estudios para categorizar los costes en los desarrollos de sistemas de información. Una de las categorías era el papeleo (paperwork, en inglés). Lo que Jones llama papeleo es algo así como la documentación que se genera sin sentido, la que sirve para "cubrir el expediente", simple y llana "burocracia". Hablamos aquí de la documentación no relacionada con los requisitos, el análisis, el diseño, codificación, planes de pruebas, ayudas, manuales, etc. Jones concluía que el papeleo supone más del 30% del coste de producir un determinado producto software. 

El jefe que no confía en su equipo

Como Director de Proyectos, Vd. debe practicar la desconfianza en muchas áreas de riesgo. Si trabaja con material defectuoso, habrá que preparar material de repuesto. Si el cliente cambia constantemente de criterio, tratará de cerrar al máximo las especificaciones. Si un proveedor tiende a “olvidarse” de sus compromisos, publicará un acta después de cada reunión.

Hay un área, sin embargo, donde ser desconfiado no le dará nunca buen resultado: Vd. no puede protegerse ante la incompetencia de su propio equipo. Si su equipo no está capacitado para realizar el proyecto, Vd. fracasará.

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.

  

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. 

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:

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. 

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.