Aumento de la productividad en un pequeño equipo de desarrolladores de back-end [cerrado]

Veo dos preguntas horneadas aquí: ¿Cómo mejoramos la productividad del equipo? y ¿Cómo podemos ayudar a un equipo a ser rentable?

Rentabilidad

Este es un tema enorme, por lo que solo lo tocaré lo suficiente para explicar por qué la productividad no es lo mismo que la rentabilidad. Para un ejemplo simple, si hago widgets que vendo por $10 y me cuesta $100/día para operar, necesito hacer más de 10. Digamos que hago 8. Puedo resolver esto encontrando una manera de hacerlo, o cobrando $13 en su lugar. Ambas opciones me hacen rentable.

Cambiar la productividad es una inversión a largo plazo. El aumento de productividad del 100 % que ha visto en tan poco tiempo es prácticamente inaudito. Estoy encantado por ti y tu equipo de que lo hayas visto, pero no es la norma y no confiaría en ver otro cambio como ese. Si necesita una solución a corto plazo, debe generar más valor, lo que podría significar cobrar más o priorizar el trabajo más valioso.

Productividad

retrospectivas

Vería qué tipo de mejoras están surgiendo de sus retrospectivas. Este es su vehículo principal para la mejora del equipo. Eche un vistazo a https://plans-for-retrospectives.com/en/ para obtener ideas sobre retrospectivas más efectivas. Pruebe su enfoque más estructurado de 5 etapas para ver si genera información más poderosa. No conozco a su equipo, pero la mayoría de los equipos con los que he trabajado no obtienen el valor total de sus retros.

Residuos magros (3 M)

Hay un gran ejercicio que he hecho con equipos alrededor de las 3 M en lean (Mura, Muda, Muri). Cree 3 columnas o secciones en una pizarra y explique las 3M (descripción rápida a continuación) y pídales que escriban notas adhesivas con los desechos que encuentran en su día de trabajo y que las coloquen en la columna de la derecha. Por lo general, obtengo al menos 20 a 30 de un grupo. No puede resolverlos todos a la vez y muchos solo pueden mejorarse en lugar de eliminarse, pero esto le dará una gran lista de cosas que ralentizan a su equipo con las que puede ayudar.

No pude encontrar un enlace con descripciones que me gustaran, así que aquí hay definiciones breves:

Muri (Overburden) : Hay una cantidad máxima de trabajo que puedo manejar a la vez y después de eso, simplemente me empantano en administrar y priorizar el trabajo y me quita tiempo para hacerlo. Para obtener más información y pruebas matemáticas, eche un vistazo a la Ley de Little de la teoría de colas. Pista: el número de cosas suele ser inferior a 5, en algunos casos, es 1.

Mura (Variación) : En el trabajo de conocimiento veo tres tipos comunes de residuos de Mura. Cambio de contexto donde estoy tratando de realizar múltiples tareas o dividir el tiempo en diferentes proyectos. Variación del tipo de tarea que requiere que trabaje de maneras muy diferentes (agrupar los tipos de tareas puede ayudar con esto). Y, por último, la variación del flujo; por ejemplo, todas las historias pasan a las pruebas al final de un sprint y los evaluadores pasan de aburridos a sobrecargados.

Muda (actividades sin valor agregado) : esto se explica por sí mismo. Qué actividades consumen tiempo en el día que no hacen avanzar las características de su aplicación. También puede echar un vistazo a los 7 desperdicios lean para obtener más información sobre esto, aunque está escrito principalmente desde la perspectiva de la fabricación y necesita hacer un poco de traducción al trabajo de conocimiento. (por ejemplo, los artículos que se encuentran en el inventario se traducen en código no publicado)