25 Ago Cuando un proyecto de software termina en juicio: las 10 pruebas que nunca deberían faltar
Un proyecto de software puede comenzar con buenas expectativas y terminar con dos versiones completamente diferentes de lo sucedido. El cliente sostiene que el programa nunca funcionó correctamente. El proveedor afirma que cumplió lo contratado y que los problemas se deben a cambios solicitados posteriormente, falta de colaboración o un uso incorrecto.
Cuando el conflicto llega a los tribunales, surge una cuestión fundamental: ¿cómo demostrar técnicamente qué ocurrió durante el proyecto?
En un litigio tecnológico, disponer de documentación y evidencias puede resultar decisivo. Estas son diez de las pruebas que conviene preservar.
1. El contrato y el alcance del proyecto
El primer punto consiste en determinar qué se contrató realmente.
Contrato, oferta, propuesta técnica, presupuesto y anexos pueden establecer funcionalidades, plazos, integraciones, tecnologías, entregables y responsabilidades.
Una expresión aparentemente sencilla como “integración con el ERP” puede admitir interpretaciones muy diferentes si no se especificó exactamente qué debía hacer esa integración.
2. Los requisitos funcionales
Los documentos de requisitos permiten comparar lo solicitado con lo finalmente desarrollado.
Historias de usuario, especificaciones funcionales, diagramas, actas de reuniones o documentos de análisis pueden ayudar a determinar si una funcionalidad estaba incluida desde el principio o apareció posteriormente.
3. Los correos electrónicos
Gran parte de la verdadera historia de un proyecto se encuentra en el correo electrónico.
Aceptaciones, advertencias, retrasos, incidencias, solicitudes de cambio y decisiones importantes pueden haber quedado documentadas allí.
En caso de litigio, no solo importa el contenido: también puede ser necesario analizar autenticidad, fechas, remitentes, destinatarios y contexto.
4. Tickets e incidencias
Jira, Redmine, GitHub, sistemas de helpdesk y otras plataformas pueden proporcionar una cronología muy valiosa.
¿Cuándo se notificó un error? ¿Qué prioridad tenía? ¿Se resolvió? ¿Volvió a aparecer? ¿Era realmente un defecto o una nueva petición?
El histórico de incidencias permite sustituir afirmaciones generales como “el programa siempre fallaba” por hechos verificables.
5. Repositorios de código fuente
Los repositorios pueden convertirse en una fuente de evidencia especialmente relevante.
Los commits permiten estudiar la evolución del software, identificar determinadas modificaciones y conocer cuándo se incorporaron cambios.
Git y otras herramientas no demuestran por sí solas que un proyecto cumpliera el contrato, pero pueden ayudar a reconstruir técnicamente su desarrollo.
6. Versiones y entregas
Es importante conservar evidencias de qué versión se entregó y cuándo.
Paquetes de instalación, versiones desplegadas, registros de publicación, documentación de releases o evidencias de los entornos de producción pueden resultar esenciales.
De poco sirve demostrar que una incidencia estaba solucionada en una versión posterior si el cliente nunca recibió o instaló esa versión.
7. Pruebas de aceptación
Uno de los puntos más conflictivos suele ser determinar si el cliente aceptó el sistema.
Documentos de aceptación, pruebas UAT, correos de conformidad, resultados de testing o actas de puesta en producción pueden ayudar a establecer el estado del proyecto en un momento determinado.
Sin embargo, una aceptación tampoco significa necesariamente que cualquier problema posterior quede automáticamente excluido. Será necesario analizar cada caso.
8. Logs del sistema
Los logs permiten reconstruir determinados acontecimientos técnicos.
Errores, accesos, procesos ejecutados, comunicaciones entre sistemas o fallos de integración pueden quedar registrados.
Pero para que tengan valor técnico deben analizarse también su origen, integridad y fiabilidad. Un archivo de logs fácilmente modificable y sin controles puede ofrecer menos garantías de las que aparenta.
9. Copias de seguridad y bases de datos
En ocasiones, la situación actual del software ya no refleja cómo funcionaba cuando apareció el conflicto.
Las copias de seguridad pueden permitir recuperar estados anteriores y analizar bases de datos, configuraciones o versiones históricas.
Por eso, cuando existe la posibilidad de un litigio, eliminar servidores, sobrescribir backups o modificar sistemas sin preservar previamente las evidencias puede dificultar enormemente una investigación posterior.
10. Comunicaciones sobre cambios de alcance
Esta es una de las pruebas más importantes.
Muchos proyectos empiezan con un alcance y terminan incorporando decenas de peticiones adicionales.
Conviene poder identificar:
qué se pidió, cuándo se solicitó, quién lo aprobó, cuánto costaba y cómo afectaba al plazo.
Sin esta trazabilidad, resulta difícil distinguir entre una funcionalidad originalmente contratada y una ampliación posterior.
El perito informático no decide quién tiene razón
Cuando el conflicto requiere conocimientos especializados, el perito informático puede analizar las evidencias y reconstruir técnicamente el proyecto.
Su función no consiste en decidir quién debe ganar el procedimiento, sino en responder de manera objetiva a cuestiones técnicas: qué se contrató desde una perspectiva tecnológica, qué se desarrolló, qué incidencias existieron, qué cambios se realizaron y qué evidencias respaldan las afirmaciones de cada parte.
Además, una buena pericial debe explicar estas cuestiones de forma comprensible para personas que no necesariamente tienen conocimientos de programación.
La mejor prueba se conserva antes del conflicto
Uno de los mayores errores es comenzar a buscar evidencias cuando el proyecto ya ha terminado mal.
Correos eliminados, repositorios inaccesibles, empleados que abandonaron la empresa, servidores sustituidos y tickets cerrados pueden hacer desaparecer información fundamental.
Por eso, una correcta gestión documental y técnica no solo mejora la dirección del proyecto. También proporciona protección si algún día surge un conflicto.
Cuando un proyecto tecnológico termina ante un juez, no suele ser suficiente afirmar “el software no funcionaba” o “entregamos todo lo contratado”.
La cuestión realmente importante es otra:
¿Qué evidencias existen para demostrarlo?
Contáctanos en luis@luisvilanova.es