Planifique la capacidad antes de sumar desarrolladores

La planificación de capacidad de desarrollo debe identificar dónde espera el trabajo antes de decidir cuántas personas incorporar. Más capacidad de implementación ayuda cuando hay tareas preparadas sin responsable. Puede empeorar la cola si los cambios terminados ya esperan a una sola persona revisora, una decisión de producto o una ventana de publicación.

Empiece por el trabajo en curso, no por la meta anual de contrataciones. Las fechas y notas de bloqueo de algunos tickets recientes suelen ofrecer evidencia suficiente para iniciar la conversación.

Separe esfuerzo de espera

Siga tareas representativas durante aclaración, implementación, revisión, verificación y publicación. Registre el esfuerzo activo separado del tiempo transcurrido. Un ticket abierto durante una semana puede contener poca implementación y varios días esperando respuesta.

La guía de Google sobre velocidad de revisión explica cómo las revisiones lentas afectan el avance del equipo. Para planificar capacidad, la consecuencia práctica es tratar la disponibilidad de revisión como una restricción, sin asumir que cada desarrollador agrega capacidad proporcional de entrega.

Compruebe si una misma persona responde por arquitectura, aprobaciones e incidentes. Un calendario lleno de esas responsabilidades no puede ofrecer también acompañamiento y revisión ilimitados.

Construya un registro con supuestos explícitos

Use horas o unidades comparables que el equipo entienda. No convierta puntos de historia de otro equipo en capacidad propia. Mantenga la incertidumbre en una línea separada, en vez de esconderla dentro de una fecha aparentemente segura.

Antes de asignar nuevas iniciativas, contemple:

• Implementación y verificación planificadas.
• Revisión e integración del trabajo de otros colaboradores.
• Soporte operativo y mantenimiento recurrente.
• Vacaciones y períodos conocidos sin disponibilidad.
• Incorporación, tanto de quien ingresa como del personal que acompaña.
• Una reserva basada en el historial real de interrupciones.

Si no existe ese historial, aclare que la reserva es una suposición y revísela al observar el trabajo. Una solicitud de personal no debería depender de fingir que todas las horas nominales están disponibles para funciones nuevas.

Ejemplo hipotético: falta capacidad de revisión

Considere un período hipotético con 160 horas de ingeniería disponibles. Suponga que soporte requiere 32, las revisiones previstas 24 y acompañar la incorporación 16 horas del equipo existente. Quedan 88 horas antes de asignar implementación nueva. Son cifras ilustrativas, no resultados de 5e Labs ni proporciones recomendadas.

El trabajo preparado exige 120 horas de implementación. Incorporar un ingeniero parece resolver la diferencia de 32 horas. Sin embargo, sus cambios también necesitan revisión y la única persona capacitada ya tiene todo su tiempo asignado.

El equipo puede acotar el primer alcance, preparar otra persona revisora o reducir otros compromisos. Sin alguna de esas decisiones, la incorporación podría generar más ramas terminadas esperando aprobación.

La cuenta no predice una fecha de entrega. Expone una suposición que, de otro modo, quedaría oculta.

Elija una condición de contratación verificable

Sume un desarrollador cuando exista trabajo preparado y separable, un responsable de producto y suficiente apoyo de revisión y publicación. Agregue capacidad especializada si una capa concreta limita el flujo. Resuelva la responsabilidad de decisión cuando los tickets ni siquiera logran quedar preparados.

Fije una revisión después de que la persona complete un cambio representativo. Compare dónde espera ahora el trabajo y dónde esperaba antes. No juzgue la participación únicamente por ocupación o cantidad de tickets iniciados.

Mapee el trabajo preparado del siguiente período y quién lo revisará antes de conversar sobre staff augmentation de desarrollo. El mapa debe explicar qué podrá terminar la persona incorporada y quién ayudará a publicarlo.