Relaciones de tareas

En LadVen OS, las relaciones muestran de dónde apareció una tarea, con qué trabajo está conectada y dónde revisar el resultado. Ayudan a no perder contexto cuando una solicitud nace de un cliente, documento, comentario, proyecto, CRM o tarea anterior.

Una relación no sustituye la formulación de la tarea. Aunque la tarea esté vinculada a una oportunidad, un proyecto o un documento, el título y la descripción deben explicar qué resultado se necesita y quién lo acepta.

Cuándo se necesita una relación

Una relación es útil cuando:

• un trabajo grande se divide en varios resultados;
• la tarea nació de un comentario, archivo, documento, registro CRM o solicitud de cliente;
• la tarea pertenece a un proyecto, cliente o proyecto de cliente;
• el resultado de una tarea afecta a otra;
• hay que conservar la ruta desde la decisión hasta la ejecución;
• los materiales están en documentos, archivos, CRM o comentarios;
• hay que comprobar que los participantes tienen acceso al contexto relacionado.

No relacione objetos solo para que la tarjeta "se vea completa". Cada relación debe explicar una ruta de trabajo: de dónde vino la tarea, qué material se usa, qué resultado afecta o dónde quedará la prueba final. Si el participante no puede decir por qué esa relación importa, elimínela o explique su sentido en la descripción.

Relaciones y responsabilidad

Una relación agrega contexto, pero no sustituye al dueño del resultado. Aunque la tarea esté conectada con cliente, proyecto, documento y tareas vecinas, debe quedar claro quién responde por llevar el resultado hasta listo, quién lo revisa y qué criterio se acepta.

Pregunta	Qué relación ayuda	Qué debe escribirse igual en la tarea
¿Para quién o para qué hacemos el trabajo?	Cliente, proyecto de cliente, registro CRM.	Qué resultado de cliente se necesita y quién lo acepta desde el equipo.
¿En qué flujo se controla?	Proyecto, grupo de trabajo, tarea padre.	Cómo la tarea afecta el resultado general del proyecto.
¿Dónde están materiales y resultado?	Documento, archivo, comentario, adjunto de la lista de verificación.	Qué abrir, revisar o adjuntar al final.
¿Qué tareas dependen entre sí?	Tarea padre, hija o relacionada.	Qué dependencia existe: bloquea, continúa, aclara o fija decisión.

Si una relación no ayuda a responder ninguna de estas preguntas, probablemente sobra. Si ayuda, pero el sentido no se entiende sin abrir varios objetos, explique la relación en una o dos frases en la descripción o en un comentario.

Una relación con cliente, oportunidad o documento no significa que todos los detalles puedan copiarse a la tarea, reporte o comentario externo. Si el contexto contiene importes, datos personales o condiciones comerciales, deje la fuente tras un enlace con permisos y lleve a la tarea solo lo necesario para ejecutar y aceptar el resultado. Antes de un reporte, exportación o conversación con el cliente, revise por separado importe, moneda, fecha y tipo de conversión, impuestos, descuentos y derechos de acceso.

Cuando aparece en un comentario un enlace a una tarea relacionada o a un objeto de CRM, los participantes pueden ver una tarjeta de vista previa. Úsela como indicador rápido de estado y contexto, pero no como sustituto de la relación en la tarjeta de tarea. Si el trabajo depende realmente del objeto, añada la relación en el bloque correspondiente de la tarea; el comentario solo explica por qué esa relación importa ahora.

Tipos de relaciones

Las relaciones muestran el origen del trabajo, el contexto de gestión, los materiales y el impacto en tareas cercanas.

