Cerebrado describía una de sus formas en Requerimientos: cuando no son asteroides sino sólo polvo cósmico:
Un requerimiento normalmente diría:
El sistema debe detectar que el saldo de una cuenta ingresa en rojo y alertar al ejecutivo de cuentas asignado al cliente.
Pero hay veces en las que dice:
Implementar un trigger sobre la instrucción insert de la tabla cuentas_movimientos. En este trigger, cuando sld_cnt - deb_pnd + crd_pnd sea menor a 0 insertar un registro en la nueva tabla notificaciones con los siguientes valores: ....
En vez de indicar cuál es el resultado esperado de una tarea se especifica cada uno de sus pasos, quedando para el micromanagement zombie la mera ejecución de éstos.
Nos imaginamos entonces al manager obsesivo y malhumorado despotricando cada vez que alguien se aparta un milímetro del nítido camino que marcan sus instrucciones y al pobre esclavo asalariado sometido a través de toda clase de presiones a la ejecución de una lista interminable de mini-tareas de las que no puede deducir ningún objetivo a mediano plazo.
Pero lo primero que pensé es que estas relaciones no serían tan frecuentes si no hubiese también algo que ganar de cada lado. Traté de verlo en forma positiva:
- El jefe gana en eficiencia, control, seguridad. También retiene para sí el conocimiento, la visión global del proceso. De esta manera no depende realmente de nadie y nadie puede hacerle sombra.
- El zombie gana en tranquilidad, despreocupación, falta de responsabilidad. Su trabajo es usualmente fácil aunque tal vez –y sólo tal vez, esto hay que remarcarlo- aburrido. Probablemente su pasión transite por otros caminos.
Imagino que detrás de cada micromanager debe haber una personalidad insegura y por lo tanto desconfiada de aquellos que lo rodean y detrás de cada zombie un trabajador apático, desinteresado, ausente.
Eso puede funcionar muy bien para un picador de piedras o para un trabajador necesitado de la paga. Pero para el desarrollo de software en equipo no.
Por un lado porque las aplicaciones que requieren un equipo de desarrollo son demasiado complejas para una sola persona. Presentan desafíos que requieren experticia en varias áreas: codificación (y con distintos perfiles), administración de base de datos, análisis funcional…
Por otro lado porque en el desarrollo de software todos cometen errores todo el tiempo. Y la única forma de que eso no derive en un fracaso estrepitoso es el control mutuo bien entendido, que implica una actitud atenta y una visión crítica en cada uno de los actores.
Y porque en el desarrollo de software intervienen varios profesionales con visiones y métodos propios que no sólo hay que aprovechar sino respetar. ¿O alguien imagina al director de hospital indicando cómo debe operarse el corazón de cada paciente?
Esto puede sonar a evangelización ágil, así que aclaro: lo anterior es independiente de la metodología. Todas las metodologías proponen algún tipo de control y revisión, que puede ser burocrático y en determinados momentos o súper ágil y permanente, pero que existe. Pero finalmente algo escapará a todo control. Será el momento en el que el programador atento encontrará un problema y lo resolverá o discutirá con el resto del equipo. O el momento en el que un programador que sólo sigue instrucciones despreocupadamente… lo deje pasar.
A nivel personal la relación micromanager-zombie es una relación devastadora para ambos y para todos en el equipo. Un proyect lider que intente retener el control de todo se convertirá rápidamente en un cuello de botella y un torbellino de pequeñas decisiones –producto de su incapacidad para delegar ampliamente- lo perseguirá día y noche. Un programador -analista, administrador o tester- verá su desarrollo profesional estancado y pronto se dará cuenta de que la experiencia acumulada es inútil puesto que no ha aprendido a resolver problemas sino a implementar soluciones.
Y a nivel organizacional también. La organización se vuelve dependiente del manager que acapara el know-how del proceso y es incapaz de generar suficientes cuadros de reemplazo ya que el aprendizaje es imposible. Usualmente debajo de un micromanager de sistemas hay una alta tasa de rotación. Y ni hablar de la actualización tecnológica o metodológica. Es inviable pensar en la prosperidad de una nueva propuesta en un contexto así.
El micromanaging suele llevar al WTFismo: cuando sólo tienes un martillo (la cabeza del micromanager) todos los problemas se resuelven martillando. Si el micromanager es (o fue) experto en base de datos, todo será base de datos, si es (o fue) experto en C todo se hará en C, si aboga por determinada metodología (o participó en ella), se cumplirá a rajatabla… y así. Tanto peor en los casos en los que se impone una solución determinada independientemente de las personas que deben participar en el proceso.
¿Y entre programadores? Cuando respondemos dudas o discutimos soluciones ¿lo hacemos a vuelo de pájaro o tiramos una serie de pasos en estilo pseudocódigo? ¿Dejamos que los demás intenten por sí mismos antes de ayudar?
Los dejo con el test de Kathy Sierra:
- Do you pride yourself on being "on top of" the projects or your direct reports? Do you have a solid grasp of the details of every project?
- Do you believe that you could perform most of the tasks of your direct reports, and potentially do a better job?
- Do you pride yourself on frequent communication with your employees? Does that communication include asking them for detailed status reports and updates?
- Do you believe that being a manager means that you have more knowledge and skills than your employees, and thus are better equipped to make decisions?
- Do you believe that you care about things (quality, deadlines, etc.) more than your employees?
A "yes" to any of these -- even a half-hearted "maybe" -- means you might be creating Micromanagement Zombies
…y si eso no te preocupa tarde o temprano estarás en un problema… solo.
No hay comentarios.:
Publicar un comentario