Métricas de valor

Introducción

Hace poco tuve la oportunidad de participar en una charla sobre métricas que midan el valor real generado por los equipos de desarrollo y que sean de utilidad para mantener el proyecto por el camino correcto. Entre los asistentes había gerentes de proyecto, analistas de calidad, diseñadores gráficos y desarrolladores. Arrancamos discutiendo cuales son las métricas que utilizamos o hemos utilizado en los proyectos. 

• Productividad de los desarrolladores: Cantidad de líneas de código escritas por unidad de tiempo, cantidad de puntos de historias completados…
• Cumplimiento de compromisos: Cantidad de compromisos realizados Vs compromisos cumplidos
• Indicadores de calidad: Cantidad de criterios de aceptación Vs Cantidad de Bugs, tasa de resolución de Bugs por unidad de tiempo…
• Indicadores que permitan medir el avance del proyecto: Valor ganado, Cantidad de historias de usuario completadas Vs cantidad total de historias…
• Generación de valor de negocio y clientes felices: ¿?

Fue curioso ver como los asistentes tenían muy clara la forma de medir la productividad, el cumplimiento de compromisos, la calidad, y el avance del proyecto, pero no tenían idea de cómo medir la generación de valor al negocio y la satisfacción de los usuarios finales. ¿Acaso esto no es lo único que realmente importa? 

De esta manera iniciamos un ciclo de discusiones en el que analizamos cada uno de los grupos de indicadores que teníamos sobre la mesa.

Productividad de los desarrolladores (¿Cuánto puedes hacer en 8.5 Horas nalga?)

La productividad individual aniquila cualquier intento de trabajo en equipo que se quiera promover dentro de una organización. Cuando alguien requiere ayuda para terminar su trabajo y pide colaboración a uno de sus compañeros, ¿Creen que este le va a ayudar poniendo en riesgo el cumplimiento de sus metas? Nadie querrá afectar sus indicadores individuales por ayudar a otro. 

Por otro lado podríamos medir la productividad de todo un equipo y de esta manera promover una cultura de trabajo cooperativo (Tal y como lo hacen las metodologías ágiles con sus gráficos de velocity y burn down chart) lo cual está bien. El problema con esto es que completar muchas funcionalidades de software no hará tu cliente más feliz.

Lo que realmente lo hará feliz es ver como lo que has hecho le permite reducir la operatividad de sus procesos de negocio o como ha podido incrementar sus clientes sin tener que contratar más personal. Y esto no se mide con la cantidad de story points completados por sprint. Va mucho más allá, requiere sentido de equipo, transciende el desarrollo mismo del software llevando a los equipos hacia el diseño de productos que habiliten nuevas capacidades en los negocios y no se limita a terminar el desarrollo de la funcionalidad, termina solo cuando aquello que construimos está siendo usado por nuestro cliente en producción y está generando el impacto que teníamos previsto.

Hoy quienes trabajamos con metodologías ágiles medimos las eficiencia de los equipos de desarrollo a partir de sus gráficos de velocidad, pero no vemos que muchas veces el product owner esta priorizando tareas (De forma similar a lo que hacíamos con los cronogramas) y no se está enfocando en pequeños impactos de negocio que se puedan poner en producción de forma rápida y que puedan ser usados tan pronto como sean liberados. 

Ahora, con lo planteado ¿Creen que las métricas de productividad son realmente de utilidad para determinar el logro de los objetivos del proyecto? Yo pienso que si son de utilidad para medir la capacidad de trabajo del equipo y ajustar los compromisos realizados de forma más realista pero no más que eso. 

La pregunta ahora es ¿Cuánto podemos lograr en un periodo de tiempo?

Cumplimiento de compromisos

Este es un tema bastante complejo. Por un lado es difícil cumplir en ambientes cambiantes y de mucha incertidumbre, pero es importante porque los seres humanos nos movemos a partir de compromisos (¿Quién no se pondría furioso si la compañía de telecomunicaciones no instala el servicio de internet el día y a la hora acordados?). 

Cuando incumplimos frecuentemente, generamos un ambiente de desconfianza en el cual es difícil desenvolverse.  De modo que  si podemos comprometernos hagámoslo y cumplamos, pero si nos sentimos indecisos, es mejor abstenerse.

En este orden de ideas, ¿Realmente tiene sentido tener indicadores de cumplimiento? Más allá de estos, debemos preocuparnos por nuestra credibilidad y mantenerla en alto. Si eventualmente no podemos cumplir comuniquemos de la mejor manera y negociemos en el momento justo.

