lunes, 25 de noviembre de 2013

¿Porcentajes? Solo para las rebajas

Vivimos en un mundo en el que estamos acostumbrados a calcular porcentajes para todo.
Nos preguntan los niños ¿cuánto queda para llegar al destino?
Nos preguntamos en el trabajo ¿qué porcentaje de subida tendré este año?
Nos preguntan (otras veces simplemente nos dan la fecha de puesta en PROducción) a los jefes de proyecto de prueba ¿qué porcentaje de esfuerzo, respecto al desarrollo hay que incluir en la planificación para dimensionar adecuadamente los trabajos de prueba que hay que realizar?
A las preguntas de los niños decimos que estamos a la mitad de camino (50 %). A las subidas últimamente por la crisis estamos acostumbrados a que sea 0 %, o algo parecido.
Pero siempre que me preguntan por un porcentaje de referencia para dimensionar los esfuerzos de prueba siempre digo lo mismo: “Lo siento, pero los porcentajes solo para las rebajas en las tiendas”.
Para aplicar un porcentaje, hay que tener clara la validez que tiene el valor total del que parto.
En nuestro caso cuando nos dan un valor de esfuerzo en horas-hombre, ese valor representa el esfuerzo que alguien ha estimado que empleará en hacer una tarea, pero seguro que cada persona a la que preguntes te dará un valor diferente y es muy posible que dichos valores difieran mucho entre sí.
Entonces ¿qué sentido tiene aplicar un porcentaje sobre una estimación de esfuerzo que alguien nos ha dado, pero que no sabemos en qué ha basado sus estimaciones ni tampoco sabemos si son correctas?
Lo peor es que la persona que da esa estimación tampoco sabe si su estimación se cumplirá (en el 99,99% de las veces no se cumple). Te recomiendo ver el video de Rodrigo Corral, es un poco largo pero merece la pena (especialmente entre el minuto 9 y el 12).



Volviendo al tema de las rebajas es como si fuésemos de compras y nos dijesen que nos hacen una rebaja del 50% sobre el precio anterior, pero:


     - no supiésemos si el precio que nos dan es realmente el precio anterior, porque la tienda no sabe qué precio tenía antes y lo que ha realizado es una estimación,


     - no supiésemos si el artículo es el mismo que antes de la rebaja, si tiene más o menos funcionalidades, o si el material con el que está hecho es el mismo.

Lo vamos a ver muy claro con estas dos situaciones:


Proyecto 1:
Para un nuevo proyecto, el jefe del proyecto estima el tamaño del proyecto que le han encargado desarrollar en unas 42.000 HH de esfuerzo. El jefe del proyecto de pruebas decide dedicar un 10 % del tiempo de desarrollo para diseñar las pruebas (4.200 HH) y un 15 % para ejecutarlas (6.300 HH).
Proyecto 2:
Para otro proyecto, el jefe del proyecto estima el tamaño del proyecto que le han encargado desarrollar en unas 54.000 HH de esfuerzo. El jefe del proyecto de pruebas decide dedicar los mismos porcentajes: un 10 % del tiempo de desarrollo para diseñar las pruebas (5.400 HH) y un 15 % para ejecutarlas (8.100 HH).
Hasta aquí todo más o menos coherente. Los fans de los porcentajes opinarán que estos podrían ser mayores o menores en función del riesgo de los proyectos.
Una vez finalizados los desarrollos del Proyecto 1, comienzan las pruebas. El jefe del proyecto de pruebas se desespera porque no le da tiempo a finalizar de diseñar todas las pruebas que considera convenientes. Y se desespera todavía más cuando puede ejecutar solo unos pocos de los casos de pruebas diseñados, por lo que reporta muy pocos defectos.
Algo parecido le pasa al jefe del proyecto de pruebas del segundo proyecto, pero al revés. Le sobra un montón de tiempo para diseñar las pruebas que ha considerado conveniente. Y le sobra más tiempo todavía para ejecutar todas esas pruebas diseñadas y en consecuencia se reportan un número alto de defectos que al equipo de desarrollo no le da tiempo a corregir.
Estas dos situaciones son bastante comunes (aunque suele ser más común lo que le ocurre al primer proyecto que al segundo, ¿quizás por la falta de control de la productividad de los proveedores de desarrollo? ¿O quizá por la ley de Parkinson?).

¿Pero qué ha ocurrido?
Pues que en los dos casos un mismo cliente, que tenía necesidad de un conjunto de funcionalidades (de un valor de unos 3.000 Puntos Función), les ha adjudicado el mismo proyecto a dos proveedores diferentes.
En el caso de lo que hemos llamado el Proyecto 1 se le asignado a un equipo muy experto (con una tarifa muy cara) y el jefe del equipo experto estimó que, como su equipo era muy productivo, necesitaría solo 42.000 HH para desarrollarlo.
En el caso del Proyecto 2 se le asignó a un equipo menos experto (con una tarifa más barata) y el jefe del equipo menos experto estimó que, como su equipo era menos productivo, necesitaría 54.000 HH.
Pero en cualquier caso, desarrolle el proyecto un equipo muy productivo o uno menos productivo, las funcionalidades que se deberían probar tendrían que ser las mismas, por lo que los esfuerzos (suponiendo que la productividad del equipo de pruebas fuera la misma), debería ser similar.  
El problema está en que normalmente los jefes de proyecto de pruebas no tienen una idea de la productividad del equipo de desarrollo que va a realizar los mismos, pero sin embargo su estimación de esfuerzos se asocia a un valor que no controlan, por lo cual no saben si se quedarán cortos con sus estimaciones o muy largos.
Lo que deberían hacer es calcular el tamaño funcional (medido por ejemplo en Puntos Función, o puntos funcionales como dirían en Colombia) y a partir de estos tamaños funcionales estimar el volumen de trabajo de pruebas que hay que realizar: ¿qué número de casos de prueba hay que diseñar, construir y ejecutar?, ¿qué número de defectos hay que detectar y corregir?
Y con los valores estimados, aplicar ratios de productividad de pruebas para convertir esos valores en una estimación de esfuerzos de las actividades de pruebas.
De esta forma las estimaciones de pruebas que hacemos no están ligadas de ninguna forma al esfuerzo de los desarrollos, sino que están en relación al tamaño funcional de lo que hay que desarrollar.
Dicho en palabras de un CIO de uno de los principales bancos españoles: “dejar de pagar más al más torpe”. Pero esa es otra historia que contaremos en una futura entrada de este blog.
Por lo que os recomiendo que la próxima vez que os pregunten ¿qué porcentaje del esfuerzo de desarrollo es recomendable aplicar para las actividades de pruebas? respondáis: “lo siento, pero los porcentajes, solo para las rebajas en las tiendas”.

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...