¿Cuáles son los puntos a tener en cuenta al firmar un contrato de subcontratación en el desarrollo de sistemas?

Los contratos que se firman en un proyecto de desarrollo de sistemas de IT son principalmente contratos de obra y contratos de mandato. Tanto para el usuario como para el proveedor, hay varias ventajas y desventajas al adoptar cada tipo de contrato, pero es importante entender sus características y los puntos a tener en cuenta al firmarlos. En este artículo, explicaremos los contratos de obra en el desarrollo de sistemas de IT.

Desarrollo de sistemas y contratos de obra

¿Qué es un contrato de obra?

Para entender qué es un contrato de obra, lo más importante es verificar los requisitos para su establecimiento directamente en el texto legal.

Artículo 632

El contrato de obra se establece cuando una de las partes se compromete a completar un trabajo y la otra parte se compromete a pagar una remuneración por el resultado de ese trabajo.

El término “completar un trabajo” es la clave. Un ejemplo típico de un contrato de obra es la construcción de un edificio que requiere obras. Por ejemplo, la “completación del trabajo” se logra cuando se construye una casa o un edificio antes de la fecha límite, y la obligación se considera cumplida. Por el contrario, si la construcción se retrasa y no se cumple con la fecha de entrega, se puede imponer una responsabilidad por incumplimiento de la obligación bajo ciertas condiciones. Sin embargo, una vez que se reconoce la “completación del trabajo”, ya no hay problemas de incumplimiento de la obligación, y a partir de entonces se convierte en un problema de responsabilidad por defectos. En este sentido, el hecho de que se da gran importancia al resultado de la “completación del trabajo” es una característica del contrato de obra. Para más detalles sobre cuándo se reconoce la “completación del trabajo”, consulte el siguiente artículo.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Los contratos de obra no sólo se utilizan en la construcción, sino también en proyectos de desarrollo de sistemas que requieren grandes ideas y una planificación detallada.

Diferencia entre el contrato de obra y el contrato de mandato

Una vez que se entiende que el contrato de obra es un tipo de contrato que se centra en el resultado de la “completación del trabajo”, también se puede entender la característica del contrato de mandato. Este último se centra en el proceso, no en el resultado de la “completación”. Por ejemplo, si el proceso de trabajo se ha llevado a cabo adecuadamente, independientemente del resultado, es posible solicitar una remuneración (Artículo 648, párrafo 2), y si el cumplimiento se termina a mitad de camino debido a circunstancias que no pueden atribuirse al mandatario, es posible solicitar una remuneración proporcional (Artículo 648, párrafo 3).

Para una comparación detallada entre el contrato de mandato y el contrato de mandato, consulte el siguiente artículo.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Por qué se prefiere el contrato de obra en el desarrollo de sistemas

En los contratos de desarrollo de sistemas, los contratos de obra son muy comunes. La razón por la que se utilizan con frecuencia es que ofrecen ciertas ventajas tanto para el usuario que encarga el trabajo como para el proveedor que lo acepta.

En primer lugar, una de las ventajas para el usuario que encarga el trabajo mediante un contrato de obra es que los requisitos para el cumplimiento de la obligación se pueden aclarar fácilmente en términos de “completación del trabajo”. En otras palabras, a menos que se llegue a un estado que se pueda considerar “completado” (incluso si se encuentran errores más tarde, etc., y surgen problemas de responsabilidad por defectos), no es necesario pagar la remuneración en principio. Esta claridad es muy atractiva para los usuarios que no quieren correr el riesgo de que la remuneración que deben pagar se dispare si el tiempo de trabajo es mayor de lo esperado o si el plazo se alarga. El hecho de pagar una remuneración fija a cambio de un producto terminado tiene una gran conveniencia desde el punto de vista de la gestión del presupuesto.

Por otro lado, para el proveedor que acepta el trabajo, también puede haber ciertas ventajas en aceptar el trabajo mediante un contrato de obra. Un contrato de obra puede ofrecer una mayor tasa de beneficio que un contrato de mandato si se puede llevar a cabo con éxito.

Dado que “completar el trabajo” es un requisito para el cumplimiento de la obligación, desde el punto de vista del proveedor que acepta el trabajo, no importa cuánto cueste el producto (en el caso del desarrollo de sistemas, la mayor parte son costos laborales) en el proceso hasta la “completación”. De esta manera, tanto el proveedor que quiere aumentar su tasa de beneficio como el usuario que quiere facilitar la gestión del presupuesto tienen sus propias expectativas, y por eso los contratos de obra son muy preferidos en el desarrollo de sistemas.

