¿Cómo se deben guardar las actas desde una perspectiva legal en el desarrollo de sistemas?

Cuando una empresa encarga el desarrollo de un sistema a otra empresa, a menudo se puede decir que los contratos firmados con los sellos corporativos de los directores representantes y los documentos de definición de requisitos creados por los responsables no son necesariamente claros sobre qué se va a crear y cuándo. Esto se debe a que en muchos desarrollos de sistemas, se realizan diariamente intercambios de correos electrónicos y llamadas telefónicas a nivel de los responsables, reuniones organizadas por personas a nivel de responsabilidad, confirmación de especificaciones que inicialmente eran ambiguas, cambios de especificaciones de acuerdo con los cambios de situación, solicitudes de adición de funciones y solicitudes de cooperación en problemas que surgen.

Desde el punto de vista de facilitar el desarrollo del sistema y prepararse para cualquier disputa, la creación y gestión de documentos es importante para gestionar sin problemas el progreso de un proyecto de desarrollo de sistemas.

En este artículo, explicaremos cómo mantener las actas y los materiales de las reuniones utilizados en las reuniones de progreso del desarrollo del sistema desde una perspectiva legal.

¿Por qué es importante la gestión de documentos en el desarrollo de sistemas?

En un proyecto de desarrollo de sistemas, es muy importante desde un punto de vista legal mantener registros de los contenidos discutidos en las reuniones de confirmación, así como del progreso y los antecedentes del proyecto. Las razones para esto pueden ser las siguientes:

Para evitar conflictos en el futuro

El desarrollo de sistemas es normalmente un proyecto que involucra a muchas partes, tanto del lado del usuario como del proveedor. Por lo tanto, si hay discrepancias en la comprensión entre el usuario y el proveedor sobre cuánto papel juega cada uno y qué obligaciones asumen, puede haber problemas en el progreso del proyecto posterior.

Además, el hecho de que muchas personas estén involucradas en el proyecto significa que, si cambiamos nuestra perspectiva, es fácil que surjan problemas de comunicación, como “las cosas que la gente dice son ligeramente diferentes y no sé quién tiene razón”.

Es significativo resumir el contenido del acuerdo formado en texto, no sólo para verificar si hay discrepancias en la comprensión de ambas partes, sino también para alinear los pasos de los interesados al resumirlo en un documento que todos puedan verificar (en su propio tiempo).

Por cierto, el uso de conocimientos legales para prevenir conflictos antes de que ocurran a veces se llama “ley preventiva”.

Como medida en caso de un conflicto posterior

Además, si explicamos la importancia de la gestión de documentos desde un punto de vista ligeramente diferente al de la ley preventiva mencionada anteriormente, podemos mencionar el “manejo de crisis” en caso de que realmente ocurra un conflicto.

Imaginemos un escenario en el que se produce algún tipo de problema, el proyecto se interrumpe antes de que se produzcan los resultados, o no se cumple la fecha de entrega original y se convierte en un caso judicial. Esto es cierto tanto para el usuario como para el proveedor, pero incluso si dices “tengo algo que decir sobre lo que ha ocurrido”, si no se ha documentado, no podrás probar tu punto de vista y podrías ser tratado injustamente en el juicio.

En particular, en los problemas que surgen de “no cumplir con la fecha de entrega”, los puntos como “cuándo y cómo se descubrió el problema”, “cuándo se solicitó el cambio de especificaciones”, “cómo respondió el proveedor a la solicitud de adición de funciones por parte del usuario” a menudo se convierten en puntos de discusión importantes que pueden influir en el resultado del juicio. Si hay muchos problemas de “dije, no dije” en ese momento, será difícil esperar una resolución justa del conflicto.

¿Qué es especialmente importante en las actas de las reuniones de desarrollo de sistemas?

Tipos de reuniones en el desarrollo de sistemas

En los proyectos de desarrollo de sistemas, a menudo se planifican y realizan diversas reuniones a medida que avanza el proyecto. Esto no es sorprendente, considerando que muchos proyectos involucran a un gran número de personas. Es común que los programadores e ingenieros que implementan el programa en el lugar de desarrollo tengan reuniones regulares para verificar el progreso de su trabajo. También puede haber ocasiones en las que revisen el código implementado para verificar si hay problemas de mantenibilidad o vulnerabilidades de seguridad, entre otros.

