jueves, 13 de noviembre de 2008

Pedrito (el líder de proyecto) y el lobo: la importancia del feedback.

Todos conocen la historia de Pedro y el lobo. Por las dudas se las refresco:

<spoiler>

Pedro era un pastor que se divertía gritando que venía el lobo sólo para molestar a la gente del pueblo, que corría inútilmente a ayudarlo. Hasta que finalmente vino el lobo. Pedro gritó pero como lo había hecho tantas veces en broma nadie le creyó... Las versiones varían: en el cuento infantil se dice que el lobo se comió unas ovejas, yo digo que también atacó a Pedro y lo dejó inválido y deforme para toda la vida.

</spoiler>

A veces sucede algo por el estilo en el desarrollo de software: se establece una fecha difícil (mas no imposible) de cumplir, la presión se hace sentir, el equipo hace un esfuerzo extra, se trabaja a las apuradas, a deshoras, se llega a tiempo o no, y luego... nada.

¿Nada? Sí, nada. Ni para bien ni para mal. Nada si se ha cumplido o alguna suerte de reprimenda o discurso sobre la responsabilidad, la confianza y los compromisos asumidos, si es que no. La vida sigue, el desarrollo continúa, se agregan funcionalidades, se corrigen errores... la presión desaparece...

Supongamos que ésa es la situación percibida, ¿cuál es el origen? Si no tenemos más información hay que inventarla. Inventemos. Me imagino tres escenarios, que se pueden ir completando a placer:

  1. La fecha límite fue artificialmente establecida para "meter presión" al equipo. La creencia subyacente puede ser que la gente se "relaja" cuando no tiene un límite de tiempo, se pierde en detalles o simplemente vaguea.

  2. La fecha era real, pero poco importante. No hay un cliente comprometido ni socios desesperados. El líder apunta que (a ojo de buen cubero) no está tan lejos de "quedar bien" hacia arriba terminando justo a tiempo (o un poco antes) si presiona hacia abajo. O tal vez era un hito interno en su línea de tiempo, y exagerar la importancia de esas fechas es su manera de tener las riendas cortas.

    Así que presiona. Si llega mejor, y se olvida de bajar las felicitaciones (o no las hubo, porque esto puede suceder a cualquier nivel). Si no se llega aparece el discurso un tanto licuado y abstracto mencionado más arriba, porque al fin y al cabo no hay una gran mala noticia.

  3. El límite existe, y sí era importante.

    Una posibilidad es que el líder haya utilizado su cintura para "zafar" de la situación y todo pasó de largo.

    Otra posibilidad es que, intentando "resguardar" al equipo de presiones excesivas, actuó como paraguas y no bajó el escarmiento.

En resumen: la fecha no existía, o sí pero no era importante, o sí pero el equipo no se enteró de las consecuencias.

Independientemente del origen o las causas subyacentes, si la comedia anterior se representa un par de veces los integrantes del equipo reaccionan como los habitantes del pueblo: simplemente se vuelven inmunes a las fechas límite y renuentes a hacer cualquier esfuerzo extra para cumplirlas.

Esta reacción es esperable, incluso la más lógica y, desde el punto de vista del equipo, la más sana. La experiencia les ha enseñado que esforzarse por alcanzar esas fechas no tiene ningún beneficio, ni su incumplimiento consecuencia alguna.

Es terríblemente difícil salir de esta situación sin un hito desagradable (como sería para Pedro aparecer sin un brazo o una pierna) o costoso (Pedro podría perder algunas ovejas), un golpe de efecto. Se necesitaría, por ejemplo, la pérdida de un cliente o la aparición de un bonus por cumplimiento de la fecha de entrega. Desagradable o costoso. Malo o menos malo (desde el punto de vista de la empresa), malo o bueno (desde el punto de vista del equipo).

Pensemos en cómo el feedback, en cualquier caso, modifica las cosas (cada punto es el correspondiente a la situación mencionada arriba):

  1. Por más que la fecha establecida sea "artifical", proporcionar feedback demuestra preocupación por el estado del proyecto, conciencia de su estado, monitoreo constante. Es decir, demuestra la importancia que se le asigna, el interés que tiene para el líder. Sea este interés ficticio o no, motiva. O por lo menos no desmotiva, como sí lo hace una fecha que luego pasa prácticamente desapercibida.
  2. Si la fecha es poco importante, se aplica el mismo razonamiento del punto anterior. Podemos además agregar que la fecha alguna importancia tiene. Si es importante para el líder puede ser importante para el equipo. Por ejemplo, quedar bien hacia arriba es un beneficio que se multiplica al ser extendido a cada uno. ¿Por qué no hacerlo?
  3. Si la fecha era realmente importante, es tal vez el peor caso. Los motivos para el compromiso están, pero no son transmitidos. No es raro notar la falta de éste.

En todo caso, la ausencia de feedback sólo puede dar indicios negativos: poco interés en el proyecto o presión acumulada en "algún lado" o manipulación grosera y finalmente inútil (BTW: ¿"manipulación" es "motivación grosera" por definición?), un líder ausente o... no perfecto (para decirlo políticamente).

Un líder de proyecto tiene muchas tareas y atribuciones. Pero para un equipo de profesionales todas pueden resumirse en una: establecer un medio en donde la información fluya, ya sea comunicando o facilitando u obligando a los demás a comunicarse, en todas la direcciones.

Hay mucho que comunicar en un proyecto de software: los requerimientos, las restricciones, los recursos, los avances, las novedades, los cambios, todo. En un equipo de profesionales, un líder no impone sino comunica... bueh, esto dependerá también de qué tan profesional sea el líder ¿no?

El hecho es que siendo un sistema de comunicación (ver artículos relacionados), cualquier problema de comunicación en un integrante del equipo, y más en el lider, es muy problemático.

Sobre esto último, algunos relacionados:

La autopista del desarrollo.

Una clase sobre buenos modales.

Comunica... ¿QUÉ?

Del desarrollo de software como sistema de comunicación y la importancia de poder leer y escribir.

No hay comentarios.: