{"id":59150,"date":"2023-11-10T17:07:59","date_gmt":"2023-11-10T08:07:59","guid":{"rendered":"https:\/\/monolith.law\/es\/?p=59150"},"modified":"2024-03-26T21:01:15","modified_gmt":"2024-03-26T12:01:15","slug":"system-development-member-breakaway","status":"publish","type":"post","link":"https:\/\/monolith.law\/es\/it\/system-development-member-breakaway","title":{"rendered":"\u00bfQu\u00e9 es la ley relacionada con la salida de miembros de un proyecto de desarrollo de sistemas?"},"content":{"rendered":"\n<p>En los proyectos de desarrollo de sistemas, normalmente se prioriza la desglosaci\u00f3n de cada proceso y tarea, avanzando con la mayor planificaci\u00f3n posible. Sin embargo, por mucho que se enfatice la planificaci\u00f3n, hay problemas imprevistos que no se pueden prevenir, \u00bfno es as\u00ed cuando se trata de problemas relacionados con las &#8216;personas&#8217;? En particular, los riesgos como la ausencia repentina por enfermedad o la renuncia de los miembros del proyecto son aspectos que no se pueden prevenir por completo, por mucho que se esfuerce en el seguimiento. En este art\u00edculo, explicaremos c\u00f3mo la ley se relaciona con la retirada de los miembros del proyecto.<br><\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_53 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/monolith.law\/es\/it\/system-development-member-breakaway\/#La_retirada_de_un_miembro_y_las_obligaciones_individuales_de_la_gestion_de_proyectos\" title=\"La retirada de un miembro y las obligaciones individuales de la gesti\u00f3n de proyectos\">La retirada de un miembro y las obligaciones individuales de la gesti\u00f3n de proyectos<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/monolith.law\/es\/it\/system-development-member-breakaway\/#Importantes_precedentes_legales_relacionados_con_la_salida_de_miembros\" title=\"Importantes precedentes legales relacionados con la salida de miembros\">Importantes precedentes legales relacionados con la salida de miembros<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/monolith.law\/es\/it\/system-development-member-breakaway\/#Caso_en_el_que_la_salida_de_un_miembro_provoco_un_retraso_en_la_fecha_de_entrega\" title=\"Caso en el que la salida de un miembro provoc\u00f3 un retraso en la fecha de entrega\">Caso en el que la salida de un miembro provoc\u00f3 un retraso en la fecha de entrega<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/monolith.law\/es\/it\/system-development-member-breakaway\/#Lo_que_se_puede_aprender_del_precedente_legal_anterior\" title=\"Lo que se puede aprender del precedente legal anterior\">Lo que se puede aprender del precedente legal anterior<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/monolith.law\/es\/it\/system-development-member-breakaway\/#Preparandose_para_el_riesgo_de_desercion_de_los_miembros\" title=\"Prepar\u00e1ndose para el riesgo de deserci\u00f3n de los miembros\">Prepar\u00e1ndose para el riesgo de deserci\u00f3n de los miembros<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/monolith.law\/es\/it\/system-development-member-breakaway\/#Establecer_un_sistema_que_no_aisle_al_personal_a_cargo\" title=\"Establecer un sistema que no a\u00edsle al personal a cargo\">Establecer un sistema que no a\u00edsle al personal a cargo<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/monolith.law\/es\/it\/system-development-member-breakaway\/#Intentar_tener_un_personal_suficiente\" title=\"Intentar tener un personal suficiente\">Intentar tener un personal suficiente<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/monolith.law\/es\/it\/system-development-member-breakaway\/#Revisar_la_asignacion_antes_de_que_empeore_la_salud\" title=\"Revisar la asignaci\u00f3n antes de que empeore la salud\">Revisar la asignaci\u00f3n antes de que empeore la salud<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/monolith.law\/es\/it\/system-development-member-breakaway\/#Implementar_una_gestion_rigurosa_de_los_cambios_y_la_documentacion_del_proyecto\" title=\"Implementar una gesti\u00f3n rigurosa de los cambios y la documentaci\u00f3n del proyecto\">Implementar una gesti\u00f3n rigurosa de los cambios y la documentaci\u00f3n del proyecto<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/monolith.law\/es\/it\/system-development-member-breakaway\/#Resumen\" title=\"Resumen\">Resumen<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"La_retirada_de_un_miembro_y_las_obligaciones_individuales_de_la_gestion_de_proyectos\"><\/span>La retirada de un miembro y las obligaciones individuales de la gesti\u00f3n de proyectos<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Primero, como premisa, se considera que en un proyecto de desarrollo de sistemas, el proveedor tiene la obligaci\u00f3n integral de asegurar su progreso fluido. Tiene la responsabilidad de estimar el personal, el tiempo, el presupuesto y las horas de trabajo necesarios para el progreso fluido del proyecto, solicitar la cooperaci\u00f3n necesaria del usuario seg\u00fan sea necesario y gestionar el progreso del proyecto. Estas obligaciones se denominan &#8220;obligaciones de gesti\u00f3n de proyectos&#8221; y su existencia ha sido se\u00f1alada repetidamente en precedentes judiciales anteriores.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/project-management-duties\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/project-management-duties[ja]<\/a><\/p>\n\n\n\n<p>La aparici\u00f3n repentina de una persona que se retira del lado del proveedor puede considerarse un tipo de problema con las obligaciones de gesti\u00f3n de proyectos del proveedor.<br><\/p>\n\n\n\n<ul>\n<li>Problemas f\u00edsicos debido a largas horas de trabajo, como demasiadas horas extra y trabajo en d\u00edas festivos<\/li>\n\n\n\n<li>Estr\u00e9s psicol\u00f3gico debido a conflictos interpersonales<\/li>\n<\/ul>\n\n\n\n<p>Se pueden imaginar varias razones para la aparici\u00f3n repentina de una persona que se retira de un proyecto. Sin embargo, estos son b\u00e1sicamente problemas de gesti\u00f3n laboral del lado del proveedor. Por lo tanto, incluso si estas circunstancias resultan en retrasos en la entrega, la posibilidad de eximir de la violaci\u00f3n de la obligaci\u00f3n es baja. En otras palabras, se espera que el proveedor tenga una actitud de gesti\u00f3n del progreso del proyecto con previsibilidad, incluso teniendo en cuenta la aparici\u00f3n de estas vacantes repentinas.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Importantes_precedentes_legales_relacionados_con_la_salida_de_miembros\"><\/span>Importantes precedentes legales relacionados con la salida de miembros<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/09\/shutterstock_744004378-1024x683.jpg\" alt=\"\" class=\"wp-image-4741\" \/><figcaption class=\"wp-element-caption\">Presentaremos ejemplos de casos que surgen de la salida de miembros en el desarrollo de proyectos.<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Caso_en_el_que_la_salida_de_un_miembro_provoco_un_retraso_en_la_fecha_de_entrega\"><\/span>Caso en el que la salida de un miembro provoc\u00f3 un retraso en la fecha de entrega<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>El caso citado en el siguiente precedente legal es aquel en el que, despu\u00e9s de la repentina salida de un miembro, el progreso del proyecto no avanz\u00f3 seg\u00fan lo planeado y se produjo un retraso en la fecha de entrega. En este caso, el representante del usuario adopt\u00f3 una actitud intimidante hacia el representante del proveedor, lo que tambi\u00e9n caus\u00f3 una carga psicol\u00f3gica.<\/p>\n\n\n\n<p>El caso se enred\u00f3 intensamente entre el usuario que quer\u00eda perseguir la responsabilidad por incumplimiento de deuda debido al retraso en el cumplimiento y el proveedor que quer\u00eda perseguir la violaci\u00f3n del deber de cooperaci\u00f3n por parte del usuario que adopt\u00f3 tal actitud intimidante y presionante.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/user-obligatory-cooporation\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/user-obligatory-cooperation[ja]<\/a><\/p>\n\n\n\n<p>Sin embargo, el tribunal decidi\u00f3 que las diversas circunstancias no exim\u00edan al proveedor de su deber de gesti\u00f3n del proyecto y apoy\u00f3 la opini\u00f3n del usuario (las partes subrayadas y en negrita son adiciones del autor).<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>El proveedor argumenta que el representante del usuario, a trav\u00e9s de un comportamiento agresivo y presionante, insult\u00f3 al representante del proveedor, lo que hizo que este \u00faltimo no tuviera m\u00e1s remedio que retirarse del trabajo de este contrato.<\/p>\n\n\n\n<p>Es cierto que el representante del usuario, en una reuni\u00f3n en noviembre de 2003 (Heisei 15), dijo en un tono fuerte: &#8220;<u>\u00bfNo tienes ganas de trabajar?<\/u>&#8220;, &#8220;<u>Este contrato se acaba. Si salgo de esta habitaci\u00f3n, se acaba.<\/u>&#8220;, pero esto se debe a la demora en el trabajo del proveedor y a su respuesta, ya que a pesar de que el per\u00edodo de prototipo se estableci\u00f3 hasta finales de octubre de 2003 (Heisei 15) en el acuerdo b\u00e1sico, la funci\u00f3n adicional del objetivo de desarrollo de este proyecto <u>no se incluy\u00f3 en absoluto<\/u> en el borrador del documento de definici\u00f3n de requisitos, y aunque se adjuntaron comentarios al borrador del documento de definici\u00f3n de requisitos presentado, <u>no hubo respuesta a ello<\/u>. No se puede decir que fue un comportamiento excesivo.<\/p>\n\n\n\n<p>Adem\u00e1s, aunque no est\u00e1 claro cu\u00e1l fue la causa de que C se retirara del trabajo de este contrato debido a una enfermedad, incluso si el estr\u00e9s del trabajo de este contrato fue la causa, esto es b\u00e1sicamente un problema de gesti\u00f3n laboral en el proveedor, y no se puede atribuir al usuario.<\/p>\n<cite>Sentencia del Tribunal de Distrito de Tokio, 4 de diciembre de 2007 (Heisei 19)<\/cite><\/blockquote>\n\n\n\n<p>En el precedente legal anterior, despu\u00e9s de considerar el hecho de que el usuario presion\u00f3 al proveedor con un &#8220;tono fuerte&#8221;, finalmente no eximi\u00f3 al proveedor de su responsabilidad. Se puede pensar que detr\u00e1s de esta decisi\u00f3n est\u00e1 la consideraci\u00f3n de equilibrar la mala respuesta del proveedor, y que ser\u00eda injusto atribuir la culpa al usuario que presion\u00f3 con varios &#8220;tonos fuertes&#8221;. Se adopt\u00f3 el esquema de que el proyecto de desarrollo del sistema se realiza mediante el cumplimiento del deber de gesti\u00f3n del proyecto por parte del proveedor y el cumplimiento del deber de cooperaci\u00f3n por parte del usuario, y se decidi\u00f3 que no se deber\u00eda reconocer la violaci\u00f3n del deber de cooperaci\u00f3n por parte del usuario. Este significado se puede ver en la frase &#8220;no se puede decir que fue un comportamiento excesivo&#8221;.<br><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Lo_que_se_puede_aprender_del_precedente_legal_anterior\"><\/span>Lo que se puede aprender del precedente legal anterior<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Adem\u00e1s, se pueden obtener las siguientes lecciones importantes:<br><\/p>\n\n\n\n<ul>\n<li>En caso de que un miembro del proyecto se retire debido a una enfermedad, si se quiere atribuir la culpa al usuario, se requiere que el proveedor demuestre la relaci\u00f3n causal de que la salida fue por culpa del usuario \u2192 Sin embargo, normalmente se considera que no es f\u00e1cil demostrar que existe una relaci\u00f3n causal.<\/li>\n\n\n\n<li>Incluso si se puede demostrar que la carga de trabajo aument\u00f3 debido al usuario y el miembro se enferm\u00f3, normalmente se considera un problema de gesti\u00f3n laboral del proveedor \u2192 Si se presta atenci\u00f3n al hecho de que se utiliza la fuerte expresi\u00f3n &#8220;comportamiento excesivo&#8221; en la sentencia, se debe considerar que las circunstancias que eximen al proveedor de su responsabilidad de gesti\u00f3n laboral son bastante limitadas.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Preparandose_para_el_riesgo_de_desercion_de_los_miembros\"><\/span>Prepar\u00e1ndose para el riesgo de deserci\u00f3n de los miembros<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/09\/shutterstock_1387110839-1024x576.jpg\" alt=\"\" class=\"wp-image-4742\" \/><figcaption class=\"wp-element-caption\">\u00bfC\u00f3mo prevenir problemas de deserci\u00f3n de los miembros del proyecto?<\/figcaption><\/figure>\n\n\n\n<p>Como se ha mencionado anteriormente, incluso si se produce una vacante repentina en el personal, es extremadamente dif\u00edcil atribuir esto a los usuarios. Puede suceder que se nos obligue a realizar un desarrollo adicional masivo o a realizar cambios forzados en las especificaciones m\u00e1s adelante, pero no es f\u00e1cil demostrar la relaci\u00f3n causal entre la alteraci\u00f3n f\u00edsica y mental y la carga de trabajo. Teniendo en cuenta estas circunstancias, es importante avanzar en la organizaci\u00f3n del personal asumiendo la aparici\u00f3n de problemas como la ausencia por enfermedad o la mala salud de los miembros del proyecto.<\/p>\n\n\n\n<p>Si este punto se disputa en un juicio, est\u00e1 claro que el proveedor estar\u00e1 en una posici\u00f3n muy desventajada. Por lo tanto, lo importante es m\u00e1s bien las medidas para prevenir tales disputas. Las medidas posibles incluyen las siguientes:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Establecer_un_sistema_que_no_aisle_al_personal_a_cargo\"><\/span>Establecer un sistema que no a\u00edsle al personal a cargo<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Se cree que es posible prevenir situaciones de aislamiento psicol\u00f3gico al establecer un sistema en el que varias personas participen en las reuniones en lugar de permitir que una sola persona participe en las reuniones.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Intentar_tener_un_personal_suficiente\"><\/span>Intentar tener un personal suficiente<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Tambi\u00e9n es importante tener suficiente personal. Asegurar suficiente personal con cierto margen ciertamente puede llevar a un aumento en los costos. Sin embargo, si se considera el costo de la indemnizaci\u00f3n por da\u00f1os y perjuicios debido al retraso en la entrega y la preocupaci\u00f3n por la aparici\u00f3n de m\u00e1s desertores en la situaci\u00f3n de manejo de problemas, no es raro que sea m\u00e1s razonable asegurar suficiente personal desde el principio.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Revisar_la_asignacion_antes_de_que_empeore_la_salud\"><\/span>Revisar la asignaci\u00f3n antes de que empeore la salud<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Si una persona se retira, la carga de trabajo de otros miembros del personal aumenta, lo que puede provocar un c\u00edrculo vicioso de m\u00e1s desertores. Para evitar este c\u00edrculo vicioso, es importante revisar la asignaci\u00f3n antes de que se produzca un deterioro grave de la salud.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Implementar_una_gestion_rigurosa_de_los_cambios_y_la_documentacion_del_proyecto\"><\/span>Implementar una gesti\u00f3n rigurosa de los cambios y la documentaci\u00f3n del proyecto<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>No es f\u00e1cil demostrar la relaci\u00f3n causal entre la deserci\u00f3n de los miembros del equipo y la violaci\u00f3n del deber de cooperaci\u00f3n por parte del usuario, pero a\u00fan as\u00ed es importante implementar una gesti\u00f3n rigurosa de los cambios y la documentaci\u00f3n. Esto se debe a que, incluso si no se puede demostrar la causa de la deserci\u00f3n de los miembros del equipo, si existe una situaci\u00f3n de exceso de trabajo que puede causar la ausencia por enfermedad del personal a cargo, es posible que contenga elementos que respalden la violaci\u00f3n del deber de cooperaci\u00f3n por parte del usuario. Estas circunstancias pueden ser un factor que respalde la justificaci\u00f3n de la compensaci\u00f3n por negligencia, etc., incluso si el proveedor es perseguido por responsabilidad por incumplimiento de obligaciones o responsabilidad por defectos en caso de un &#8220;incendio&#8221; en el proyecto.<\/p>\n\n\n\n<p>En el siguiente art\u00edculo, se explica la importancia de la gesti\u00f3n de documentos en los proyectos de desarrollo de sistemas.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/the-minutes-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/the-minutes-in-system-development[ja]<\/a><\/p>\n\n\n\n<p>Adem\u00e1s, en particular en lo que respecta a los cambios en las especificaciones, se explica en detalle en el siguiente art\u00edculo.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/howto-manage-change-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/howto-manage-change-in-system-development[ja]<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Resumen\"><\/span>Resumen<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Hemos discutido la teor\u00eda legal asociada con el fen\u00f3meno de &#8220;la salida de los miembros del equipo&#8221;. Para los proveedores, debemos admitir que es extremadamente dif\u00edcil desde un punto de vista legal perseguir la responsabilidad de los usuarios por la salida de los miembros.<\/p>\n\n\n\n<p>Sin embargo, incluso con estas circunstancias, es importante no malinterpretar que &#8220;la ley no es \u00fatil en el problema de la salida de los miembros del equipo&#8221;. El proceso de pensamiento en los casos citados en s\u00ed mismo cuestiona c\u00f3mo definir los l\u00edmites entre &#8220;la obligaci\u00f3n de gesti\u00f3n de proyectos del proveedor&#8221; y &#8220;la obligaci\u00f3n de cooperaci\u00f3n del usuario&#8221;. Adem\u00e1s, las medidas para prevenir tales conflictos a menudo se derivan al retroceder desde las situaciones de conflicto anticipadas.<\/p>\n\n\n\n<p>Es importante entender que el punto de &#8220;estar en desventaja en un juicio&#8221; no significa que &#8220;la ley no es \u00fatil&#8221;, sino m\u00e1s bien que &#8220;la perspectiva de la prevenci\u00f3n legal es importante&#8221;.<br><\/p>\n","protected":false},"excerpt":{"rendered":"<p>En los proyectos de desarrollo de sistemas, normalmente se prioriza la desglosaci\u00f3n de cada proceso y tarea, avanzando con la mayor planificaci\u00f3n posible. Sin embargo, por mucho que se enfatice la pla [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":60906,"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\/59150"}],"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\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/comments?post=59150"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/59150\/revisions"}],"predecessor-version":[{"id":60908,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/59150\/revisions\/60908"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/media\/60906"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/media?parent=59150"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/categories?post=59150"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/tags?post=59150"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}