Como ya comentábamos, hay algunos casos títpicos de conflictos en los contratos tecnológicos, y sobre todo relacionados con el uso de licencias de software.
En este sentido, siempre conviene tanto cuando la relación de las partes es buena como si se empieza a vislumbrar ciertos problemas que pueden acabar en conflicto, recabar documentación y pruebas necesarias para el caso de que llegue un supuesto conflicto. Ya se sabe de la máxima romana: «Si vis pacem para bellum«: Si quieres la paz, prepárate para la guerra.
Preconstitución de pruebas
Durante la relación, es importante hacer un buen seguimiento contractual mediante reuniones periódicas y actas firmadas por ambas partes que reflejen lo acordado, lo modificado, las quejas en su caso, los retrasos, etc. Es la mejor manera de documentar incumplimientos por una u otra parte. También es importante recabar correspondencia, e-mails, etc., pero lo ideal son las actas de las reuniones.
En los supuestos de desarrollo de software a medida, si hay retrasos, es muy importante dejar constancia del estado de desarrollo del software solicitado, sobre todo si queremos acreditar que el desarrollo del mismo va con retraso por causa imputable a la empresa tecnológica. ¿Cómo dejamos constancia? Nos haccemos una copia del código fuente junto con la documentación necesaria y nos vamos a un Notario para que levante acta, para que además un perito lo evalúe.
Otro punto muy importante es acudir al análisis o diseño funcional. De esta manera sabré hasta dónde puedo exigir (si soy el cliente) o hasta dónde me pueden exigir (si soy la empresa tecnológica). Si no se cumple, ya tenemos otra prueba.
También debemos dfierenciar entre tareas pendientes y nuevas necesidades o requerimientos. Con el análisis funcional será fácil determinarlo, y que no puedan imputarnos incumplimientos si lo que nos requieren son nuevas necesidades no contempladas en el análisis funcional.
Obviamente los partes de trabajo y la descripción de tareas conforme se desarrolla el software son muy importantes para preconstituir prueba.
Valor de las entregas parciales y aceptación de facturas: lo pagado y entregado, se da por aceptado, salvo pacto en contrario.
Realizar demostraciones acerca de la funcionalidad. Si el software ya tiene muchas de las especificaciones requeridas por el cliente, conviene hacer demostraciones de funcionalidad para acreditar esto, y dejar constancia de la formación realizada.
RFP: Request for proposal. Es la solicitud que hace el cliente para recibir una oferta por parte de la empresa desarrolladora del software. Con este documento, se puede establecer una prelación de documentos:
Si quieremos favorecer a la empresa desarrolladora la prealación sería:
1. -Contrato
2.- Oferta (redactada por la empresa)
3.- RFP
Si queremos favorecer al cliente:
1.- COntrato
2.- RFP (redactado por el cliente)
3.- Oferta
La documentación precontractual de esta manera sería parte del contrato (si así se acuerda).
La formación a usuarios también es importante por que éstos tendrán un papel importante en la fase de desarrollo del mismo.
Por tanto, resumiendo, tenemos la preconstitución de las siguientes pruebas:
1.- Acta notarial de manifestaciones
2.- Aceptación de análisis funcional
3.- Diferenciación de tareas / necesidades nuevas
4.- Peticiones escritas (actas)
5.- Partes de trabajo y descripción de tareas
6.- Aceptación de facturas incluyendo bien claro el concepto
7.- Demostraciones de funcionalidad
8.- Formación a usuarios
Pruebas periciales
1.- Comprobación de si el diseño funcional es correcto y completo. Si el cliente no tiene un buen departamento de IT, deberá contratar un externo que lo verifique.
2.- Comprobación de que el diseño funcional se corresponde con el resultado o desarrollo realizado.
3.- Comprobación de la metodología empleada por la empresa (hay muchas normas ISO que se deben seguir para poder comprobar esto). Si no se han seguido estas normas, se puede «atacar» por ahí.
4.- Comprobación del tiempo necesario y razonable empleado.
5.- Coste horas/trabajador/a
6.- Peticiones no previstas que retrasan el proyecto.
7.- Ahorros esperados o comprometidos contractualmente.
8.- Criterios de selección de solución implementada.
Es importante tener en cuenta que en el supuesto de que se retrase el proyecto y esto implique la resolución del contrato, también podría exigir no sólo los gastos realizados sino los gastos que me supondrá y deberé incurrir para contratar a otra empresa que realice el trabajo que la empresa anterior no supo terminar.
9.- Igualdad de Conocimientos: El perito podrá evaluar el nivel de conocimiento de cada parte para saber quién engañó a quién por estar en una posición más favorable al saber más de tecnología.
Criterios de resolución contractual
1.- Dependerá si es arrendamiento de servicios o de obra.
2.- Existencia de un estudio previo o no de necesidades.
3.- Existencia o no de descripción o acuerdo de nuevos requerimientos.
4.- Metodología aplicada
5.- Desequilibrio del conocimiento técnico
6.- La colaboración del cliente o usuario.
7.- Demostraciones previas.
8.- Buen uso o no de la aplicación.
9.- Adaptación o «traje a medida».
10.- La más importante: INFORME PERICIAL.
Medidas preventivas desde el punto de vista procesal.
1.- Lo primero obviamente es firmar un buen contrato y completo.
2.- Documentar TODO lo posible.
3.- Definir la naturaleza del contrato.
4.- Crear condiciones generales de contratación (si eres una empresa de software).
5.- Tener instrucciones claras de negociación del contrato: qué es negociable, qué es intocable.
6.- Regular perfectamente la propiedad intelectual.
7.- Limitar la RC (si eres la empresa tecnológica).
8.- Cláusula de resolución con posibilidad de un plazo de subsanación.
9.- Resolución de conflictos menores y seguimiento del contrato.
10.- Revisiones aleatorias de contratos firmados.
Andrés Bruno. Protección de datos. 