Manual de Usuario — TeamOrbit

Guia completa para gestionar la capacidad, proyectos y productividad de tu equipo de desarrollo.

1. Introduccion

Que es TeamOrbit

TeamOrbit es una aplicacion de gestion de capacidad y proyeccion de ancho de banda para equipos de desarrollo de software. Permite planificar, registrar y auditar como se distribuye el tiempo del equipo entre los distintos tipos de proyectos, detectar cuellos de botella y tomar decisiones informadas sobre la asignacion de recursos.

El problema que resuelve es simple pero critico: saber en todo momento cuantas horas tiene tu equipo, cuantas estan comprometidas y cuantas quedan libres, desglosado por area, por tipo de proyecto y proyectado a futuro.

Conceptos clave

• Capacidad — Se mide siempre en horas disponibles, nunca en cantidad de personas. Cada persona tiene una carga horaria configurada (completa, medio tiempo o personalizada) y un porcentaje de overhead que se descuenta.
• Sprint — La unidad de tiempo interna del equipo. Por defecto dura 3 semanas. Toda la planificacion, el registro de horas y las proyecciones se basan en sprints. Los sprints se numeran secuencialmente.
• Overhead — Porcentaje del tiempo de una persona dedicado a actividades no-proyecto (reuniones de gestion, coordinacion, one-on-ones, etc.). Se descuenta automaticamente de la capacidad disponible de esa persona.
• Snapshot — Foto congelada de la capacidad del equipo que se genera al cerrar un sprint. Contiene la carga horaria, overhead, roles y areas de cada persona en ese momento. Los snapshots historicos no cambian aunque despues se modifiquen los datos de las personas.

Los 5 tipos de proyecto

TeamOrbit clasifica todo el trabajo del equipo en 5 tipos, cada uno con un color distintivo:

Estos 5 tipos son los que aparecen en todas las graficas de capacidad, en el Dashboard, en el Simulador y en los reportes. Las horas libres (no comprometidas) se muestran como un sexto componente en gris.

2. Inicio de Sesion

TeamOrbit ofrece dos metodos de autenticacion:

Autenticacion local (usuario y contrasena)

Microsoft 365 (Entra ID) SSO

Roles de usuario

• Admin — Acceso total a todas las funcionalidades, incluyendo gestion de usuarios y configuracion del sistema.
• Lider — Acceso operativo: puede gestionar proyectos, registrar horas, ver reportes. No puede administrar usuarios ni configuracion global.

Mapeo Usuario ↔ Persona (auto-link)

Para que el sistema sepa a que Persona del equipo corresponde cada Usuario logueado, hay dos opciones:

1. Auto-link por email (recomendado): si la Persona tiene cargado el campo Email Microsoft 365 (ver seccion 5), al loguearse el sistema busca el match por email y conecta automaticamente Usuario.PersonaId. Funciona tanto en login Entra ID como en login local.
2. Mapeo manual: en el ABM de Usuarios (seccion 21) se puede setear el PersonaId a mano para casos donde el email no coincida.

Este mapeo es lo que habilita features como el recordatorio flotante de pendientes y los reportes personales.

Recordatorio flotante de pendientes

Apenas la persona ingresa, si tiene promesas Pendiente o Prioridad como owner para la semana actual, aparece un toast flotante en la esquina inferior derecha con la lista. Se puede cerrar; reaparece en el siguiente login o tras 24 horas si la sesion sigue viva (para usuarios que no acostumbran cerrar sesion). Requiere que la Persona este mapeada con el Usuario (ver arriba).

3. Dashboard

El Dashboard es la pantalla principal al ingresar al sistema. Muestra el estado actual del sprint en curso (no mensual). Toda la informacion se calcula en funcion del sprint activo y los datos registrados hasta el momento.

Los 5 KPIs principales

Cada tarjeta KPI se explica a continuacion:

• Capacidad Total — Suma de las horas netas de todas las personas activas, multiplicada por los dias habiles del sprint. Descuenta overhead y feriados.
• Capacidad Comprometida — Porcentaje de la capacidad total que ya esta asignada a proyectos (DD prorrateado + estimaciones OT activas + estimaciones Roadmap activos + reservas vigentes). Si supera el 90%, se muestra en amarillo; si supera el 100%, en rojo.
• Horas DD Sprint — Horas consumidas del total de contratos DD prorrateados al sprint. La prorracion se basa en los dias habiles del sprint que caen dentro de cada mes.
• OT Activas — Cantidad de ordenes de trabajo con estado "EnProgreso".
• Soporte Dev — Horas registradas como tipo "Soporte" durante el sprint actual.

Capacidad por Area (grafica de barras apiladas)

Esta es la grafica mas importante del Dashboard. Muestra una barra horizontal por cada area del equipo. Cada barra se compone de 6 segmentos apilados:

Seccion de Alertas

El Dashboard muestra alertas automaticas cuando se detectan situaciones que requieren atencion:

• Areas con mas del 90% de capacidad comprometida.
• Contratos DD que se acercan al limite de horas mensuales.
• OTs con fecha de entrega proxima (dentro de los siguientes 7 dias).
• Areas con 0 horas libres (sobrecarga).

Proximas Entregas

Tabla con las 8 entregas mas cercanas (OTs y Roadmaps), mostrando nombre, tipo, cliente, fecha de entrega y estado. Permite una vista rapida de los compromisos inmediatos del equipo.

Widget de Roadmap (nuevo)

Card en el Dashboard con 4 KPIs del portfolio de roadmaps activos, mas una lista corta de los 6 roadmaps mas relevantes para llegar a completarse.

Proyeccion por Sprint

Grafica de barras que muestra la capacidad total vs. comprometida para el sprint actual y los proximos sprints (cantidad configurable en Configuracion > SprintsProyeccion). Permite visualizar si el equipo tiene capacidad para asumir nuevo trabajo en el futuro cercano.

4. Simulador de Capacidad

El Simulador permite experimentar escenarios "what-if" sin afectar datos reales. Es una herramienta exploratoria que proyecta la capacidad por sprints futuros segun las simulaciones que agregues.

Los 4 tipos de simulacion

4.1 Agregar OT

Simula el impacto de una nueva orden de trabajo en la capacidad del equipo.

Las horas se distribuyen uniformemente entre los sprints que cubren el rango de fechas. El simulador muestra como cambiaria la barra de cada area afectada.

4.2 Agregar Contrato DD

Simula un nuevo contrato de desarrollo dedicado.

Las horas mensuales se prorratean automaticamente a cada sprint segun los dias habiles. La distribucion por area se hace proporcionalmente a la capacidad de cada area.

4.3 Agregar/Quitar Persona

Simula el impacto de sumar o perder un integrante del equipo.

Al agregar una persona, se suma su capacidad al area seleccionada. Al quitar, se resta. El simulador recalcula las barras de capacidad para todos los sprints proyectados.

4.4 Enviar a Challenge

Simula tercerizar parte del trabajo de una OT existente a un proveedor externo.

Al enviar a challenge, las horas se "liberan" del area seleccionada, reduciendo la carga interna.

Vistas de la grafica

El Simulador ofrece dos vistas de la grafica principal, intercambiables con un toggle:

• Por Area — Una barra por cada area, mostrando la carga total (DD + OT + Roadmap + Soporte + Estabilizacion) vs. capacidad disponible.
• Por Tipo — Una barra por cada tipo de proyecto, mostrando cuantas horas se consumen en total por cada tipo en cada sprint.

Tarjetas de resultado

Debajo de la grafica, el Simulador muestra 3 tarjetas de resumen:

• Primera ventana disponible — El primer sprint futuro donde hay capacidad suficiente para absorber la simulacion.
• Areas en riesgo — Areas que quedarian por encima del 90% de capacidad comprometida con la simulacion aplicada.
• Impacto neto — Diferencia total en horas entre la situacion actual y la simulada, por sprint.

Tabla de detalle

Una tabla expandible muestra sprint por sprint, area por area, las horas comprometidas actuales vs. las simuladas, con la diferencia resaltada en color (verde si se libera capacidad, rojo si se consume).

5. Personas

Gestion del equipo. Cada persona tiene configurada su capacidad, que impacta directamente en todas las proyecciones, calculos y reportes del sistema.

Todos los campos

Tipos de Carga Horaria

Calculo de horas netas (con overhead)

El overhead se aplica sobre las horas brutas para obtener las horas netas disponibles para proyectos:

Flujo para crear una persona

Validaciones

• Los porcentajes de dedicacion de los roles deben sumar exactamente 100%. El formulario no permite guardar si la suma es diferente.
• El Area Principal no puede estar seleccionada como Area Secundaria al mismo tiempo.
• Si la Carga Horaria es "Personalizado", el campo Horas Diarias es obligatorio y debe ser mayor a 0.

6. Areas

Las areas representan equipos o disciplinas del equipo de desarrollo (Canal Web, Canal App, Platform, QA, DevOps, etc.). Son una pieza fundamental porque toda la distribucion de capacidad se hace por areas.

Campos

Listado de areas

El indice de areas muestra para cada una:

• Nombre del area
• Lider encargado (si tiene asignado)
• Cantidad de personas asignadas (area principal)
• Horas/dia totales del area — suma de las horas netas de todas las personas del area

La capacidad se calcula automaticamente sumando las horas netas de cada persona asignada al area. No se puede editar manualmente, depende de las personas y su configuracion.

7. Roles

Los roles definen el tipo de trabajo que realiza cada persona (Desarrollador, QA, Analista Funcional, DevOps, Scrum Master, etc.). Cada persona puede tener multiples roles con un porcentaje de dedicacion.

