QCyPC Indicadores_de_Control

¿Quality Control = Project Control?
Indicadores Objetivos para Control de Proyectos de Desarrollo de Software
Lic. Juan Pablo Pussacq Laborde
Jefe de la Oficina de Proyectos, RMyA

Introducción
El Problema
Es común que los proyectos de desarrollo de software terminen con importantes desvíos en costo y calendario o,
en algunos casos, que no terminen. Existen muchas causas a este problema. Una deellas es no contar con
buenas herramientas de control, a pesar de que generalmente tenemos buenas herramientas de planificación.
El objetivo de este trabajo es presentar algunas ideas que ayudan a tratar esta causa.
Como líderes de proyecto, nos hacemos muchas veces las siguientes preguntas:
¿Cuál es el grado de avance?

¿En qué fecha terminaremos?

¿Cuánto gastaremos realmente?

Normalmente noencontramos las respuestas o las encontramos y son muy poco confiables. Eso hace que no
tengamos buenos elementos para tomar decisiones.

Problemas clásicos
Uno de los problemas típicos es el síndrome del 90% (figura 1), síndrome por el cual el proyecto avanza sin
problemas hasta que llega al 90% y se estanca.
100%

Avance

80%

90%

60%
40%

50%

20%
0%

Tiempo
Figura 1 – Síndrome del 90%Normalmente esto sucede porque utilizamos información subjetiva para registrar avance y cuando nos
enfrentamos a la realidad, nos enteramos que el avance no era real. La realidad puede estar dada por una etapa
de prueba o por un usuario enfrentándose por primera vez al producto. Si hubiésemos contado con información
objetiva en el momento adecuado, tal vez hubiéramos sabido que el proyecto estaba al 20%cuando todos
creíamos que estaba al 50%. Esto nos hubiera permitido tomar las decisiones correctas en el momento correcto.

Primer paso para una solución
Lo primero que debemos entender como líderes de proyecto es que no podemos basarnos en información
subjetiva para tomar decisiones. Esto parece trivial, pero es muy común el “pensamiento mágico” en proyectos
de desarrollo de software. Como líderes,no debemos concluir que hay avance sólo porque alguien dijo
“avanzamos”, debemos reunir evidencia física.

Control de Proyectos basado en Control de Calidad
Una posible evidencia física que sirve como base para la registración de avance puede ser una porción de
software construida. En un proyecto en donde existe un equipo de desarrollo y un equipo de prueba que trabajan
en paralelo, podemosregistrar avance periódicamente basado en evidencia física. ¿Cuál es la evidencia?
El producto desarrollado...

pero también probado...

y estabilizado (sin defectos críticos).

© 2004, Juan Pablo Pussacq Laborde
-1Originally published as a part of 2004 PMI Global Congress Proceedings – Buenos Aires, Argentina

De esta manera estamos utilizando el resultado de Control de Calidad como información deentrada para el
control. Adicionalmente podremos medir no sólo la velocidad de construcción, sino también la velocidad de
corrección, obteniendo información sobre cuánto demorará la estabilización del producto.

¿Cuál es el grado de avance?
El Problema
Existen errores clásicos a la hora de medir avance en proyectos de desarrollo de software:
a) Avance por calendario: se mide avance sólo por paso deltiempo. Aunque parezca trivial, es algo muy
común. Planificamos una tarea para que se complete en 20 días. Al décimo día informamos que estamos al 50%
sin verificar que efectivamente hayamos realizado el 50% del trabajo.
b) Avance por código completo: se mide avance cuando una porción del código está completa, pero sin saber el
grado de estabilidad que tiene. Decimos que un determinado módulo dela aplicación está al 100% porque el
desarrollo ha terminado, pero ¿Tiene defectos? ¿Cumple con los requerimientos de los usuarios?
Ambos errores llevan al síndrome del 90% que nombramos anteriormente.

El Indicador de Funcionalidad Completa
El indicador de Funcionalidad Completa mide avance cuando una funcionalidad está completa, pero...
No hay avance si la funcionalidad no está completa
No...