Tipo de relación	Qué muestra	Cuándo usar
Tarea padre	Tarea o iniciativa más grande de la que salió la actual.	Cuando la tarea actual es parte de un resultado general.
Tarea hija	Parte separada del trabajo dentro de la tarea actual.	Cuando una parte tiene responsable, plazo o criterios propios.
Tarea relacionada	Tarea vecina sin jerarquía estricta.	Cuando influyen entre sí, pero ninguna es parte de la otra.
Proyecto	Proyecto interno, grupo de trabajo o dirección.	Cuando la tarea se busca y planifica dentro de trabajo de proyecto.
Cliente	Compañía o cliente al que pertenece la tarea.	Para historia de cliente, ventas, implantación o soporte.
Proyecto de cliente	Proyecto o flujo concreto dentro del cliente.	Cuando un cliente tiene varias direcciones paralelas.
CRM	Oportunidad, cliente potencial, contacto, compañía u otro registro CRM.	Cuando la tarea continúa venta, soporte o acción de cliente.
Documento	Documento, tabla, contrato, especificación o archivo de trabajo.	Cuando el documento es fuente, material o resultado.
Archivo	Adjunto de tarea, lista de verificación o comentario.	Cuando el material se necesita para ejecución, revisión o historia.
Comentario	Discusión, decisión, pregunta o devolución a corrección.	Cuando el nuevo trabajo nació de la discusión y no debe perder la causa.

Jerarquía, dependencia y contexto

Qué mostrar	Qué relación elegir	Cómo leerlo como gerente
La tarea es parte de un resultado grande	Tarea padre o hija	El resultado general tiene partes con dueños propios.
El resultado de una tarea influye en otra	Tarea relacionada	No se incluyen entre sí, pero deben verse juntas.
La tarea pertenece al flujo del equipo	Proyecto o grupo de trabajo	Puede planificarse y filtrarse dentro de la dirección.
La tarea pertenece a historia de cliente	Cliente, proyecto de cliente o CRM	El resultado debe verse en contexto de cliente.
Hay que abrir material o prueba	Documento, archivo, comentario	La relación lleva a fuente, decisión o resultado final.

No todas las relaciones significan lo mismo. Una tarea hija es un resultado separado. Una tarea relacionada es una dependencia, una continuación o un alcance nuevo. Proyecto y cliente son contexto de gestión. Documento y archivo son material o evidencia. Si estos sentidos se mezclan, la tarjeta empieza a parecer un archivo histórico, no una instrucción de trabajo.

Para el gerente, cada tipo de relación responde una pregunta distinta. La jerarquía responde "de qué resultado grande forma parte"; la dependencia responde "qué bloquea o continúa qué"; el cliente y CRM responden "qué obligación externa o venta afecta"; el documento y archivo responden "con qué fuente se trabaja y dónde está la prueba". Si una relación no responde ninguna pregunta de gestión, no mejora el control.

Tareas padre e hijas

Use tareas padre e hijas cuando un resultado grande se divide en partes. La tarea padre conserva el objetivo general; las hijas tienen responsables, plazos y criterios propios. No cree hijas para pasos mínimos que caben en la lista de verificación.

Cree una tarea hija si la parte del trabajo:

• tiene un ejecutor responsable propio;
• necesita un plazo separado;
• puede ejecutarse en paralelo;
• bloquea el resultado general;
• contiene archivos, lista de verificación o discusión propios;
• debe verse en listas e informes separada de la tarea padre.

Buen ejemplo:

Tarea padre:
Preparar el lanzamiento piloto para el cliente

Tareas hijas:
- Acordar el contrato del piloto
- Preparar el esquema técnico de conexión
- Reunir la lista de participantes de la formación

Mal ejemplo:

Tarea padre:
Preparar el lanzamiento piloto

Tareas hijas:
- Abrir la plantilla
- Escribir el texto
- Revisar ortografía

En el segundo caso conviene usar la lista de verificación: tareas separadas añadirían navegación innecesaria y borrarían la imagen general.

Tareas relacionadas

Use una tarea relacionada cuando no hay jerarquía, pero el contexto importa: una tarea continúa otra, bloquea, aclara decisión o fija nuevo alcance. En la descripción indique por qué están relacionadas.

Use una tarea relacionada si:

