Liderazgo — Relaciones lider-liderado

Tema: Módulo de liderazgo — Gestión de relaciones entre líderes y liderados
Idioma: ES

Resumen en pocas palabras

El módulo de Liderazgo permite a los usuarios de la plataforma definir y gestionar sus relaciones jerárquicas de forma flexible. Cualquier usuario puede solicitar a otro que sea su líder, o invitar a otro a ser su liderado. Ambas partes deben aceptar la relación para que quede establecida. También se puede transferir el liderazgo a otra persona o desvincular una relación existente. Quienes tienen el permiso correspondiente pueden además ver el organigrama completo de su organización como un árbol de nodos.

Objetivo de negocio

Que cada organización pueda construir y mantener su estructura jerárquica de manera flexible, sin depender de una nómina rígida gestionada solo por administradores. Los propios usuarios participan activamente en definir sus relaciones de liderazgo, con un proceso de aceptación que garantiza que nadie queda asignado sin su consentimiento. El módulo brinda también una vista visual del organigrama para quienes necesitan entender la estructura completa de la organización.

Contexto y alcance

Qué está incluido

Solicitudes de liderazgo bidireccionales con flujo de aceptación
Gestión de solicitudes entrantes y salientes (aceptar, rechazar, cancelar)
Transferencia de liderazgo a otra persona (para usuarios que ya tienen líder)
Desvinculación bidireccional de una relación activa: quitar al propio líder o quitar a un liderado
Transición automática del rol de líder al asignar el primer liderado y al perder el último
Notificaciones in-app de los eventos de liderazgo, dirigidas a la persona involucrada (ver 16-notificaciones.md)
Búsqueda de personas dentro de la organización por nombre o email
Organigrama visual de la organización (para quienes tienen el permiso)
Permisos específicos del módulo integrados al sistema de roles existente

Qué no está incluido en este documento

Notificaciones por email o push (fase posterior)
El detalle del sistema de notificaciones in-app de eventos de liderazgo, que ya está implementado (ver 16-notificaciones.md)
La lógica del E-map grupal que usa estas relaciones (ver 14-e-map-grupal.md)
La administración de roles y permisos (ver 03-roles.md)

Actores

Actor	Qué hace
Usuario	Cualquier persona de la organización. Puede solicitar un líder, invitar liderados, aceptar o rechazar solicitudes, transferir o desvincular relaciones. Todos los usuarios tienen esta capacidad por defecto.
Usuario con permiso de organigrama	Usuario con permiso específico para ver el organigrama completo de la organización. Puede ser cualquier rol al que se le asigne ese permiso.
Sistema (backend)	Gestiona las solicitudes, establece o rompe las relaciones al aceptarse o rechazarse, y mantiene actualizado el árbol jerárquico de la organización.

Permisos del módulo

El módulo de liderazgo incorpora dos permisos independientes al sistema de roles existente:

Permiso	Qué permite	Quién lo tiene
Liderazgo — Gestionar	Enviar y recibir solicitudes de liderazgo, aceptar, rechazar, cancelar, transferir y desvincular relaciones. Buscar personas de la organización.	Todos los usuarios por defecto
Liderazgo — Ver organigrama	Ver el árbol jerárquico completo de la organización.	Solo roles con este permiso asignado explícitamente

Estos permisos son completamente independientes: tener uno no otorga el otro. Un usuario puede gestionar sus relaciones sin poder ver el organigrama completo, y alguien puede ver el organigrama sin poder modificar relaciones.

Nuevo rol de sistema: Gestor de liderazgo

Se crea un nuevo rol de sistema llamado Gestor de liderazgo que existe en todas las organizaciones. Tiene ambos permisos asignados. Puede incorporarse al rol de administrador de organización o asignarse a roles custom que cada organización defina.

Visibilidad sobre E-maps: El Gestor de liderazgo puede ver el E-map de cualquier persona de la organización, independientemente de si existe una relación de liderazgo directa. No está restringido a su propia cadena jerárquica. Esta es la definición del actor "Cuenta root / administradora" descrito en el DRF 14. Puede haber más de uno por organización. Casos de uso típicos: directorio, área de RRHH.

Casos de uso

CU-1 Solicitar un líder

