- Los equipos de ingeniería suelen estar bajo presión para "lanzar más funcionalidades, más rápido"
- Pero cuando se intenta avanzar en demasiadas tareas al mismo tiempo, la productividad en realidad disminuye
- "El secreto para lanzar más es, en realidad, hacer menos" -
Less is More
Principios clave
- Hacer visible todo el trabajo
- Definir el trabajo en unidades pequeñas
- Limitar el trabajo en curso
- Asignar recursos de acuerdo con la capacidad
- Bono: dejar margen para lo inesperado
# Hacer visible todo el trabajo
- Visualizar el trabajo obliga a enfrentar la realidad
- Cuando todo el trabajo puede verse de un vistazo, hay ventajas como las siguientes
- Se pueden establecer prioridades con claridad
- Se puede detener o pausar trabajo innecesario
- El equipo puede enfocarse en terminar lo que ya comenzó
- El objetivo no es rastrear todo para siempre → es entender con claridad la realidad y tomar mejores decisiones
# Definir el trabajo en unidades pequeñas
- Si el trabajo es demasiado grande, la energía del equipo se agota y el avance deja de ser claro
- Limitar las unidades de trabajo a alrededor de 1 o 2 semanas
- Los desarrolladores mantienen la motivación gracias a logros de corto plazo
- Se puede recibir retroalimentación rápido y corregir a tiempo
- Ventajas de las unidades de trabajo pequeñas
- Las revisiones de código se vuelven más fáciles
- Se comparte conocimiento de forma natural
- Se fortalece la colaboración entre integrantes del equipo
- Disminuye el riesgo en el despliegue
- Reducir el tamaño de las unidades de trabajo acelera la velocidad → permite mantener el impulso sin quedar abrumados por funcionalidades complejas
# Limitar el trabajo en curso
- Atender varias funcionalidades al mismo tiempo termina reduciendo la productividad
- Aparece el costo del cambio de contexto → adaptarse a una nueva tarea puede tomar hasta 23 minutos
- Cuanto más trabajo en curso haya, más aparecen problemas como
- Baja en la calidad
- Más bugs
- Caída en la moral del equipo
- Señales de sobrecarga a nivel de equipo
- Más de 4 tareas por desarrollador
- El tiempo de finalización es más largo de lo previsto
- Hay más funcionalidades en curso que funcionalidades terminadas
- Señales de sobrecarga a nivel individual
- Menor capacidad de concentración
- Aumento en el tiempo de respuesta en revisiones de código
- Dificultad para explicar prioridades en reuniones de seguimiento
# Asignar recursos de acuerdo con la capacidad
- El enfoque de "un desarrollador se encarga de una funcionalidad" es ineficiente
- Concentrar los recursos del equipo en el trabajo más importante
- Más colaboración → resolución de problemas más rápida
- Mejor calidad de código → más revisión entre pares en tiempo real
- El trabajo se termina más rápido
- A través de la colaboración, los desarrolladores pueden lograr una comprensión más profunda
- Hay que incentivar el rendimiento a nivel de equipo → poner el foco en el desempeño del equipo, no en el individual
# Dejar margen
- Operar al 100% de capacidad en realidad empeora los resultados
- El trabajo inesperado es inevitable → lo único incierto es cuándo aparecerá
- Problemas que aparecen cuando no hay margen
- El equipo termina trabajando de forma reactiva
- Baja en la calidad
- Menos innovación
- Aumento de la deuda técnica
- Cuando hay margen, existen ventajas como
- Se puede responder con flexibilidad a problemas inesperados
- Se hace posible resolver problemas de manera creativa
- Se mantiene una alta calidad
- Se sostiene un ritmo de trabajo sostenible
- El margen adecuado es de alrededor del 20% → puede ajustarse según las características del equipo
Resumen de la estrategia clave
- Hacer visible el trabajo → para ver la realidad con claridad
- Definir el trabajo en unidades pequeñas → mantener el impulso
- Limitar el trabajo en curso → aumentar la concentración
- Asignar recursos de acuerdo con la capacidad → enfocarse según las prioridades
- Dejar margen → ganar flexibilidad
Conclusión
- Para hacer más trabajo, se necesita una estrategia de hacer menos
- El desempeño de un equipo no se mide por cuántas funcionalidades procesa al mismo tiempo, sino por qué tan eficazmente entrega valor al cliente
- El rol del líder no es agregar más trabajo al equipo, sino quitar el trabajo innecesario
12 comentarios
En el libro <El Proyecto Fénix>, que también se ha mencionado varias veces en GeekNews, aparece una idea similar: cuanto más cerca se está del 100% de capacidad, más se alarga geométricamente el tiempo de respuesta.
Oh. ¡Eso también aparece en el libro Goal!
Porque The Phoenix Project en sí fue escrito como una versión de TI de The Goal.
Vaya........ ¡muchas gracias!!
Intento mantener un 80% de trabajo y un 20% de margen, pero siempre termino pensando cuál debería ser el criterio... incluso me pregunto si debería medirlo simplemente por tiempo.
¡Por eso yo aparto por completo las tardes de los viernes como tiempo para desarrollo personal!
Si se divide de esta manera en tareas pequeñas, el líder que tiene la visión completa termina teniendo un gran poder. Los ingenieros que trabajan junto a él más bien se desmotivan y quedan pensando: "¿hacia dónde se supone que vamos?". Una desventaja representativa del ágil basado en sprints.
Parece que está escrito demasiado solo desde la perspectiva del líder, tal como dice el título.
El impulso de los ingenieros también se ve muy influido por la dirección hacia la que el líder esté levantando la bandera. Parece que también hace falta pensar un poco más en cómo presentar cuál es el valor que se quiere dar al cliente, y cuál es el output de cada sprint y el outcome de entrega. Por supuesto, son habilidades blandas difíciles, así que es raro ver líderes que lo hagan bien y tampoco hay muchos textos sobre eso.
Me identifico muchísimo con este comentario. Existía el riesgo de que surgiera microgestión sobre los aspectos técnicos. Realmente no es nada fácil.
¿No será que se trata de compartir la visión general y, una vez que todos la entienden, dividir el trabajo en tareas pequeñas?
Si se divide en períodos de 1 a 2 semanas, parece natural que solo unas pocas personas conozcan la visión de una sola funcionalidad, como ocurre con la diferencia entre proceso y thread. La idea es aumentar la productividad limitando el foco.
Incluso si se comparte la visión, eso parte de la premisa de que surgirán dudas sobre ella, pero creo que también asumí de forma natural que no se logra alinear cómo se va siguiendo la visión general según la dirección que va cambiando un poco en cada sprint planning.
Aunque coincido plenamente con lo que plantea este artículo, también estoy de acuerdo con el problema que mencionaste.
De hecho, es justamente uno de los puntos que yo también he estado considerando.
Dependía de cada squad, pero cuando se involucraba activamente a los miembros del equipo en la planificación del sprint, ese problema que mencionaste no solía presentarse. Mientras compartíamos el contexto del proyecto y también la situación cambiante en cada sprint para que pudieran reconocer suficientemente las tareas que iban cambiando, les pedíamos que intentaran dividir el trabajo de manera muy detallada.
Como dices, desde la perspectiva de la gestión, si se piensa en el seguimiento del progreso, la medición de la velocidad de trabajo, la respuesta ante situaciones inesperadas y el costo de oportunidad cuando el contenido del trabajo no sale como se pretendía, al final sí resulta que dividirlo en partes pequeñas permite que todo avance mejor.
Se repiten textos parecidos, pero la ambición humana no tiene fin y seguimos repitiendo los mismos errores
Que la carga del CPU de una computadora esté al 100% no es normal,
pero cuando la carga de trabajo de las personas está al 100%, la conclusión es que hay que esforzarse más..