Campos

Crear un rol

Asignar roles a personas

La asignacion se hace desde la ficha de cada persona (seccion Personas). Se selecciona el rol y se indica el porcentaje de dedicacion. La suma de todos los roles asignados a una persona debe ser 100%.

Los roles impactan en:

• Reportes de capacidad — Permiten ver la distribucion de roles por area.
• Snapshots — Los roles de cada persona se congelan en el snapshot al cerrar un sprint.

8. Organigrama

El organigrama es una visualizacion jerarquica de solo lectura que se genera automaticamente a partir del campo Superior de cada persona.

Como funciona

• Las personas sin superior aparecen en la raiz del arbol (tipicamente el CTO o gerente general).
• Cada persona muestra debajo a todos sus subordinados directos.
• Se muestra el nombre, area y rol principal de cada persona.
• La vista es interactiva: se pueden expandir y colapsar ramas.

9. Clientes

Gestion de la cartera de clientes. Los clientes son la entidad a la que se vinculan los contratos DD y las ordenes de trabajo.

Campos del cliente

Gestion de contactos

Cada cliente puede tener multiples contactos, y solo uno puede estar marcado como principal.

Al marcar un contacto como principal, cualquier otro contacto del mismo cliente que estuviera marcado como principal se desmarca automaticamente.

Flujo para gestionar contactos

Vista de detalle del cliente

La pagina de detalle muestra:

• Informacion general del cliente y su estado.
• Contactos — Lista de contactos con acciones de editar y marcar como principal.
• Contratos DD — Lista de contratos de desarrollo dedicado vinculados, con estado y horas mensuales.
• Ordenes de Trabajo — Lista de OTs vinculadas al cliente, con estado, horas estimadas y fecha de entrega.

10. Ordenes de Trabajo (OT)

Las OTs representan trabajos puntuales para un cliente: desarrollos a medida, integraciones, migraciones, etc. Cada OT tiene una estimacion de horas, una fecha de entrega y fases que representan su ciclo de vida.

Crear una OT

Fases de una OT (8 fases del ciclo)

Al crear una OT, el sistema genera automaticamente 8 fases secuenciales con pesos configurables (ver Configuracion). El orden es fijo: Pendiente → Discovery → Relevamiento → Refinamiento → Implementacion → Control de Calidad → UAT → Completa.

Regla de reserva de capacidad

Una OT (o proyecto DD) reserva capacidad en el sprint si y solo si:

• NO esta cancelada (Cancelada = false), Y
• Su fase actual no es "Pendiente" ni "Completa".

Es decir, solo las 6 fases intermedias (Discovery, Relevamiento, Refinamiento, Implementacion, Control de Calidad, UAT) reservan capacidad. La fase Pendiente (Orden 1) es la de todo proyecto recien creado que aun no fue tomado por el equipo, y la fase Completa (Orden 8) es el cierre administrativo (handover/factura/firma). Ninguna de las dos consume ancho de banda del sprint.

Flag "Cancelada" (nuevo)

Reemplaza al viejo valor Estado = "Cancelada". Cada OT y cada proyecto DD tiene un switch "Cancelada" (bool) en el form de edicion. Al activarlo:

• La OT/proyecto deja de reservar capacidad automaticamente (los queries de capacidad filtran por !Cancelada), sin importar en que fase este.
• Se oculta por defecto en el Index de OTs y en la cola de proyectos DD. Un toggle "Ver canceladas / Ver cancelados" arriba de la lista las muestra cuando se lo necesita.
• Reactivarla (destildar el switch) vuelve a reservar capacidad segun su fase actual.

Vista de detalle de la OT

La pagina de detalle es la mas rica en informacion. Incluye:

Semaforo (traffic light)

El semaforo indica el estado de salud de la OT comparando las horas reales registradas contra la estimacion actual y el avance de fases:

Gestion de fases

Desde el detalle se puede:

• Avanzar fase — Marca la fase actual como completada y pasa a la siguiente. La primera fase pasa a "EnProgreso" y la OT cambia a estado "EnProgreso".
• Retroceder fase — Reabre una fase completada para corregir. Pasa la fase anterior de "Completada" a "EnProgreso".
• Editar fechas de un hito — Se pueden ajustar manualmente la fecha de inicio y/o fin de cualquier fase sin modificar su estado (útil para dejar el timeline alineado con lo que efectivamente ocurrió).
• Comentarios por hito — Cada fase acepta comentarios cortos (máx 500 caracteres). Sirven para dejar contexto interno sobre cada etapa (bloqueos, decisiones, contactos). Los comentarios NO se muestran al cliente en el portal.
• Cada avance/retroceso de fase se registra en el log de actividad.

Fases en Proyectos DD

Los proyectos DD tienen el mismo sistema de fases que las OTs: avance/retroceso, edición de fechas y comentarios por hito. La lógica de estados (Pendiente → EnProgreso → Completada) es idéntica.

Seguimiento de horas

Horas por area

Desglose de horas estimadas vs. horas reales por cada area involucrada en la OT. Permite ver si hay areas que estan consumiendo mas o menos de lo estimado.

Actividad reciente

Log cronologico de todas las acciones sobre la OT: avances de fase, retrocesos, cambios de estimacion, challenges creados, horas registradas.

Challenges (Tercerizacion)

Un challenge permite delegar parte o la totalidad del trabajo de una OT a un proveedor externo.

Las horas en challenge se descuentan de la carga interna del equipo: si una OT tiene 200h estimadas y se envian 50h a challenge, solo 150h impactan la capacidad del equipo.

Azure DevOps Links

Cada OT puede tener vinculos a Work Items de Azure DevOps. Esto permite trazar el trabajo registrado en TeamOrbit con los items del backlog. Los links se agregan y administran desde la vista de detalle de la OT.

11. Desarrollo Dedicado (DD)

Los contratos de Desarrollo Dedicado representan acuerdos con clientes que contratan una cantidad fija de horas mensuales. El equipo debe consumir las horas contratadas cada mes, y el sistema rastrea el cumplimiento.

Crear un contrato DD

Estados del contrato

• Activo — El contrato esta en vigencia y se deben consumir horas.
• Pausado — Temporalmente detenido. No se espera consumo.
• Finalizado — El contrato termino.

Proyectos dentro del contrato

Cada contrato DD puede tener multiples proyectos. Los proyectos permiten organizar el trabajo del contrato y seguir el avance por separado. Cada proyecto DD comparte el mismo sistema de 8 fases que una OT (ver seccion 10):

Cola de proyectos DD — modal grande (nuevo)

Dentro de /ContratosDD/Details, la cola de proyectos DD se redisenó. Antes cada fila mostraba el stepper de fases inline + un form de edicion inline colapsable. Ahora la fila es compacta — muestra prioridad + nombre + estado (nombre de fase actual) + horas + chevron. Al hacer click en la fila se abre un modal grande con todo el detalle del proyecto:

• Stepper completo de fases con indicador de fase actual.
• Formulario de edicion del proyecto (nombre, descripcion, prioridad, distribucion por area, switch Cancelada).
• Botones para Avanzar / Retroceder fase.
• Popover de comentarios y edicion de fechas por hito.
• Boton para borrar (si no tiene horas registradas).
• Links a Azure DevOps.

Barra de consumo en el listado

En la vista de listado de contratos DD, cada contrato muestra una barra de progreso que indica cuantas horas se han consumido en el mes actual respecto al total contratado.

Vista de detalle del contrato DD

El detalle del contrato es un dashboard completo con multiples visualizaciones:

KPIs del mes actual

Semaforo del contrato

El semaforo compara el ritmo de consumo actual con el ritmo necesario para completar las horas contratadas:

• Verde — El consumo esta al ritmo esperado o por encima.
• Amarillo — El consumo esta ligeramente por debajo del ritmo necesario.
• Rojo — El consumo esta muy por debajo; se necesita acelerar para cumplir.

Grafica historica de 6 meses

Un grafico de barras con los ultimos 6 meses mostrando horas contratadas (linea) vs. horas consumidas (barras). Permite identificar tendencias de sub o sobre consumo.

Proyectos con drag-and-drop

Los proyectos dentro del contrato se pueden reordenar arrastrando (drag & drop) para ajustar prioridades visualmente.

Prorracion de horas mensuales a sprints

Internamente, TeamOrbit convierte las horas mensuales del contrato en horas por sprint para las proyecciones de capacidad. La prorracion se basa en los dias habiles que cada sprint cubre dentro de cada mes:

12. Roadmap

Los roadmaps representan iniciativas estrategicas internas del equipo: nuevas funcionalidades del producto, mejoras tecnicas, refactorings mayores, etc. No estan vinculados a un cliente especifico.

Campos del roadmap

Tareas del roadmap

Cada roadmap puede tener multiples tareas que descomponen el trabajo en piezas mas granulares:

Gestion de tareas

Desde el detalle del roadmap:

• Agregar tarea — Boton para crear una nueva tarea con sus estimaciones por area.
• Editar tarea — Modificar nombre, descripcion, prioridad, estimaciones.
• Reordenar tareas — Cambiar el orden de prioridad.
• Eliminar tarea — Solo si no tiene horas registradas.

Vista de detalle

El detalle del roadmap muestra:

• Informacion general y estado.
• Tabla de tareas con horas estimadas vs. horas reales consumidas por tarea.
• Actividad reciente (log de cambios).
• Links a Azure DevOps (si los tiene).
• Porcentaje de avance calculado sobre horas consumidas vs. estimadas.