El usuario busca a una persona de su organización por nombre o email y le envía una solicitud para que sea su líder. La solicitud queda en estado pendiente hasta que la otra persona la acepte o rechace. El usuario puede ver el estado de la solicitud en su tabla de solicitudes enviadas.

CU-2 Invitar a alguien como liderado

El usuario busca a una persona de su organización por nombre o email y le envía una invitación para que sea su liderado. La persona invitada recibe la solicitud y decide si aceptarla o rechazarla. El usuario puede seguir el estado desde su tabla de solicitudes enviadas.

CU-3 Gestionar solicitudes recibidas

El usuario ve en su tabla de solicitudes todas las solicitudes que recibió — tanto de personas que quieren ser su líder como de personas que quieren ser su liderado. Puede aceptar o rechazar cada una. Al aceptar, la relación queda establecida de inmediato.

CU-4 Cancelar una solicitud enviada

Si el usuario envió una solicitud y todavía está pendiente, puede cancelarla desde su tabla de solicitudes enviadas antes de que la otra persona la resuelva.

CU-5 Transferir liderazgo

Si el usuario ya tiene un líder y quiere cambiar de líder, puede enviar una solicitud de transferencia directamente al nuevo líder sin necesidad de desvincular primero al actual. La transferencia es una solicitud que el nuevo líder debe aceptar: mientras esté pendiente, el vínculo actual se mantiene. Si el nuevo líder acepta, el vínculo con el líder anterior se rompe automáticamente y el líder anterior recibe un aviso (en su tabla de actividad y como notificación in-app). Si el usuario no tiene líder actual, no aplica la transferencia — debe usar el flujo de solicitud de líder (CU-1).

CU-6 Desvincular una relación activa (bidireccional)

El usuario puede desvincular una relación activa en cualquiera de las dos direcciones: quitar a su líder actual o quitar a uno de sus liderados. En ambos casos la otra persona recibe un aviso en su tabla de actividad y una notificación in-app indicando que la relación fue disuelta.

CU-7 Ver el organigrama de la organización

Los usuarios con el permiso de organigrama pueden ver el árbol jerárquico completo de su organización como un mapa de nodos. Cada nodo muestra el nombre y avatar de la persona. Los usuarios sin relaciones de liderazgo aparecen en una sección separada como "sin asignar".

Reglas de negocio

R-1.1 Toda relación requiere aceptación de ambas partes

Ninguna relación de liderazgo se establece de forma unilateral. Siempre que una persona solicita o invita, la otra debe aceptar explícitamente para que la relación quede activa.

R-1.2 Un usuario solo puede tener un líder directo

Cada usuario puede tener como máximo un líder directo asignado en un momento dado. No se permiten múltiples líderes simultáneos.

R-1.3 No se pueden enviar solicitudes duplicadas

Si ya existe una solicitud pendiente entre dos usuarios (en cualquier dirección), el sistema no permite enviar otra solicitud entre las mismas personas hasta que la existente sea resuelta o cancelada.

R-1.4 No se puede solicitar una relación ya existente

Si dos usuarios ya tienen una relación activa (uno es líder del otro), el sistema no permite enviar nuevas solicitudes entre ellos.

R-1.5 Las solicitudes son dentro de la misma organización

Un usuario solo puede enviar solicitudes a personas que pertenezcan a su misma organización. No se pueden establecer relaciones entre organizaciones distintas.

R-1.6 Un usuario no puede ser su propio líder

El sistema impide enviar solicitudes a uno mismo.

R-1.7 La transferencia reemplaza, no acumula

Al aceptarse una transferencia de liderazgo, el vínculo anterior se rompe automáticamente. No puede quedar el usuario con dos líderes activos.

R-1.8 La desvinculación notifica a la otra parte

Cuando se rompe una relación (por desvinculación o transferencia aceptada), la otra persona ve un aviso en su tabla de actividad dentro del módulo y recibe además una notificación in-app del sistema de notificaciones (ver 16-notificaciones.md). No hay notificación por email en esta fase.

R-1.9 El organigrama refleja el estado en tiempo real

El organigrama muestra siempre el estado actual de las relaciones. Cada vez que se establece o rompe un vínculo, el árbol se actualiza.

R-1.10 Los usuarios sin relaciones aparecen como "sin asignar"

Los usuarios de la organización que no tienen líder ni liderados aparecen en el organigrama en una sección separada de "sin asignar", visible solo para quienes tienen el permiso de organigrama.