Puntos a tener en cuenta al firmar un contrato de obra

Aunque los contratos de obra pueden ser beneficiosos para ambas partes, los proveedores deben ser conscientes de los riesgos asociados con la firma de estos contratos sin la debida consideración. En particular, el hecho de que la “finalización del trabajo” sea necesaria para cumplir con las obligaciones significa que no se puede eximir de la responsabilidad por incumplimiento de las obligaciones sin la finalización del producto. Este es también el motivo de los frecuentes casos de problemas, como tener que dedicar tiempo a la entrega incluso si se incurre en pérdidas debido a errores en las estimaciones del proveedor.

Entonces, ¿qué se debe tener en cuenta al firmar un contrato de obra? Veamos cada punto a continuación.

Definir claramente los requisitos del sistema y las condiciones de aceptación antes de tiempo

En un contrato de obra, es esencial definir claramente las condiciones para la “finalización del trabajo”. Normalmente, los requisitos para la “finalización del trabajo” se refieren al contenido acordado en la fase de definición de requisitos. Sin embargo, en la práctica, puede haber casos en los que se requieran cambios después del hecho a medida que avanza el proceso de desarrollo, por lo que los requisitos para la “finalización del trabajo” también pueden cambiar. Incluyendo estos, se considera importante esforzarse en documentar el historial de cambios en las especificaciones. En el siguiente artículo, se explica cómo manejar la gestión de cambios en los proyectos de desarrollo de sistemas desde una perspectiva legal.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Además, en relación con este tema, también es efectivo prevenir problemas futuros al acordar de antemano sobre la “aceptación” que realiza el usuario. Es natural suponer situaciones en las que, incluso si se intenta entregar el producto, no se puede contactar con el responsable del usuario o no se recibe respuesta durante mucho tiempo. Para evitar que se deje en un estado en el que no está claro si la aceptación ha sido aprobada o no, es beneficioso establecer un plazo específico para la aceptación. Esto se conoce como la “cláusula de aceptación presunta”, que se explica en el siguiente artículo.

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

Acordar de antemano sobre la transferencia de derechos de autor

Otro problema común es la transferencia de derechos de autor. Aunque el principio es que los derechos de autor son adquiridos por la “persona que los crea”, es decir, el proveedor en el caso del desarrollo de sistemas, es posible transferir o ceder estos derechos debido a la naturaleza de los mismos. Por lo tanto, acordar de antemano si se cederán los derechos de autor al usuario puede prevenir problemas posteriores. Para obtener más detalles sobre la propiedad y la transferencia de derechos de autor, consulte el siguiente artículo.

https://monolith.law/corporate/copyright-for-the-program-source-code[ja]

Otras precauciones

Además, si desea firmar un contrato como un contrato de obra sin incluir elementos de subcontratación, debe tener en cuenta los siguientes puntos:

• Mantener la remuneración independiente del tiempo de trabajo
• Indicar claramente “Contrato de obra” en el título del contrato
• Indicar claramente las cláusulas de garantía de defectos
• Asegurarse de que el pago de la remuneración sea un intercambio equivalente por los resultados o productos

Es importante tener en cuenta estos puntos.

Por otro lado, no se debe caer en la trampa de pensar que todo se convierte en un contrato de obra simplemente escribiendo “Contrato de obra” en el título del contrato. En la práctica, puede suceder que las plantillas de contratos de otras empresas se utilicen de manera continua, sin tener en cuenta si el contenido de las mismas es un contrato de obra o de subcontratación. En caso de litigio, se dará más importancia a los aspectos más sustanciales, como el contenido general de las cláusulas del contrato y las costumbres comerciales hasta la fecha, que a los elementos superficiales como el texto del título. También se debe prestar atención a este punto.

Resumen

Si se tiene en cuenta lo anterior, será más fácil manejar adecuadamente los contratos de trabajo por encargo. Cabe destacar que la palabra “encargo” se utiliza tanto en contratos de tipo contractual como en contratos de tipo cuasi-mandato. Además, el término “encargo de trabajo” se utiliza comúnmente cuando las partes tienen la intención de tener un contrato de cuasi-mandato. Sería aún mejor prestar atención a estas sutiles diferencias en la terminología.