Además de estas reuniones a nivel de los responsables en el lugar de desarrollo, también puede haber reuniones en las que se reúnan los directores de la empresa y los responsables con autoridad. En estos casos, la reunión a menudo se centra en la dirección y política general del proyecto de desarrollo. Estas reuniones a nivel de responsabilidad, destinadas a “captar” los asuntos importantes, también se conocen como comités de dirección.

El Comité de Dirección requiere especial atención

Como se mencionó anteriormente, se planifican diversas reuniones en el lugar de desarrollo de sistemas, dependiendo de la posición de las personas involucradas y del propósito de la reunión. Sin embargo, desde un punto de vista legal, la reunión que debe ser considerada especialmente importante es el Comité de Dirección. En comparación con las reuniones de progreso y revisión a nivel de responsables, el Comité de Dirección es particularmente importante para prevenir diversos conflictos y para tomar medidas en caso de que surjan conflictos. La importancia de la documentación debe ser plenamente reconocida. Las razones para esto son:

1. Debido a la naturaleza del Comité de Dirección, que es una reunión organizada por personas a nivel de responsabilidad, a menudo se trata de una reunión que implica decisiones importantes. Por lo tanto, es probable que se le dé importancia desde un punto de vista legal, ya que muestra cómo se perciben las cosas tanto por el usuario como por el proveedor.
2. En las reuniones a nivel de responsables, el contenido de la reunión a menudo se refleja más tarde en varios documentos de diseño y especificaciones. Por lo tanto, es difícil imaginar que surjan problemas debido a la “ausencia de documentación”. (Por supuesto, si la documentación de estos también es escasa, se considerará necesario mejorarla.)

Estos son algunos de los puntos que se pueden mencionar.

Casos judiciales relacionados con las actas del Comité Directivo

A continuación, presentamos un caso en el que las actas de las reuniones del Comité Directivo fueron tratadas como evidencia importante en un juicio real. El caso citado en la sentencia a continuación se refiere a un proyecto de desarrollo de sistemas que se estancó a mitad de camino, y se reconoció que el proveedor había incumplido su obligación de gestión del proyecto. El contenido de las actas de las reuniones en este caso, que mostraba la comprensión inicial de ambos, el proveedor y el usuario, tuvo un significado muy grande en el juicio.

El proveedor señala que el contenido de las actas de las reuniones del Comité Directivo, que se basa para reconocer el progreso del desarrollo del sistema en cuestión, fue modificado por el usuario y no necesariamente refleja la realidad del trabajo. Sin embargo, el Comité Directivo fue establecido con el propósito de tomar decisiones a nivel de alta gerencia en el desarrollo del sistema en cuestión, y los responsables de la implementación del desarrollo del sistema participaron tanto del lado del proveedor como del usuario, compartiendo la evaluación general, el progreso del trabajo y los problemas del cronograma, y tomando decisiones sobre problemas importantes. Y se suponía que el proveedor crearía las actas de las reuniones sobre los puntos discutidos allí y las registraría en la base de datos de las actas de las reuniones a más tardar en la mañana del segundo día hábil después de la reunión, y que las actas de las reuniones registrarían las decisiones finales de la reunión. Al finalizar las actas de las reuniones, tanto el proveedor como el usuario, reconociendo plenamente el significado de registrar el trabajo en las actas de las reuniones, examinaron su contenido y expresión, y se puede suponer que confirmaron el contenido como reflejando la realidad de la reunión. En particular, el proveedor, como persona que se dedica al desarrollo de sistemas, debía estar bien familiarizado con el significado y el método de creación de tales actas de las reuniones. Por lo tanto, se puede decir que es apropiado tratar las actas de las reuniones confirmadas como reflejando la realidad del trabajo del Comité Directivo, y a menos que se reconozcan circunstancias especiales, es apropiado reconocer que el contenido registrado allí resume el contenido del trabajo en cuestión en la fecha en cuestión en el Comité Directivo.

