¿Cuáles son las obligaciones de cooperación que recaen sobre el usuario que encarga el desarrollo del sistema?

El trabajo de desarrollo de sistemas, cuanto más grande sea el sistema a desarrollar, requiere la inversión de un gran número de personas y tiempo. Por lo tanto, no solo el proveedor que asume el desarrollo, sino también el usuario que encarga el desarrollo del sistema, tiene ciertas obligaciones de cooperación.

Esto es diferente de la relación normal de contratación. Por ejemplo, si le pides a un sastre que haga un traje a medida, el cliente (usuario) que hace el pedido no tiene ninguna “obligación” en particular. La “obligación” recae principalmente en el sastre (proveedor) que recibe el pedido. Es precisamente porque el sistema de TI requiere un gran número de personas y tiempo que el usuario también necesita “cooperar” con el proveedor.

En este artículo, explicaremos qué obligaciones legales tiene el lado del cliente en el desarrollo de sistemas, que no puede ser dejado completamente en manos del proveedor.

No se puede simplemente “delegar” todo en su propio sistema

Incluso en un solo proyecto de desarrollo de sistemas, a menudo hay muchas personas y organizaciones involucradas. No solo los ingenieros y programadores expertos en codificación, sino también el papel del gerente de proyecto es importante para consolidar la producción de dicho personal en un solo resultado.

Sin embargo, no importa cuán alta sea la capacidad técnica y organizativa del proveedor, el desarrollo del sistema no se puede lograr solo con el poder del proveedor. Por ejemplo, no hay forma de conocer términos internos utilizados solo dentro de la empresa y conocimientos de negocios específicos de la empresa solo con los esfuerzos unidireccionales del proveedor. Cuanto más grande es el desarrollo del sistema, más a menudo la empresa que utiliza el sistema es una gran empresa con muchas personas y tareas. Para llevar al éxito el proyecto de desarrollo del sistema, en realidad, a menudo es el caso que la organización de esta lógica de negocios tiene un gran peso antes del trabajo en la computadora.

Por lo tanto, no es que el lado del usuario se vuelva pasivo porque “no soy un experto en tecnología de la información”, sino que al proporcionar información de manera proactiva, el progreso del proyecto puede ser suave. En este sentido, el papel que el lado del usuario tiene en el proyecto de desarrollo del sistema no es en absoluto pequeño.

¿Qué es la obligación de cooperación del usuario basada en precedentes judiciales?

Entonces, ¿qué tipo de obligación de cooperación tiene el usuario en un proyecto de desarrollo de sistemas? Hay muchas pistas en los precedentes judiciales anteriores sobre este punto.

En el juicio, se discutió la existencia de una obligación de cooperación del usuario en el desarrollo debido a la demora en la toma de decisiones del usuario (demandante) en casos donde la fecha de entrega del proveedor (demandado) se retrasó. En este caso, el tribunal reconoció la violación de la obligación de cooperación por parte del usuario y negó la responsabilidad del proveedor por incumplimiento de contrato. (Aunque se reconoció la rescisión del contrato, también se reconoció una compensación por negligencia del 60%.)

El contrato de desarrollo del sistema informático en cuestión es un contrato de desarrollo de sistema hecho a medida, y en tal contrato, el proveedor no puede completar el sistema por sí solo. Es necesario que el cliente (usuario) coordine las opiniones internas de manera precisa durante el proceso de desarrollo, comunique claramente al proveedor qué funciones desea, discuta las funciones deseadas con el proveedor, decida finalmente las funciones, además, decida las pantallas y los formularios, y acepte los productos entregables.

Fallo del Tribunal de Distrito de Tokio, 10 de marzo de 2004 (Año 16 de Heisei)

Este fallo no sólo indica que el desarrollo del sistema en sí es un trabajo conjunto con el usuario, sino que también es muy sugerente en cuanto a “en qué aspectos específicos se debe colaborar”.

Intentemos traducir el lenguaje de la sentencia anterior a los términos de TI del desarrollo de sistemas.

Podemos organizarlo de esta manera. Todos estos son cosas que no se pueden hacer solas, sin importar cuán avanzada sea la especialidad en el sistema de TI. Las funciones requeridas y el diseño de la pantalla son básicamente cosas que el usuario debe aclarar, y sólo el usuario puede verificar si se ha realizado lo que se solicitó.

Además, al igual que se impone una obligación de gestión de proyectos al proveedor, se impone una obligación de cooperación al usuario. Por lo tanto, si el usuario viola su obligación de cooperación en el proceso anterior, existe la posibilidad de que el proveedor pueda reclamar al usuario por incumplimiento de contrato o daños y perjuicios por actos ilícitos.

¿Cómo se interpretan las solicitudes de cambio de especificaciones después de la facturación?

Además, si asumimos que el proyecto de desarrollo del sistema es un trabajo conjunto entre el usuario y el proveedor, la discusión se desarrollará hacia un debate más avanzado. Es decir, “si el usuario solicita adiciones o modificaciones de funciones después de la facturación, y esto dificulta la entrega a tiempo, ¿quién es responsable?” es el problema.