Las horas se pueden registrar contra el roadmap en general o contra una tarea especifica. En el Registro de Horas, al seleccionar tipo "Roadmap", se elige el roadmap y opcionalmente la tarea.

13. Soporte Dev

Soporte Dev es el modulo para dar seguimiento al trabajo reactivo del equipo: incidencias de produccion, certificacion, bug fixes, consultas tecnicas, etc. A diferencia de los otros tipos de proyecto, el soporte no se planifica — se registra a medida que ocurre.

Dashboard de Soporte

La pantalla principal de Soporte Dev es un dashboard con 6 visualizaciones:

1. Horas por Categoria (barras)

Grafico de barras horizontales mostrando cuantas horas se consumieron en cada categoria de soporte (ej: Incidencias Produccion, Certificacion, Consultas, etc.).

2. Horas por Persona (top 10)

Barras horizontales con las 10 personas que mas horas de soporte registraron en el periodo seleccionado.

3. Tendencias temporales

Grafica de lineas que muestra la evolucion de horas de soporte en el tiempo. Se puede alternar entre vistas: diaria, semanal, mensual y anual.

4. Evaluacion de incidencias (torta)

Grafico circular (pie/doughnut) que muestra la proporcion de incidencias evaluadas como "Bien Elevada" vs "Mal Elevada". Permite medir la calidad de la elevacion de tickets.

Gestion de categorias

Las categorias de soporte se administran desde Soporte Dev > Categorias. Cada categoria tiene:

• Nombre — Nombre de la categoria (ej: "Incidencia Produccion", "Certificacion", "Bug Critico").
• Activa — Si la categoria esta disponible para seleccionar al registrar horas.

Filtros

El dashboard de soporte permite filtrar por:

• Rango de fechas — Desde/hasta para acotar el periodo.
• Categoria — Filtrar por una categoria especifica.
• Cliente — Filtrar incidencias de un cliente en particular (campo opcional del registro de soporte).
• Persona — Filtrar por quien registro las horas.

Tabla de detalle expandible

Debajo de las graficas, una tabla muestra el detalle agrupado por categoria. Cada fila de categoria se puede expandir para ver los registros individuales con: fecha, persona, horas, work item, titulo, evaluacion.

Tabla de Mal Elevadas

Una tabla dedicada muestra las incidencias evaluadas como "Mal Elevada", con el motivo registrado por la persona. Esto permite al equipo de soporte analizar los patrones y mejorar la calidad de la elevacion de tickets.

14. Versiones (Estabilizacion)

Las versiones representan releases del producto (v4.5, v4.5.5, v4.6, etc.) y su periodo de estabilizacion posterior al lanzamiento. Las horas de estabilizacion se registran contra una version para medir el esfuerzo de post-release.

Campos de la version

Estados de la version

• En Estabilizacion — La version fue liberada y esta siendo testeada y corregida activamente.
• Estabilizada — La version paso el control de calidad. Los bugs criticos fueron resueltos.
• En Produccion — La version esta desplegada en produccion.

Vista de detalle de la version

El detalle de una version incluye un mini-dashboard con:

KPIs

Graficas

• Doughnut por tipo — Distribucion de horas por tipo de trabajo de estabilizacion.
• Barras por area — Cuantas horas de estabilizacion consumio cada area.

Tablas

• Por persona — Horas registradas por cada persona contra esta version.
• Por area — Horas agrupadas por area.

Como registrar horas de estabilizacion

En el Registro de Horas, seleccionar tipo "Estabilizacion" y elegir la version activa contra la cual registrar. Las horas se suman automaticamente al dashboard de la version.

15. Reservas de Capacidad

Las reservas de capacidad permiten apartar un porcentaje de la capacidad global del equipo para Soporte, Estabilizacion, Ad Hoc, o categorias dinamicas definidas por el usuario, distribuido entre las areas. Esto asegura que siempre haya un margen disponible para trabajo reactivo o iniciativas puntuales.

Concepto

La idea es simple: si el equipo tiene 2000 horas/sprint de capacidad neta y se configura una reserva del 20% para Soporte, entonces 400 horas quedan "apartadas" y no se consideran como capacidad libre para nuevos proyectos DD, OT o Roadmap.

Crear una reserva

Distribucion por area

Despues de definir el porcentaje global, se debe distribuir ese porcentaje entre las areas del equipo. La distribucion indica que proporcion de las horas reservadas absorbe cada area.

Impacto en el sistema

Las reservas vigentes impactan multiples modulos:

• Dashboard — Las horas reservadas se muestran como parte de la capacidad comprometida en la grafica por area.
• Simulador — Las proyecciones futuras descuentan las horas reservadas de la capacidad libre.
• Calculos de capacidad — Toda consulta al CapacidadService considera las reservas activas y vigentes.

Codificacion de color en el listado

• Vigente — Hoy esta dentro del rango Fecha Desde - Fecha Hasta y esta activa.
• Futura — Fecha Desde es posterior a hoy.
• Vencida — Fecha Hasta es anterior a hoy.
• Inactiva — Fue desactivada manualmente.

Formularios side-sheet — botón Guardar

El formulario de creación/edición de reservas se abre como side-sheet (panel lateral). El footer del side-sheet (con el botón Guardar) se promociona automáticamente fuera del <form> para pegarse al borde inferior — antes esto dejaba el botón "huérfano" y no submitía. Ahora al mover el footer se asigna automáticamente form={id} a los submit buttons, asegurando que Guardar siempre esté vinculado al formulario correcto. La mecánica es genérica: aplica a cualquier side-sheet con esa estructura.

Auditoria (vista de detalle)

En el detalle de cada reserva, la seccion de auditoria muestra sprint por sprint la comparacion entre las horas que se reservaron vs. las horas que realmente se consumieron en el concepto correspondiente (Soporte o Estabilizacion):

15b. Categorias Dinamicas de Reserva

Las categorias dinamicas son reservas de capacidad definidas por el usuario que se comportan exactamente igual que las fijas (Soporte, Estabilizacion, AdHoc), pero permiten reservar espacio para iniciativas puntuales que no entran en esas tres categorias. Por ejemplo: "Estimar WO", "Capacitacion masiva", "Hackathon", "OKRs Q3", etc.

ABM de categorias dinamicas

En Reserva Capacidad > Categorias dinamicas se administran las categorias. Cada una tiene:

Reservar capacidad para una categoria dinamica

Igual que para Soporte/Estabilizacion/AdHoc, se crea una reserva desde Reservas de Capacidad > Nueva Reserva. En el selector de Concepto aparece "Categoria dinamica..." que despliega un dropdown con las categorias activas. El resto del formulario (% global, periodo, distribucion por area) es identico.

Registrar horas contra una categoria dinamica

En el Registro de Horas, al agregar una fila, el selector de Tipo incluye "Categoria dinamica". Cuando se elige, el selector de proyecto trae solo las categorias dinamicas activas con reserva > 0% vigente en el sprint actual. Si una categoria no tiene reserva activa, no se puede registrar horas contra ella.

Impacto en el sistema (identico a las fijas)

• Pre-planning — El header "h reservadas" suma Sop+Estab+AdHoc + todas las dinamicas vigentes. Las horas libres restantes son las disponibles para postular candidatos.
• Dashboard — La barra de capacidad por area incluye una porcion para "Dinamicas". El detalle de la barra agrupa todas las dinamicas en una sola entrada.
• Resumen de Capacidad (Reportes) — Nueva columna "Dinamicas reservado" por area y total general.
• Simulador — Las proyecciones futuras descuentan las reservas dinamicas igual que las fijas.
• Cierre de sprint — El snapshot de comprometido por area refleja las reservas dinamicas en las horas libres.

Dashboard de categorias dinamicas

En Reserva Capacidad > Dashboard de Categorias Dinamicas hay una vista dedicada con filtro por categoria y por sprint. Muestra:

• Reservadas vs consumidas en el sprint, con % de cumplimiento.
• Cantidad de registros y desglose por persona.
• Distribucion por area (reservadas vs consumidas).
• Historico sprint-por-sprint para auditar la evolucion.

16. Registro de Horas

El Registro de Horas es la pantalla central donde cada persona registra como distribuyo su tiempo durante la semana. Utiliza una grilla semanal (Lunes a Viernes) donde las filas son proyectos y las columnas son dias.

Grilla semanal paso a paso

Flujo especial para Soporte Dev

Las horas de soporte requieren informacion adicional. Al hacer clic en una celda de hora de tipo Soporte, se abre un modal con los siguientes campos:

Boton de detalle

Para todos los tipos de proyecto (no solo Soporte), cada fila tiene un icono de detalle (). Al hacer clic, se puede agregar:

• Titulo — Titulo descriptivo del trabajo realizado.
• Descripcion — Detalle adicional.
• Work Item — ID de Azure DevOps (se valida que exista).

Auto-guardado

Las horas se guardan automaticamente al salir de cada celda (evento "blur"). No hay un boton de guardar explicito. Si hay un error de conexion, la celda se resalta en rojo y se puede reintentar.

Panel de Distribucion

Un panel lateral o inferior muestra:

• Grafica de torta — Distribucion de las horas de la semana por tipo de proyecto (DD, OT, Roadmap, Soporte, Estabilizacion).
• Drill-down jerarquico — Al hacer clic en un segmento de la torta, se expande para mostrar la distribucion por proyecto individual dentro de ese tipo.

Panel de Tracking

Visualizaciones de seguimiento personal:

• Heatmap de actividad — Calendario con colores segun la intensidad de horas registradas por dia (similar al heatmap de contribuciones de GitHub).
• Tendencia semanal — Grafica de lineas mostrando las horas registradas por semana en las ultimas semanas.
• KPIs personales — Promedio diario de horas, porcentaje de registro (horas registradas vs. horas esperadas), racha de dias consecutivos con registro.

