La cláusula que más se olvida en un proyecto de software: los criterios de aceptación

Como empresa de software, es uno de los primeros temas que tratamos en cada proyecto. Un proyecto que empieza sin criterios de aceptación escritos es un proyecto en el que, hasta el día de la entrega, cada uno espera algo distinto.

Cuando se abre un expediente de litigio de software, las partes suelen discutir esto. Si el software funciona o no.

La razón por la que este debate no se resuelve no es técnica. En el contrato no consta qué significa "funciona". Si no hay criterio de aceptación, el desarrollador dice que entregó, el cliente dice que no lo recibió, y ambos tienen razón según su propio criterio.

Esta única carencia es el denominador común de los litigios de software que he visto.

Cómo debe redactarse el criterio de aceptación

La aceptación es el momento que produce la consecuencia jurídica de la entrega. También desde ahí empieza a correr el plazo de responsabilidad por vicios. Es decir, que esa fecha sea incierta significa que también es incierto cuándo termina la responsabilidad.

Una cláusula de aceptación que funciona incluye lo siguiente. La lista de pruebas de aceptación, el entorno en que se ejecutará la prueba, quién la ejecutará, el plazo de objeción y la regla de que, si no llega objeción dentro del plazo, la aceptación se tendrá por producida.

El elemento que más se omite es el entorno de prueba. Un software que funciona en la máquina del desarrollador puede no funcionar en el entorno del cliente, y en ese punto se discute quién es responsable. Si el entorno está definido en el contrato, esa discusión no surge.

Vincular el criterio de aceptación a la satisfacción subjetiva es, por su parte, la peor opción. Una aceptación condicionada "a la satisfacción del cliente" crea una obligación sin límite temporal, y el trabajo del desarrollador nunca termina.

Los derechos de propiedad intelectual no pasan automáticamente

El segundo error frecuente es la presunción de propiedad. El cliente cree que, a cambio del precio pagado, es propietario del código. Jurídicamente, la situación no es esa.

Los programas de ordenador están protegidos como obra bajo la Ley n.º 5846, y, salvo pacto en contrario, los derechos patrimoniales permanecen en el titular de la obra. La cesión debe regularse expresamente, hacerse por escrito, y los derechos cedidos deben enumerarse uno por uno. Una fórmula general como "se ceden todos los derechos" queda abierta a discusión.

Además, hay que distinguir tres categorías. El código escrito específicamente para el cliente suele cederse. Los componentes preexistentes del desarrollador no se ceden, se licencian, y el alcance y la duración de la licencia se redactan por separado. Los componentes de código abierto están sujetos a sus propias licencias, y la lista de los utilizados debe adjuntarse como anexo al contrato.

Cuando estas tres categorías no se distinguen, ocurre lo siguiente. El cliente cree que es propietario de todo el código, el desarrollador sigue usando su propia biblioteca en otro proyecto, y el problema solo se advierte cuando surge un litigio.

Un contrato sin gestión de cambios no funciona

Por bien redactado que esté el pliego de alcance, durante el proyecto llegan solicitudes de cambio. Si el contrato no dice cómo se tramitará esa solicitud, cada petición se convierte en una negociación.

Una regulación que funciona responde a estas preguntas. A quién y de qué forma se comunica la solicitud. Quién hace el análisis de impacto y en cuántos días. Cómo se calcula el efecto sobre el precio y el calendario. Con la firma de quién se da la aprobación. Qué ocurre con la solicitud no aprobada.

Cuando estas cinco preguntas tienen respuesta, el cambio deja de ser una crisis y se convierte en un proceso.

La condición de encargado del tratamiento surge sin que se note

Si el desarrollador accede a datos personales del cliente, pasa a tener la condición de encargado del tratamiento en el sentido de la Ley 6698. Esta condición se adquiere muchas veces sin que nadie se dé cuenta.

El caso más frecuente es el uso de datos reales en el entorno de pruebas. Se lleva una copia de la base de datos de producción al entorno de pruebas, los desarrolladores trabajan con ella, y desde ese momento nace una relación de tratamiento de datos. Si el contrato no contiene disposición al respecto, esa relación funciona sin fundamento jurídico.

La solución más limpia es no dejar que esta situación llegue a producirse. Probar con datos enmascarados o sintéticos no es técnicamente difícil y elimina en gran medida el riesgo. Si el acceso a datos reales es realmente indispensable, deben regularse por escrito el objeto, la duración y la finalidad del tratamiento, la sujeción del desarrollador a instrucciones, el uso de subencargados, las medidas de seguridad, y la devolución o destrucción de los datos al final del contrato.

El mantenimiento es un contrato aparte

Por último, el mantenimiento y el soporte. Esta es una prestación distinta del desarrollo y debe regularse por separado.

Lo que hay que escribir no es el tiempo de intervención, sino la clasificación de incidencias. Si no se define qué incidencia entra en qué categoría, cada incidencia se reclama con la máxima prioridad. Una vez definidas las categorías, el tiempo de intervención y de resolución se escribe por separado para cada una.

Además está la cuestión de la medición. Un compromiso de nivel de servicio que no sea medible queda sin sanción cuando se incumple. Cómo se hará esa medición y según el registro de quién debe constar en el contrato.

Quién debe redactar el contrato

Todas estas cláusulas exigen que el derecho y la ingeniería decidan juntos. El abogado no puede redactar el criterio de aceptación por sí solo, porque no sabe qué es comprobable. El ingeniero no puede redactar por sí solo la cesión de derechos de propiedad intelectual.

La parte que acude a la negociación del contrato sin equipo técnico acaba aceptando cláusulas que después resultan inaplicables. La cláusula inaplicable, cuando surge el litigio, se comporta como si nunca hubiera existido.