El desarrollo del sistema generalmente comienza con la definición de requisitos, y se busca avanzar en el orden de diseño básico, diseño detallado, fabricación (implementación del programa), prueba, etc., para evitar retrasos tanto como sea posible (generalmente llamado modelo de cascada). Sin embargo, debido a ciertas circunstancias, si se descubre que hay un defecto en el proceso anterior, también ocurre con frecuencia en la realidad que hay retrasos en el proceso.

¿Cómo debemos pensar si no podemos cumplir con la fecha de entrega en tales casos? Al interpretar los precedentes, parece que hay diferencias en las conclusiones dependiendo del momento en que se produjo el trabajo adicional.

Si el trabajo adicional fue antes de la clarificación de las especificaciones como el diseño externo

El precedente mencionado anteriormente indica que no es una violación del deber de cooperación en sí mismo solicitar un desarrollo adicional del usuario durante el diseño básico (antes de la etapa de implementación del programa).

Es natural en el proceso de desarrollo del sistema como este caso que el usuario haga varias solicitudes al proveedor sobre el sistema a construir durante el trabajo de diseño básico, y además, en el usuario demandante sin conocimientos especializados, si dicha solicitud requiere tarifas de encargo adicionales o una extensión del plazo de entrega, etc., es difícil juzgar con precisión si interfiere con el proceso de trabajo. Por lo tanto, no se puede decir que el demandante usuario debería haberse abstenido de hacer solicitudes que requieran tarifas de encargo adicionales o una extensión del plazo de entrega, etc. Por el contrario, si el demandante usuario hizo una solicitud que requiere tarifas de encargo adicionales o una extensión del plazo de entrega, etc., el demandado que tiene el deber de gestión del proyecto debería haberle informado de esto al demandante usuario y haber solicitado discusiones sobre la retirada de la solicitud o la extensión del plazo de entrega, etc., para evitar interferencias con el trabajo de desarrollo.

Fallo del Tribunal de Distrito de Tokio, 10 de marzo de 2004 (2004)

En este fallo, se indicó que el usuario también tiene cierto deber de cooperación, y que no se debe considerar que el usuario es un experto en desarrollo de sistemas. En otras palabras, dado que el usuario que realiza el pedido no es un experto en desarrollo de sistemas, no es extraño que haga pedidos por partes hasta que se aclare el contenido del sistema a desarrollar (incluso si no está acostumbrado a hacer pedidos), y mucho menos si el contenido del pedido requiere una revisión del plazo de entrega, etc., “debería haberse dado cuenta de ello por sí mismo” es demasiado severo.

Por supuesto, el deber impuesto al proveedor aquí se considera que se refiere a los esfuerzos de comunicación, como solicitar una extensión del plazo de entrega (o, si no se puede mover el plazo de entrega, sugerir que se retire la solicitud adicional en sí). Por lo tanto, no se considera que incluya la obligación de aceptar todas las solicitudes del usuario y entregarlas a tiempo según la fecha original, por lo que es necesario tener cuidado con este punto.

Si el trabajo adicional fue después de la confirmación de las especificaciones en la etapa de fabricación o prueba

Si invertimos el contenido del fallo anterior, podemos prever hasta cierto punto qué conclusión habría tenido si se tratara de un desarrollo adicional después de que las especificaciones ya se hubieran confirmado. En ese caso, es probable que tales solicitudes sean difíciles de aceptar. Ciertamente, el nivel de comprensión del trabajo de desarrollo entre el usuario y el proveedor no cambia, ya sea antes o después de la confirmación de las especificaciones.

Sin embargo, cambiar o agregar el contenido del pedido después de que las especificaciones se hayan confirmado tiene una alta probabilidad de forzar la repetición del trabajo. En muchos casos, es difícil defender que “es natural que el cliente haga varias solicitudes” si la entrega se retrasa incluso en tales casos. Además, si se producen muchos cambios de especificaciones y adiciones de funciones después de la facturación, esto plantea la pregunta de si no hubo una violación del deber de cooperación por parte del usuario en el proceso ascendente que ya debería haberse completado antes.

Desde este punto de vista, no es realista considerar que el proveedor es responsable del retraso en la entrega causado por los cambios de especificaciones realizados después de que se confirmaron una vez. Se puede decir que es apropiado leer al mismo tiempo el significado de este tipo del texto del fallo mencionado anteriormente.

Además, este tipo de juicio tiende a ser realizado utilizando no solo el contrato, sino también las actas de las reuniones de acuerdo con el progreso del desarrollo del sistema como evidencia.

Resumen: Es importante no olvidar que la definición de requisitos es un proceso del lado del usuario

La definición de requisitos es una oportunidad para que el proveedor demuestre su habilidad, pero al mismo tiempo, debemos ser conscientes de que es fundamentalmente un proceso del lado del usuario. Independientemente de si el sistema se desarrolla con la ayuda de expertos externos, se considera legalmente que es un área que debe estar bajo la gobernanza de la propia empresa.

Si el usuario no coopera en el proceso de desarrollo, incluso si el proyecto se incendia, es posible que el tribunal tenga una visión estricta hacia el usuario. Este es un punto que debemos reconocer desde el principio.