Aprendiendo a ser un jefe pérfido

Hace ya unos años, mi jefa se fue de baja de maternidad. Durante esos meses, me tocó a mi llevar a su grupo de gente, unas seis personas.

El responsable del proyecto que estábamos empezando en ese momento me comentó que en un par de meses iba a venir el cliente y que quería una demo de lo que lleváramos hecho hasta ese momento. Yo, siendo novato en estas tareas de jefe-planificador, insistí mucho en lo que a mí me gustaría saber cómo programador: Qué entraba en la demo y qué no tenía que estar hecho. Tras un par de horas de reunión llegamos a un acuerdo, una serie de cosas hechas con una serie de faltantes, junto con un plazo de tiempo que yo consideraba razonable.

Después de eso hice una planificación por semanas con la gente disponible, para llegar a esa demo en plazo. La planificación era apurada, pero razonable. Además, con intención de aprovechar lo que cada uno sabía hacer, hice algo que se salía de lo normal. En vez de dar una funcionalidad a cada una de las personas, repartí cada funcionalidad entre varios, de forma que cada persona hiciera dentro de esa funcionalidad lo que mejor sabía a hacer. Puse a hacer todos los gráficos al que sabía de gráficos, pequeñas librerías de componentes reutilizables a los más nuevos que desconocían el proyecto, pero sabían programar, etc, etc. El resultado de esta decisión es que el trabajo de uno dependía de que otro acabara previamente el suyo. El que tenía que integrar los gráficos en la ventana principal, tenía que esperar a que el de los gráficos los tuviera acabado. El que necesitaba el componente reutilizable en su parte de código, debía esperar a que este componente estuviera, etc, etc.

Hice una reunión al principio para explicar el objetivo de la demo, el plazo y las tareas que todos tenían asignadas hasta esa fecha. Todos los Lunes hacíamos una reunión para ver cómo íbamos, para ver si Fulanito había acabado su parte para que Menganito pudiera seguir con la suya, rehacer la planificación si era necesario, etc, etc. Yo, por mi parte, también estaba en esa planificación con mis cosas para hacer y era un programador más dentro del equipo -aunque con menos código para hacer y algo más de responsabilidad-. También me encargaba, casi a diario, de hablar con unos y otros y ver si tenían problemas para continuar con su tarea, si necesitaban algo, problemas, etc y trataba de ayudarles.

¿Y qué paso con todo eso?. La demo se cumplió y salió bien, pero lo que más me asombró fue lo que conseguí sin quererlo. La gente empezó, sin pedírselo y ni siquiera insinuárselo, a echar horas extras e incluso me pidieron permiso para venir los sábados: "Estoy a punto de acabar y me falta un poco para dejarlo "niquelado". ¿puedo venir el sábado para terminarlo?". Incluso gente que tenía fama de cumplir estrictamente su horario y ser de los que diez minutos antes de la hora se está preparando para salir, empezaron a quedarse más tiempo según nos acercábamos al fin de semana y se veían apurados para acabar su parte. El Viernes salimos a las dos y media. Algunos llegaron a quedarse hasta las ocho de la tarde, insisto, sin ni siquiera insinuárselo.

Mi conclusión es que la gente, en general, se siente responsable de su trabajo. Si a una persona le das un plazo razonable, pero ajustado, de tiempo para hacer un trabajo y le haces ver la importancia de que su trabajo esté: Un compañero depende de ese trabajo para seguir con el suyo, el jefe le pregunta cómo va y se preocupa de allanarle el camino, etc, esa persona al final tiende a dar todo de sí para que su trabajo esté en el plazo.

Para que una planificación funcione, se cumpla y motive a la gente a seguirla, creo que debería cumplir más o menos los siguientes puntos

  1. Un objetivo claro a un plazo no muy largo, uno o dos meses, con una planificación razonable, pero ajustada. Que la gente lo vea posible, pero sin dar opción a perder el tiempo. Si el objetivo es importante, como una visita del cliente o un jefazo, mejor que si es simplemente un objetivo interno que no pasa nada si no se cumple.
  2. Tareas asignadas a cada persona a corto plazo, a una semana, por ejemplo. Cada programador debe saber qué tiene que hacer ahora y qué va a hacer después.
  3. Las tareas de unas personas deberían ser necesarias para que otras personas puedan realizar las suyas a la semana siguiente. De esta forma, cada persona ve la necesidad de acabar sus tareas en los plazos cortos establecidos y siente que su trabajo es importante y necesario.
  4. El "jefe" debe tener también sus tareas en la planificación, que se le vea que trabaja y debe preocuparse de resolver los problemas que tengan los programadores para cumplir sus tareas. De esta forma se refuerza el que los programadores sientan que su trabajo es necesario e importante.
  5. Seguimiento de la planificación. Reuniones frecuentes -por ejemplo, una vez por semana- para ver qué hay hecho, retocar la planificación si hace falta, etc. En estas reuniones, si un programador no ha cumplido, sin necesidad de echarle la bronca ni ponerle mala cara, verá que la consecuencia es que hay que retocar la planificación y que otras personas van a tener que retrasar su propio trabajo.

Sin embargo, todo esto también me creó un cargo de conciencia importante. Siempre he sido más currito que jefe y me he identificado más con los curritos que con los jefes. Hacer una planificación de este estilo sabiendo que posiblemente consigas que la gente eche horas extras sin pedírselo, me parece "jugar" con la gente, típico de jefe pérfido, malvado y sobre todo manipulador. De hecho, al que me pidió permiso para venir un sábado le dije que no lo hiciera, que cuando llegaran los hitos importantes con el cliente -entrega del proyecto- ya habría ocasión de quedarse y posiblemente obligados.

También tuve otro tipo de problemas con esta planificación. Una funcionalidad la repartí entre dos personas de carácter fuerte y algo conflictivo. La "estrecha" colaboración entre ambos hizo que acabaran peleándose y no volvieran a hablarse. Supongo que en parte fue culpa mía, que debería haber definido con más detalle el trabajo asignado a cada uno de ellos y la interface entre ambas partes del programa.

Esta entrada fue publicada en metodologías. Guarda el enlace permanente.

Una respuesta en “Aprendiendo a ser un jefe pérfido

  1. Pingback: Diario de Programación » Blog Archive » ¿La programación es una carrera que llena tu vida?

Deja una respuesta

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

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.