R-1.11 El rol de líder se activa y desactiva de forma automática

La condición de líder de un usuario se deriva de sus liderados actuales, no se asigna a mano:

Cuando a un usuario se le asigna su primer liderado (al aceptarse una solicitud, invitación o transferencia que lo deja como líder de alguien), pasa automáticamente a ser líder.
Cuando un usuario pierde a su último liderado (por desvinculación o por una transferencia que le quita al único liderado que tenía), deja automáticamente de ser líder.

R-1.12 La transferencia requiere tener un líder actual

La transferencia de liderazgo solo está disponible para usuarios que tienen un líder asignado. Es una solicitud que el nuevo líder debe aceptar; hasta que la acepte, el vínculo actual del usuario se mantiene. Un usuario sin líder no puede transferir y debe usar la solicitud de líder (CU-1).

R-1.13 Los eventos de liderazgo generan notificaciones in-app

Cada solicitud recibida, invitación recibida, transferencia recibida, aceptación, rechazo y desvinculación genera una notificación in-app para la persona involucrada. El detalle de estos tipos está en 16-notificaciones.md.

Estados de una solicitud

Estado	Descripción
Pendiente	Enviada, esperando respuesta de la otra persona
Aceptada	La otra persona aceptó — la relación quedó establecida
Rechazada	La otra persona rechazó la solicitud
Cancelada	Quien la envió la canceló antes de ser resuelta

Validaciones y mensajes al usuario

Solicitud a alguien de otra organización: No permitido — el sistema indica que la persona no pertenece a la organización.
Solicitud duplicada (ya existe una pendiente): El sistema indica que ya hay una solicitud pendiente con esa persona.
Relación ya existente: El sistema indica que ya existe una relación activa con esa persona.
Solicitud a uno mismo: No permitido.
Persona no encontrada: Si la búsqueda no encuentra resultados, se indica claramente.
Sin permiso de organigrama: El organigrama no es accesible; se muestra mensaje de acceso restringido.

Criterios de aceptación

AC-1 Solicitud enviada y recibida

Un usuario puede buscar a otra persona de su organización por nombre o email, enviarle una solicitud (de líder o de liderado) y ver el estado de esa solicitud en su tabla de enviadas.

AC-2 Gestión de solicitudes recibidas

Un usuario con solicitudes pendientes puede verlas en su tabla, y aceptar o rechazar cada una. Al aceptar, la relación queda establecida inmediatamente.

AC-3 Cancelación de solicitud enviada

Un usuario puede cancelar una solicitud enviada mientras está en estado pendiente. Una vez resuelta (aceptada o rechazada), no puede cancelarse.

AC-4 Transferencia de liderazgo

Un usuario que ya tiene líder puede enviar una solicitud de transferencia a un nuevo líder. Un usuario sin líder no puede transferir. La transferencia es una solicitud: solo al aceptarla el nuevo líder, el líder anterior queda desvinculado automáticamente y recibe un aviso en su tabla de actividad y una notificación in-app.

AC-5 Desvinculación bidireccional con aviso

Al desvincular una relación activa —tanto quitando al propio líder como quitando a un liderado— la otra persona ve un aviso en su tabla de actividad y recibe una notificación in-app indicando que la relación fue disuelta.

AC-6 Organigrama visible para quienes tienen permiso

Un usuario con permiso de organigrama puede ver el árbol completo de la organización con todos los nodos activos y la sección de usuarios sin asignar. Un usuario sin ese permiso no puede acceder a esa vista.

AC-7 Reglas de integridad respetadas

El sistema rechaza correctamente: solicitudes duplicadas, relaciones ya existentes, solicitudes entre organizaciones distintas y solicitudes a uno mismo.

AC-8 Transición automática del rol de líder

Un usuario que no era líder pasa a serlo automáticamente al quedar con su primer liderado. Un usuario que era líder deja de serlo automáticamente al perder a su último liderado.

AC-9 Notificación in-app por evento de liderazgo

Cada evento de liderazgo (solicitud/invitación/transferencia recibida, aceptación, rechazo, desvinculación) genera una notificación in-app para la persona involucrada, según lo descrito en 16-notificaciones.md.

Trazabilidad

