8 min lectura • Guide 709 of 877
Gestionando Solicitudes de Features de Múltiples Stakeholders
Múltiples stakeholders con prioridades competidoras es normal—el caos no tiene que serlo. GitScrum ayuda a gestionar solicitudes de features con formularios de intake, sistemas de scoring y roadmaps transparentes que alinean stakeholders alrededor de prioridades compartidas.
Desafíos de Gestión de Solicitudes
Problemas Comunes
CAOS DE SOLICITUDES DE STAKEHOLDERS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SÍNTOMAS: │
│ • Cada stakeholder piensa que su solicitud es top priority │
│ • Solicitudes llegan por múltiples canales │
│ • Sin criterios claros para qué se construye │
│ • "La rueda que rechina" se prioriza │
│ • Cambios de scope constantes │
│ • Equipo frustrado por prioridades cambiantes │
│ • Stakeholders frustrados por falta de progreso │
│ │
│ CAUSAS RAÍZ: │
│ • Sin proceso formal de intake │
│ • Criterios de priorización poco claros │
│ • Falta de visibilidad en constraints │
│ • Sin entendimiento compartido de capacidad │
│ • Presión política anulando proceso │
│ │
│ IMPACTO: │
│ • Equipo trabaja en cosas incorrectas │
│ • Valor de negocio no maximizado │
│ • Relaciones tensas │
│ • Productividad perdida en cambio de contexto │
│ │
│ SOLUCIÓN: Proceso transparente y consistente │
│ que trata a todos los stakeholders justamente │
└─────────────────────────────────────────────────────────────┘
Proceso de Intake
Formulario de Solicitud
INTAKE DE SOLICITUD DE FEATURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FORMULARIO DE SOLICITUD DE FEATURE │
│ │
│ Solicitante: ___________ Departamento: ___________ │
│ Fecha: ___________ Prioridad solicitada: ___________ │
│ │
│ 1. ¿QUÉ NECESITAS? │
│ [Descripción breve del feature deseado] │
│ ________________________________________________ │
│ │
│ 2. ¿POR QUÉ LO NECESITAS? │
│ [Problema de negocio a resolver] │
│ ________________________________________________ │
│ │
│ 3. ¿QUIÉN SE BENEFICIA? │
│ [Número de usuarios/clientes afectados] │
│ ________________________________________________ │
│ │
│ 4. ¿QUÉ PASA SIN ESTO? │
│ [Impacto de no hacerlo] │
│ ________________________________________________ │
│ │
│ 5. ¿QUÉ TAN URGENTE ES? │
│ ☐ Crítico (impacto de negocio ahora) │
│ ☐ Alto (necesario este trimestre) │
│ ☐ Medio (sería útil) │
│ ☐ Bajo (nice to have) │
│ │
│ 6. ¿HAY ALTERNATIVAS? │
│ [Workarounds usados actualmente] │
│ ________________________________________________ │
│ │
│ 7. ¿CÓMO MEDIREMOS ÉXITO? │
│ [Métricas que mejorarían] │
│ ________________________________________________ │
│ │
│ [Enviar Solicitud] │
└─────────────────────────────────────────────────────────────┘
Canal Único
DISCIPLINA DE CANAL DE SOLICITUDES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ❌ ANTES: Solicitudes Vienen de Todas Partes │
│ │
│ • Email a desarrolladores individuales │
│ • Mensajes de Slack │
│ • Conversaciones de pasillo │
│ • Notas al margen en reuniones │
│ • "¿Puedes solo..." │
│ │
│ RESULTADO: Cosas se pierden, priorización injusta │
│ │
│ ───────────────────────────────────────────────── │
│ │
│ ✅ DESPUÉS: Canal Único de Intake │
│ │
│ Todas las solicitudes → Formulario → Backlog GitScrum │
│ │
│ RESPUESTAS A SOLICITUDES FUERA DE CANAL: │
│ │
│ "¡Gran idea! Por favor envíala a través del formulario │
│ de solicitud de features para que pueda ser evaluada │
│ y priorizada apropiadamente junto con otras solicitudes." │
│ │
│ "Te escucho - para asegurar que no se pierda, │
│ ¿puedes agregarlo al backlog de solicitudes?" │
│ │
│ BENEFICIO: Todo rastreado, nada perdido, │
│ evaluación justa para todas las solicitudes │
└─────────────────────────────────────────────────────────────┘
Priorización
Sistema de Scoring
MODELO DE SCORING PONDERADO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CRITERIOS DE SCORING: │
│ │
│ Impacto de Negocio (35%): │
│ 5 = Impacto mayor en ingresos/costos │
│ 4 = Mejora significativa del negocio │
│ 3 = Mejora moderada │
│ 2 = Mejora menor │
│ 1 = Impacto mínimo │
│ │
│ Usuarios Afectados (25%): │
│ 5 = Todos los usuarios/clientes │
│ 4 = Mayoría de usuarios │
│ 3 = Muchos usuarios │
│ 2 = Algunos usuarios │
│ 1 = Pocos usuarios │
│ │
│ Alineación Estratégica (20%): │
│ 5 = Core del roadmap actual │
│ 4 = Fuertemente alineado con OKRs │
│ 3 = Soporta objetivos │
│ 2 = Débilmente alineado │
│ 1 = No alineado │
│ │
│ Esfuerzo (20% inverso): │
│ 5 = Muy bajo esfuerzo (días) │
│ 4 = Bajo esfuerzo (1-2 semanas) │
│ 3 = Esfuerzo medio (1 mes) │
│ 2 = Alto esfuerzo (2-3 meses) │
│ 1 = Muy alto esfuerzo (3+ meses) │
│ │
│ SCORE FINAL = Suma ponderada │
└─────────────────────────────────────────────────────────────┘
Sesión de Priorización
REUNIÓN DE PRIORIZACIÓN
═══════════════════════
FRECUENCIA: Quincenal o mensual
DURACIÓN: 60-90 minutos
ASISTENTES:
├── Product Owner (facilita)
├── Tech Lead (esfuerzo)
├── Representantes de stakeholders clave
└── UX Lead (impacto usuario)
AGENDA:
─────────────────────────────────────
1. Revisión de nuevas solicitudes (15 min)
├── Presentar cada solicitud nueva
├── Clarificar problema y contexto
└── Responder preguntas
2. Scoring de solicitudes (30 min)
├── Aplicar criterios a cada solicitud
├── Discutir discrepancias
└── Alcanzar consenso en scores
3. Stack ranking (15 min)
├── Ordenar por score
├── Considerar dependencias
└── Ajustar por capacidad
4. Decisiones y comunicación (15 min)
├── Confirmar top prioridades
├── Identificar rechazos con razón
└── Asignar comunicación a stakeholders
OUTPUT:
├── Backlog priorizado actualizado
├── Decisiones documentadas
├── Mensajes de comunicación preparados
└── Próximos pasos claros
Comunicación con Stakeholders
Decir No Efectivamente
FRAMEWORK PARA DECIR NO
═══════════════════════
ESTRUCTURA DE RESPUESTA:
─────────────────────────────────────
1. Reconocer
"Entiendo que [X] es importante para ti y
aprecio que lo hayas traído."
2. Explicar criterios
"Usamos un framework de priorización que
considera impacto de negocio, usuarios
afectados, alineación estratégica y esfuerzo."
3. Mostrar ranking
"Tu solicitud puntuó [X/100], que la coloca
en posición [Y] de [Z] solicitudes actuales."
4. Ofrecer alternativa (si existe)
"Mientras tanto, podrías [alternativa]
que resuelve parte de tu necesidad."
5. Dejar puerta abierta
"Repriorizar si cambian las circunstancias
o si tienes nueva información."
EJEMPLO:
─────────────────────────────────────
"Gracias por solicitar integración con X.
Evaluamos esto contra nuestros criterios y
puntuó 45/100, principalmente porque afecta
a pocos usuarios (~5%). Actualmente tenemos
15 items con score mayor.
Para tu caso de uso, podrías exportar a CSV
y usar la importación manual de X como workaround.
Si la base de usuarios de X crece o tienes
datos adicionales de impacto, estamos abiertos
a reevaluar."
Roadmap Transparente
VISIBILIDAD PARA STAKEHOLDERS
═════════════════════════════
NIVELES DE ROADMAP:
─────────────────────────────────────
1. Vista Pública (todos los stakeholders)
┌─────────────────────────────────────────────────┐
│ Q1 2024 │
│ ├── ✅ Feature A (Completado) │
│ ├── 🔄 Feature B (En desarrollo) │
│ └── 📋 Feature C (Planeado) │
│ │
│ Q2 2024 │
│ ├── 📋 Feature D │
│ └── 📋 Feature E │
│ │
│ Considerando (sin timeline) │
│ ├── Feature F │
│ └── Feature G │
└─────────────────────────────────────────────────┘
2. Vista de Backlog (stakeholders senior)
├── Todas las solicitudes con scores
├── Razones de rechazo
└── Criterios de repriorización
UPDATES REGULARES:
─────────────────────────────────────
├── Email mensual de roadmap
├── Reunión trimestral de planning review
├── Notificación cuando solicitud cambia status
└── Dashboard siempre actualizado en GitScrum
Soluciones Relacionadas con GitScrum
- Gestión de Solicitudes de Clientes
- Priorización de Backlog
- Gestión de Expectativas de Stakeholders
- Comunicación Transparente con Stakeholders
Conclusión
Gestionar solicitudes de múltiples stakeholders requiere un proceso justo, transparente y consistente. GitScrum proporciona las herramientas para centralizar solicitudes, aplicar scoring objetivo, comunicar decisiones claramente y mantener a todos informados del progreso. Al tratar a todos los stakeholders equitativamente con criterios claros, reduces conflictos políticos y construyes las cosas que realmente importan para el negocio.