Vista del Equipo

Tabla de resumen del equipo completo:

Tambien incluye un resumen por area con totales de horas esperadas vs. registradas.

17. Licencias

Las licencias representan periodos en que una persona no esta disponible para trabajar (vacaciones, enfermedad, estudios, etc.). El sistema las descuenta automaticamente de la capacidad disponible del equipo, tanto en el sprint actual como en proyecciones futuras.

Tipos de licencia

Configurables desde Configuracion → Tipos de Licencia. Por defecto el sistema incluye:

• Vacaciones
• Enfermedad
• Estudio
• Personal

Se pueden agregar nuevos tipos o desactivar los existentes (no se eliminan, solo se ocultan para mantener el historico).

Cargar una licencia

Tipos: dia completo vs parcial

Como impactan las licencias en la capacidad

Las horas de licencia se muestran como una categoria separada en las graficas de capacidad del Dashboard, Simulador y Sprint Details, junto a DD, OT, Roadmap, Soporte y Estabilizacion. Esto permite ver visualmente cuanta capacidad se pierde por ausencias.

Listado y filtros

La pantalla principal de Licencias muestra una tabla con todas las licencias activas y futuras, con filtros por persona, tipo y rango de fechas. Se pueden editar o eliminar licencias antes de su fecha de inicio.

18. Sprints

Los sprints son la unidad de medida del tiempo interno del equipo. Toda la planificacion, el registro de horas y las proyecciones se organizan en torno a sprints. Por defecto, cada sprint dura 3 semanas (configurable).

Gestion de sprints

Crear siguiente sprint

Un solo clic en el boton "Crear Siguiente Sprint". El sistema calcula automaticamente:

• Numero: El ultimo numero + 1.
• Fecha Inicio: El dia siguiente a la fecha de fin del sprint anterior.
• Fecha Fin: Fecha inicio + duracion configurada (DuracionSprintSemanas x 7 dias).

Editar sprint

Solo se pueden editar sprints con estado Activo. Se puede modificar:

• Numero del sprint
• Fecha de inicio
• Fecha de fin

Cerrar sprint

Al cerrar un sprint, el sistema:

Reabrir sprint

Si se necesita corregir datos despues del cierre, se puede reabrir un sprint cerrado. Al reabrir:

• El estado vuelve a "Activo".
• El snapshot anterior se mantiene pero se regenerara al volver a cerrar.

Al cerrar de nuevo, se genera un snapshot nuevo que reemplaza al anterior.

Regenerar snapshot

Permite volver a tomar la foto de capacidad sin necesidad de reabrir/cerrar. Util si se corrigieron datos de personas y se quiere actualizar el snapshot.

Auto-cierre

Al acceder al Dashboard o al Simulador, si hay sprints cuya fecha de fin ya paso y siguen en estado Activo, el sistema los cierra automaticamente y genera su snapshot. Esto asegura que ningun sprint quede abierto indefinidamente.

Que contiene un snapshot

Para cada persona activa del equipo al momento del cierre, se guarda:

Vista de detalle del sprint

La pagina de detalle de un sprint cerrado muestra:

KPIs del sprint

Graficas

• Consumo por tipo (doughnut) — Cuantas horas se consumieron en DD, OT, Roadmap, Soporte y Estabilizacion.
• Capacidad vs Consumo por area (barras) — Para cada area, barra doble: capacidad total y horas consumidas.

Tablas

• Tabla de capacidad por area — Area, personas, capacidad total, horas consumidas, % uso.
• Tabla de horas por tipo — Tipo de proyecto, horas totales, % del total.
• Tabla de snapshot por persona — Detalle de cada persona: area, carga horaria, overhead, horas netas, roles, areas secundarias.

Informe de Cierre: Planificado vs Ejecutado

Al cerrar un sprint, ademas del snapshot de capacidad, el sistema genera dos elementos historicos:

1. Snapshot Comprometido por Area

Para cada area, congela el breakdown completo de horas comprometidas al momento del cierre: capacidad, DD, OT, Roadmap, Soporte, Estabilizacion, Licencias y Libre. Esto permite ver mas adelante como estaba planificado el sprint.

2. Saldos OT por Sprint y Area

Para cada Orden de Trabajo activa, registra cuanto se planifico ejecutar y cuanto se ejecuto realmente, desglosado por area. La formula del planificado es: EstimacionNeta / SprintsAbarcados (sin arrastre).

Como interpretar el saldo

• Saldo positivo (amarillo) = horas planificadas que NO se ejecutaron. El proyecto se atrasa pero la carga del proximo sprint NO se incrementa (no hay arrastre).
• Saldo negativo (rojo) = horas ejecutadas en exceso. El proyecto va adelantado.
• Cumplimiento entre 90-110% (verde) = ejecucion en linea con el plan.

Historico en OT Details

En el detalle de cada OT (menu Ordenes de Trabajo → ver detalle), hay una nueva seccion "Historico de Cumplimiento por Sprint" que muestra sprint a sprint cuanto se planifico, cuanto se ejecuto y el saldo, agrupado por area.

18b. Incidencias UAT

Sistema de gestión de incidencias UAT reportadas por clientes contra proyectos en curso (OT o DD). Reemplaza el ticketing por email para tener trazabilidad, sign-off explícito y cómputo automático de capacidad.

Ciclo de vida

1. El cliente reporta una incidencia desde el portal /customers. Ingresa título, descripción, severidad (Bloqueante/Alta/Media/Baja), tipo (Bug/Mejora/Duda/Otra), versión afectada, módulo afectado y puede adjuntar hasta 5 archivos × 25MB.
2. El sistema asigna automáticamente al PM del cliente (campo PM asignado en Clientes) y aplica horas estimadas default del setting HorasEstimadasDefaultPorTicket.
3. El PM revisa, ajusta estimación y distribución por área (heredada de la OT/DD pero editable) y mueve el estado: Nueva → EnAnalisis → EnDesarrollo → ListaRetest → Resuelta.
4. Cuando llega a Resuelta, el cliente hace sign-off desde su portal: cierra (Cerrada) o reabre con motivo.
5. Bankingly puede Rechazar o Diferir con motivo si la incidencia no aplica.

Visibilidad de proyectos al cliente

El cliente solo ve proyectos cuya fase actual está en el setting EstadosVisiblesEnPortal (default: Control de Calidad, UAT, Completa). Cuando un proyecto está en Construcción no aparece en el portal.

Capacidad comprometida

Las horas estimadas de una incidencia abierta (Nueva, EnAnalisis, EnDesarrollo, ListaRetest, Resuelta) se distribuyen por área (IncidenciaArea.Porcentaje) y se cuentan como capacidad comprometida del sprint actual. Cuando la incidencia se cierra/rechaza/difiere, las horas se liberan automáticamente.

Conversación

En el detalle hay dos tipos de comentario:

• Público: lo ven cliente y Bankingly. Se envía email a la otra parte (cliente recibe link al portal de cliente, interno recibe link al backoffice).
• Interno (solo Bankingly): nunca se le envía al cliente. Útil para coordinación interna sobre la incidencia.

Adjuntos

Almacenados en el filesystem del servidor (App_Data/adjuntos-incidencias/{IncidenciaId}/). Tipos permitidos: pdf, png, jpg, jpeg, gif, webp, docx, xlsx, pptx, txt, csv, log, zip. Máximo 25MB por archivo y 5 por upload.

Pantalla interna

Acceso desde Seguimiento → Incidencias UAT. Lista filtrable por cliente, estado, severidad, asignado y búsqueda libre. El detalle permite cambiar estado, reasignar, ajustar horas/distribución por área y agregar comentarios públicos o internos.

Alta manual desde el interno (nuevo)

Arriba a la derecha de /Incidencias hay un botón "Nueva incidencia" que abre un side-sheet. Permite al equipo interno reportar una incidencia UAT en nombre de cualquier cliente activo. Útil para tickets llegados por fuera del portal (Slack, mail, llamada, teams, etc.).

Campos del side-sheet:

• Cliente (obligatorio) — Selector de clientes activos.
• OT o Proyecto DD (opcional, cascada) — Al elegir cliente se cargan sus OTs y proyectos DD visibles. Se puede dejar sin proyecto (solo ClienteId).
• Título, Descripción — Idem portal cliente.
• Severidad, Tipo, Versión, Módulo — Idem portal cliente.

Al guardar:

• El creador queda registrado como el user interno (no como usuario cliente).
• El PM del cliente se asigna automáticamente.
• La notificación por email dispara exactamente igual que las incidencias del portal (PM + suscriptos al OT/proyecto DD).

18c. Dashboard de Calidad

Vista de métricas sobre las incidencias UAT a lo largo del tiempo. Permite cambiar el rango temporal (30/90/180/365 días).

KPIs principales

• Incidencias en período: cantidad total reportada.
• Abiertas hoy: cuántas están en estados activos.
• Cerradas con sign-off: aprobadas por el cliente.
• Bloqueantes abiertas: número crítico — debería ser cercano a cero.
• Tiempo promedio de resolución: en horas, desde la creación hasta el cierre.

Distribuciones

Gráficos de barras por severidad y por tipo, y tabla por cliente que muestra totales, abiertas, bloqueantes y horas estimadas pendientes.

18d. Usuarios Cliente

Administración de las cuentas del portal /customers. Cada usuario pertenece a UN cliente y se identifica por email (único global). No usa contraseña — login por OTP.

Crear usuario

