No te olvides de poner el Where...

Si alguna vez has programado, creo que tienes que ver y oír esto.

http://www.youtube.com/watch?v=i_cVJgIz_Cs

Ha pasado un mes sin publicar anda en este blog, y ya era demasiado tiempo. Y al ver esta entrada de forma fortuita en linkedin, no me he podido resistir. Merecía la pena ponerlo y guardar este momento. Que aproveche...

Gracias a Jorge Eduardo Olaya Perdomo por compartirlo y permitirme conocer la existencia de este vídeo. Y a Jorge Rubira, por publicarlo en YouTube. Saludos.

Trucos para un buen informe de seguimiento

Leía hace poco un artículo en el excelente blog de Javier Garzás, sobre lo que nunca debería faltar en un informe de seguimiento. Y me he quedado con una sensación de que me faltaba algo. En primer lugar, los informes de seguimiento no son algo estándar y cerrado válido para cualquier proyecto. Empezaremos por pensar en los objetivos del informe.

Objetivos del informe de seguimiento.

Este tipo de informes, se realizan periódicamente con el cliente en un proyecto (de software o de cualquier tipo). El informe de seguimiento software pretende:

• Identificar brevemente el proyecto. Un par de frases, un resumen del plan o del proyecto en cuestión. Esto es útil en clientes para los que trabajan múltiples proveedores. Hay que tener en cuenta que estas reuniones las sufren constantemente, y el cliente necesita que "les hagamos una introducción". No podemos llegar y empezar a soltar nuestro rollo. Recordad: adaptar el mensaje a lo que necesita el cliente, no a lo que queremos contar nosotros.
• Mostrar los objetivos del proyecto. ¿Qué se quería hacer? ¿Cuáles son los objetivos?
• Mostrar de forma resumida el estado del proyecto (precisamente respecto a esos objetivos). El estado incluye cosas como revisión de posibles desviaciones en la fecha de fin, esfuerzos dedicados, o costes. Seguimiento de hitos y entregables. Cumplimiento del contrato, y los distintos acuerdos alcanzados. El estado supone comparar la situación actual respecto al global del proyecto: el coste total, el esfuerzo total en horas estimado, y la fecha final de entrega (entre otros). Presupone una planificación y un seguimiento respecto a la misma.
• Mostrar los riesgos y su estado. Siempre hay riesgos. No gestionarlos, no dedicar tiempo de gestión, planificación y seguimiento no hace que desaparezcan.
• Mostrar los problemas y su estado. Los problemas, se refieren aquí a problemas de gestión. No a incidentes o fallos del software. Los problemas surgen en cualquier momento (un entorno no disponible, una tecnología que no funciona, un profesional que se va de la empresa...). Los problemas han podido ser detectados previamente (como riesgos), o surgir de imprevisto.
• Hitos clave y su estado. En todo proyecto suele haber fechas clave, que incluso pueden determinar el poder facturar o no todo o parte del proyecto.
• Entregables clave y su estado. Los proyectos no son solo código. Suelen llevar otros entregables (documentos, hardware,...), y que estarán recogidos en el contrato u objetivos iniciales.

Otros posibles contenidos el informe de seguimiento.

Vamos a ver otras cosas que pueden incluirse en un informe de seguimiento, pero que hay que pensarse bien si encajan en el tipo de seguimiento que pretendemos presentar:

