Visibilidad

La falta de visibilidad sobre los proyectos de una organización podría considerarse un escenario equivalente a no disponer de iluminación para inspeccionar como se está cocinando el Volcán de Chocolate en el interior del horno.

En el contexto de desarrollo de software, es posible dirigir la visiblidad sobre un proyecto en tres sentidos; hacia el cliente, hacia la organización y hacia los miembros del equipo.

Planteados los distintos destinatarios, es común que se presentarse una pequeña pero no por eso poco importante dicotomía:

  • Dar el mismo nivel de visiblidad en las tres direcciones
  • Ajustar la información en función del grupo al que está dirigida
  • Las prácticas de Scrum están fuertemente alineadas con la primera de las opciones, defendiendo la transparencia sobre estado del proyecto. Por otro lado, la segunda de las opciones tiene sus incuestionables beneficios, pero se le asocia la desventaja de tener que sumar a la inversión de esfuerzo que requiere generar los informes, el trabajo de adaptarlos.

    Las métricas automáticas proveen una solución cuantitativa concreta para obtener clara visiblidad sobre variables significativas de un proyecto…  Pero claro, una solución tan maravillosa no puede menos que ser cara, difícil de mantener y requerir mucha disciplina por parte todos los miembros del proyecto…

    Una práctica que maximiza la relación costo beneficio en este plano es realizar reuniones de avance periódicas. En dichos encuentros es posible presentar el estado del proyecto, los desvíos respecto a la planificación y la lista de riesgos.  Adicionalmente, reuniones complementarias a las de avance, como el kickoff y el postmortem (o restrospective -como le dicen los ágiles-) también proveen un montón de visibilidad sobre los proyectos y los procesos de la organización.

    Como conclusión,  podríamos decir que resulta central para la salud de nuestros proyectos que los involucrados puedan advertir con claridad el estado actual, hacia donde se dirigen, y cuán bien -o mal- encaminados están. Y en definitiva, lo que cueste esta práctica siempre va a ser un precio menor al costo asociado a que los involucrados en un proyecto no sepan en donde están ni hacia donde  van.

    Share and Enjoy:
    • Print
    • Digg
    • StumbleUpon
    • del.icio.us
    • Facebook
    • Yahoo! Buzz
    • Twitter
    • Google Bookmarks

    3 Comments

    • Hola, muy bueno el post. Me gustaria conocer sus opiniones sobre los aspectos de dar visibilidad:
      – frecuencia (de retrospective, postmortem, retrospective… whatever the name)
      – contenidos y nivel de detalle
      – manera (oral, escrita, excel, presentacion, valores de metricas + discusion, etc.)

      Todo esto (imagino) es ajustable segun la audiencia y la cultura de la organización en la que está inmerso el proyecto. Me gustaría leer algun post sobre estos temas.

      Saludos,
      Raul Latashen

      • Ajustable al contexto del proyecto y la cultura de la organización, totalmente de acuerdo con eso. Creo que una variable de referencia importante para definir los dos primeros puntos que planteás (frecuencia y contenidos) es el desvío y sus consecuencias. Es decir, cada cuanto tengo que dar visiblidad depende de manera directa del intervalo de tiempo en el cual el proyecto evoluciona lo suficiente como para que el impacto del desvío sea alto. Respecto a los contenidos y la modalidad, soy fuertemente partidaria de dejar algún tipo de documentación que refleje el estado del proyecto en un instante dado (foto), pero creo que requiere un complemento oral que de espacio a la discusión y el intercambio de ideas. Si hay valores cuantitativos, genial, pero no hay que olvidar que lo realmente da visiblidad son los indicadores (y no así las métricas). Próximamente un post sobre atributos, medidas, métricas e indicadores.

        Gracias Raul! Abrazo, Natty.

    • […] métricas e indicadores proveen un alto nivel de visibilidad sobre procesos, proyectos y productos. En particular, si lo que se pretende es exposición de […]

    Leave a comment