¿Cuáles son los problemas legales y contractuales relacionados con el desarrollo ágil?
Existen metodologías para avanzar en el desarrollo de sistemas. El modelo más clásico y general es el modelo de cascada (Waterfall), y muchos libros de derecho que tratan el desarrollo de sistemas discuten sobre la base de este modelo. En este artículo, explicaremos los problemas legales que pueden surgir en el desarrollo de sistemas basado en el modelo de desarrollo ágil, que es difícil de obtener información de libros y otros medios.
El modelo de desarrollo ágil y los asuntos legales
¿Qué es un modelo en el desarrollo de sistemas?
En los proyectos de desarrollo de sistemas, existe algo llamado modelo de desarrollo, que sirve como un marco para entender el progreso general del proyecto. El más representativo de estos es el llamado “modelo de cascada”. Es decir, al igual que el agua que cae desde “arriba” hasta “abajo” de un río, se realiza de una sola vez cada etapa del proceso, como la definición de requisitos, diseño, implementación, pruebas, etc. Este método es adecuado para avanzar en el trabajo de manera planificada, con el objetivo de reducir al mínimo la repetición y el retrabajo.
Por otro lado, en el modelo de desarrollo ágil, se implementan pequeños programas y luego se prueban, repitiendo este proceso. A través de este trabajo repetitivo de implementar y probar pequeños programas, se va construyendo gradualmente un sistema más grande. Para una explicación más detallada de estos modelos de desarrollo de sistemas y una comparación de las ventajas y desventajas de ambos modelos de desarrollo, consulte el siguiente artículo.
https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]
Características del modelo de desarrollo ágil
Una de las grandes ventajas del desarrollo con el modelo ágil es que permite entrar en el trabajo real con un sentido de velocidad. Como las tareas de “etapas iniciales”, como la definición de requisitos y la creación de documentos de diseño, y las tareas de implementación del programa no están separadas, es adecuado para avanzar de manera flexible, incluyendo la respuesta a adiciones y modificaciones de funciones, cambios de especificaciones, etc. Desde el punto de vista legal, lo que es especialmente importante para el éxito del modelo de desarrollo ágil es cómo se manejan la gestión de documentos y la gestión de cambios. En el modelo de desarrollo ágil, los roles y responsabilidades no están tan claramente definidos como en el modelo de cascada. Además, como se trata de un método que enfatiza la “velocidad” para llegar a la ejecución y el inicio, en lugar de la “gestión”, es fácil que los documentos de diseño, las especificaciones y las actas de las reuniones no estén completos.
Además, en relación con la gestión de cambios, dado que el modelo de desarrollo ágil permite una respuesta suave a los cambios, existe el riesgo de que el proyecto se incendie si se salta el proceso de aprobación para los tomadores de decisiones y se responde a las solicitudes de cambio de especificaciones a nivel de campo. Si esto sucede, la ventaja del modelo de desarrollo de “una respuesta suave a los cambios posteriores” puede convertirse en un riesgo de incendio para el proyecto.
Manejo de documentos y cambios en el desarrollo ágil
La importancia de la gestión de documentos
En los proyectos de desarrollo basados en el modelo de desarrollo ágil, una preocupación legal es que las interacciones basadas en la comunicación oral se acumulen, lo que puede llevar a una falta de documentación. En cuanto a por qué la gestión de documentos es importante en los proyectos de desarrollo de sistemas en primer lugar, se explica en detalle en el siguiente artículo.
https://monolith.law/corporate/the-minutes-in-system-development[ja]
En este artículo, se explica la importancia de la gestión de documentos en los proyectos de desarrollo de sistemas desde dos perspectivas: la prevención de conflictos (es decir, “asuntos legales preventivos”) y la preservación de pruebas en caso de conflicto (es decir, “gestión de crisis”).
La implementación de un comité de comunicación es efectiva para la gestión de documentos
En el caso de adoptar el modelo de desarrollo ágil, a diferencia del modelo de cascada, no se prepara un plan claro de antemano. Por lo tanto, no es suficiente simplemente gestionar la discrepancia entre el plan y los resultados reales, y existe la preocupación de que los costos, tanto financieros como temporales, se disparen si se deja todo en manos del equipo de trabajo.
Por lo tanto, es efectiva la medida de que el responsable organice regularmente reuniones del comité de comunicación para facilitar el progreso del proyecto. En el caso de proyectos de desarrollo de pequeña escala, es cierto que se prefiere un enfoque en el que los responsables se reúnan cuando puedan, en lugar de organizar regularmente reuniones del comité de comunicación. Sin embargo, en el caso del modelo de desarrollo ágil, el riesgo de no tratar los problemas oportunos en las reuniones también tiende a ser mayor. Por lo tanto, es seguro incluir la celebración regular de reuniones del comité de comunicación en los contratos y otros documentos. La forma de estipularlo se muestra de la siguiente manera en el contrato modelo del Ministerio de Economía, Comercio e Industria (METI).
(Establecimiento del comité de comunicación)
Artículo 12 Las partes A y B, hasta la finalización de este trabajo, para discutir los asuntos necesarios para que este trabajo se pueda llevar a cabo sin problemas, como el progreso del trabajo, la gestión y el informe de riesgos, el trabajo conjunto de ambas partes y la implementación del trabajo asignado a cada una, la confirmación del contenido a incluir en las especificaciones del sistema, la discusión y resolución de problemas, deberán celebrar un comité de comunicación. Sin embargo, (omisión).
2. El comité de comunicación se celebrará regularmente a la frecuencia estipulada en el contrato individual, y además, se celebrará en cualquier momento cuando A o B lo considere necesario.
3. Al comité de comunicación asistirán los responsables de ambas partes, los encargados principales y las personas que los responsables consideren apropiadas. Además, A y B pueden solicitar a la otra parte la asistencia de las personas necesarias para la discusión en el comité de comunicación, y la otra parte deberá cumplir con esta solicitud a menos que haya una razón razonable para no hacerlo.
4. B, en el comité de comunicación, deberá preparar y presentar un informe de gestión del progreso en el formato acordado por separado entre A y B, y confirmará el estado del progreso basándose en dicho informe de gestión del progreso, así como la existencia de retrasos, las razones y las medidas a tomar en caso de retrasos, la necesidad de cambios en el sistema de promoción estipulado en este capítulo (cambio de personal, aumento o disminución, cambio de subcontratista, etc.), el estado de implementación de las medidas de seguridad, la existencia de razones para cambiar el contrato individual, y en caso de que existan razones para cambiar el contrato individual, el contenido de las mismas, y confirmará los asuntos decididos, los asuntos que se seguirán considerando y, en caso de que existan asuntos que se seguirán considerando, el calendario de consideración y las partes que llevarán a cabo la consideración.
(Los siguientes artículos 5, 6 y 7 se omiten.)
El punto más importante es que se le da una cierta legitimidad al comité de comunicación en las cláusulas del contrato, y se le da un significado diferente a las reuniones que se celebran de manera ad hoc.
El camino para aprovechar el comité de comunicación en la gestión de cambios
Además, en el desarrollo ágil, se asume que los asuntos acordados inicialmente por ambas partes cambiarán posteriormente. Por lo tanto, es muy importante cómo se gestiona la situación de los cambios posteriores en las especificaciones.
En este caso, si se celebra regularmente el comité de comunicación, la gestión de los cambios también se vuelve muy fluida. Por ejemplo, se puede estipular en el contrato que las discusiones sobre cambios se llevarán a cabo en el comité de comunicación, y que si una de las partes solicita una discusión sobre cambios, la otra parte tiene la obligación de participar en esa discusión. (A continuación se extrae la disposición del contrato modelo del Ministerio de Economía, Comercio e Industria.)
(Procedimiento de gestión de cambios)
Artículo 37 A o B, cuando reciba una propuesta de cambio de la otra parte (omisión), dentro de ○ días a partir de la fecha de recepción, entregará a la otra parte un documento escrito (en adelante, “documento de gestión de cambios”) que contenga los siguientes asuntos, y A y B discutirán la aprobación o desaprobación de dicho cambio en el comité de comunicación estipulado en el artículo 12. (Los asuntos a incluir se omiten)
Los puntos clave de la disposición anterior se pueden resumir de la siguiente manera:
- Se unifica el método de aceptación de la propuesta de cambio en un formato llamado “propuesta de cambio”.
- Se establece un plazo para la fecha desde la recepción de la propuesta hasta la discusión de la misma. → No necesariamente tiene que ser “dentro de ◯ días”, también se puede considerar reemplazarlo por palabras como “lo más pronto posible”.
- Se unifica el lugar para discutir la aprobación o desaprobación del cambio en el “comité de comunicación”.
En otras palabras, para evitar malentendidos como “hice una propuesta de cambio, no la hice”, “respondí a la aprobación o desaprobación del cambio, no lo hice”, se clarifica el método de procedimiento.
Se requiere comprensión de la obligación de buena fe y el principio de equidad
Hasta ahora, hemos presentado modelos de cláusulas contractuales relacionadas con el “Consejo de Coordinación” y la “Negociación de Cambios”. Sin embargo, para entender esencialmente estos, es importante considerar asuntos como la “obligación de buena fe” y el “principio de equidad”. En primer lugar, el modelo de desarrollo ágil tiende a ser difícil de avanzar sin una relación de confianza entre el cliente y el proveedor. Esto se debe a que se prioriza la velocidad de inicio del trabajo real, y los procedimientos hasta el inicio se mantienen al mínimo. Por lo tanto, es común en la práctica incluir cláusulas que impongan una “obligación de buena fe” al otro partido.
Artículo 4, párrafo 3: En la negociación de cambios, se considerarán el objeto del cambio, la posibilidad de cambio, el impacto del cambio en el precio y el plazo de entrega, y ambas partes discutirán de buena fe si se realizará el cambio.
Esto es para prevenir un enfoque que traicione al otro lado con una teoría legal formalista, como “si se acepta o no un cambio en el contrato es puramente a discreción de la parte que recibe la propuesta, y no hay obligación de cumplir con la coerción”, en las negociaciones que han avanzado basándose en una relación de confianza inicial. Esto también refleja los principios legales que se aplican a las transacciones entre individuos, no solo al desarrollo de sistemas.
Artículo 1, párrafo 2 del Código Civil Japonés
El ejercicio de los derechos y el cumplimiento de las obligaciones deben realizarse de buena fe y con sinceridad.
La ley no siempre valora solo el “contenido del contrato” o “el texto de la cláusula” que es formalista. Especialmente en las transacciones con la otra parte, se debe utilizar de manera flexible incorporando la “equidad” y “sinceridad” sustanciales. Además, para más detalles sobre el hecho de que lo que se impone legalmente como “obligación” no siempre se basa en el procedimiento de “contrato”, consulte el siguiente artículo.
https://monolith.law/corporate/system-development-unlawful-responsibility[ja]
Resumen
En los proyectos de desarrollo de sistemas basados en el modelo de desarrollo ágil, es esencial entender el riesgo de que los procedimientos administrativos y la estructura de gestión se vuelvan descuidados de manera informal. Sin embargo, no solo eso, también se considera importante comprender las características flexibles inherentes a la ley, como el “principio de buena fe”, y tener la actitud de aplicarlas en la práctica.
Category: IT
Tag: ITSystem Development