⚠️
Riesgo crítico detectado: fuga de talento + 3 proyectos bloqueados
El equipo creció 133% en 8 meses (6 → 14 personas). Los canales de comunicación pasaron de 15 a 91. Sin intervención inmediata en estructura y ownership, la probabilidad de perder al dev senior y retrasar el Dashboard v2 es alta.
1
Commander's Intent — Dashboard v2
Framework 1 · Objetivo claro + éxito medible + autonomía de ejecución
Situación
El 68% de nuestros clientes abandona el dashboard actual en los primeros 3 minutos (dato de Mixpanel). El Dashboard v2 es la actualización más demandada en encuestas NPS (score 32 → objetivo 55). Marketing ya tiene campañas programadas para el 28 de julio con 12.000 leads en la lista. No lanzar a tiempo tiene un coste directo de 40.000 € en MRR potencial.
Intent — Estado final deseado
Tener el Dashboard v2 en producción el lunes 28 de julio a las 9:00 CEST, funcionando para el 100% de los clientes activos (320 cuentas), con tiempo de carga inferior a 1,8s y cero errores críticos en las primeras 72h.
El éxito tiene este aspecto
- Time-to-insight: de 4 min → < 45 segundos
- Tiempo de carga: < 1,8 segundos (p95)
- NPS de UI: > 50 (actual: 32)
- Retention a 7 días: > 78% (actual: 61%)
- Cero regresiones en módulo de exportación
- Documentación publicada antes del lanzamiento
- 100% clientes migrados en 48h post-lanzamiento
Restricciones — Lo que NO hacer
No cambiar API pública (clientes con integraciones)
No eliminar vistas de tabla clásica sin flag de opt-out
No usar CDNs externos (clientes enterprise con políticas de red)
No reducir granularidad de datos por debajo de 15 min
No lanzar sin modo oscuro funcional (compromiso del roadmap)
Recursos disponibles
- 3 devs frontend (Clara, Tomás, Javi)
- 1 data scientist para queries optimizadas (Beatriz)
- 1 diseñadora UX dedicada (Elena)
- Entorno de staging con datos anonimizados
- Budget de 3.000 € para herramientas / test users
- Acceso a 12 clientes beta para pruebas
Timeline de hitos
- Sem 1–2: Diseño finalizado + componentes base
- Sem 3: Beta interna funcionando en staging
- Sem 4: Beta con 12 clientes seleccionados
- Sem 5: Fix de bugs críticos + QA exhaustivo
- Sem 6: Lanzamiento producción + monitorización
Owner único del proyecto
Clara Romero (Tech Lead Frontend) — Clara decide cómo el equipo llega al resultado. Marta (CEO) no toma decisiones técnicas durante las 6 semanas. Escalaciones únicamente para: cambios de scope, bloqueos de más de 48h, o riesgo de incumplir restricciones.
2
Diagnóstico de Overhead de Comunicación
Framework 2 · n×(n−1)/2 · Reducción de reuniones y channels
📊 Canales de comunicación: situación real vs. objetivo
15
Canales
Equipo de 6 (hace 8 meses)
→
91
Canales actuales
Equipo de 14 (hoy)
→
28
Canales objetivo
2 subequipos de 5–6 (plan)
Fórmula: n×(n−1)/2. Con 14 personas = 91 canales. Dividiendo en 2 subequipos de 6+8 = 15+28 = 43 canales internos + 1 canal de sincronización entre leads = ~44 canales efectivos (vs. 91 actuales). Reducción del 52%.
| Reunión actual |
Participantes |
Frecuencia |
Problema |
Decisión |
| Standup todo el equipo |
14 personas |
Diaria · 30 min |
3,5h/día de equipo quemadas en status updates |
ELIMINAR |
| Sync de producto semanal |
9 personas |
Semanal · 60 min |
Demasiados asistentes; acaba siendo un show |
REDUCIR a 4 leads |
| Standup subequipo producto |
5 personas |
Diaria · 15 min |
Ninguno — tamaño correcto |
MANTENER |
| Standup subequipo datos |
4 personas |
Diaria · 15 min |
Ninguno — tamaño correcto |
MANTENER |
| Sprint planning |
14 personas |
Quincenal · 90 min |
Demasiado grande; la mitad no añade valor |
DIVIDIR por subequipo |
| Sync de leads cross-equipo |
2 leads |
Semanal · 30 min |
Ninguno — canal de coordinación correcto |
CREAR (nuevo) |
| Reunión de reviews lunes |
8–12 personas |
Semanal · 60 min |
Sin agenda clara; "nos ponemos al día" |
ELIMINAR → Loom async |
| 1:1 manager con cada persona |
2 personas |
Semanal · 30 min |
Ninguno — no recortar jamás |
MANTENER |
Resultado esperado: De ~4h/día en reuniones → 1,5h/día. Son 75 horas semanales recuperadas para el equipo completo (14 personas × 5h = 70h). Equivale a casi 2 devs a tiempo completo en capacidad productiva.
3
Tabla de Ownership — Proyectos Bloqueados
Framework 6 (Bystander Apathy) + Framework 5 (Forcing Functions)
🔵 Tomás Vera — Backend Lead
Plan de migración documentado: esquema, orden de tablas, rollback step-by-step
Deadline: Viernes 19 Jun
⚡ Presentación al equipo el viernes 4 PM
🟣 Beatriz Lora — Data Science
Validar integridad de datos: 3 entornos de staging probados con datos reales anonimizados
Deadline: Miércoles 24 Jun
⚡ Demo en staging obligatoria pre-producción
🔴 Marta Solano — CEO
Aprobar ventana de mantenimiento (domingo 4-6 AM) y comunicar a clientes afectados
Deadline: Lunes 22 Jun
⚡ Email a clientes ya redactado, pendiente de fecha
🟦 Clara Romero — Tech Lead (Owner)
Arquitectura de componentes final + decisión stack (React Query vs SWR)
Deadline: Martes 17 Jun
⚡ Ship-or-kill review quincenal
🟩 Elena Cruz — UX Design
Prototipo Figma navegable de las 5 vistas core. Validado con 3 clientes beta.
Deadline: Viernes 20 Jun
⚡ User test público: grabación compartida el lunes
🟡 Javi Más — Frontend
Pipeline de CI/CD para despliegue en staging automático con cada PR
Deadline: Jueves 26 Jun
⚡ Sin CI/CD = sin merge a main
🔵 Tomás Vera — Backend Lead
Decisión técnica documentada: webhooks vs. polling API. Elegir UNO y justificar con datos de latencia.
Deadline: Miércoles 18 Jun
⚡ Pre-mortem: "¿Por qué fallaría?" — sesión 1h el martes
🟤 Raúl Pérez — Ops
Cuenta en Shopify Partner Center + app draft creada. Acceso para el equipo de dev.
Deadline: Lunes 16 Jun
⚡ Bloqueante para el resto: debe ir primero
🟠 Laura Gil — CS Lead
Identificar 5 clientes para beta cerrada. Recoger requirements reales: qué métricas necesitan de Shopify.
Deadline: Viernes 20 Jun
⚡ Demo con clientes beta programada para sem 4
4
Golden Trifecta — Retención del Dev Senior
Framework 3 + Framework 4 · Earned Regard · Acción inmediata para Marta
🌟
Apreciación genuina
No "buen trabajo". Específico y público.
Marta en el canal #equipo esta semana: "La arquitectura de microservicios que propuso Tomás en febrero nos ahorró replantear el 30% del backend. Es el tipo de decisiones que nos hace escalar bien."
🤝
Cortesía bajo presión
Cuando hay fuego, los líderes se vuelven cortantes. No hacerlo.
Protocolo: cuando haya un bug crítico, el primer mensaje es siempre "¿Qué necesitas de mí para resolverlo?" — no "¿Cuándo estará arreglado?"
💎
Respeto a la expertise
Darle el Commander's Intent, no las instrucciones paso a paso.
Tomás recibe el Commander's Intent de la migración DB y decide cómo ejecutarla. Marta no entra a decidir qué herramienta ni en qué orden. Si pregunta, es para entender, no para corregir.
📈 Impacto esperado del plan a 6 semanas
−52%
Canales de comunicación activos
+75h
Horas semanales recuperadas
3/3
Proyectos con owner y deadline
28 Jul
Fecha objetivo Dashboard v2