Tokyo High Court, 26 de septiembre de 2013 (Año 25 de la era Heisei)

Se puede considerar que la postura del tribunal es que si las actas de las reuniones son documentos de la reunión creados por acuerdo mutuo entre el proveedor y el usuario, se puede esperar que tengan cierto poder de presunción como “evidencia”. Desde otro punto de vista, si se hace una descripción demasiado fácil en las actas de las reuniones, existe el riesgo de que se convierta en evidencia tal cual, y se debe prestar mucha atención a esto.

¿Qué elementos concretos se deben registrar en las actas de las reuniones?

Las actas de las reuniones tienen una importancia crucial como evidencia en caso de litigio (y también para facilitar las negociaciones posteriores entre las partes, incluso si no hay litigio). Entonces, ¿qué se debe documentar y registrar específicamente en las actas de las reuniones? A continuación, lo organizaremos.

Aspectos que se deben registrar desde el punto de vista del proveedor

El proveedor tiene la obligación de gestionar el proyecto como experto en desarrollo de sistemas para el proyecto. Para una explicación detallada de qué es exactamente esta obligación, consulte el siguiente artículo.

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

Considerando esta obligación, los aspectos que el proveedor debe registrar en particular son:

1. El hecho de que cada etapa de desarrollo se ha completado y la fecha de la misma.
2. El historial de cómo ha respondido a las solicitudes de cambios de especificaciones y adiciones de funciones recibidas del lado del usuario.
3. Las medidas que ha tomado para solicitar cooperación cuando el progreso del trabajo de desarrollo se ha retrasado debido a las circunstancias personales del usuario, y la historia de esto.

Estos son algunos ejemplos.

Además, en relación con el punto 3 anterior, por ejemplo, el siguiente artículo explica qué debe considerar el proveedor si el usuario no realiza la aceptación. En este artículo, se explica cómo el juicio del tribunal puede cambiar significativamente dependiendo de cuánto cooperó el proveedor para la realización de la aceptación del usuario, citando sentencias reales.

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

Aspectos que se deben registrar desde el punto de vista del usuario

Por supuesto, el usuario también tiene la obligación de cooperar en cierta medida con el trabajo de desarrollo del proveedor, ya que es un sistema que se utilizará internamente en su propia empresa. Para una explicación general de esta obligación, consulte el siguiente artículo.

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

1. Historial de lo que el usuario ha comunicado al proveedor, como las funciones deseadas y la apariencia de la pantalla.
2. Historial de varios problemas que han surgido en el proceso del proveedor (por ejemplo, la salida repentina de un miembro o el retraso en el cronograma de desarrollo debido a la falta de investigación por parte del proveedor y sus causas).

En relación con el punto 2 anterior, lo que es particularmente propenso a desarrollar problemas imprevistos es cuando se está desarrollando un nuevo sistema al mismo tiempo que se está eliminando el antiguo. Los problemas son especialmente propensos a ocurrir cuando se transfieren datos del sistema antiguo al nuevo, pero para una explicación detallada de los problemas legales relacionados con estos problemas, consulte el siguiente artículo.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

Resumen

Lo anterior constituye una guía sobre cómo mantener registros de reuniones en el lugar de desarrollo del sistema desde una perspectiva legal. Además de los aspectos prácticos, es importante profundizar en la comprensión de la conexión entre temas como “ley”, “desarrollo de sistemas” y “gestión de documentos”. Precisamente porque el desarrollo de sistemas involucra a muchas personas y organizaciones y tiende a evolucionar hacia transacciones comerciales a gran escala, la prevención y gestión de conflictos asociados se vuelve crucial. Y desde la necesidad de preservar evidencia desde una perspectiva legal, la existencia de “documentos” que pueden ser verificados objetivamente por cualquiera adquiere un gran significado.

Ciertamente, verbalizar completamente todas las interacciones y la evolución del proyecto puede ser una carga y no siempre es realista. Sin embargo, es importante identificar qué asuntos son importantes desde un punto de vista legal y avanzar en la documentación de estos asuntos de manera oportuna. Este punto debería ser ampliamente reconocido por todos los involucrados en los negocios, independientemente de si son expertos en leyes o no.