Indicadores de calidad

¿Y qué es la calidad? Finalmente un producto es de calidad si satisface las necesidades y cumple con las expectativas de quien lo adquiere. En este orden de ideas depende de las personas que interactúan con él. Entonces ¿Tiene sentido decir que el producto tiene una calidad del 50%? 

Es claro que si el sistema tiene fallas tendremos que conocerlas priorizarlas e implementarlas porque de otra manera no podrá ser usado ni generar el impacto deseado en el negocio, pero ¿Qué sentido tiene manejarlos como Bugs?, ¿Por qué no manejarlos simplemente como cambios realizados al sistema de igual manera como se hace con las historias de usuario?.

Los Bugs solo promueven una cultura de culpables, debilitan el trabajo en equipo y hacen que pasemos largas horas justificando lo que pasó.

Esto no quiere decir que se admitan productos de mala calidad. Significa que tan pronto como se presenta el error, este se corrige al igual que el proceso para que no se vuelva a presentar. Nadie es perfecto y una cultura que penaliza los errores solo desmotiva y genera temor en las personas. Y el temor es el peor enemigo de la creatividad.

Indicadores que permitan medir el avance del proyecto

¿Realmente necesito medir que tantas funcionalidades he completado en un periodo de tiempo? O es más importante saber ¿Qué tantos impactos positivos he generado en el negocio? Es muy frecuente tener grandes funcionalidades construidas que no se encuentran articuladas entre si y por ende no pueden generar el impacto deseado.

GENERACIÓN DE VALOR DE NEGOCIO Y CLIENTES FELICES 

Todo nuestro esfuerzo solo tiene sentido cuando logramos un impacto positivo sobre las personas y/o el negocio. Y esto no lo determina el nivel de productividad individual o del equipo, ni el haber cumplido todos los compromisos establecidos durante un periodo de tiempo, ni los bellos gráficos indicadores de Bugs por funcionalidades que ponen en evidencia cuan mal programadores podemos ser, ni mucho menos la cantidad de funcionalidades completadas en el tiempo.

Existen 3 métricas que pueden ser muy útiles y nos pueden ayudar a medir cuan eficientes somos al entregar valor. 

Cycle time (CT)

Es el tiempo total transcurrido para mover una unidad de trabajo desde el comienzo hasta el final de un proceso. Llevándolo a un proceso de desarrollo de software SCRUM, se trata del tiempo transcurrido desde que una historia de usuario es priorizada por el equipo hasta que se transforma en una unidad de software funcional e incluye el esfuerzo real realizado por las personas más los tiempos de delay que puedan retrasar la construcción tales como dependencias con otros procesos.

Pero… ¿Tener una funcionalidad completada genera impacto sobre el negocio?.

Lead time (LT)

Es el tiempo total transcurrido desde que el cliente realiza la solicitud hasta que se le entrega un producto terminado. 

¿Una funcionalidad de software es un producto terminado?, ¿La única forma de entregar un producto terminado es completar todas las funcionalidades que se solicitan?. 

Observen el siguiente escenario.

Un teatro desea ampliar su canal de ventas y ofrecer a los usuarios la posibilidad de comprar boletos de cine por Internet (Ese es su objetivo final de negocio). Después de realizar el análisis encontramos que se pueden generar varios impactos adicionales antes de tener el canal de Internet plenamente habilitado: 

Pequeños impactos de negocio	Funcionalidades
Permitir a los usuarios consultar la cartelera de películas disponibles y sus horarios.	Realizar el registro de las películas en cartelera Consultar las películas en cartelera …
Permitir a los usuarios ver la disponibilidad de asientos en cada película para que no pierdan el desplazamiento hasta el teatro si no hay disponibilidad.	Consultar La cantidad de asientos disponibles Mostrar la imagen del teatro y marcar los asientos ocupados en otro color. …
Permitir a los usuarios realizar la reserva de los asientos por Internet y que el pago lo hagan en la taquilla.	Permitir a los usuarios seleccionar una silla disponible y realizar el registro de la reserva. Validar que el tiempo que falta para iniciar la película sea menor a 2 horas. Si el cliente es VIP se le permite reservar sillas preferenciales. …
Permitir a los usuarios pagar con tarjetas débito por Internet	…
Permitir a los usuarios pagar con tarjetas de crédito por Internet.	…
Permitir a los usuarios cancelar las reservas por Internet.	…

