El rincón de JMACOE

Voy a empezar con una pregunta, si tienes  $400 en tu presupuesto de desarrollo que haces

1. A. Premias a tu programador estrella con un bono de $400 o
2. B. Le compras un monitor LCD de 24 pulgadas 1920×1200?

Si tu respuesta es «A», entonces necesitas seguir leyendo. Si su respuesta es «B» entonces entiendes lo que motiva a los programadores, pero te sugiero que sigas leyendo y comentando más adelante, si tienes alguna idea de lo que trato.

Una de las cosas que nunca enseñan a los gerentes que nunca programaron es cómo motivar a los programadores. Puedes pensar que los programadores están motivados por las mismas cosas que el resto del personal, pero te equivocas. Los programadores tienden a ser considerados con el coeficiente intelectual más alto y por lo tanto normalmente son más difíciles.

El programador promedio podría estar proyectando una imagen de superioridad, pero no se pierdan de leer esto los que no son programadores y creo que está dirigida a ellos. No es verdad. Tienes que entender a los programadores en sí, no contra los programadores de otro tipo contra cualquier otra persona.

Esto es importante cuando tomas cualquier decisión acerca de cómo recompensarlos. Si compras un nuevo equipo para personal de ventas es posible que la reacción sea… nada. Si compras un nuevo equipo para el personal de programación, comenzará inmediatamente a analizar quién tiene qué y en función de que están siendo remunerados los demás basados en la calidad de los equipos. Si piensas que esto no es pertinente piénsalo de nuevo.

Lo que se pretende generalmente es que el ambiente laboral es más importante para un programador que cualquier tipo de compensación económica (dentro de los límites). Pero la gestión de quién obtiene qué dentro de su empresa no es fácil.

Sólo puedes tomar el punto de vista (y si tienes presupuesto lo suficientemente grande) que todo el mundo está normalizado y que todos tienen el mismo equipo. En la práctica, dentro de un entorno de desarrollo no funciona porque cada programador podrá exigir una instalación muy especializada que rompe la regla de la normalización y vuelves a «quién obtiene qué.

Hardware en cascada

Los programadores exteriormente tratan de dar la impresión de que son un montón de liendres sueltas que no se preocupan por las prácticas comerciales estándar y luego no dan ninguna importancia a la política habitual de la oficina de quien está por encima de quién. Todo esto va por la ventana con los nuevos equipos ya que el hardware se ve como un símbolo de estatus dentro de la «jerarquía inexistente del programador».

Así que cuando se actualizan los equipos es muy importante comprender la estructura de esta jerarquía invisible. Suelo actualizar la parte superior del árbol y empujo hacia abajo el resto de los equipos, esto puede significar un montón de volver a instalar pero la mayoría de los programadores estará muy feliz de poner horas extras para realizar el re-instalar si la recompensa es una nuevo equipo (o por lo menos un equipo más rápido)

El atractivo de la solución de un problema

Los programadores programan porque les encanta resolver problemas. Recuerda esta regla:

«Si das un programador un trabajo que no implique la solución de algo se convertirá en infeliz.»

Resolver puede significar muchas cosas y es más fácil (y más importante) entender la clasificación de la tarea «no-resolver». Normalmente pedir a un programador ir arreglar algo que debe calificarse de «no-resolver» como solución ya ha sido encontrada y estás pidiendo que vuelva a resolver mirando el código de nuevo.

Lo importante es que encuentre la manera de hacer las tareas «no resolver» en las tareas «resolver». Un ejemplo típico sería la diferencia entre pedirle a uno de sus programadores elaborar un informe (por ejemplo, algunas estadísticas de uso) a mano o asignándole más tiempo para que pueda «resolver» algo y producir un sistema automatizado que te enviará en un mail el informe cada día/semana/mes. Otras situaciones típicas «no resolver»

• Escribir documentación
• Creación de horarios
• Escribir informes
• Primera línea de soporte

Todos los programadores tienen que realizar tareas que no son felices, no de problemas y hacer frente mejor a algunos hacer frente a una proporción más alta «no la solución» de las tareas que otros. Entender sus programadores y que puede hacer frente a qué nivel de «no resolver» es importante para mantener un buen funcionamiento en general.

Reuniones

Los programadores ven las reuniones como pérdidas de tiempo. La mayoría de la comunicación entre los programadores se realiza mediante correo electrónico o por un paseo rápido al otro mostrador para aclarar algo que está fuera del alcance de un correo electrónico. Por lo tanto cualquier momento dentro de una sala de reuniones es un momento infeliz y aumenta de manera exponencial con la longitud de la reunión. Así que a toda costa si lo hace tendrá que arrastrar a su equipo de desarrollo dentro de la reunión o bien incluir alguna forma de Lego para jugar (lo digo en serio) o realizarla en muy corto tiempo.

Algunos fundamentos de este tema