07 Sep Proyecto terminado al 80 %: cómo puede determinar un perito qué parte del trabajo está realmente realizada
En los conflictos relacionados con proyectos de software aparece con frecuencia una afirmación aparentemente sencilla: “el proyecto está terminado al 80 %”.
El problema es que ese porcentaje, por sí solo, dice muy poco.
Puede referirse a horas consumidas, funcionalidades desarrolladas, presupuesto ejecutado o tareas marcadas como completadas. Y ninguna de esas métricas garantiza que el sistema esté realmente operativo o que pueda considerarse entregado en un 80 %.
Cuando cliente y proveedor discrepan sobre el grado de avance, una pericial informática puede ayudar a determinar qué parte del proyecto existe realmente, qué funciona y qué queda pendiente.
Un porcentaje no equivale necesariamente a progreso real
Supongamos que un proveedor ha consumido el 80 % de las horas presupuestadas.
Eso no significa que el sistema esté completado en ese mismo porcentaje.
Puede ocurrir que se haya desarrollado gran parte del código, pero falten integraciones críticas. También puede suceder que muchas funcionalidades estén implementadas parcialmente, que no se hayan realizado pruebas suficientes o que determinados módulos no puedan utilizarse en producción.
Por eso, el análisis pericial no debería partir únicamente de porcentajes declarados por una de las partes.
El contrato y el alcance son el punto de partida
Para valorar el grado real de ejecución, el perito necesita conocer qué se había contratado.
Entre la documentación relevante pueden encontrarse:
- contrato y anexos técnicos;
- documento de requisitos;
- propuesta económica;
- especificaciones funcionales;
- planificación inicial;
- hitos y entregables;
- actas de reuniones;
- solicitudes de cambio;
- correos y comunicaciones entre las partes.
Esta documentación permite establecer cuál era el resultado esperado y comparar posteriormente ese objetivo con lo que realmente se ha desarrollado.
Funcionalidad entregada frente a funcionalidad prevista
Una de las formas más fiables de analizar el avance consiste en revisar funcionalidad por funcionalidad.
Por ejemplo, si el sistema debía incluir gestión de usuarios, facturación, generación de informes, integración con un ERP y un portal para clientes, no basta con comprobar que existen pantallas asociadas a cada módulo.
El perito puede analizar si esas funciones están completas, si realizan correctamente los procesos previstos y si pueden utilizarse en condiciones reales.
Una funcionalidad puede clasificarse, por ejemplo, como:
- completada y operativa;
- desarrollada parcialmente;
- desarrollada pero pendiente de pruebas;
- implementada con errores relevantes;
- no desarrollada.
Este enfoque proporciona una visión mucho más precisa que un porcentaje global.
El código fuente también aporta evidencias
Cuando existe acceso al código, su análisis puede ayudar a comprobar qué elementos han sido efectivamente desarrollados.
El repositorio puede ofrecer información sobre:
- archivos creados o modificados;
- evolución del proyecto;
- fechas de desarrollo;
- ramas y versiones;
- autores de los cambios;
- funcionalidades incorporadas;
- componentes abandonados o incompletos.
Sin embargo, tener miles de líneas de código tampoco demuestra que un proyecto esté cerca de finalizar.
El código debe relacionarse con los requisitos funcionales y técnicos previstos.
Tickets y herramientas de gestión
Jira, Trello, Azure DevOps, Redmine y otras herramientas similares pueden contener información importante sobre el estado del proyecto.
Los tickets permiten conocer incidencias, tareas, responsables, prioridades y fechas.
Pero también deben interpretarse con cautela.
Una tarea marcada como “Done” no significa necesariamente que haya sido aceptada por el cliente o que funcione correctamente.
Por eso resulta necesario contrastar la información del gestor de proyectos con el software realmente entregado.
Las pruebas pueden cambiar completamente la valoración
Un sistema aparentemente muy avanzado puede encontrarse todavía lejos de estar preparado para producción.
Las pruebas permiten comprobar si las funcionalidades funcionan conjuntamente y si el sistema responde correctamente ante situaciones reales.
Entre otros aspectos pueden revisarse:
- errores pendientes;
- pruebas unitarias;
- pruebas de integración;
- pruebas de aceptación;
- resultados de UAT;
- incidencias críticas;
- rendimiento;
- seguridad.
Por ejemplo, un módulo puede estar técnicamente desarrollado, pero no superar las pruebas de aceptación. En ese caso, considerarlo completamente terminado podría ofrecer una imagen incorrecta del proyecto.
Los cambios de alcance deben separarse del proyecto original
Otro punto habitual en los litigios tecnológicos son las modificaciones solicitadas durante el desarrollo.
Es importante diferenciar entre tareas inicialmente contratadas y funcionalidades añadidas posteriormente.
Si no se hace esta separación, pueden aparecer interpretaciones muy diferentes.
El proveedor puede considerar que los retrasos derivan de solicitudes adicionales, mientras que el cliente puede entender que esas tareas ya estaban incluidas en el alcance inicial.
Los correos, actas, presupuestos adicionales y change requests pueden ayudar a reconstruir lo ocurrido.
¿Se puede establecer un porcentaje exacto?
En algunos proyectos es posible estimar un grado de ejecución. Pero ese porcentaje debería basarse en criterios objetivos y explicarse claramente.
No todas las funcionalidades tienen el mismo peso.
Un sistema puede tener nueve módulos menores terminados y uno esencial sin desarrollar. Decir que está completado al 90 % simplemente porque nueve de diez módulos existen podría resultar engañoso si el módulo pendiente impide utilizar todo el sistema.
Por ello, la valoración puede ponderar aspectos como complejidad, criticidad, esfuerzo previsto y dependencia entre componentes.
El objetivo de la pericial
Una pericial informática no debería limitarse a decidir si una de las partes tiene razón cuando afirma que el proyecto está “al 80 %”.
Su función es transformar esa afirmación en elementos verificables.
Qué se contrató, qué se desarrolló, qué funciona, qué fue aceptado, qué queda pendiente y qué parte del trabajo podría aprovecharse.
Solo entonces puede realizarse una valoración técnica suficientemente sólida para servir como apoyo en una negociación, una reclamación o un procedimiento judicial.
Contáctanos en luis@luisvilanova.es