Entonces, \u00bfqu\u00e9 tipo de obligaci\u00f3n de cooperaci\u00f3n tiene el usuario en un proyecto de desarrollo de sistemas? Hay muchas pistas en los precedentes judiciales anteriores sobre este punto.<\/p>\n\n\n\n
En el juicio, se discuti\u00f3 la existencia de una obligaci\u00f3n de cooperaci\u00f3n del usuario en el desarrollo debido a la demora en la toma de decisiones del usuario (demandante) en casos donde la fecha de entrega del proveedor (demandado) se retras\u00f3. En este caso, el tribunal reconoci\u00f3 la violaci\u00f3n de la obligaci\u00f3n de cooperaci\u00f3n por parte del usuario y neg\u00f3 la responsabilidad del proveedor por incumplimiento de contrato. (Aunque se reconoci\u00f3 la rescisi\u00f3n del contrato, tambi\u00e9n se reconoci\u00f3 una compensaci\u00f3n por negligencia del 60%.)<\/p>\n\n\n\n
\nEl contrato de desarrollo del sistema inform\u00e1tico en cuesti\u00f3n es un contrato de desarrollo de sistema hecho a medida, y en tal contrato, el proveedor no puede completar el sistema por s\u00ed solo<\/u>. Es necesario que el cliente (usuario) coordine las opiniones internas de manera precisa durante el proceso de desarrollo, comunique claramente al proveedor qu\u00e9 funciones desea, discuta las funciones deseadas con el proveedor<\/u>, decida finalmente las funciones<\/u>, adem\u00e1s, decida las pantallas y los formularios<\/u>, y acepte los productos entregables<\/u>.<\/p>\nFallo del Tribunal de Distrito de Tokio, 10 de marzo de 2004 (A\u00f1o 16 de Heisei)<\/cite><\/blockquote>\n\n\n\nEste fallo no s\u00f3lo indica que el desarrollo del sistema en s\u00ed es un trabajo conjunto con el usuario, sino que tambi\u00e9n es muy sugerente en cuanto a “en qu\u00e9 aspectos espec\u00edficos se debe colaborar”.<\/p>\n\n\n\n
Intentemos traducir el lenguaje de la sentencia anterior a los t\u00e9rminos de TI del desarrollo de sistemas.<\/p>\n\n\n\n
\n\n\nDecidir finalmente las funciones…<\/strong>\u2192Definici\u00f3n de requisitos: Clarificaci\u00f3n de qu\u00e9 tipo de sistema con qu\u00e9 funciones se quiere crear<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n\n\nDecidir las pantallas y los formularios…<\/strong>\u2192Dise\u00f1o b\u00e1sico: Dise\u00f1o de la apariencia del sistema desde el punto de vista del operador del sistema, como las pantallas y los formularios<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n\n\nAceptar los productos entregables…<\/strong>\u2192Prueba: Verificar si el producto final cumple con las especificaciones, confirmar con evidencia como volcados de base de datos, y aceptar la entrega.<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\nPodemos organizarlo de esta manera. Todos estos son cosas que no se pueden hacer solas, sin importar cu\u00e1n avanzada sea la especialidad en el sistema de TI. Las funciones requeridas y el dise\u00f1o de la pantalla son b\u00e1sicamente cosas que el usuario debe aclarar, y s\u00f3lo el usuario puede verificar si se ha realizado lo que se solicit\u00f3.<\/p>\n\n\n\n
Adem\u00e1s, al igual que se impone una obligaci\u00f3n de gesti\u00f3n de proyectos al proveedor, se impone una obligaci\u00f3n de cooperaci\u00f3n al usuario. Por lo tanto, si el usuario viola su obligaci\u00f3n de cooperaci\u00f3n en el proceso anterior, existe la posibilidad de que el proveedor pueda reclamar al usuario por incumplimiento de contrato o da\u00f1os y perjuicios por actos il\u00edcitos.<\/p>\n\n\n\n
<\/span>\u00bfC\u00f3mo se interpretan las solicitudes de cambio de especificaciones despu\u00e9s de la facturaci\u00f3n?<\/strong><\/span><\/h2>\n\n\n\n\u00bfSe entiende que el usuario solicita trabajos adicionales al proveedor despu\u00e9s de la facturaci\u00f3n?<\/figcaption><\/figure>\n\n\n\nAdem\u00e1s, si asumimos que el proyecto de desarrollo del sistema es un trabajo conjunto entre el usuario y el proveedor, la discusi\u00f3n se desarrollar\u00e1 hacia un debate m\u00e1s avanzado. Es decir, “si el usuario solicita adiciones o modificaciones de funciones despu\u00e9s de la facturaci\u00f3n, y esto dificulta la entrega a tiempo, \u00bfqui\u00e9n es responsable?” es el problema.<\/p>\n\n\n\n
El desarrollo del sistema generalmente comienza con la definici\u00f3n de requisitos, y se busca avanzar en el orden de dise\u00f1o b\u00e1sico, dise\u00f1o detallado, fabricaci\u00f3n (implementaci\u00f3n del programa), prueba, etc., para evitar retrasos tanto como sea posible (generalmente llamado modelo de cascada). Sin embargo, debido a ciertas circunstancias, si se descubre que hay un defecto en el proceso anterior, tambi\u00e9n ocurre con frecuencia en la realidad que hay retrasos en el proceso.<\/p>\n\n\n\n
\u00bfC\u00f3mo debemos pensar si no podemos cumplir con la fecha de entrega en tales casos? Al interpretar los precedentes, parece que hay diferencias en las conclusiones dependiendo del momento en que se produjo el trabajo adicional.<\/p>\n\n\n\n
<\/span>Si el trabajo adicional fue antes de la clarificaci\u00f3n de las especificaciones como el dise\u00f1o externo<\/strong><\/span><\/h3>\n\n\n\nEl precedente mencionado anteriormente indica que no es una violaci\u00f3n del deber de cooperaci\u00f3n en s\u00ed mismo solicitar un desarrollo adicional del usuario durante el dise\u00f1o b\u00e1sico (antes de la etapa de implementaci\u00f3n del programa).<\/p>\n\n\n\n
\nEs natural en el proceso de desarrollo del sistema como este caso que el usuario haga varias solicitudes al proveedor sobre el sistema a construir durante el trabajo de dise\u00f1o b\u00e1sico<\/span>, y adem\u00e1s, en el usuario demandante sin conocimientos especializados<\/span>, si dicha solicitud requiere tarifas de encargo adicionales o una extensi\u00f3n del plazo de entrega, etc., es dif\u00edcil juzgar con precisi\u00f3n si interfiere con el proceso de trabajo<\/span>. Por lo tanto, no se puede decir que el demandante usuario deber\u00eda haberse abstenido de hacer solicitudes que requieran tarifas de encargo adicionales o una extensi\u00f3n del plazo de entrega, etc. Por el contrario, si el demandante usuario hizo una solicitud que requiere tarifas de encargo adicionales o una extensi\u00f3n del plazo de entrega, etc., el demandado que tiene el deber de gesti\u00f3n del proyecto deber\u00eda haberle informado de esto al demandante usuario y haber solicitado discusiones sobre la retirada de la solicitud o la extensi\u00f3n del plazo de entrega, etc., para evitar interferencias con el trabajo de desarrollo.<\/p>\nFallo del Tribunal de Distrito de Tokio, 10 de marzo de 2004 (2004)<\/cite><\/blockquote>\n\n\n\nEn este fallo, se indic\u00f3 que el usuario tambi\u00e9n tiene cierto deber de cooperaci\u00f3n, y que no se debe considerar que el usuario es un experto en desarrollo de sistemas. En otras palabras, dado que el usuario que realiza el pedido no es un experto en desarrollo de sistemas, no es extra\u00f1o que haga pedidos por partes hasta que se aclare el contenido del sistema a desarrollar (incluso si no est\u00e1 acostumbrado a hacer pedidos), y mucho menos si el contenido del pedido requiere una revisi\u00f3n del plazo de entrega, etc., “deber\u00eda haberse dado cuenta de ello por s\u00ed mismo” es demasiado severo.<\/p>\n\n\n\n
Por supuesto, el deber impuesto al proveedor aqu\u00ed se considera que se refiere a los esfuerzos de comunicaci\u00f3n, como solicitar una extensi\u00f3n del plazo de entrega (o, si no se puede mover el plazo de entrega, sugerir que se retire la solicitud adicional en s\u00ed). Por lo tanto, no se considera que incluya la obligaci\u00f3n de aceptar todas las solicitudes del usuario y entregarlas a tiempo seg\u00fan la fecha original, por lo que es necesario tener cuidado con este punto.<\/p>\n\n\n\n
<\/span>Si el trabajo adicional fue despu\u00e9s de la confirmaci\u00f3n de las especificaciones en la etapa de fabricaci\u00f3n o prueba<\/strong><\/span><\/h3>\n\n\n\nSi invertimos el contenido del fallo anterior, podemos prever hasta cierto punto qu\u00e9 conclusi\u00f3n habr\u00eda tenido si se tratara de un desarrollo adicional despu\u00e9s de que las especificaciones ya se hubieran confirmado. En ese caso, es probable que tales solicitudes sean dif\u00edciles de aceptar. Ciertamente, el nivel de comprensi\u00f3n del trabajo de desarrollo entre el usuario y el proveedor no cambia, ya sea antes o despu\u00e9s de la confirmaci\u00f3n de las especificaciones.<\/p>\n\n\n\n
Sin embargo, cambiar o agregar el contenido del pedido despu\u00e9s de que las especificaciones se hayan confirmado tiene una alta probabilidad de forzar la repetici\u00f3n del trabajo. En muchos casos, es dif\u00edcil defender que “es natural que el cliente haga varias solicitudes” si la entrega se retrasa incluso en tales casos. Adem\u00e1s, si se producen muchos cambios de especificaciones y adiciones de funciones despu\u00e9s de la facturaci\u00f3n, esto plantea la pregunta de si no hubo una violaci\u00f3n del deber de cooperaci\u00f3n por parte del usuario en el proceso ascendente que ya deber\u00eda haberse completado antes.<\/p>\n\n\n\n
Desde este punto de vista, no es realista considerar que el proveedor es responsable del retraso en la entrega causado por los cambios de especificaciones realizados despu\u00e9s de que se confirmaron una vez. Se puede decir que es apropiado leer al mismo tiempo el significado de este tipo del texto del fallo mencionado anteriormente.<\/p>\n\n\n\n
Adem\u00e1s, este tipo de juicio tiende a ser realizado utilizando no solo el contrato, sino tambi\u00e9n las actas de las reuniones de acuerdo con el progreso del desarrollo del sistema como evidencia. <\/p>\n\n\n\n
<\/span>Resumen: Es importante no olvidar que la definici\u00f3n de requisitos es un proceso del lado del usuario<\/strong><\/span><\/h2>\n\n\n\nLa definici\u00f3n de requisitos es una oportunidad para que el proveedor demuestre su habilidad, pero al mismo tiempo, debemos ser conscientes de que es fundamentalmente un proceso del lado del usuario. Independientemente de si el sistema se desarrolla con la ayuda de expertos externos, se considera legalmente que es un \u00e1rea que debe estar bajo la gobernanza de la propia empresa.<\/p>\n\n\n\n
Si el usuario no coopera en el proceso de desarrollo, incluso si el proyecto se incendia, es posible que el tribunal tenga una visi\u00f3n estricta hacia el usuario. Este es un punto que debemos reconocer desde el principio.
El trabajo de desarrollo de sistemas, cuanto m\u00e1s grande sea el sistema a desarrollar, requiere la inversi\u00f3n de un gran n\u00famero de personas y tiempo. Por lo tanto, no solo el proveedor que asume el desa […]<\/p>\n","protected":false},"author":1,"featured_media":76369,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[19,31],"acf":[],"_links":{"self":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/57506"}],"collection":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/comments?post=57506"}],"version-history":[{"count":6,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/57506\/revisions"}],"predecessor-version":[{"id":76372,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/57506\/revisions\/76372"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/media\/76369"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/media?parent=57506"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/categories?post=57506"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/tags?post=57506"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}