• la tarea continúa una discusión de otra tarea;
• el resultado de una tarea es necesario para decidir en otra;
• el trabajo no se puede unir porque las tareas tienen distintos responsables o plazos;
• hay que conservar una referencia a un intento anterior, trabajo cancelado o variante alternativa;
• parte del alcance se sacó de la tarea actual, pero la jerarquía padre/hija no encaja.

Traslade solo el contexto necesario: motivo de la relación, vínculo con la tarea original y materiales importantes. No copie toda la discusión manualmente. Si la decisión estaba en un comentario, es mejor enlazarlo o resumir la conclusión en la nueva tarea.

No convierta una tarea relacionada en copia de la anterior. Traslade la decisión, el límite del nuevo alcance, el archivo o comentario clave y el responsable del siguiente resultado. Lo que no debe trasladarse: debate completo, adjuntos intermedios obsoletos, participantes que solo observaban y promesas que ya fueron rechazadas.

Crear una tarea relacionada desde el contexto

Cuando una nueva solicitud nace de comentario, archivo, lista de verificación o revisión, cree una tarea relacionada desde ese contexto si está disponible. Así se conserva la causa y la tarea original no se convierte en trabajo infinito.

Orden de trabajo:

1. Abra la fuente de origen: tarea, comentario, registro CRM, documento, archivo, proyecto o cliente.
2. Inicie la creación de tarea desde ese contexto, si la acción está disponible.
3. Compruebe qué relación se añadirá automáticamente: padre/hija, relacionada, proyecto, cliente, CRM o documento.
4. Formule el nombre de la nueva tarea como un resultado independiente.
5. Explique en la descripción por qué apareció la tarea y dónde mirar el contexto inicial.
6. Asigne ejecutor responsable, plazo y participantes.
7. Adjunte solo archivos o documentos que realmente hagan falta para ejecutar.
8. Guarde la tarea.
9. Abra la tarea creada y compruebe que la relación aparece en la tarjeta.

Si LadVen OS no creó la relación automáticamente, añádala manualmente justo después de guardar. No deje la tarea solo con la frase "como comentamos": en unos días los participantes no sabrán dónde se comentó.

Proyecto, cliente y proyecto de cliente

Proyecto y grupo muestran el flujo interno. Cliente y proyecto de cliente muestran la obligación externa o historia de interacción. Elija el contexto correcto para que la tarea aparezca en informes, filtros y revisión del proceso.

Vincule la tarea con un proyecto si el trabajo se planifica, discute y controla dentro de un equipo de proyecto. El proyecto ayuda a filtrar la lista de tareas, agrupar trabajo y ver carga por dirección.

Vincule la tarea con un cliente si el resultado importa para la historia del cliente: venta, implantación, soporte, contrato, reunión, solicitud, reclamación o acompañamiento regular.

Use proyecto de cliente cuando una misma compañía tiene varios flujos independientes. Por ejemplo, implantación, soporte, integración y formación pueden ir en paralelo, pero pertenecer a un mismo cliente.

Buena práctica:

• proyecto muestra el flujo interno de trabajo;
• cliente muestra la parte externa del contexto;
• proyecto de cliente precisa la dirección dentro del cliente;
• registro CRM muestra venta, solicitud, contacto u oportunidad concreta.

Si una tarea pertenece a cliente y proyecto a la vez, compruebe que las relaciones no se contradicen. Una tarea de implantación no debe quedar por accidente en el proyecto de otro equipo o en otro cliente.

Para el propietario de negocio y el responsable de área, esta separación es importante en los informes: el proyecto muestra cómo se gestiona el trabajo dentro del equipo, y el cliente muestra la historia externa de la relación. No use uno como sustituto del otro. Una tarea de contrato puede estar en el proyecto "Implantación", vinculada al cliente y también a una oportunidad CRM; eso es correcto si cada relación explica una capa distinta del contexto.

Relaciones CRM

Agregue CRM cuando la tarea continúa venta o soporte: preparar factura, actualizar contacto, acordar condiciones, revisar pago, programar reunión o enviar documento. La relación CRM debe ir acompañada de una instrucción concreta.

Añada relación CRM si la tarea:

• nació de una llamada, correo, reunión u oportunidad;
• influye en el siguiente paso de venta;
• se necesita para preparar propuesta, contrato, factura o implantación;
• fija una acción sobre una solicitud del cliente;
• debe verse desde la historia del cliente;
• requiere participación de gerente de cuenta, legal, implantación o soporte.

Ejemplo:

Contexto:
La tarea se creó desde la oportunidad del lanzamiento piloto. El cliente pidió confirmar los plazos de integración antes de la reunión.

Qué hacer:
Revisar restricciones técnicas, acordar fecha de lanzamiento y dejar el comentario final en la tarea.

Antes de cerrar, compruebe si el resultado debe volver a CRM: comentario, etapa actualizada, documento adjunto o siguiente tarea. Si la decisión queda solo en la tarea, el equipo comercial puede no verla en la historia del cliente.

Documentos y archivos

Documentos y archivos cumplen roles distintos. Un documento puede ser fuente, material de trabajo o resultado final; un archivo puede ser evidencia de un paso concreto, versión intermedia o entrega aceptada. Antes de cerrar la tarea, el revisor debe entender qué material era insumo, qué material cambió durante el trabajo y qué versión queda como resultado.

Situación	Qué vincular o adjuntar
Trabajar con un contrato editado aparte	Documento relacionado y explicación breve en descripción.
Entregar documento inicial de requisitos al ejecutor	Archivo de la tarea.
Confirmar ejecución de un paso	Archivo del punto de la lista de verificación.
Discutir versión intermedia	Archivo en comentario.
Guardar resultado final	Archivo de la tarea o documento de resultado con comentario final.

Si un documento es la fuente, indique sección, página, pestaña o fragmento. Si es el resultado, escriba el criterio de aceptación: se abre para los participantes, contiene la versión final y ya no requiere cambios en esta tarea. Si un archivo aparece en un comentario como entrega, cierre la discusión con un comentario final para que no haya que buscar la versión correcta entre adjuntos intermedios.

No duplique el mismo material en todos los lugares. Si el documento está vinculado como fuente, basta con explicar qué parte mirar. Si el archivo es el resultado final, marque esa versión en los criterios de aceptación o en el comentario final. Así el revisor no acepta una versión intermedia por error.

Si el documento es material de trabajo, acuerde dónde se dejan las correcciones y quién acepta la versión final. Antes de asignar la tarea, revise que el nombre del archivo, la fecha, la versión y el acceso correspondan al trabajo actual; de lo contrario el ejecutor puede abrir una copia antigua o un material que no puede editar.

En tareas de cliente, mantenga dentro de LadVen OS el camino de comprobación: fuente, versión de trabajo, resultado final y comentario de aceptación. Si el archivo sale por enlace externo, la tarea debe explicar qué versión salió, quién puede verla y cuándo se retirará el acceso. Así la relación con el documento no se convierte en un enlace suelto sin control.

Comentarios como fuente de relación

Si una nueva tarea aparece desde una discusión, vincule o cite el comentario original. Así se entiende qué pregunta, decisión o devolución a corrección generó el trabajo.

Cuando cree una tarea desde comentario:

• conserve el vínculo con la tarea o comentario de origen, si LadVen OS permite enlace directo;
• resuma la decisión de forma breve y clara;
• indique qué no entra en la tarea original y por qué se separa;
• añada participantes que deben ver la continuación;
• deje en la tarea original un comentario de que el trabajo se separó.

Ejemplo de comentario final en la tarea original:

Fijamos la decisión: cerramos esta tarea por la comprobación manual. La conciliación automática pasa a una tarea relacionada para estimar volumen y plazo por separado.

Cómo no perder contexto

No agregue relaciones mudas. Explique por qué la relación importa, qué material abrir, qué tarea bloquea a cuál y qué resultado se espera. Revise que participantes tengan acceso a objetos relacionados.

El conjunto mínimo de contexto es:

• el nombre de la tarea describe un resultado, no solo un enlace;
• la descripción explica por qué apareció la tarea;
• la tarea original, proyecto, cliente, CRM o documento están indicados;
• los archivos importantes están adjuntos o vinculados en el lugar correcto;
• los comentarios fijan decisiones que cambian el alcance;
• los participantes tienen acceso a los objetos relacionados;
• después de crear la relación se puede ir en ambas direcciones, si la interfaz lo permite.

Si una relación es importante para ejecutar, menciónela en el texto de la tarea. Por ejemplo: "El trabajo pertenece al proyecto de implantación del cliente; revisar el contrato en el documento relacionado". No obligue al ejecutor a adivinar el sentido de la relación por el nombre del objeto.

Para la aceptación, use una ruta de comprobación:

1. Abra primero la fuente: tarea principal, CRM, documento o comentario del que nació el trabajo.
2. Compruebe la decisión: qué se acordó, quién lo confirmó y qué límites quedaron fijados.
3. Revise el resultado: archivo, lista de verificación cerrada, comentario final y tareas relacionadas para nuevo alcance.

Si el responsable no puede seguir esa ruta en pocos minutos, la relación existe formalmente, pero el contexto está mal preparado. Añada una explicación corta en la descripción o en el comentario final.

Cómo no diluir el trabajo con relaciones

Una relación no debe convertir una tarea simple en centro de todo el proceso. Si aparece un resultado independiente, cree tarea hija o relacionada. Si solo es un paso pequeño, use lista de verificación. Si es referencia, deje enlace y explicación.

Para que las relaciones no diluyan el trabajo:

• mantenga un solo resultado en el nombre de la tarea;
• separe en la descripción la fuente del contexto y la acción esperada;
• no adjunte un documento solo porque trata del mismo tema;
• no agregue tareas relacionadas si no hay dependencia ni continuación;
• no use la tarea principal como carpeta de todo un frente de trabajo;
• no cierre la tarea sin comentario final si el resultado debe volver a CRM, al proyecto de cliente o a un documento;
• no añada automáticamente a todos los participantes de los objetos relacionados.

Si para ejecutar hace falta abrir más de tres objetos, escriba una ruta corta: "primero revisar el contrato, luego el comentario con la decisión, después actualizar el archivo de resultado". Esto ahorra tiempo y reduce el riesgo de usar el material equivocado.

Permisos y restricciones

Una relación puede apuntar a un objeto que no todos ven. Antes de asignar, revise acceso a cliente, proyecto, CRM, documento y archivos. No reenvíe materiales fuera de LadVen OS como reemplazo permanente.

La comprobación de acceso debe hacerse antes de iniciar el trabajo si la tarea depende de contrato, archivo de cliente, CRM, proyecto privado, documento editado por otro equipo o comentario con decisión. Si el acceso falla después de asignar, la tarea parece bloqueada aunque el resultado y el responsable estén definidos correctamente.

Si un participante no ve el objeto relacionado:

• compruebe que está añadido a la tarea con el rol correcto;
• revise permisos del proyecto, cliente, CRM o documento;
• adjunte a la tarea solo el material permitido para ese participante;
• pida al propietario del objeto que ajuste acceso si hace falta;
• deje un comentario con la decisión de acceso para no repetir la misma aclaración.

No solucione el acceso enviando archivos privados por canales externos. Eso rompe la historia de trabajo y crea riesgo de versiones incorrectas.

Si la relación no está disponible para un participante, la tarea debe decir qué hacer: solicitar acceso, acudir al propietario del objeto, sustituir la relación por un documento permitido o aclarar el contexto en un comentario. No deje el bloqueo como un mensaje técnico sin siguiente paso.

Cómo revisar relaciones

Compruebe que cada relación ayuda a ejecutar, revisar o reconstruir la tarea; que no hay duplicados; que el contexto está explicado; que los accesos funcionan; y que las tareas hijas o relacionadas tienen responsables y plazos propios.

Lista de verificación de revisión antes de cerrar o aceptar:

• el resultado de la tarea está claro sin abrir diez objetos;
• la relación principal explica origen, dependencia o material;
• la tarea vinculada no contradice cliente, proyecto o CRM;
• los documentos y archivos abren para los participantes necesarios;
• el nuevo alcance está en tarea hija o relacionada, no escondido en comentarios;
• el comentario final indica dónde quedó el resultado;
• en modo de lectura se ve qué tarea es principal, hija o relacionada;
• el objeto CRM, proyecto o cliente se abre para los participantes que lo necesitan;
• filtros, agrupaciones o listas guardadas ayudan a encontrar la tarea vinculada;
• los enlaces ocultos o no disponibles no bloquean la ejecución sin siguiente paso.

Para el gerente, la revisión no consiste en contar relaciones, sino en comprobar que la cadena de trabajo se lee sin investigación adicional. Debe verse qué objeto originó la tarea, qué dependencia sigue abierta, qué material prueba el resultado y qué trabajo se separó en otra tarea. Si una relación no ayuda a tomar una decisión, no aporta control.

Si la relación se agregó por error, corríjala de inmediato y deje un comentario si los participantes ya pudieron ver el contexto equivocado. Cambiar una relación sin explicación puede romper informes, filtros y la comprensión del resultado aceptado.

Buenas prácticas

• Vincule tareas cuando hay dependencia real o contexto de cliente/proyecto.
• Mantenga título y descripción claros aunque existan relaciones.
• Separe nuevos resultados en tareas hijas o relacionadas.
• Explique relaciones importantes en comentario o descripción.
• Revise permisos de objetos relacionados.
• Use relación con comentario cuando el trabajo nació de una discusión.
• Si la relación influye en la aceptación, añádala a los criterios de listo.
• Para tareas de cliente, vincule CRM o cliente solo cuando el resultado deba quedar en la historia del cliente.
• Para tareas de proyecto, compruebe que la relación ayuda al responsable a ver el avance, no que solo reemplaza una etiqueta.
• Para documentos, indique si el documento es fuente, versión de trabajo o resultado final.
• Para tareas relacionadas, escriba la dependencia: "espera resultado", "continúa decisión", "se separó aparte" o "bloquea lanzamiento".

Errores frecuentes

• usar relación como sustituto de descripción;
• crear tarea hija para cada paso menor;
• no explicar por qué dos tareas están relacionadas;
• vincular cliente o CRM incorrectos;
• dejar nuevo alcance dentro de tarea cerrada;
• no revisar accesos a documentos relacionados;
• mezclar varias obligaciones independientes en una tarjeta;
• adjuntar un documento final sin decir qué versión se acepta;
• copiar toda una discusión en vez de enlazar o resumir la decisión;
• mantener relaciones antiguas que ya no influyen en ejecución, revisión ni cierre;
• mezclar proyecto y cliente: el proyecto sirve para gestión interna, el cliente para historia externa;
• considerar una tarea relacionada como sustituto de una instrucción: el enlace muestra la fuente, pero no explica qué hacer ni quién responde por el resultado;
• añadir participantes de tareas relacionadas automáticamente: genera notificaciones innecesarias y vuelve confusa la responsabilidad.

Qué relaciones conviene revisar

Antes de dar la tarea por clara, revise el sentido de trabajo de las relaciones, no la imagen de la interfaz:

• la tarjeta muestra qué tarea es principal, hija o simplemente relacionada;
• una tarea creada desde un comentario u otra tarea conserva una razón clara de la relación;
• proyecto, cliente y objeto CRM ayudan a encontrar el trabajo y aceptar el resultado, no sustituyen la descripción;
• el documento o archivo relacionado se abre para los participantes y tiene un propósito claro;
• después de guardar, la relación se ve en el modo de lectura de la tarea;
• si una relación o archivo no está disponible por permisos, el participante entiende a quién acudir y cuál es el siguiente paso.

Secciones relacionadas

• Crear una tarea
• Asignar participantes
• Adjuntar archivos a una tarea
• Agregar lista de verificación
• Comentarios en una tarea