Botón Nuevo usuario. Pedir: cliente, email corporativo y nombre completo. El usuario podrá loguear desde /customers/login inmediatamente — el OTP se envía al hacer login, no al crearlo.

Desactivar

El botón rojo desactiva sin borrar. Un usuario inactivo no puede generar OTPs ni autenticarse. Los registros (incidencias creadas, comentarios) se conservan con su nombre.

Notificaciones internas (opt-in por proyecto)

En /Perfil/Notificaciones, cada usuario interno Bankingly puede:

• Recibir email cuando alguien comenta una incidencia que tiene asignada.
• Suscribirse a proyectos específicos para recibir notificación cuando se crea cada incidencia nueva contra ese proyecto.

La pantalla se organiza en dos tabs:

• Órdenes de Trabajo — Checkboxes por OT activa (agrupadas por cliente).
• Proyectos DD — Checkboxes por Proyecto DD activo (agrupados por contrato/cliente).

Los checkboxes son opt-in — no vienen pre-marcados. Cada usuario elige a qué proyectos concretos suscribirse. La lógica de despacho al crear una incidencia UAT es:

• Si la incidencia tiene ProyectoDDId → se notifica al PM del cliente + usuarios suscritos a ese Proyecto DD.
• Si la incidencia tiene OrdenTrabajoId (y no ProyectoDDId) → se notifica al PM + suscritos a esa OT.
• Si la incidencia solo tiene ClienteId (sin proyecto) → solo se notifica al PM del cliente (fallback).

El PM asignado al cliente (campo en Clientes) siempre recibe, sin necesidad de suscripción.

P1. Portal de Clientes — visión general

Ambiente separado bajo /customers que usan los UsuarioCliente para reportar y dar seguimiento a incidencias UAT. El portal está visualmente diferenciado:

• Si el Cliente tiene LogoUrl cargado en Clientes, lo muestra arriba.
• Si no tiene logo, muestra el badge Bankingly + el nombre del cliente.

El portal está aislado: un usuario interno Bankingly que pega /customers es redirigido a su propio dashboard; un UsuarioCliente que intenta entrar a cualquier ruta interna recibe 404 (no se revela la existencia del backoffice). Las consultas EF aplican un Global Query Filter que limita los datos al ClienteId del usuario logueado, garantizando aislamiento aún si hay bug en el código de aplicación.

P2. Login con OTP por email

El cliente entra a /customers/login e ingresa su email corporativo. Recibe un código de 6 dígitos por email (vence en 10 minutos). Lo ingresa en la siguiente pantalla. Tras validar, se crea sesión con cookie de 8 horas y se aplica IP binding: si la IP cambia entre requests, la sesión se invalida automáticamente.

Anti-abuso

• Máximo 5 OTPs por email/hora; máximo 15 por IP/hora.
• Máximo 3 intentos por código; al 4° intento el código se invalida y hay que pedir uno nuevo.
• Bloqueo global de 10 intentos fallidos por email/hora (independiente de cuántos OTPs se hayan emitido).
• Respuesta uniforme aun cuando el email no exista — no se filtra información sobre qué emails están dados de alta.

P3. Vista interna del portal (Bankingly)

Los usuarios internos Bankingly también acceden al portal /customers desde el sidebar de Orbit (link Portal Clientes). El portal detecta automáticamente que es un user interno y muestra una vista cross-cliente:

• Header con badge naranja "Bankingly · Vista interna" + selector de cliente.
• Dashboard inicial: métricas agregadas de TODOS los clientes (abiertas globales, bloqueantes, pendientes de sign-off, breakdown por cliente).
• Listado /customers/incidencias con filtros: estado, severidad, búsqueda, abiertas, proyecto, cliente y asignado (+ shortcut "solo mis asignadas").
• Detalle de incidencia: ve TODOS los comentarios (incluso los internos), descarga adjuntos de cualquier cliente, y panel lateral de acciones internas (comentar interno o público, cambiar estado, reasignar).
• Lo que NO puede el interno desde el portal: hacer sign-off del cliente, reabrir-como-cliente, crear incidencia (eso queda en /Incidencias del backoffice).

El interno puede pasar a "modo cliente" eligiendo un cliente del selector — verá lo mismo que ve ese cliente (proyectos visibles, sólo comentarios públicos del thread, etc.). Esto es útil para validar la experiencia del cliente o asistirlo por teléfono.

P4. Flujo del cliente

1. En el Dashboard ve sus proyectos visibles (OTs y DDs en fase Control de Calidad/UAT/Completa) y un resumen de incidencias.
2. Click en Reportar incidencia: selecciona proyecto, título, severidad, tipo, descripción y opcionalmente adjuntos.
3. En el detalle de cada incidencia ve la conversación pública (sus comentarios + los del equipo Bankingly), puede agregar nuevos comentarios y adjuntos.
4. Cuando la incidencia llega a Resuelta, aparece el botón Hacer sign-off que la cierra. Si vuelve a aparecer el problema, usa Reabrir con motivo.
5. Recibe email automático ante: creación (PM), cambio de estado, comentarios públicos del equipo.

Herramientas: Organizacion Semanal

Tablero kanban para definir y dar seguimiento a las promesas semanales del equipo de tecnologia. Pensado para usar en la reunion de lideres de cada lunes (definir prioridades) y la de cada viernes (revisar lo cumplido). Se accede desde el menu lateral Herramientas → Tools → Organizacion Semanal.

Concepto general

• Una promesa es un compromiso que una persona (o varias) toma para una semana especifica.
• Cada promesa tiene un titulo, descripcion opcional, 0 a N owners (personas responsables) y un estado.
• La semana laboral se considera lunes a viernes, alineado con la dinamica de stand-up del equipo.

Estados disponibles

• Pendiente - aun no comenzo o esta en curso normal.
• Prioridad - foco urgente de la semana.
• OnHold - frizada por una decision externa (no penaliza).
• Cancelada - decidiste no hacerla (penaliza con -2).
• Entregada - cumplida (suma +10). Es la "meta" del kanban (ultima columna en verde).

Navegacion: sprint y semanas

• Las flechas « y » saltan al sprint anterior/siguiente.
• Dentro del sprint hay tabs Semana 1, 2, 3... (cantidad dinamica segun la duracion del sprint definida en el ABM de Sprints).
• El boton Hoy te lleva al sprint y semana actuales.
• El pill del sprint muestra el rango Mon-Fri en espanol (ej: "Lun 12 May - Vie 30 May 2026").

Camino de las Promesas

Pista visual horizontal arriba del kanban con el flujo Pendiente → Prioridad → OnHold → Entregada. Cada promesa aparece como un token (con la inicial del owner) en la etapa donde esta. Hover muestra detalle, click abre el modal de edicion. Las promesas Canceladas quedan fuera de pista (badge a la derecha indicando cuantas son).

Prioridades por persona (acordeon)

Widget colapsado por default (se expande al click). Lista las personas activas agrupadas por area principal, con el conteo de promesas en estado Prioridad de la semana calendario actual. El lider de cada area (definido en el ABM de Areas) aparece destacado con una estrella ambar. El header siempre visible muestra un pill resumen: "N prioridades · X/Y con asignacion · Z en 0". Personas con 0 prioridades aparecen con un badge ambar para detectarlas a simple vista.

Filtros

• Estados: multi-select (todos checkeados por default).
• Personas: multi-select de los owners que tienen promesas en la semana.
• Las promesas sin owner siempre son visibles (no se ocultan por filtro de personas).
• Boton Limpiar para resetear.

Kanban: 5 columnas

Orden de izquierda a derecha (camino al objetivo): Pendientes → Prioridad → On Hold → Canceladas → Entregadas. Cada card muestra titulo, descripcion (si tiene), avatares apilados de los owners, y un badge naranja x N si fue movida.

Acciones por card (al hover)

• Editar - abre el modal con todos los campos.
• Deshacer movimiento (violeta) - solo si la promesa proviene de un movimiento anterior; restaura la promesa a su semana original.
• Mover a proxima semana (celeste) - solo si NO estas en la ultima semana del sprint.
• Mover al proximo sprint (naranja) - solo si hay sprint siguiente creado.
• Eliminar - borra la promesa sin penalizar puntos.

Drag-and-drop entre columnas

Podes arrastrar una card de un estado a otro para cambiar su estado. Las promesas movidas (ghost) no se pueden arrastrar.

Mover una promesa: copia + ghost

Cuando moves una promesa (sea a la proxima semana o al proximo sprint), el sistema:

1. Marca la promesa original como movida (ghost). Queda visible en su semana original como historico, en gris rayado, no editable, con un badge naranja "MOVIDA" y boton "Deshacer".
2. Crea una copia activa en la semana destino, con el mismo titulo, descripcion, owners y estado, e incrementa VecesMovida.
3. Cada movimiento penaliza al owner con -2 puntos (igual que cancelarla).

Esto permite, al pararse en una semana pasada, ver donde "murio" cada tarea que se arrastro.

Deshacer un movimiento

Boton de undo violeta disponible tanto en la copia activa como en el ghost. Borra la copia y reactiva el ghost. Si la copia ya fue movida nuevamente (cadena de movimientos), bloquea con mensaje claro: hay que deshacer los movimientos posteriores primero.

Multi-owner

Una promesa puede tener 0, 1 o varios owners. En el modal de edicion, el campo Owners es un multi-select con buscador (Tom Select). Si una promesa tiene varios owners, suma/resta puntos a todos por igual y aparece en la card de cada uno en el panel personal.

Mis Promesas del Sprint (panel derecho)

