Unidades de control y de valor

Un enfoque para la gestión del desarrollo de software

Un enfoque de valor en la gestión del desarrollo de software

Consideren tres tableros, de los típicos que vemos en organizaciones que adoptan métodos ágiles para la gestión de proyectos.

El primero es el clásico tablero kanban. Puede ser el clásico de SCRUM con sus tres columnas típicas: “por hacer”, “en progreso” y “listo”, o uno más sofisticado con columnas que representan el flujo del proceso de desarrollo propio de esa empresa o equipo.

El segundo es un “burn down chart”, este gráfico nos ayuda a medir cómo vamos “quemando” etapas de un proyecto. En SCRUM es bien popular porque permite “predecir” si lograremos cumplir con la estimación del sprint.

Y el tercer tablero no es tan común, pero lo he visto en muy pocas organizaciones. Se trata publicar ciertas métricas de productividad y calidad básicas, como la cantidad de pull requests diarios y la cantidad de fallos en producción. Este es un tablero de los típicos que veríamos en entornos que practican SRE, por ejemplo, donde se podría deducir el “toil” o el “Presupuesto de Fallo”.

Los dos primeros tableros son los clásicos tableros de control. Sirven para medir el “cómo vamos”, dejan contentos a los gerentes y a los directores, pero no aportan mucho más¹.

El tercer tablero entrega medidas de valor. Si estamos desarrollando software, la métrica más importante es código que implementa una funcionalidad y se ejecuta sin fallas. Así que desde este punto de vista, este tablero nos indica el valor entregado por el equipo.

Podrán decir que una historia de usuario cerrada es valor entregado, pero no lo veo así. Una historia de usuario es una referencia, una especificación de qué queremos hacer, el valor está en el artefacto entregado, en nuestro caso, el código ejecutándose en producción.

Por eso que yo separo estos tableros en dos tipos: de control y de valor. Ambos tipos de tableros son valiosos, pero no debemos perdernos en el objetivo real. Si solo te centras en el control de tareas realizadas, pierdes de vista lo que realmente importa: software funcionando correctamente.

Para mí hay tres modos de gestión, la de costos (o negativa), la de procesos (o de valor nulo), y la gestión de valor (o positiva). La perspectiva acá está centrada en la idea de generar riqueza.

La gestión del proceso, de las cosas que debes hacer en el día a día, es neutra en sí misma, pues depende si el proceso genera o no genera valor al final. La ejecución de tareas en un orden, siguiendo un plan, no garantiza ni éxito ni fracaso, solo garantiza que hiciste cosas de la forma en que se esperaba que lo hicieras. O, visto desde la perspectiva de los agilistas, lo que importa es lograr más que hacer.

Por otro lado, tal como dice Goldratt, la meta final de toda empresa es ganar dinero y una de las mejores maneras de generar riquezas es cuando te enfocas en crear valor. Si te centras en solo gestionar los costos no usas tu creatividad para generar más riqueza. Hay muchos argumentos para explicar por qué la gestión centrada en la reducción de costos afecta la productividad, si les interesa, pueden leer los argumentos expuestos por Goldratt en su famoso libro “La Meta”, lo importante es que hoy sabemos que es mejor centrar nuestros esfuerzos en la generación de valor.

Y por eso que es relevante identificar las unidades de valor y separarlas de las unidades de control. Cuando aprendas esta distinción básica habrás dado un gran salto en tu gestión de proyectos de desarrollo de software.

1. Probablemente el burn down chart sea un tablero que mide costos, y quizás por eso siempre he encontrado que tiene un aporte negativo