Es la tercera semana de un ciclo de lanzamiento de seis semanas y tu equipo de desarrollo de software está bloqueado. El responsable de producto necesita una fecha confirmada para una demostración ante el cliente, el responsable de ingeniería advierte sobre un aumento repentino de defectos y el equipo de QA ya está trabajando en horario nocturno. Dos ingenieros tienen asignadas tres iniciativas cada uno, las rotaciones de soporte a producción los distraen constantemente y el diseñador divide su tiempo entre dos equipos. La decisión pendiente parece sencilla sobre el papel: mantener la fecha y reducir el alcance, mantener el alcance y posponer la fecha, o añadir una capacidad de la que en realidad no se dispone. Cada día de espera aumenta el retrabajo y erosiona la confianza. Este curso te ayuda a desarrollar los hábitos y las herramientas necesarias para superar este bloqueo. Aprenderás a identificar demandas ocultas de recursos en la planificación, a crear un modelo de capacidad que refleje la forma real de trabajar del equipo y a utilizar la IA para generar opciones negociables con las partes interesadas.
La primera señal no es el diagrama de Gantt, sino el patrón de interrupciones. Un ingeniero comienza a desarrollar una funcionalidad, pero debe atender un incidente de gravedad 2 (Sev 2); luego regresa para resolver conflictos de fusión (merge conflicts) y, acto seguido, realiza apresuradamente una revisión de código para otro proyecto porque está bloqueando a un compañero. El hito se retrasa y el equipo intenta compensarlo omitiendo pruebas. Una semana después, aumentan los defectos, el control de calidad (QA) se convierte en un cuello de botella y la versión candidata (release candidate) sufre constantes cambios y retrocesos. El agotamiento (burnout) se manifiesta mediante tiempos de ciclo más largos, traspasos de tareas frágiles y más tiempo dedicado a solicitar actualizaciones de estado que a realizar el trabajo propiamente dicho.
Un error común de los gestores de proyectos (PM) es tratar esto como un problema de ejecución. Es una reacción instintiva lógica, ya que permite convocar más reuniones diarias (stand-ups), endurecer el control en Jira y exigir mayor concentración. Sin embargo, la consecuencia es que se aumenta la carga de coordinación sobre las mismas personas que ya están sobreasignadas. El problema real es que el cronograma exige más horas-hombre —y en las semanas equivocadas— de las que el equipo puede aportar sin comprometer la calidad.
Al asignar personas, se está resolviendo un problema de restricciones, no simplemente rellenando casillas. El alcance es el trabajo prometido. El cronograma es el plazo en el que debe completarse dicho trabajo. La capacidad es la cantidad de horas de trabajo efectivo que el equipo puede aportar cada semana. Las competencias determinan qué personas pueden realizar qué tareas sin asumir riesgos inaceptables. Las suposiciones de disponibilidad son las reglas implícitas —como los turnos de guardia, las reuniones y las solicitudes de servicios compartidos— que reducen la capacidad real.
Antes de decidir una acción, determine qué restricción es la que realmente condiciona su situación: el cronograma, las competencias o la disponibilidad.
Esto es importante porque un mismo síntoma puede tener causas diferentes. En la entrega de software, a menudo predominan las limitaciones de competencias; por ejemplo, cuando solo una persona conoce el flujo de despliegue. En una campaña de marketing, la restricción determinante podría ser el calendario vinculado a eventos externos. En la implementación de operaciones sanitarias, factores de disponibilidad como el tiempo de formación y la cobertura de turnos pueden generar bloqueos, incluso si la plantilla parece suficiente. Tu labor consiste en identificar la restricción y elegir una respuesta que la modifique, en lugar de una que simplemente añada presión.
No puedes equilibrar los recursos hasta saber con qué cuentas realmente. Un modelo de capacidad es tu estimación explícita de las horas semanales utilizables por rol, una vez descontado el tiempo que no contribuye al avance del proyecto. Comienza con las horas nominales. Resta los días de vacaciones y festivos, así como las reuniones y ceremonias fijas. A continuación, aplica un factor de enfoque: el porcentaje del tiempo restante que realmente puede dedicarse a las tareas planificadas del proyecto, teniendo en cuenta las interrupciones y la coordinación. Por último, resta el tiempo dedicado a servicios compartidos, como el soporte a producción o las solicitudes internas ineludibles.
Utiliza la herramienta de creación para elaborar un plan de capacidad para el sprint que incluya las vacaciones y la carga de reuniones de cada rol.