Espejo personal por persona, ordenado alfabeticamente (no es ranking). Para cada persona muestra:

• Avatar + nombre.
• Contadores rapidos: ✓ N entregadas, ✗ N falladas, ○ N en curso.
• Badge de salud personal (sin comparar con otros):
  • verde "Cumpliendo" - >=80% cumplidas.
  • ambar "Atencion" - 50-79%.
  • rojo "Bajo cumplimiento" - menos de 50%.
  • gris "En curso" - aun nada cerrado.
• Listado de sus promesas con icono por estado y titulo (click para editar, incluso de otras semanas del sprint).

Calculo de salud y puntos

Solo cuentan las promesas con semana ya vencida (hoy es sabado o despues del viernes de esa semana). Las activas o futuras quedan "en curso".

• Entregada: +10, cuenta como cumplida.
• OnHold: 0, no penaliza ni cuenta como falla (decision externa).
• Cancelada: -2, cuenta como falla.
• Pendiente / Prioridad con semana vencida: -2, cuenta como falla (no entregaste el compromiso).
• Pendiente / Prioridad de semana actual o futura: 0, "en curso".
• Movida: -2 por cada movimiento, acumula con el resto.

Recordatorio flotante al loguearse

Si la persona logueada es owner de alguna promesa Pendiente o Prioridad para la semana calendario actual, aparece un toast en la esquina inferior derecha con la lista. Se puede cerrar con la X; reaparece en el siguiente login o pasadas 24 horas (si la sesion queda viva). Para que esto funcione, la persona tiene que tener cargado su email Microsoft 365 en el ABM de Personas (ver seccion 5).

Todas las acciones (crear, editar, mover, deshacer, eliminar, drag-and-drop) actualizan el contenido via AJAX, sin recargar la pagina entera.

Herramientas: Pre-planning

Tablero compartido para postular y priorizar candidatos al proximo sprint. Pensado para una instancia donde una persona comparte pantalla y el resto del equipo discute en vivo qué entra y qué no. Se accede desde Herramientas → Pre-planning en el menu lateral.

Concepto

• Cada area de la empresa (Delivery, Soporte, Comercial, Tecnologia, Otras) postula candidatos al sprint.
• Los candidatos pueden tener un work item de Azure DevOps asociado (importado por ID/URL o por query) o ser items manuales.
• Entre todos arrastran al panel inferior los que entran al sprint, en orden de prioridad.
• El header muestra siempre el ancho de banda disponible del sprint y cuanto consumen los candidatos seleccionados.

Header con sprint y capacidad

• Selector de sprint arriba a la derecha (default: sprint siguiente al actual).
• Pill con el numero de sprint y rango Mon-Fri en espanol.
• Barra de capacidad con: horas totales del sprint, horas reservadas (Soporte+Estabilizacion+AdHoc del simulador), horas libres y horas candidateadas. Semaforo verde si entra, ambar si esta cerca, rojo si excede.

Pool por area (5 columnas)

Cada area tiene su propia columna con color distintivo (Delivery azul, Soporte rojo, Comercial verde, Tecnologia violeta, Otras gris). Cada candidato es una card con: titulo, area, horas estimadas, link al work item de Azure DevOps si aplica.

Acciones por card

• Click sobre card → spotlight (resalta para que la sala mire lo mismo durante la discusion).
• Doble click → modal de edicion.
• Boton lapiz → editar; boton flecha → postular al sprint directamente sin drag.
• Si tiene WI: boton link abre el work item en pestaña nueva (para revisar contexto durante la planning).

Crear candidato manual

Boton + Nuevo candidato (atajo Ctrl + N). Modal con titulo, area, horas estimadas opcional y descripcion. Solo el titulo es obligatorio.

Importar de Azure DevOps

• Importar WI (atajo Ctrl + I): pegas el ID numerico o la URL completa del work item. Trae titulo, tipo, estado, descripcion y estimacion original.
• Importar Query: pegas el GUID o URL de una query guardada en Azure DevOps. Trae hasta 100 work items en bloque, ignora los duplicados ya presentes.

Si Azure DevOps no esta configurado en este ambiente (PAT en appsettings), los botones de import quedan ocultos pero podes seguir creando candidatos manuales.

Drag-and-drop

• De cualquier columna del pool a otra columna del pool → cambia el area de origen.
• De cualquier columna del pool al panel inferior Priorizados → lo postula al sprint.
• Dentro del panel Priorizados → reordena la prioridad (rank 1, 2, 3...).
• Doble click sobre una card priorizada → la saca de prioridades y vuelve al pool.
• Las cards priorizadas quedan tambien marcadas como atenuadas en su columna del pool, asi nunca se pierde de vista que esa area aporto este item.

UX para "una persona comparte pantalla"

• Cards grandes y legibles a varios metros de distancia.
• Spotlight al click para focalizar la atencion de la sala en una card especifica.
• Atajos de teclado para no usar mouse (Ctrl+N, Ctrl+I).
• Areas con colores fuertes distinguibles a primera vista.

Histórico

Cada pre-planning queda guardado por sprint y se accede en cualquier momento desde el selector de sprint del header (lista los 15 sprints más cercanos). Los candidatos quedan persistidos para consulta futura. El campo EstadoFinal está reservado para tracking posterior (Completado / Cancelado / Recandidateado / etc.).

Refresco AJAX

Todas las acciones (crear / editar / eliminar candidato, importar, drag-drop, postular al sprint, crear batalla) actualizan el contenido del bloque #pp-content-area sin recargar la página entera, evitando flash visual.

Batalla — votación anónima en tiempo real

Cuando en la instancia no se logra acuerdo sobre la prioridad relativa de varios candidatos, el presenter dispara una batalla: postula 2+ candidatos, define una duración (10–600 s) y opcionalmente un nombre. El sistema genera una URL pública corta (/Batalla/{slug}) y muestra un panel "presenter" en una pestaña aparte.

Mecánica

1. El presenter inicia la batalla con el botón "Iniciar". El estado pasa a "EnCurso" pero hay un countdown de preparación de 5 segundos antes de habilitar el voto, para que los participantes alcancen a entrar al URL.
2. Los votantes acceden al URL público (no requiere login), ingresan su nombre (validación: único por batalla, case-insensitive), y reciben un token de sesión via cookie HttpOnly + localStorage.
3. Cuando llega FechaInicio, los votantes pueden arrastrar los candidatos para ordenarlos del 1 al N (1° = favorito).
4. Al confirmar el voto, se asignan puntos: 1° = N pts, 2° = N-1, ..., último = 1. Cada votante puede votar una sola vez (cookie + nombre único).
5. El panel presenter muestra en tiempo real (polling 1.5 s):
   • Pista de carrera con barra animada por candidato (gana el de más puntos).
   • Lista de votantes con estado: amarillo "conectado" / verde "votó".
   • Estadísticas: conectados / votaron / pendientes.
   • Alerta ámbar si una IP entra con varios nombres (sospecha de duplicado).
   • Timer regresivo grande tipo videojuego.
6. Cuando se cumple el tiempo (o el presenter cierra manualmente) aparece el podio con oro/plata/bronce. Cada lugar tiene un botón "Postular al sprint" que marca a ese candidato como seleccionado en el pre-planning.

Anti-fraude (capas)

• Token de sesión (cookie HttpOnly + localStorage): identifica al votante. No depende de IP.
• Nombre único por batalla: case-insensitive trim. Si "Juan" ya entró, otro tipear "JUAN " falla.
• IP solo informativa, no bloqueante (oficinas con NAT comparten IP). Si una IP aparece con varios nombres, badge ⚠ visible al presenter pero no bloquea.

Histórico de batallas

Cada batalla queda asociada al pre-planning. En la pantalla principal aparece un listado con chips (estado, duración, fecha) y link directo al panel presenter. Permite revisitar resultados de batallas pasadas.

19. Reportes

TeamOrbit incluye 8 reportes predefinidos para analisis de capacidad, cumplimiento, productividad y tendencias. Todos los reportes se pueden imprimir o exportar a PDF usando el boton del navegador.

19.1 Resumen de Capacidad

Unidad: Sprint. Filtro: Seleccionar sprint.

Muestra la capacidad total del equipo vs. la capacidad comprometida, desglosada por area y por tipo de proyecto.

• Tabla por area: capacidad total, horas DD, horas OT, horas Roadmap, horas reservas, total comprometido, libre.
• Grafica de barras apiladas por area.
• Resumen general: capacidad total, comprometida, libre, % comprometido.

19.2 Cumplimiento de Horas

Unidad: Sprint. Filtro: Seleccionar sprint.

Compara las horas esperadas vs. las horas realmente registradas por cada persona del equipo.

Las horas esperadas se calculan como: horas netas/dia (del snapshot si el sprint esta cerrado, o actuales si esta activo) x dias habiles del sprint.

19.3 Soporte Dev

Unidad: Sprint. Filtro: Seleccionar sprint.

Detalle de todas las horas de soporte registradas durante el sprint:

• Horas por categoria.
• Horas por persona.
• Conteo de incidencias.
• Porcentaje de bien/mal elevadas con detalle de motivos.

19.4 DD Mensual

Unidad: Mes (excepcion — es el unico reporte mensual, porque es la unidad de facturacion del cliente). Filtro: Seleccionar anio y mes.

Reporte orientado al cliente que muestra el consumo mensual de horas DD por contrato:

• Por cada contrato: horas contratadas, horas consumidas, % consumo.
• Desglose por proyecto dentro del contrato.
• Detalle de horas registradas: fecha, persona, horas, descripcion.

19.5 OT Avance

Filtro: Seleccionar OT o ver todas las activas.

