\n
Esto implica que se espera que el proveedor avance el proyecto de acuerdo con el cronograma establecido en el contrato y, dependiendo de la situaci\u00f3n, trabaje con el usuario para asegurar que el desarrollo avance sin problemas.<\/p>\n<\/div><\/div>\n\n\n\n
– La obligaci\u00f3n de gestionar adecuadamente la participaci\u00f3n del usuario en el desarrollo y trabajar con el usuario para asegurar que no se realicen acciones que obstaculicen el trabajo de desarrollo por parte de usuarios que no tienen conocimientos especializados en desarrollo de sistemas.<\/p>\n\n\n\n
Esto se refiere a mostrar al usuario los problemas y plazos para los asuntos que requieren toma de decisiones y preocupaciones que deben resolverse, indicar los problemas que surgen cuando la toma de decisiones del usuario se retrasa, aconsejar al usuario para fomentar la toma de decisiones, y si hay solicitudes que no se pueden aceptar debido al progreso del desarrollo, explicar completamente las razones y rechazar las solicitudes del usuario.<\/p>\n\n\n\n
De esta manera, el proveedor tiene la obligaci\u00f3n de avanzar en el trabajo de desarrollo mientras fomenta la toma de decisiones del usuario y se esfuerza por asegurar el \u00e9xito del desarrollo del sistema<\/strong>.<\/p>\n\n\n\n<\/span>Obligaci\u00f3n de cooperaci\u00f3n del usuario<\/span><\/h3>\n\n\n\nPor supuesto, en el desarrollo de sistemas, no es el caso de que el proveedor asuma unilateralmente todas las obligaciones. Despu\u00e9s de todo, dado que es un sistema de TI que se utilizar\u00e1 en la empresa del cliente, el proyecto de desarrollo del sistema no deber\u00eda ser “asunto de otros” para el cliente.<\/p>\n\n\n\n
Aunque se utilicen expertos externos confiando en su capacidad t\u00e9cnica y organizativa para desarrollar sistemas, la gobernanza interna deber\u00eda ser aplicable. Sin esfuerzo para aprovechar la habilidad de los expertos externos, es imposible entregar el trabajo necesario como si fuera asunto de otros. En este sentido, el usuario tambi\u00e9n tiene la obligaci\u00f3n de cooperar en el desarrollo del sistema<\/strong>.<\/p>\n\n\n\nLas obligaciones de cooperaci\u00f3n que el usuario debe cumplir incluyen lo siguiente:<\/p>\n\n\n\n
\u3000\u2460 El usuario realiza un an\u00e1lisis de riesgos de manera proactiva, coordina adecuadamente las opiniones internas y unifica las opiniones antes de transmitir las solicitudes al proveedor.<\/p>\n\n\n\n
\u3000\u2461 Verificar los productos entregables.<\/p>\n\n\n\n
\u3000\u2462 Responder a las solicitudes de cooperaci\u00f3n del proveedor.<\/p>\n\n\n\n
Se espera que el usuario comunique claramente al proveedor las funciones que requiere el sistema y coopere activamente en el desarrollo<\/strong>.<\/p>\n\n\n\n<\/span>La gesti\u00f3n de proyectos no es f\u00e1cil<\/span><\/h3>\n\n\n\nAvanzar con la gesti\u00f3n de riesgos del proyecto como premisa.<\/figcaption><\/figure>\n\n\n\nEl hecho de que los sistemas de TI est\u00e9n compuestos por la combinaci\u00f3n de peque\u00f1os componentes puede ser dif\u00edcil de percibir para los usuarios que solo ven la pantalla. Sin embargo, es muy importante al considerar la dificultad de gestionar un proyecto de desarrollo de sistemas. Precisamente porque los sistemas de TI son as\u00ed, se requiere del proveedor una atenci\u00f3n meticulosa y, al mismo tiempo, la capacidad de organizar la imagen general de manera concisa y la capacidad de tener una visi\u00f3n general.<\/p>\n\n\n\n
La dificultad del trabajo se encuentra en lugares que no se pueden imaginar solo mirando la pantalla, y tambi\u00e9n es la raz\u00f3n por la que los proyectos “se incendian” si se cambia el punto de vista. Primero, es importante entender estos puntos y saber que “gestionar un proyecto para desarrollar un sistema de TI no es una tarea f\u00e1cil”<\/strong> ser\u00e1 la premisa b\u00e1sica para aprender sobre la gesti\u00f3n de riesgos del proyecto.<\/p>\n\n\n\n<\/span>Lo que puede suceder en caso de incumplimiento de las obligaciones de gesti\u00f3n de proyectos<\/span><\/h2>\n\n\n\n\nEntonces, \u00bfqu\u00e9 sucede espec\u00edficamente cuando hay una violaci\u00f3n de las obligaciones de gesti\u00f3n de proyectos?<\/p>\n\n\n\n
No hay ninguna disposici\u00f3n clara que diga “Estas son las obligaciones de gesti\u00f3n de proyectos”.<\/p>\n\n\n\n
Sin embargo, a partir de los precedentes judiciales, podemos deducir una postura bastante consistente sobre lo que puede hacer un usuario si el proveedor ha incumplido sus obligaciones.<\/p>\n\n\n\n
Si el proveedor ha incumplido sus obligaciones, el usuario puede reclamar al proveedor indemnizaci\u00f3n por da\u00f1os y perjuicios o la rescisi\u00f3n del contrato.<\/strong> Sin embargo, si el usuario tambi\u00e9n tiene un problema, se puede determinar que el proveedor no es responsable, o se puede compensar la negligencia, lo que puede reducir la cantidad de indemnizaci\u00f3n por da\u00f1os y perjuicios.<\/p>\n\n\n\nPor otro lado, si el usuario ha incumplido su obligaci\u00f3n de cooperar, el proveedor puede reclamar al usuario una cantidad equivalente a la remuneraci\u00f3n, bas\u00e1ndose en el riesgo asumido (Art\u00edculo 536, p\u00e1rrafo 2, del C\u00f3digo Civil japon\u00e9s) o el incumplimiento de la obligaci\u00f3n, si el trabajo no se ha completado como resultado.<\/p>\n\n\n\n
<\/span>Ejemplos de casos judiciales que demuestran la obligaci\u00f3n de la gesti\u00f3n de proyectos<\/span><\/h2>\n\n\n\n\nExisten varios casos judiciales representativos que explican la obligaci\u00f3n de la gesti\u00f3n de proyectos.<\/p>\n\n\n\n
El caso que se detalla a continuaci\u00f3n se desarroll\u00f3 hasta llegar a juicio debido a retrasos en la fecha de entrega y a que el proveedor solicit\u00f3 un aumento en la estimaci\u00f3n inicial en el desarrollo de sistemas. Podr\u00eda ser un ejemplo t\u00edpico de un “proyecto en llamas”, donde la disputa se prolonga hasta llegar a juicio sobre c\u00f3mo dividir la responsabilidad entre el usuario y el proveedor.<\/p>\n\n\n\n
\nEl acusado, como especialista en desarrollo de sistemas, ten\u00eda la obligaci\u00f3n de completar el sistema inform\u00e1tico del caso en cuesti\u00f3n antes de la fecha de entrega acordada, de acuerdo con el contrato de desarrollo del sistema inform\u00e1tico y la propuesta del sistema inform\u00e1tico, bas\u00e1ndose en su alto nivel de conocimiento y experiencia especializada. Por lo tanto, el acusado deber\u00eda entender que tiene la obligaci\u00f3n de avanzar en el trabajo de desarrollo de acuerdo con los procedimientos de desarrollo, m\u00e9todos de desarrollo, procesos de trabajo, etc., presentados en el contrato de desarrollo del sistema inform\u00e1tico y la propuesta del sistema inform\u00e1tico, gestionar constantemente el progreso, esforzarse por descubrir factores que obstaculicen el trabajo de desarrollo y tratar adecuadamente con ellos. Adem\u00e1s, dado que el desarrollo del sistema se lleva a cabo en consulta con el cliente, el acusado deber\u00eda haber tenido la obligaci\u00f3n de gestionar adecuadamente la participaci\u00f3n del demandante, la Asociaci\u00f3n Nacional de Seguros de Salud, en el desarrollo del sistema y de influir en el demandante, que no tiene conocimientos especializados en desarrollo de sistemas, para evitar cualquier acci\u00f3n que obstaculice el trabajo de desarrollo (en adelante, estas obligaciones se denominar\u00e1n “tareas de gesti\u00f3n de proyectos”).<\/p>\nSentencia del Tribunal de Distrito de Tokio, 10 de marzo de 2004 (A\u00f1o 16 de Heisei)<\/cite><\/blockquote>\n\n\n\nNo es importante interpretar el lenguaje detallado o la complicada secuencia de eventos del caso a partir del resumen de la sentencia anterior. Lo m\u00e1s importante es que se utiliza la frase “obligaci\u00f3n de gesti\u00f3n de proyectos”<\/strong>. Aunque no hay una disposici\u00f3n expl\u00edcita, se puede ver la actitud de establecer una gu\u00eda para dividir la responsabilidad legal bajo la direcci\u00f3n del tribunal.<\/p>\n\n\n\nResumamos y organicemos el contenido de la sentencia anterior de manera sencilla. La “obligaci\u00f3n de gesti\u00f3n de proyectos” mencionada aqu\u00ed es:<\/p>\n\n\n\n