Mise en Place para Gerentes de Proyectos TI
🖥️ Mise en Place para Gerentes de Proyectos TI
Cómo la disciplina de una cocina de alta gama puede transformar tu próximo release
🍲 El día que un chef me enseñó Scrum
En pleno despliegue de un sistema de Nómina en la nube (de esos que siempre vienen “para el viernes”), se me ocurrió relajarme viendo The Bear. Mala idea: la serie es una olla de presión — una cocina donde cada segundo cuenta y cualquier descuido acaba en caos.
Pero algo me atrapó: la obsesión del equipo por mise en place — todo en su lugar.
Apagué la tele y caí en cuenta:
Eso es exactamente lo que le falta a mi backlog.
🛠️ La cocina y el sprint: similitudes que no ves hasta que arde el aceite
| Cocina profesional | Proyecto TI |
|---|---|
| Mise en place: ingredientes medidos, cuchillos afilados. | Kick‑off sólido: alcance claro, historias de usuario pulidas. |
| Chef de partie con roles definidos. | Squad con responsabilidades y RACI visibles. |
| “Sí, chef” → comunicación concisa bajo presión. | Stand‑ups de 15 min → bloqueos fuera, foco adentro. |
| Degustación previa antes de servicio. | Sprint Review con demo a stakeholders reales. |
| Limpieza y retro al cierre. | Sprint Retrospective y lecciones aprendidas accionables. |
🚀 Receta de “mise en place” para tu próximo proyecto
-
Prep‑work financiero
-
Costo del sprint ≠ horas hombre; incluye licencias, entornos, soporte y deuda técnica.
-
¿No hay business case? No hay cocina.
-
-
Ingrediente visible, error evitable
-
Historias en Definition of Ready: criterios de aceptación claros, datos de prueba listos.
-
Evitas “¡pero faltaba la salsa!” a media UAT.
-
-
El expediter del restaurante = tu Product Owner
-
Quien grita más fuerte NO define la prioridad. Lo hace el valor de negocio medido.
-
Roadmap visible, WIP limitado.
-
-
Plan B es parte del plan A
-
¿Servidor on‑prem? Réplica en la nube.
-
¿Microservicio crítico? Chaos Testing antes de la madrugada del Go‑Live.
-
-
Respeto al rol, presión controlada
-
El Dev no interrumpe al QA cambiando specs el Día‑4.
-
El Scrum Master protege el flujo como el chef expeditor protege la salida de platos.
-
⚠️ Lección bíblica (sin ser iglesia):
“Si el hacha está sin afilar, se necesita más fuerza; la sabiduría logra el éxito”
— Eclesiastés 10:10
Traducción para TI: “No afiles el código el día del deploy; afila el proceso antes del sprint.”
🧠 Moraleja: Cada commit cuenta
-
Preparar > Parchear.
-
Prevenir > Apagar fuegos.
-
Procesar > Improvise‑ar.
La próxima vez que tu jefe pida “solo un cambiecito” a las 5:30 p.m., piensa en la cocina: el restaurante abre, los clientes llegan y… si no hiciste tu mise en place, cada segundo te quemará más.
¿Listo para servir tu proyecto al punto exacto?
Afilemos cuchillos, afinemos sprint, y a cocinar valor.
✅CHECKLIST PMO – MISE EN PLACE PARA PROYECTOS TI
🔹 FASE 1: INICIO / KICK-OFF
Antes de comenzar, asegúrate de tener:
| Ítem | Verificación |
|---|---|
| 🎯 Objetivos del proyecto claros y alineados con estrategia de negocio | ☐ |
| 📌 Alcance definido (no ambiguo) | ☐ |
| 🗺️ Roadmap macro aprobado y visualizado | ☐ |
| 👥 Stakeholders identificados y mapeados (RACI) | ☐ |
| 💰 Presupuesto y recursos aprobados | ☐ |
| 🔐 Accesos, entornos y dependencias técnicas identificadas | ☐ |
| 📁 Documentación base disponible: contrato, SLA, NDA, etc. | ☐ |
🔹 FASE 2: PLANIFICACIÓN
Para iniciar correctamente el desarrollo / ejecución:
| Ítem | Verificación |
|---|---|
| 📦 Backlog inicial curado por el Product Owner | ☐ |
| 🧪 Historias de usuario con criterios de aceptación (DoR) | ☐ |
| 📊 Métricas iniciales establecidas (baseline) | ☐ |
| 🔄 Sprint 0 realizado si aplica (infra, pipeline, automatizaciones) | ☐ |
| 📅 Calendario de sprints / fases compartido | ☐ |
| 🛠️ Herramientas definidas (Jira, Confluence, Teams, etc.) | ☐ |
| 📚 Manual de comunicación y gobierno definido | ☐ |
🔹 FASE 3: EJECUCIÓN
Durante el sprint o fase activa, verifica:
| Ítem | Verificación |
|---|---|
| 🔄 Standups diarios efectivos (15 min, foco, sin desviarse) | ☐ |
| 🛡️ Scrum Master o PM protege el flujo (sin distracciones externas) | ☐ |
| 🧩 Gestión de riesgos activa (heatmap actualizado) | ☐ |
| 🚦 Indicadores de avance (burndown, velocity, KPIs) al día | ☐ |
| 📣 Stakeholders informados (reportes semanales o quincenales) | ☐ |
| 🧠 Decisiones documentadas (no en WhatsApp) | ☐ |
🔹 FASE 4: CIERRE Y APRENDIZAJE
Para cerrar correctamente cada sprint o proyecto:
| Ítem | Verificación |
|---|---|
| 🎉 Sprint Review con demo real y retroalimentación capturada | ☐ |
| 🧠 Retrospective realizada con acciones concretas | ☐ |
| 📈 Indicadores finales comparados contra baseline | ☐ |
| 📁 Documentación archivada (tech docs, lessons learned, etc.) | ☐ |
| 🤝 Cierre formal con cliente interno / externo | ☐ |
| 🧾 Lecciones aprendidas compartidas en comunidad / COE | ☐ |
🔹 BONUS: EVALUACIÓN PMO
Cada trimestre o al cierre del proyecto, reflexiona:
| Pregunta | ¿Cumplido? |
|---|---|
| ¿Se entregó valor al negocio de forma tangible? | ☐ |
| ¿El equipo creció en madurez y autonomía? | ☐ |
| ¿Hubo mejora continua del proceso y herramientas? | ☐ |
| ¿Documentamos lo suficiente para escalar o replicar? | ☐ |
Comentarios
Publicar un comentario