Reporte de avance de ordenes de trabajo:

• Estado general de la OT y semaforo.
• Progreso de fases (cual esta activa, cuales completadas).
• Horas estimadas vs. reales por area.
• Challenges vinculados con su estado.
• Desvio total: horas reales vs. estimacion actual.

19.6 Cumplimiento y Distribucion

Acceso: Reportes → "Cumplimiento y Distribucion".

Este es el reporte mas potente para validar si el equipo esta ejecutando lo que se planeo, no solo en cantidad de horas sino tambien en la distribucion de la carga entre proyectos y areas.

Filtros

• Por Sprint (default): seleccionar cualquier sprint. Si el sprint esta en curso, el "planificado" se prorratea por dias transcurridos para responder "voy en linea a este punto del sprint?".
• Por Rango de Fechas: definir desde-hasta arbitrario. Util para analizar periodos que cruzan multiples sprints o meses.

KPIs principales

Tres niveles de distribucion

1. Por Tipo — Barras agrupadas comparando DD, OT, Roadmap, Soporte, Estabilizacion. Permite ver si la mezcla de tipos respeta lo planeado.
2. Por Proyecto — Dos doughnut comparativos lado a lado: distribucion planificada vs distribucion real. Ideal para detectar desbalance: "se planifico 30% para OT-X y se ejecuto 50%".
3. Por Area — Barras horizontales agrupadas que muestran cumplimiento por equipo.

Como leer el reporte

19.7 Tendencia por Sprint

Acceso: Reportes → "Ver Tendencias". No requiere filtros, muestra todos los sprints cerrados.

Este reporte permite visualizar como evoluciona la dedicacion de horas a lo largo del tiempo, sprint tras sprint. Es ideal para identificar tendencias y cambios en la distribucion del trabajo.

Graficas incluidas

1. Evolucion por Tipo de Proyecto — Grafica de barras apiladas mostrando las horas dedicadas a cada tipo (DD, OT, Roadmap, Soporte, Estabilizacion) por sprint. Permite ver si el soporte esta creciendo, si se esta dedicando mas tiempo a roadmap, etc.
2. Capacidad: Consumida vs Disponible — Barras de horas consumidas con linea de capacidad total superpuesta. Muestra la brecha entre capacidad y consumo real.
3. Evolucion por Area — Barras apiladas por area, mostrando como cada area contribuye al total sprint a sprint.

Tabla de desglose Area x Sprint

Muestra cuantas horas registro cada area en cada sprint, permitiendo comparar la evolucion del esfuerzo por equipo.

19.8 Comparativa de Versiones

Acceso: Reportes → "Comparar Versiones". Muestra todas las versiones que tienen horas de estabilizacion registradas.

Permite comparar el esfuerzo de estabilizacion entre releases para medir si la calidad del producto esta mejorando o empeorando.

Metricas comparadas

Graficas incluidas

1. Horas de Estabilizacion por Version — Barras comparando el esfuerzo total.
2. Incidencias por Version — Barras comparando la cantidad de bugs.
3. Dias de Estabilizacion — Barras comparando la duracion del periodo.
4. Promedio Horas por Incidencia — Linea de tendencia mostrando la evolucion de la complejidad de los bugs.

Indicadores de tendencia

La tabla comparativa muestra flechas de tendencia respecto a la version anterior:

• Verde hacia abajo — Mejora (menos horas, menos incidencias).
• Rojo hacia arriba — Empeoramiento (mas horas, mas incidencias).

Desglose por Area

Tabla cruzada mostrando cuantas horas dedico cada area a estabilizar cada version. Util para identificar si un area especifica genera mas trabajo de estabilizacion que otras.

20. Asistente AI

El Asistente AI es un chatbot integrado en TeamOrbit, powered by Claude (Anthropic), que tiene acceso en tiempo real a TODA la informacion del sistema. No es un chatbot generico: es un analista que puede responder preguntas complejas sobre capacidad, horas, proyectos, licencias, comparativas entre areas, validar calculos, y explicar paso a paso como se llego a un numero.

Activacion

El asistente requiere dos cosas para funcionar:

Como usarlo

Una vez habilitado, aparece un boton flotante violeta abajo a la derecha de cualquier pantalla. Al hacer clic, se abre el panel del chat.

Tipos de preguntas que puede responder

• Capacidad y carga: "¿Que area tiene mas horas libres este sprint?", "Compara la capacidad de Backend vs Frontend"
• Validacion de calculos: "¿De donde sale el numero 320 de soporte para Canal Web?", "Explicame paso a paso como se calcula la capacidad de Maria"
• Personas y proyectos: "¿Cuantas horas registro Pedro este sprint?", "¿En que proyectos esta trabajando Frontend?"
• Saldos y cumplimiento: "¿Que paso con la OT-123 en el sprint 5?", "¿Que area tiene peor cumplimiento historico?"
• Licencias futuras: "¿Quienes estan de licencia el proximo mes?"
• Comparativas y tendencias: "¿Como evoluciona el soporte sprint a sprint?"

Modo Pantalla (interaccion contextual)

El boton del icono de monitor () en el header del chat activa el modo pantalla. En este modo, la proxima pregunta incluye automaticamente el contexto de lo que estas viendo en la pagina actual: KPIs, graficas Chart.js, tablas y alertas.

Esto permite preguntas como:

• "¿De donde sale el total de la barra azul de la segunda grafica?"
• "¿Por que esta tabla muestra 500 horas en QA?"

El asistente puede señalar elementos en pantalla con un borde violeta y un tooltip, e incluso ofrecer botones numerados si necesita desambiguar a que elemento te referis.

Conocimiento del sistema

El asistente conoce:

• Datos en tiempo real: personas, areas, roles, clientes, contratos DD, OTs, roadmaps, challenges, versiones, sprints, registros de horas, licencias, feriados, reservas y snapshots historicos.
• Formulas exactas del sistema: 17 formulas documentadas que el bot usa para validar y explicar cualquier numero. Ver capitulo "Formulas y Calculos del Sistema".
• Reglas del dominio: nunca cuenta personas para medir capacidad (siempre horas), no inventa datos, rechaza preguntas fuera del dominio TeamOrbit.

Artifacts (dashboards HTML generados por el bot)

Cuando el bot genera un artifact HTML (por ejemplo, un dashboard resumen o una comparativa entre áreas), el panel donde se renderiza es angosto (columna del chat). Los artifacts ahora tienen scroll horizontal automático y layouts responsive, para que grids amplios, steppers con muchas fases o tablas con muchas columnas no se corten visualmente. Esto aplica a cualquier artifact HTML devuelto por el asistente.

Limitaciones

• El historial de chat se mantiene por usuario y se borra a las 30 minutos de inactividad.
• Cada pregunta tiene un limite de 500 caracteres.
• No tiene acceso a sistemas externos (ej: Azure DevOps, calendarios, Slack).
• Si una pregunta es ambigua, el bot puede pedir mas contexto antes de responder.

20b. Conectar Claude a TeamOrbit (MCP)

Ademas del asistente que vive dentro de TeamOrbit, podes conectar Claude Desktop o Claude Code directamente a tus datos del equipo a traves del protocolo MCP (Model Context Protocol). Eso te permite tener conversaciones con Claude que ya conocen tu sprint, tus horas y tus proyectos, y registrar horas desde Claude sin abrir la web.

¿Que podes hacer una vez conectado?

El MCP expone las mismas operaciones que la app web. Si lo podes hacer desde la UI, lo podes hacer por Claude.

Identidad y contexto

Personas, areas y equipo

Proyectos y clientes

Registro de horas

Reportes y dashboards

Lo mismo que ves en las páginas de Dashboard, SoporteDev, AdHoc, Organigrama, Roadmaps, Reservas y Versiones — accesible por Claude para que arme resúmenes, comparativas o exports.

Mantenimiento del sistema (crear/editar/eliminar)

Todas estas escrituras son paridad con la web — lo que un usuario puede hacer desde la UI lo puede pedir por Claude.

Pre-requisitos

• Claude Desktop instalado (descarga desde claude.ai/download) o Claude Code CLI.
• Node.js v18+ instalado. Para verificar, en una terminal: node --version. Si no tenes, bajalo de nodejs.org.
• VPN corporativa activa si vas a usar el ambiente productivo (teamorbit-mcp.int.prod.bankingly.com). Para desarrollo local no hace falta.
• Tu Usuario de TeamOrbit linkeado a una Persona (si registras horas, tu Usuario debe tener PersonaId).

Paso 1 — Generar tu token personal

Paso 2 — Configurar Claude Desktop

%APPDATA%\Claude

{
  "mcpServers": {
    "teamorbit": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "mcp-remote",
        "http://teamorbit-mcp.int.prod.bankingly.com/mcp",
        "--header",
        "Authorization: Bearer tor_TU_TOKEN"
      ]
    }
  }
}

Paso 3 — Verificar que cargo

Hay tres formas, de la mas rapida a la mas definitiva:

Opcion A — Preguntarle directo a Claude

En una conversacion nueva escribi:

Usa la tool me del MCP teamorbit

Si funciona, Claude responde con tus datos:

Opcion B — En la UI del input

Al lado del cuadro donde escribis los mensajes hay un icono de tools o conectores. Si MCP cargo bien, vas a ver teamorbit listado con sus herramientas disponibles.

Opcion C — Settings → Developer

En el menu de configuracion de Claude Desktop, buscar la seccion Developer o Servidores MCP. Debe aparecer teamorbit con estado Connected.

Paso 4 — Empezar a usarlo

