Algunas notas sobre el trabajo diario de desarrollo de software

Los Directores de Desarrollo de Software tienen que enfrentarse todos los días a desarrolladores y consultores de talento pero problemáticos. El secreto para unas buenas decisiones de dirección es hacer lo más apropiado para los usuarios.

No he encontrado una sola organización de software que no esté permanentemente bajo crítica o escrutinio por la posible presencia de "prima donnas", "falta de control", o "ausencia de realidad". Estas percepciones se contemplan a veces con buen humor, hasta que el software no se entrega en los plazos prometidos.

Yo he tenido mi parte de prima-donnas y situaciones de falta de control, que amenazaron a los proyectos de desarrollo. Al hacer frente a estos problemas, siempre he puesto el énfasis en aquello que era más apropiado para mis usuarios (clientes).

Todos hemos tratado con ingenieros y desarrolladores de aplicaciones que no se sienten obligados a trabajar en tareas que son necesarias para el progreso de la empresa. Si no pueden ponerse de acuerdo en la norma de que lo primero son los clientes, lo segundo la compañía y en tercer lugar los empleados, seguramente irán en detrimento de usted y de su personal.

Este no es mi trabajo

En una de las reuniones más "movidas" de nuestro departamento, presenté una tarea de ingeniería de software que había que llevar a cabo. Aunque no era una tarea interesante, se había convertido en la necesidad más prioritaria para el cliente.

Para mí y para los directores de mi departamento, parecía una decisión fácil: nuestro ingeniero de más antigüedad debería dedicar un par de meses a la tarea.

Al discutir ésta en la reunión, este ingeniero senior específico comprendió el peligro de la selección natural y, ante todo el mundo en el departamento, dijo: "De ninguna forma voy a trabajar en este proyecto, incluso si se me pide. Es un trabajo demasiado pesado y difícil."

Imaginen mi sorpresa. Aseguré al ingeniero y a todos los demás en la reunión que, aunque no se había tomado aún una decisión sobre quién resolvería el problema, todos debemos a veces ayudar a la compañía cuando se necesita, y les recordé que, por cierto, "aproximadamente un 90% de mi trabajo es un trabajo pesado y difícil."

Mi principal preocupación fue la reacción del resto del equipo. ¿Cómo asumirían la salida forzada de este empleado, especialmente teniendo en cuenta que era tan capacitado y tan estimado por los demás?

Para mi sorpresa, la mayor parte del departamento no sólo apoyó mi acción, sino que la consideró como un refuerzo positivo a la norma de "el cliente primero y la compañía después". Se habían sentido frustrados, aceptando tareas largas y laboriosas que no les agradaban demasiado, mientras que esta persona sólo realizaba las tareas cortas que le interesaban.

Es muy fácil pasar a depender de consultores que le ayuden a uno en las cuestiones de proceso, personal y comunicaciones. Quiero resaltar al máximo que los directores de desarrollo deben intentar manejar estas cuestiones sin consultores, o utilizarlos sólo para tareas específicas y bien planteadas.

No puedo comprender esto, pero un consultor sí podrá

En una ocasión, llegué a una compañía en la que la Dirección no tenía estrategia, los empleados se encontraban decepcionados, y los consultores habían comenzado a trabajar y estaban dispuestos a ayudar a la compañía a resolver su problema. Después de aproximadamente tres semanas de evaluar las ventajas y beneficios, pensé que los consultores no nos estaban ayudando a alcanzar los objetivos originales, así que prescindí de ellos. Así, tuve que emplear una enorme energía en asegurar que todos los equipos estuvieran adecuadamente organizados, pero por nosotros, no por personas externas. Este es el motivo de que las prioridades de los clientes, la compañía y los empleados sean tan importantes para superar el amor propio y las divergencias entre equipos de desarrollo. Mantener criterios de decisión consistentes nos ayudó a superar un período difícil. Con seguridad, el personal mantenía una actitud bastante fuerte de sospecha y desconfianza hacia mí. En los años 90 y aún más allá, preveo que el liderazgo deberá ser demostrado desde dentro, pues estoy convencido de que cualquier compañía dispone de un enorme talento y capacidad internas.

No se pueden mantener sesiones de motivación, similares a las que se mantienen para el personal de ventas, con desarrolladores de aplicaciones, que tienden a ser bastante escépticos y poco ajustados a las normas corrientes. Es muy difícil estar en sincronización con aquello que les motiva y mantener el debido respeto al liderazgo durante tiempos difíciles.

Reconózcase a sí mismo como líder

Uno de mis directores de desarrollo se sentía frustrado con la compañía y con mi liderazgo. En una comida de trabajo, dijo, "Sabes, Ken, nadie sabe en realidad lo que tu quieres, ni qué significa el desarrollo. No demuestras liderazgo."

Es obvio que ser un líder en un entorno de desarrollo requiere una gran paciencia y saber aceptar críticas constructivas de cualquiera. Incluso si uno alcanza la reputación de líder, no significa que la conserve para siempre. Deberá ser ganada constantemente.

Los equipos de desarrollo pueden convertirse en una segunda familia, y pueden producirse problemas de gestión y de trabajo en equipo muy graves cuando los desarrolladores no actúan al nivel necesario. Suministrarles información continua y de forma regular sobre rendimiento contribuirá a identificar rápidamente los problemas, mientras que no afrontar correctamente los problemas de rendimiento puede destruir equipos de trabajo o, lo que es aún peor, impedir que los proyectos se terminen a tiempo.

Retirar a las personas que no son efectivas

Uno de mis directores senior inventó una tecnología que aportó mucha fama y éxito a la compañía. Sin esta innovación, seguramente la compañía no habría existido cuando yo entré a trabajar en ella.

El problema era que sus equipos no estaban llevando nada a cabo. Cada vez que tenía una idea, celebraba una sesión intensiva para discutirla con su equipo.

Mi jefe no estaba satisfecho con el progreso alcanzado por el equipo, pero yo no tenía el valor para retirarlo de su cargo.

Mi jefe intervino y retiró del proyecto a este director de desarrollo, trasladándolo a una posición de "visionario" (es decir, de "pensador" de proyectos de futuro). El equipo se mostró en realidad satisfecho, y hubiera querido que esto hubiera sucedido antes.

Esta historia demuestra que es necesario hacer siempre lo correcto para el proyecto y para la compañía, incluso si se trata de una decisión personal difícil. El éxito depende de que el personal actúe con efectividad en el cargo o función apropiados.

¿Piensa usted que "dar poder" a un equipo de desarrollo resultará automáticamente en acciones bien dirigidas y responsables? Las decisiones a nivel de Dirección y la atención por parte de la Dirección son necesarias en un 100% para garantizar que se adopten las decisiones correctas.

No necesitamos a nadie que nos dirija

Estaba presentando un informe de bajo rendimiento cuando, para mi sorpresa, el empleado en cuestión dijo, "Mi rendimiento hubiera sido mucho mejor si los miembros de nuestro equipo se hubieran dirigido a sí mismos. En realidad, los nuevos libros sobre gestión indican que el moderno desarrollo de aplicaciones requiere equipos auto-dirigidos."

Respondí afirmando, "en primer lugar, aprecio el hecho de que usted esté leyendo libros y publicaciones sobre gestión y dirección de desarrollo. Estoy seguro de que existen organizaciones de software que practican la auto-dirección. Uno de los motivos de que estemos manteniendo esta discusión es que su director ha observado que su rendimiento está afectando al rendimiento de