¿Qué leyes están relacionadas con la 'quema' de proyectos de desarrollo de sistemas?

Un proyecto de desarrollo de sistemas no es algo que se pueda lograr de la noche a la mañana. Requiere la inversión de numerosos recursos, incluyendo a muchas personas y organizaciones, una gran cantidad de dinero y un largo período de desarrollo. En este artículo, explicaremos cómo se puede organizar el fenómeno de “incendio” en un proyecto de desarrollo de sistemas bajo un marco legal, y proporcionaremos una guía para las soluciones.

¿Por qué los proyectos “se incendian”?

Un sistema de IT, incluso si no es un proyecto de gran escala, solo puede funcionar correctamente gracias a la acumulación de una gran cantidad de archivos de programa y código fuente. A menudo, estos sistemas están meticulosamente diseñados, mucho más allá de lo que uno podría imaginar desde la perspectiva de la interfaz de usuario (de hecho, cuanto más simple y concisa es la interfaz de usuario de un sistema de IT, más detallado suele ser su diseño).

• El plazo de entrega es lo único que se ha decidido, mientras que las especificaciones y los requisitos siguen siendo ambiguos a medida que pasa el tiempo
• Los miembros están demasiado distraídos por los problemas políticos internos, y muchos terminan abandonando debido al estrés de las relaciones interpersonales
• Hay una falta de habilidades de negociación en el nivel de gestión, incluyendo al PM, y no se solicita a los miembros que informen, se comuniquen y consulten adecuadamente

Las razones específicas de la “incineración” de un proyecto pueden variar de un proyecto a otro. Sin embargo, desde un punto de vista legal, las razones de la “incineración” de un proyecto pueden ser organizadas de manera relativamente simple en varios tipos.

Tipo de incendio 1: Cuando un proyecto se estanca a mitad de camino

En el progreso del desarrollo de sistemas, la falta de comunicación entre el usuario y el proveedor es un motivo típico por el cual un proyecto puede estancarse a mitad de camino. En primer lugar, un proyecto de desarrollo de sistemas requiere, por supuesto, la capacidad técnica y organizativa especializada del proveedor, pero también depende de la cooperación del usuario final que utilizará el sistema.

Por lo tanto, si un proyecto avanza con roles ambiguos para cada parte, y surge una especie de “empuje de responsabilidades” entre ellos, el progreso fluido del proyecto puede verse obstaculizado. Para una consideración legal de las obligaciones del usuario y del proveedor, respectivamente, consulte los siguientes artículos.

https://monolith.law/corporate/project-management-duties[ja]

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

Dejando a un lado los detalles de las responsabilidades que cada uno debe asumir, que se pueden encontrar en los artículos mencionados anteriormente, el punto clave aquí es que en un proyecto de desarrollo de sistemas, tanto el usuario como el proveedor tienen ciertas responsabilidades. En términos generales, los casos y precedentes judiciales han reconocido que el usuario tiene la obligación de cooperar en aspectos que no pueden completarse sin su ayuda, como la definición de requisitos, el diseño de la apariencia de la pantalla (es decir, el diseño básico) y la aceptación.

Por otro lado, el proveedor también tiene una obligación integral de facilitar el progreso del proyecto y de identificar y eliminar los obstáculos para este, después de recibir la cooperación del usuario en los puntos mencionados anteriormente (y al mismo tiempo, después de hacer esfuerzos para solicitar dicha cooperación).

Bajo esta perspectiva, los tribunales han demostrado una actitud de tratar todos los conflictos de manera justa, mostrando que el usuario tiene la obligación de ejercer la gobernanza desde dentro como un sistema interno, y que el proveedor tiene la obligación de demostrar su especialización y habilidades técnicas como un experto externo.

Además, es común que estos “estancamientos” ocurran durante la fase de aceptación. Para obtener una explicación detallada sobre la aceptación, consulte el siguiente artículo.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

En tales casos, una vez que surge un conflicto, se tiende a dar importancia a la evidencia que se puede verificar objetivamente, como el progreso de proyectos anteriores y el contenido de las reuniones. Por lo tanto, los documentos registrados previamente a menudo tienen un gran significado. Para no perjudicar su posición, es esencial una gestión rigurosa de los documentos. Para una explicación detallada desde el punto de vista de la importancia de la gestión de documentos en el desarrollo de sistemas, consulte el siguiente artículo.

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

Tipo de incendio 2: Cuando se cancela por conveniencia personal del usuario