Algunos ejemplos de cosas que podes pedirle a Claude una vez conectado:

Claude va a usar las tools necesarias por debajo, va a preguntarte ante ambiguedades ("¿cual proyecto del cliente XYZ?") y va a pedirte confirmacion antes de borrar registros.

Vigencia y renovacion del token

• Por default los tokens duran 90 dias.
• Cuando se acerca la fecha de vencimiento, la pantalla de Mis tokens te avisa.
• Para renovar: simplemente crea uno nuevo con la misma pantalla, pega el nuevo valor en el claude_desktop_config.json y reinicia Claude Desktop. El viejo lo podes dejar vencer o revocarlo a mano.
• Si tu cuenta de Usuario se desactiva (ej. dejas la empresa), todos tus tokens dejan de funcionar automaticamente.

Auditoria

Toda accion de escritura via MCP queda registrada en el log de auditoria del sistema, con el sufijo [MCP] en el nombre de usuario para distinguirla de las acciones hechas por la web. Los admins pueden auditarlo en Usuarios → Actividad.

Troubleshooting

Si seguis con problemas, mira el log de Claude Desktop en %APPDATA%\Claude\logs\mcp-server-teamorbit.log — tiene el detalle exacto de lo que paso al iniciar la integracion.

21. Usuarios

Gestion de cuentas de acceso al sistema. Solo visible para usuarios con rol Admin.

Crear un usuario

Editar un usuario

Se pueden modificar todos los campos excepto el nombre de usuario. La contrasena solo se actualiza si se ingresa un nuevo valor; si se deja en blanco, se conserva la anterior.

Desactivar un usuario

En lugar de eliminar, los usuarios se desactivan (soft delete). Un usuario desactivado no puede iniciar sesion pero sus datos historicos se conservan. Se puede reactivar si es necesario.

Log de actividad

Cada usuario tiene un log de actividad que registra todas sus acciones en el sistema:

• Login y logout.
• Creacion, edicion y eliminacion de entidades (personas, OTs, contratos, etc.).
• Avances de fase, cambios de estado.
• IP de origen y URL accedida.
• Valores antes y despues de cada cambio (formato JSON).

Auto-provisionamiento con Microsoft 365

Cuando un usuario inicia sesion por primera vez con su cuenta de Microsoft 365 (Entra ID), el sistema crea automaticamente una cuenta de usuario con:

• Nombre de usuario: El email de Microsoft.
• Nombre completo: El nombre del perfil de Microsoft.
• Rol: Lider (por defecto).
• Entra Object ID: Identificador unico de Microsoft para futuras sesiones.
• Persona vinculada: Ninguna (un admin debe vincularla manualmente).

Presentaciones de Avances

Funcionalidad que genera presentaciones PowerPoint (PPTX) profesionales usando Inteligencia Artificial (Claude de Anthropic). Ideal para los informes mensuales de avance por area que se presentan al resto de la empresa.

Como generar una presentacion

1. Ir a Presentaciones en el menu lateral.
2. Seleccionar el Template (define el estilo, colores y prompt de IA).
3. Definir el periodo (desde - hasta).
4. Seleccionar las areas a incluir (una, varias o todas).
5. Presionar Generar Presentacion. La IA analizara los datos del periodo y generara las slides (20-40 segundos).
6. Revisar el preview y presionar Descargar PPTX.

Templates

Desde Gestionar Templates se pueden crear y editar templates de presentacion. Cada template incluye:

Datos incluidos

La IA recibe automaticamente toda la informacion del periodo seleccionado por area:

• Ordenes de Trabajo (OTs): horas registradas, fases, avance, detalle de tareas.
• Dedicacion Directa (DD): horas por proyecto y cliente.
• Roadmap: avance de iniciativas internas y tareas.
• Soporte: horas por categoria.
• Estabilizacion: horas por version.
• Ad Hoc: trabajo no planificado.

Historial

Cada presentacion generada se guarda en el historial. Se puede recargar y descargar nuevamente desde la tabla de historial sin volver a llamar a la IA.

22. Configuracion

Pantalla de configuracion global del sistema. Se organiza en varias pestañas.

Pestana: Configuracion General

Pestana: Feriados

Gestion de dias feriados que se descuentan del calculo de dias habiles.

Los feriados impactan en:

• Calculo de dias habiles por sprint — Menos dias habiles = menos capacidad total.
• Calculo de dias habiles por mes — Afecta la prorracion de horas DD al sprint.
• Calculo de horas esperadas por persona — Dias feriados no se cuentan como dias laborables.

Pestana: Tipos de Licencia

Gestion de los tipos de licencia que se pueden asignar a las personas (Vacaciones, Licencia Medica, Maternidad/Paternidad, etc.).

Las licencias asignadas a personas descuentan dias de su capacidad durante el periodo de la licencia.

Pestana: Roles de Capacidad

Permite excluir roles especificos del calculo de capacidad. Util para roles que no aportan horas a proyectos (ej: Director, Practicante de observacion).

Las personas que tengan SOLO roles excluidos no se cuentan en la capacidad ni aparecen en las graficas. Si tienen al menos un rol contabilizable, se incluyen normalmente.

Pestana: Asistente AI

Toggle para habilitar/deshabilitar el chatbot del Asistente AI globalmente. La API Key se configura en appsettings.json (no en la UI por seguridad).

23. Formulas y Calculos del Sistema

Esta seccion documenta las formulas que TeamOrbit usa internamente para calcular capacidad, distribucion de horas, reservas y cumplimiento. Sirve como referencia para validar manualmente cualquier numero del sistema.

1. Horas diarias de una persona

Brutas (sin overhead):

• Carga "Completo" → HorasPorDia global (default 7)
• Carga "MedioTiempo" → HorasPorDia / 2
• Carga "Personalizado" → Persona.HorasDiarias (valor custom)

Netas (descontando overhead):

HorasNetas = HorasBrutas × (100 - PorcentajeOverhead) / 100

Ejemplo: persona Completo con 20% overhead → 7 × 0.80 = 5.6 hs/dia netas.

2. Dias habiles

Dias entre FechaInicio y FechaFin del periodo, excluyendo:

• Sabados y domingos
• Feriados configurados
• Para una persona especifica: licencias de dia completo de esa persona

3. Capacidad de una persona en el sprint

CapacidadPersonaSprint = HorasNetas × DiasHabilesBrutosPersona

Ejemplo: 5.6 hs/dia × 15 dias = 84 hs en el sprint.

4. Capacidad de un area

CapacidadArea = Σ CapacidadPersonaSprint (de todas las personas del area, principal o secundaria).

Una persona que esta en multiples areas se cuenta en cada una de ellas.

5. Horas de licencia

• Dia completo: DiasHabiles × HorasNetas de la persona
• Parcial: CantidadHoras del registro (si el dia es habil y esta dentro del periodo)

Se usan NETAS porque la licencia representa lo que la persona NO aporta a proyectos.

6. Horas DD proporcionales al sprint

Para cada mes que toca el sprint:

HorasDelMes = (DiasSprintEnMes / DiasHabilesTotalesMes) × HorasMensuales

Luego: HorasDDSprint = Σ HorasDelMes de cada mes que toca el sprint.

7. DD distribuido por area

HorasDDArea = HorasDDSprint × PorcentajeAreaContrato / 100

Si hay multiples contratos DD activos, se suman.

8. Horas OT por area (estimacion prorrateada, sin arrastre)

1. HorasNetas = EstimacionArea - Challenges
2. SprintsAbarcados = cantidad de sprints futuros hasta FechaEntregaActual
3. HorasOTSprint = HorasNetas / SprintsAbarcados

Las horas no ejecutadas NO se arrastran al sprint siguiente. El historico de saldos permite ver atrasos/adelantos.

9. Horas Roadmap por area (sin arrastre)

HorasRoadmapSprint = EstimacionArea / SprintsAbarcados

Igual que OT pero sin descuento de challenges. Los Roadmaps son "horas deseadas": si no se ejecutan, se pierden.

10. Reservas Soporte y Estabilizacion

1. CapacidadBrutaGlobal = Σ (HorasBrutas × DiasBrutos) de TODAS las personas
2. HorasReservadas = CapacidadBrutaGlobal × PorcentajeGlobal / 100
3. HorasReservaArea = HorasReservadas × PorcentajeDistribucionArea / 100

Se usan BRUTAS porque las reservas son politicas globales sobre la jornada completa, no afectadas por overhead individual.

11. Horas libres de un area

HorasLibre = CapacidadArea - DD - OT - Roadmap - Soporte - Estab - Licencias

Si es negativo, se muestra como 0 (area sobreasignada).

12. Porcentaje de uso de un area

PctUso = (DD + OT + Roadmap + Soporte + Estab + Licencias) / CapacidadArea × 100

• > 90% = alerta de saturacion (amarillo/naranja)
• > 100% = area sobreasignada (rojo)

13. Saldo OT por sprint

Al cerrar un sprint:

• HorasPlanificadas = HorasNetas / SprintsAbarcados (lo que "deberia" haberse ejecutado)
• HorasEjecutadas = horas reales registradas en el sprint para esa OT y esa area
• Saldo = HorasPlanificadas - HorasEjecutadas

El cumplimiento se mide como: Cumplimiento% = HorasEjecutadas / HorasPlanificadas × 100

14. Cumplimiento y Distribucion (rango arbitrario)

Para sprint en curso: planificado prorrateado por dias transcurridos.

Para rango arbitrario: suma de las porciones de cada tipo que tocan el rango (DD por dias del mes, OT/Roadmap por sprint share, Soporte/Estab por % del periodo).

24. Glosario