Desglose de Tareas y Asignación de Trabajo

El Arte de Descomponer las Cosas

🔄 Repaso rápido: En la lección anterior, exploramos planificación y alcance de proyectos con IA. Ahora construyamos sobre esa base.

¿Conoces esa sensación cuando un proyecto parece abrumador? ¿Cuando el entregable es tan grande y complejo que no sabes por dónde empezar?

Esa sensación es información. Te está diciendo que no has desglosado el trabajo lo suficiente.

Un plan que dice “Construir nuevo portal de clientes” es inútil. Un plan que lo descompone a “Crear wireframe de login (4h), implementar API de autenticación (6h), escribir flujo de reset de contraseña (3h)” es accionable.

La diferencia entre un manager que tiene el control y uno que se está ahogando es usualmente la calidad de su desglose de tareas. La IA hace esta descomposición más rápida, más completa y más difícil de equivocar.

Work Breakdown Structure (WBS)

Un WBS es la columna vertebral de la ejecución del proyecto:

“Crea un WBS para este proyecto: PROYECTO: [nombre y descripción]. ENTREGABLES: [qué hay que producir]. EQUIPO: [roles y skills disponibles]. TIMELINE: [deadline general]. Genera un WBS jerárquico: NIVEL 1 fases mayores (3-6), NIVEL 2 entregables por fase (2-5), NIVEL 3 paquetes de trabajo (grupos de tareas relacionadas), NIVEL 4 tareas individuales. Para cada tarea individual: descripción clara orientada a acción, esfuerzo estimado (horas), skill/rol requerido, dependencias, definición de done. REGLAS: toda tarea 2-8 horas, incluir tareas que se olvidan (testing, documentación, ciclos de revisión, deployment, handoffs), incluir buffer de contingencia (10-20%).”

Ejemplo: Desglose de Rediseño Web

Proyecto: Rediseñar sitio web de marketing Equipo: 1 diseñador, 2 developers, 1 copywriter, 1 PM Timeline: 8 semanas

FASE 1: Discovery y Planificación (Semana 1-2)
├── 1.1 Auditoría del sitio actual
│   ├── Inventario de contenido (4h, copywriter)
│   ├── Revisión de analytics (3h, PM)
│   ├── Auditoría técnica (4h, developer)
│   └── Análisis competitivo (4h, diseñador)
├── 1.2 Definir requerimientos
│   ├── Entrevistas con stakeholders (6h, PM)
│   ├── Documento de requerimientos de usuario (4h, PM)
│   └── Documento de requerimientos técnicos (3h, developer)
└── 1.3 Finalización del plan
    ├── Timeline detallado (3h, PM)
    └── Kickoff meeting (3h, PM)

FASE 2: Diseño (Semana 2-4)
├── 2.1 Arquitectura de información
│   ├── Sitemap (4h, diseñador)
│   └── Estructura de navegación (3h, diseñador)
├── 2.2 Diseño visual
│   ├── Moodboard (4h, diseñador)
│   ├── Homepage (8h, diseñador)
│   ├── Templates de páginas interiores (6h, diseñador)
│   └── Diseños responsive (6h, diseñador)
└── ...

Nota lo que se incluye y muchos PMs olvidan: ciclos de revisión, tiempo de revisiones, reuniones de aprobación, tareas de deployment y buffer.

El Prompt “¿Qué Estamos Olvidando?”

Después de generar un WBS, pide a la IA que lo audite:

“Aquí está mi WBS del proyecto: [PEGA WBS]. Revísalo e identifica: 1) TAREAS FALTANTES (testing, documentación, training, migración de datos, ciclos de aprobación, deployment, monitoreo post-lanzamiento, plan de rollback), 2) TAREAS SUBESTIMADAS (cuáles probablemente toman más de lo estimado y por qué), 3) DEPENDENCIAS FALTANTES, 4) ÁREAS DE RIESGO (tareas con mayor riesgo de retraso), 5) STAKEHOLDERS OLVIDADOS (personas que necesitan revisar o aprobar).”

Este paso de “audita el plan” captura el 80% de las sorpresas que te pegarían durante la ejecución.

✅ Revisión rápida: Mira tu plan de proyecto actual. Encuentra la tarea más grande. ¿Se puede desglosar más? Si una tarea pasa de 8 horas, casi seguro esconde complejidad.

Estimando Esfuerzo Realísticamente

Las estimaciones de IA son razonables, pero necesitan calibración. Usa el método PERT de tres puntos:

Regla crítica: Siempre valida las estimaciones de IA con la persona que hará el trabajo. Una tarea que la IA estima en 4 horas puede tomarle a tu developer junior 12 horas, o a tu senior 2 horas. El contexto importa.

Priorización: Framework RICE

Cuando tienes más tareas que capacidad, usa RICE:

Score = (Reach × Impact × Confidence) / Effort

• Reach: ¿Cuántos usuarios/stakeholders afectados? (número)
• Impact: ¿Cuánto mejorará el resultado? (3=masivo, 2=alto, 1=medio, 0.5=bajo)
• Confidence: ¿Qué tan seguros estamos? (100%=alta, 80%=media, 50%=baja)
• Effort: Persona-meses para completar

Asignación Efectiva de Trabajo

El desglose de tareas solo es útil si las personas correctas se asignan al trabajo correcto. Genera un plan de asignación que incluya: tabla de asignaciones con razón, análisis de carga de trabajo por semana, cuellos de botella (dónde hay una persona como punto único de falla), y recomendaciones.

Mapeo de Dependencias

Las dependencias determinan tu ruta crítica. Si fallas una, todo el schedule se desliza. Identifica:

• Finish-to-Start (FS): Lo más común — una tarea debe terminar antes de que otra empiece
• Start-to-Start (SS): Dos tareas pueden empezar simultáneamente
• Finish-to-Finish (FF): Dos tareas deben terminar juntas

La cadena más larga de tareas dependientes es tu ruta crítica — las tareas que, si se retrasan, retrasan todo el proyecto.

Ponlo en Práctica

Toma un proyecto en el que estés trabajando y genera un WBS completo. Después corre el prompt “¿Qué Estamos Olvidando?”. Compara lo que la IA encontró con lo que cubre tu plan actual. Identifica al menos tres tareas que necesitan agregarse o desglosarse más.

Conclusiones Clave

• Buenos desgloses de tareas son la diferencia entre tener el control y ahogarse — desglosa todo en tareas de 2-8 horas
• Un WBS descompone proyectos jerárquicamente: fases, entregables, paquetes de trabajo, tareas
• Siempre audita tu WBS con el prompt “¿Qué Estamos Olvidando?”: testing, documentación, ciclos de revisión y deployment se olvidan comúnmente
• Usa estimación de tres puntos (optimista, realista, pesimista) para tareas inciertas
• Valida cada estimación de IA con la persona que realmente hará el trabajo
• Mapea dependencias para encontrar tu ruta crítica — estas son las tareas que no pueden deslizarse

En la Siguiente Lección

En la Lección 4: Gestión de Riesgos y Mitigación, detectaremos problemas antes de que se conviertan en problemas.