También se puede prever el caso en que, en medio de un proyecto, se dicta la suspensión por deseo del usuario. Por ejemplo, supongamos que se ha comenzado a crear un sistema de TI para gestionar los recursos humanos de manera unificada, incluyendo las bases en el extranjero, y la estrategia de expansión de ventas de la empresa, como la expansión al extranjero, se retira. En tales casos, el desarrollo del sistema que se ha comenzado puede ya no ser necesario para el usuario.

En primer lugar, la cuestión de cómo se debe construir un sistema de TI utilizado en una empresa no puede ser separada de la cuestión de “qué tipo de trabajo existe en la empresa” como premisa. Por lo tanto, es posible que los requisitos del sistema que se necesitan (o que se vuelven innecesarios) cambien después del hecho debido a los efectos de cambios significativos en la organización y la reorganización de los departamentos de negocios, y una revisión radical de la estrategia.

Debido a estas circunstancias, cuando un proyecto se interrumpe en medio del camino, también pueden surgir varios problemas legales. En tales casos, normalmente, dado que es por conveniencia personal del usuario, se reconoce al proveedor ciertos derechos legales, como la solicitud de remuneración de acuerdo con el porcentaje de finalización. Dependiendo del tipo de contrato que se haya adoptado, aunque hay diferencias en las disposiciones que sirven de base, el contenido se organiza de la siguiente manera:

・En caso de contrato de obra: Artículo 641 del Código Civil Japonés
Artículo 641 del Código Civil Japonés
→Mientras el contratista no complete el trabajo, el cliente puede rescindir el contrato en cualquier momento indemnizando los daños.
・En caso de contrato de mandato: Artículo 648, párrafo 3 del Código Civil Japonés (dependiendo de las circunstancias, también puede haber una solicitud de indemnización por daños y perjuicios basada en el Artículo 651 del Código Civil Japonés)
Artículo 648 del Código Civil Japonés
→Cuando el mandato termina en medio de la ejecución debido a una causa que no puede atribuirse al mandatario, este puede solicitar una remuneración de acuerdo con el porcentaje de ejecución ya realizado.
Artículo 651 del Código Civil Japonés
→1. El mandato puede ser rescindido en cualquier momento por cualquiera de las partes.
→2. Cuando una de las partes rescinde el mandato en un momento desfavorable para la otra parte, esa parte debe indemnizar los daños de la otra parte. Sin embargo, esto no se aplica si hay una razón justificable.

Tipo de crisis 3: Cuando se descubren deficiencias en el sistema entregado posteriormente

A menudo, los usuarios evalúan la calidad de un sistema basándose en la sensación de operación en la pantalla. Sin embargo, desde el punto de vista de quienes reciben el trabajo, lo que resulta más complicado es el diseño de la base de datos y la identificación de los elementos de prueba después de considerar todos los métodos de operación.

En otras palabras, incluso un sistema que parecía funcionar sin problemas al principio puede presentar problemas como:

• A medida que aumenta la cantidad de datos registrados, la velocidad de procesamiento se ralentiza.
• Aunque el sistema parecía funcionar sin problemas en las operaciones diarias básicas, se descubrió que se producen errores en operaciones especiales que ocurren una vez cada varios meses o años.
• Aunque parece que los resultados se están produciendo correctamente en la superficie, la lógica real puede no ser correcta. (Por ejemplo, incluso si “2” se produce correctamente en respuesta a la entrada “1+1” del usuario, no necesariamente significa que el cálculo se está realizando correctamente. A menudo, los errores de lógica no se pueden descubrir simplemente operando la pantalla de manera descuidada. En este sentido, se puede decir que se requiere cierta “habilidad técnica” en el proceso de prueba.)

Estos son problemas que realmente pueden ocurrir. Si analizamos estos casos desde un punto de vista legal, podríamos considerar la posibilidad de que se trate de una violación de la obligación de gestión del proyecto por parte del proveedor, es decir, un problema de incumplimiento incompleto en términos del Código Civil japonés.

En este caso, si no se ha establecido ninguna regla especial en el contrato, se aplicarán las disposiciones relativas a los contratos de obra.

Los puntos a considerar en este caso se resumen de la siguiente manera:

https://monolith.law/corporate/defect-warranty-liability[ja]

Estos son los puntos que se resumen.

Resumen

Cada proyecto de desarrollo de sistemas avanza a través de diversos y variados giros y vueltas. Sin embargo, cuando se trata de “incendios” en proyectos legales, el marco que hemos presentado en este artículo puede servir como un mapa. Los problemas legales relacionados con el desarrollo de sistemas ciertamente abarcan una amplia gama de temas.

Así como el trabajo de desarrollo de sistemas requiere habilidades de pensamiento constructivo, la gestión de riesgos asociada también puede llevarse a cabo de manera más constructiva si no se pierde de vista la imagen general del campo. ¿No es así?