ID	Tipo	Descripción breve	Criterio de prueba
CU-1	Caso de uso	Solicitar un líder	AC-1
CU-2	Caso de uso	Invitar un liderado	AC-1
CU-3	Caso de uso	Gestionar solicitudes recibidas	AC-2
CU-4	Caso de uso	Cancelar solicitud enviada	AC-3
CU-5	Caso de uso	Transferir liderazgo (requiere tener líder)	AC-4
CU-6	Caso de uso	Desvincular relación activa (bidireccional)	AC-5
CU-7	Caso de uso	Ver organigrama	AC-6
R-1.1	Regla	Toda relación requiere aceptación	AC-2
R-1.2	Regla	Un solo líder directo por usuario	Sin múltiples líderes activos
R-1.3	Regla	Sin solicitudes duplicadas	AC-7
R-1.4	Regla	Sin solicitud si ya existe relación	AC-7
R-1.5	Regla	Solo dentro de la misma organización	AC-7
R-1.6	Regla	No puede ser su propio líder	AC-7
R-1.7	Regla	Transferencia reemplaza el vínculo anterior	AC-4
R-1.8	Regla	Desvinculación notifica a la otra parte (in-app)	AC-5, AC-9
R-1.9	Regla	Organigrama en tiempo real	AC-6
R-1.10	Regla	Sin relaciones = sección "sin asignar"	AC-6
R-1.11	Regla	Rol de líder automático (primer/último liderado)	AC-8
R-1.12	Regla	Transferencia requiere tener líder actual	AC-4
R-1.13	Regla	Eventos de liderazgo generan notificaciones in-app	AC-9
AC-1	Aceptación	Solicitud enviada y visible en tabla	Búsqueda + envío + estado
AC-2	Aceptación	Aceptar/rechazar solicitudes recibidas	Relación activa post-aceptación
AC-3	Aceptación	Cancelar solicitud pendiente	Solo cancela pendientes
AC-4	Aceptación	Transferencia con desvinculación automática	Aviso al ex-líder
AC-5	Aceptación	Desvinculación con aviso	Aviso en tabla de actividad
AC-6	Aceptación	Organigrama con permiso / bloqueado sin él	Acceso por permiso
AC-7	Aceptación	Validaciones de integridad	Mensajes de error claros
AC-8	Aceptación	Transición automática del rol de líder	Líder al primer liderado; deja de serlo sin liderados
AC-9	Aceptación	Notificación in-app por evento de liderazgo	Notificación a la persona involucrada

Supuestos

La asignación inicial del campo leader_id en el perfil del usuario se gestiona únicamente a través de este módulo — no por edición directa del perfil.
Cada organización gestiona sus relaciones de forma independiente; no existen relaciones entre organizaciones.
No existe límite en la cantidad de liderados que puede tener un líder.
La jerarquía no tiene límite de profundidad definido.

Preguntas abiertas (para cerrar con el cliente)

¿Qué pasa con el historial de solicitudes? ¿Se conservan las solicitudes rechazadas y canceladas de forma indefinida, o se eliminan tras un período?
¿Puede un administrador forzar una relación sin pasar por el flujo de solicitudes, en casos excepcionales?
¿Qué ocurre con el E-map grupal al desvincular un liderado? El mes activo puede quedar con datos incompletos del equipo. ¿Se recalcula o se congela?
Notificaciones por otros canales: las notificaciones in-app de eventos de liderazgo ya están implementadas (ver 16-notificaciones.md). ¿Se desea sumar email o push para estos eventos, y por qué canales?

Correcciones / historial de validación

Fecha	Versión	Cambio
2026-04-11	v1.0	Documento inicial. Módulo de liderazgo: solicitudes bidireccionales, flujo de aceptación, transferencia, desvinculación, organigrama, permisos y nuevo rol de sistema.
2026-04-21	v1.1	A-15.1: Rol "Gestor de liderazgo" actualizado — puede ver el E-map de cualquier persona de la organización sin restricción de jerarquía. Se alinea con el actor "Cuenta root / administradora" del DRF 14.
2026-07-02	v1.2	Se corrige que las notificaciones in-app de eventos de liderazgo YA están implementadas (antes marcadas como fase posterior); se remite al DRF 16. Se documenta la transición automática del rol de líder (R-1.11), la precisión de que la transferencia requiere tener líder actual y es una solicitud a aceptar (CU-5, R-1.12) y la desvinculación bidireccional (CU-6). Nuevas AC-8 y AC-9.