El Ingeniero Comecocos

Pac-Mac SuperBrosUna de las personas que definitivamente quieres en tu equipo es el Ingeniero Comecocos. Se trata de un perfil difícil de encontrar y raramente demandado a los reclutadores. En este post explico los rasgos de este tipo de trabajor esencial en cualquier proyecto informático.

El rasgo fundamental del Ingeniero Comecocos es que en el día a día opera como el Pac-Man de los años 80: lo sueltas en el tablero de juego y él mismo se encarga de comerse todos los puntos esquivando a los fantasmas. Aunque se mueve de forma aparentemente aleatoria por los pasillos, tiene una idea global de dónde estan los fantasmas y de cómo esquivarlos para completar la misión. Este tipo de trabajador es más o menos lo que predican las metodologias ágiles, basadas en que antes que decirle a los programadores lo que deben hacer es mejor preguntárselo y pedir su consejo.

Lo que sucede es que frecuentemente no se fomenta en exceso la proactividad, los jefes la piden a gritos, pero tales peticiones a menudo caen en saco roto o la gente no puede ser proactiva simplemente porque se lo impiden las normas. Se supone que el objetivo de Agile es maximizar el valor aportado al cliente con la mejor eficiencia operativa posible. Pero en la realidad la practica diaria ágil se convierte en una sucesión de monótonos y anodinos stand-ups matinales aderezados por retrospectivas que tampoco se traducen en cambios tácticos importantes. Al final, cada programador trabaja con sus tickets y a poca gente le importa lo que suceda cuando el ticket pase a la etapa de testeo, o si deberia haber otros tickets que ni siquiera están en la herramienta de seguimiento del proyecto.

Los rasgos identificativos del Pac-Man son pues los siguientes :

• Se da cuenta de lo que falta en el Backlog, el Kanban Board (o lo que sea que se utilice), lo añade a su propia lista de tareas y lo acomete.
• Se percata de cuando se esta apilando trabajo sin terminar en la cola de otro programador y toma medidas para desbloquear las historias de usuario atascadas.
• Tiene conciencia de lo que sucederá cuando los testers, devops, técnicos de atención diaria de sistemas y usuarios reciban el producto. Es capaz de proporcionar documentacion e instrucciones sobre cómo probar, claves para diagnosticar fallos leyendo los logs y advertencias sobre funcionalidades difíciles de entender para los usuarios.
• Avisa cuando los contratos (explícitos o implícitos) o los protocolos con un proveedor no son los adecuados y se deberían cambiar.
• Puede visualizar cómo serán el rendimiento y la estabilidad del sistema cuando pase del entorno de desarrollo a un entorno de producción con gran carga de datos y usuarios.
• No espera a que le sea asignada una tarea, escoge la más prioritaria del backlog y se pone con ella.
• Nunca deja solo a otro programador que está enfrascado en un problema de difícil resolución.
• Nunca entrega código “autodocumentado” sin instrucciones de despliegue y mantenimiento.
• Es psicológicamente resiliente a cambios súbitos o soluciones subóptimas de compromiso impuestas por el mercado, o por clientes o gerentes que no saben realmente lo que quieren.

La necesidad de este tipo de conducta en el equipo surge debido a que tan pronto cómo un proyecto alcanza un tamaño mediano se vuelve complejo saber exactamente que es lo que está sucediendo. Por mucho que se intente mantener al minimo el WIP (Work In Progress) no es raro tener mas de un centenar de tareas abiertas incluso en un proyecto relativamente pequeño. Y en un proyecto grande puede haber miles de tareas en curso. En tales circunstancias es difícil mantener un control centralizado de la situación. Los militares conocen bien este fenomeno cuando la radio de campaña se satura de gente gritando todos al mismo tiempo porque estan en contacto con el enemigo. En esos casos, si la estrategia esta bien diseñada, lo mejor puede ser dejar que las unidades operativas tomen decisiones sobre el terreno y se coordinen entre ellas sin pasar por un mando central. De esta forma en algunas ocasiones es posible ganar un batalla sin saber ni siquiera cómo se ha logrado la victoria.

Quizá una de las primeras referencias bibliográficas que se pueden encontrar sobre el problemas de la coordinación en proyectos grandes es la historia del desarrollo de Office por parte de Microsoft. En los 90, Microsoft puso en prática exitósamente una estrategia de “estabilizar y sincronizar” (tras muchas tribulaciones narradas por Joel Spolsky y otros gerentes de proyecto de la época).

No obstante lo anterior, no todo son ventajas y un camino de rosas con el miembro del equipo “tipo Comecocos”. En algunas ocasiones el estilo maverick puede conducirles a ir en exceso por libre, esquivando tareas que les desagradan. Algunos se desmoralizan cuando no consiguen avanzar durante cierto tiempo debido a restricciones impuestas externamente. Puede que se equivoquen en la asignacion de prioridades o que se obsesionen con algo que creen que debería tener o hacer el producto. Algunos son hiperactivos y sólo pueden trabajar de forma errática saltando de una tarea a otra sin completar realmente ninguna. Y si no saben informar correctamente pueden volver loco al gerente de proyecto.

Post relacionado:
El perfil del empleado perfecto.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Esta entrada fue publicada en Entorno laboral, Organizando la Comunidad. Modelos de Desarrollo, Sin categoría. Guarda el enlace permanente.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *