¿Cómo se debe gestionar los cambios en el desarrollo de sistemas desde una perspectiva legal?

En los proyectos de desarrollo de sistemas, a menudo ocurre que el contenido que el usuario había explicado previamente cambia a medida que avanza el trabajo. Por lo tanto, incluso como proveedor que acepta el trabajo, puede surgir la necesidad de adaptarse a los cambios en el contenido del contrato que se ha firmado una vez.

En este artículo, desde un punto de vista legal, explicamos cómo manejar el fenómeno de los “cambios” que se realizan posteriormente en proyectos de desarrollo de sistemas que no avanzan según lo previsto.

¿Por qué los proyectos de desarrollo de sistemas se “modifican” después?

El desarrollo de sistemas es un trabajo conjunto entre el proveedor y el usuario

Generalmente, el desarrollo de sistemas pasa por una etapa de planificación y propuesta, luego se definen los requisitos de desarrollo y se firma un contrato. Una vez firmado el contrato, se sigue un proceso que incluye varios diseños, la implementación según el diseño, y finalmente, se realiza una prueba antes de finalizar. En todo este proceso, es obvio que el proveedor, como experto en desarrollo de sistemas, tiene una amplia gama de responsabilidades, pero también se impone un cierto deber de cooperación al usuario. En particular, la cooperación del usuario es importante en etapas como la identificación de las funciones que debe tener el sistema (definición de requisitos), la apariencia y la sensación de operación del lado de la pantalla (diseño básico), y la confirmación de si se ha logrado lo requerido (prueba o aceptación). Para una explicación general de las obligaciones que el usuario tiene en el desarrollo de sistemas, consulte el siguiente artículo.

https://monolith.law/corporate/user-obligatory-cooperation[ja]

Aunque hay un deber de cooperación, los usuarios a menudo solicitan cambios

Sin embargo, no siempre es posible que los usuarios, que no son expertos en desarrollo de sistemas, transmitan de manera exhaustiva y sin falta toda la información necesaria para el desarrollo de sistemas al proveedor. En la realidad, debido a la naturaleza detallada y meticulosa del trabajo, a menudo es difícil para los usuarios prever qué hechos tendrán un significado decisivo en las etapas posteriores. Irónicamente, los hechos más importantes a menudo surgen poco a poco. Debido a estas circunstancias, en los proyectos reales, aunque el ideal es “atravesar todas las etapas desde la etapa inicial hasta la etapa final”, se asume que se pueden hacer varios cambios después, y cómo manejar la “gestión de cambios” se vuelve importante.

¿Qué es un Documento de Gestión de Cambios?

Escenarios en los que se utiliza el Documento de Gestión de Cambios

El Documento de Gestión de Cambios es un documento que los usuarios utilizan para solicitar al proveedor cambios en las especificaciones o la adición de funciones, apartándose de lo que se había explicado previamente. Como se mencionó anteriormente, durante las fases de definición de requisitos y diseño básico, los usuarios también tienen la obligación de cooperar con el trabajo del proveedor, pero es posible que surjan demandas diferentes en las etapas posteriores.

Algunos ejemplos de situaciones en las que se necesita un Documento de Gestión de Cambios podrían ser, por ejemplo:

• Cuando se pasa por alto algo durante la definición de requisitos o el diseño básico, y se solicita la adición de una función posteriormente.
• Cuando se revisa la política del negocio en medio del desarrollo y se necesita un cambio de especificaciones.

Estos son solo algunos ejemplos.

Además, en relación con temas como la adición de funciones o el cambio de especificaciones, lo que más preocupa a quienes reciben el trabajo es si la ley permite un cambio en la cantidad estimada. Este punto se explica en detalle en otro artículo.

https://monolith.law/corporate/increase-of-estimate[ja]

El Documento de Gestión de Cambios sirve como base para evaluar la validez de la estimación cuando se aumenta la cantidad estimada después del hecho. Para evitar disputas con la otra parte cuando se factura basándose en una estimación aumentada posteriormente (y para dar peso a su argumento en caso de disputa), es importante crear un Documento de Gestión de Cambios.

Contenido del Documento de Gestión de Cambios

Entonces, ¿qué tipo de información debe incluirse en el Documento de Gestión de Cambios desde un punto de vista legal? El uso del Documento de Gestión de Cambios para acomodar cambios en las especificaciones y la adición de funciones es un mecanismo contractual que ya es ampliamente reconocido en general. Por lo tanto, al revisar modelos de cláusulas contractuales proporcionadas por agencias gubernamentales, como el modelo de contrato del Ministerio de Economía, Comercio e Industria, se puede tener una idea general de qué información se debe registrar.

(Procedimiento de Gestión de Cambios)
Artículo 37 Cuando la Parte A o la Parte B recibe una propuesta de cambio basada en el Artículo 34 (Cambio de las especificaciones del sistema, etc.), el Artículo 35 (Aprobación de los documentos intermedios por parte del usuario), o el Artículo 36 (Tratamiento de los asuntos no resueltos), deben entregar a la otra parte un documento escrito (en adelante, “Documento de Gestión de Cambios“) que incluya los siguientes puntos dentro de los ○ días siguientes a la fecha de recepción, y la Parte A y la Parte B deben discutir la aceptabilidad de dicho cambio en el Comité de Comunicación establecido en el Artículo 12.
① Nombre del cambio
② Responsable de la propuesta
③ Fecha
④ Razón del cambio
⑤ Detalles del cambio, incluyendo las especificaciones relacionadas con el cambio
⑥ Si el cambio requiere costos, la cantidad de los mismos
⑦ Programa de trabajo para el cambio, incluyendo el período de consideración
⑧ Otros impactos del cambio en los términos de este contrato y los contratos individuales (plazo de trabajo o fecha de entrega, honorarios, cláusulas contractuales, etc.)

Si lees directamente el texto de la ley y confirmas los elementos recomendados para su inclusión, no se necesita más explicación. Para evitar problemas de “dije/no dije” más adelante, debes registrar en detalle y de manera concreta el proceso de cambio.

Al incluir estos elementos y obtener la firma o el sello del responsable o tomador de decisiones tanto del proveedor como del usuario, el Documento de Gestión de Cambios adquiere el mismo significado que un contrato en términos de evidencia, incluso si se llega a un juicio.

Lo que deberías saber sobre la gestión de cambios

La gestión de cambios generalmente debe realizarse junto con la gestión de tareas

La razón para crear un documento de gestión de cambios es que, al gestionar el historial de cambios, se puede guiar el proyecto hacia su logro (o, en caso de no lograrlo, evitar la persecución de responsabilidades injustas). En la práctica, la creación del documento de gestión de cambios a menudo se realiza junto con la creación y actualización de la lista de gestión de tareas. Es decir, una vez que se ha gestionado el historial de cambios en la tabla de gestión de cambios, los elementos de cambio acordados se incorporan en la lista de gestión de tareas como tareas a abordar en el futuro.

Es mejor establecer también regulaciones sobre cómo llevar a cabo las discusiones de cambio

No solo la forma de gestionar los cambios, sino también la forma de llevar a cabo las discusiones sobre los cambios, si se establecen regulaciones al respecto, se puede esperar que la respuesta a los cambios sea más fluida. Este punto es especialmente importante cuando se adoptan métodos de desarrollo que asumen que se realizarán varios cambios después, como el desarrollo ágil. En la práctica, a menudo se ven ejemplos de regulaciones que especifican cuándo debe responder la otra parte a una solicitud de discusión sobre la gestión de cambios.

Discusión de cambios y obligación de buena fe

Cuando se trata de cambiar un contrato sobre el cual ambas partes han acordado una vez, es como si se estuviera celebrando un nuevo contrato. Desde el punto de vista de que el contrato se basa en la libre voluntad de las partes, en principio, el proveedor no tiene la obligación de aceptar el contrato de cambio. Sin embargo, si se enfatiza demasiado este aspecto de los derechos, puede haber preocupaciones de que el proyecto de desarrollo del sistema no progrese sin problemas en la práctica.

Por lo tanto, a menudo se menciona en los contratos que existe una “obligación de responder de buena fe a las discusiones de cambio”, y hay ejemplos de disposiciones que permiten reclamaciones de indemnización por daños y perjuicios si el proveedor no responde de buena fe a los cambios.

Un ejemplo de esto sería el siguiente (a continuación, se muestra un ejemplo de la redacción del artículo, citado del “Modelo de contrato básico/individual” creado oficialmente por la Organización Independiente de Promoción del Procesamiento de Información de Japón).

Artículo 4, párrafo 3: En las discusiones de cambio, se examinarán el objeto del cambio, la posibilidad de cambio, el impacto del cambio en el precio y el plazo de entrega, etc., y ambas partes discutirán de buena fe si se realizará el cambio.

Regulaciones sobre el método de cambio

Como se mencionó anteriormente, cuando se realiza un cambio, es “seguro” desde el punto de vista legal tener una discusión sobre el cambio cada vez. Sin embargo, en proyectos pequeños, puede que no sea necesario establecer cómo llevar a cabo las discusiones de cambio. En ese caso, en lugar de establecer regulaciones sobre las discusiones, se puede considerar un método en el que el cambio se realiza solo después de que los responsables del usuario y del proveedor han firmado y sellado el documento de gestión de cambios, incluso sin discusión. Si se permite un cambio fácil solo con un acuerdo verbal, puede ser ambiguo si se ha realizado un cambio, y esto puede causar grandes problemas más adelante, por lo que la gestión de documentos debe ser rigurosa.

Por supuesto, puede ser una carga preparar documentos por separado para la gestión de cambios cada vez, y puede que quieras priorizar una respuesta flexible. En ese caso, una opción podría ser documentar los asuntos relacionados con los cambios en las actas de las reuniones. En cuanto a cómo mantener las actas de las reuniones en el desarrollo del sistema, se explica en detalle en el siguiente artículo.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Resumen

En entornos donde los cambios de especificaciones son frecuentes, ciertamente, es común estar al borde de problemas y disputas. Sin embargo, en tales situaciones donde se requiere flexibilidad, simplemente enfatizar la “importancia de la gestión” de manera rígida puede hacer que sea difícil implementar medidas prácticas.

El problema de cómo equilibrar la velocidad requerida en los negocios y la preparación para situaciones imprevistas a menudo varía dependiendo de la situación de la empresa y el contenido del proyecto. Aunque se tenga en cuenta el contenido de este artículo, se considera importante que cada empresa y proyecto busque su propio método apropiado.