• Avance del proyecto. No es lo mismo avance que estado. Al hablar de avance, nos referimos a lo incorporado desde la reunión de seguimiento anterior. Este tipo de reunión sería incremental, y trata de mostrar la diferencia respecto a lo anterior. De nuevo, este tipo de información suele darse en proyectos ágiles. Cuidado con esto, porque estamos mostrando la situación relativa respecto a un estado anterior, pero no respecto al proyecto total (eso sería un estado del proyecto). En proyectos ágiles, habría que dar también un estado, es decir, informar de cómo nos encontramos respecto al total del proyecto, informando de un coste estimado, fecha estimada de finalización, etc, etc.
• Estado de la calidad. Soy defensor de la calidad, y creo que hay que planificarla, establecerla muy al principio, y utilizar para ello indicadores lo más objetivos posibles. Sin embargo, en el tipo de clientes que he visto en mis bastantes años de vida profesional, no metería gráficas ni un análisis semanal de métricas (pocos clientes los entenderían). Eso sí, esos análisis los haría "de puertas para adentro", y lo convertiría en un semáforo donde se indicara si dichos indicadores están bien, o si por el contrario alguno de ellos no se está cumpliendo. Este tipo de indicadores, por ejemplo, lo trataría en un informe de seguimiento técnico, no en un comité ejecutivo. Por desgracia, los indicadores de calidad no son entendibles, y pueden dar lugar a falsos equívocos, preocupaciones innecesarias. Lo que hay que hacer es evidenciar que se trabaja con calidad dentro de un margen, y que se trata no de dar un producto perfecto, sino un producto con un buen balance entre coste y calidad. Por supuesto, siempre es posible que un sistema automatizado, u otra empresa certificadora, sea quien presente el estado de la calidad.
• Demo del software. Una demo del software, no siempre podrá realizarse con los clientes en todas las reuniones del seguimiento. Básicamente, porque una reunión de seguimiento ha de ser algo muy concreto, muy enfocado, y una revisión funcional del software puede llevarnos mucho tiempo. Por otro lado, una demo no se hace cada 1, 2, o 3 semanas. Tal vez sí en proyectos ágiles que lleven asociado un cliente deseoso de ver ese software avanzar. Pero no siempre. Una última cosa. Las demos son caras. Se dedica tiempo y recursos en preparar una demo. Y no sólo por el software: están las personas que asisten (cuyo tiempo es caro, y hay que respetar), están los datos, que han de estar listos para presentar el software (la gente no quiere ver el software, quiere ver las cosas que es capaz de hacer, y eso requiere de una preparación de datos previa).

Al final, no existe un informe perfecto. El informe debe servir al cliente y a los propósitos del proyecto. Todo lo aquí comentado suele incluir se en informes, pero hemos de recordar que no todas las reuniones de seguimiento son iguales.

Antes de presentarnos a una reunión, deberemos: establecer qué necesita el cliente, cuál es el ámbito del proyecto... De todas formas, yo recomendaría siempre al principio del proyecto establecer claramente:

• Modelo de relación: tipos de reunión, quiénes asistirán, decisiones a revisar, periodicidad...
• En cada tipo reunión, definir qué informe se revisará, contenido, roles (quién lo presenta, quién lo aprueba, etc).

El necesario estrés

Hablando el otro día con un compañero de trabajo, me contaba una interesante metáfora.

Había un pescador que pescaba atunes, pero los tiburones diezmaron la pesca. Y para evitar arruinarse, tuvo una gran idea. Decidió crear una piscifactoría, criar los atunes en cautividad, y venderlos para así obtener grandes beneficios. Pronto se dio cuenta de que los atunes no se vendían tanto como él pensaba. El motivo era que tenían demasiada grasa. En cautividad, los atunes se criaban gordos, y no tenían un incentivo que les hiciese hacer ejercicio.

Recordando cómo era la pesca en el mar, pensó que los atunes libres se crian con un sabor perfecto, y hacen mucho ejercicio porque deben sobrevivir. Así que decidió traer un tiburón y soltarlo en la piscifactoría. Pronto, los atunes ganaron en calidad, mejoraron su sabor, y se criaron más sanos y produciendo unas mejores ventas. Incluso considerando las pérdidas producidas por el ataque del tiburón, merecía la pena.

Al final, el motivo era la introducción de un nivel de estrés pequeño, pero suficiente para que los atunes se vieran en la necesidad de sobrevivir, criarse ágiles y sanos.

Al final, la moraleja que comentaba con este compañero es clara: un poco de estrés es bueno. Sin un incentivo, sin la adecuada presión...la gente se relaja. Y demasiada relajación, no nos lleva a los éxitos, ni provoca que la gente se estimule en mejorar su código, su planificación, sus pruebas...

Al final, PON UN POCO DE ESTRES EN TU VIDA. ¿Pero sin pasarse, eh?