Como lo vemos en el ejemplo anterior, en realidad podemos generar muchos pequeños impactos frecuentemente que empiecen satisfacer las necesidades del cliente. 

Funcionalidad no es igual a impacto 

Lo que veo hoy en la realidad diaria de los proyectos es que nos quedamos observando los gráficos de velocidad y decimos que vamos bien. El product owner se limita a priorizar funcionalidades en el backlog que muchas veces apuntan a objetivos diferentes y por ende el tiempo total de generación de valor al cliente es muy alto. Trabajamos en muchas funcionalidades con una velocidad y productividad muy buena como equipo, pero aún no logramos entregar valor a ese mismo ritmo.

Por supuesto que es importante mantener unos buenos niveles de productividad (Velocidad), esto demuestra la madurez del equipo en el tiempo, pero me parece más importante que como equipo nos empecemos a sensibilizar mas respecto a lo que debemos lograr y no tanto a lo que hay que hacer. WORK SMARTER NOT HARDER. Solo cuando logramos un pequeño impacto que pueda ser usado en condiciones reales por el negocio en producción recibimos un verdadero feedback y justo ahí empezamos a mejorar el producto. Las review en ambientes de prueba normalmente revisan que el software satisfaga los criterios de aceptación, pero ¿Acaso el product owner tiene la capacidad de pensar en los cientos de escenarios bajo los cuales se mueve un negocio en su realidad diaria?

Process efficiency

Finalmente podríamos utilizar un tercer indicador que nos permita conocer cuan eficientes somos a la hora de entregar valor. Esta eficiencia se puede analizar desde dos ángulos.

• Eficiencia del proceso de construcción (EC): Ya mencionamos que el cycle time (CT) nos permite conocer nuestra capacidad como equipo para construir funcionalidades pero este tiempo se ve afectado por dos factores.

Value Added Time (VAT): Es el tiempo invertido realmente por el equipo en actividades que aportan valor a la funcionalidad que está siendo construida. Es importante aclarar que el entrenamiento y slack time disponible para que el equipo mejore continuamente hace parte de las actividades que generan valor.

Non value Added Time (NAT): Es el tiempo muerto en el que el equipo no puede construir por dependencias con otros procesos o por cualquier serie de impedimentos que pueda tener.

La eficiencia del proceso de construcción es entonces EC= VAT/CT.

Ejemplo: Si soy capaz de construir 10 historias de usuario en 40 Horas o 1 sprint (Cycle time) y el esfuerzo invertido realmente en construcción fue de 30Horas (Value added time), estando las 10 horas restantes involucradas en actividades de gestión, llamadas, solicitudes para conseguir insumos (Non value added time), etc, la eficiencia de mi proceso de construcción es

EC=30/40= 75%

• Eficiencia de generación de valor (EV): ¿Qué tan eficientes somos para que lo que construimos impacte en el negocio o las personas? EV=CT/LT

Sprints 1 semana (40 Horas)	Escenario 1	Escenario 2
Sprint 1	Realizar el registro de las películas en cartelera	Realizar el registro de las películas en cartelera
Sprint 2	Validar que el tiempo que falta para iniciar la película sea menor a 2 horas.	Consultar las películas en cartelera
Sprint 3	Consultar La cantidad de asientos disponibles	IMPACTO: Permitir a los usuarios consultar la cartelera de películas disponibles y sus horarios.
Sprint 4	Consultar las películas en cartelera	Cycle time = 2 Sprints= 80 Horas Lead time = 2 Sprints = 80 Horas + (Tiempo de salida a producción) EV= 80/80= 100% (Podría ser menos si el proceso de salida a producción tarda mucho)
	IMPACTO: Permitir a los usuarios consultar la cartelera de películas disponibles y sus horarios.	…..
	Cycle time = 2 Sprints= 80 Horas Lead time = 4 Sprints = 160 Horas + (Tiempo de salida a producción) EV= 80/160= 50% (Podría ser menos si el proceso de salida a producción tarda mucho)	…..

Mientras más cerca esté el lead time del cycle time más eficiente será nuestro proceso.

No sé a ciencia cierta cómo medir la felicidad de los clientes (No he tenido dinero para comprar el felizómetro) pero si estoy seguro de que la ansiedad será menor cuando entregamos, pues las personas empiezan a ver el resultado de su inversión y muy probablemente esto los haga felices o la menos los tenga tranquilos.