En nuestro día a día hay un montón de costumbres, maneras de trabajar asumidas, de las que no somos conscientes, damos por establecidas, y que representan, realmente, la diferencia en eficiencia, entrega de valor, competitividad, etc., entre unas organizaciones u otras. Solemos ser conscientes de el uso o ausencia de grandes estrategias, de si existe un DevOps, un Scrum, un Cascada, un ITIL, etc., ese tipo de «grandes» cosas, pero se nos pasan, son menos populares, otro montón de cosas si cabe más determinantes.
Ejemplo de ello, del que te he hablado otras veces, es el coste de la interrupción (Interrumpir a quien programa, o al que realiza cualquier actividad intelectual, hace que su productividad caiga (mas de lo que imaginas) o Controlando las interrupciones, uno de los mayores destructores de productividad), autentico destructor de la productividad que se pasa por alto y que su gestión no está de moda.
Hoy te quiero hablar de otro de estos, otro de esos que está ahí desde hace tiempo, que no está de moda y que tiene auténticos devotos… el coste de la decisión.
Cada correo que mando a otra persona para que me dé un OK de algo, cada checklist que tengo que verificar antes del siguiente paso, cada documento con pasos de una metodología, cada requisito a implementar, cada línea de código a programar, cada caso de test a pasar, etc., conlleva tomar una decisión.
Y tomar decisiones conlleva tiempo. Y normalmente tiempo de varias personas, del que escribe de alguna manera sobre qué decidir, más el que tiene que decidir, más las posibles vueltas por malos entendimientos en la decisión tomada.
Hay decisiones necesarias de tomar e innecesarias (desperdicios). Tomar decisiones conlleva un coste, principalmente en tiempo, llamémosle desperdicio si ese coste que conlleva decidir no era necesario o si podría haberse hecho de manera más eficiente.
Típicamente yo veo 4 puntos en los que tradicionalmente se esconde el coste evitable de decidir, el desperdicio, que campan a sus anchas principalmente en organizaciones muy basadas en metodologías clásicas, procedimientos, reglas y similares. Vamos con ellos…
1. Antigüedad de aquello sobre lo que decidir. De manera similar al concepto de deuda técnica, cuanto más antiguo es aquello de lo que tengo que decir más desperdicio. No es lo mismo contestar a ese correo ahora que dentro de un mes. No es lo mismo terminar esa checklist de paso a producción de aquello que se terminó ayer que de eso que se terminó hace un mes.
2. Cantidad de cosas sobre las que decidir. Cuanto mayor es el número en conjunto de cosas a decidir mayor desperdicio. No es lo mismo desarrollar algo y testearlo, decidir si está OK, que testear toda una aplicación y sus cientos de funcionalidades. No es lo mismo hacer todo y testear todo, que hacer algo pequeño y testearlo, hacer algo pequeño y testearlo, etc.
3. Canal. Decidir suele implicar a dos partes, el que expone sobre qué decidir y el que decide sobre ello. Y cuanto más ineficiente es el canal para transmitir una decisión entre una persona y otra… mayor desperdicio. La separación física entre los miembros de un equipo impacta en su rendimiento, a más distancia más cosas mal interpretadas. Y el canal impacta, no es lo mismo hablar que enviarte un mail o un documento. La forma más eficiente es siempre comunicar cara a cara.
4. Gente involucrada. Y cuanta más gente involucra una decisión más desperdicio. Más aún si no era necesario involucrar a esas personas. Típicamente en organizaciones montadas en el individualismo, en modelos a la defensiva, gran cantidad de decisiones podría haberlas tomado uno mismo, sin contar con nadie, pero se prefiere involucrar a otros por si la decisión es errónea… tener coautores del error. También esto ocurre en empresas pensadas para no pensar, donde no se deja decidir sin involucrar a un superior.
El día a día está lleno de ejemplos que cargan grandes cantidades de desperdicios sobre los anteriores, por ejemplo, grandes documentos de cosas hechas hace meses que un montón de gente tiene que validar. Cantidades de mails enviados a un montón de gente para tomar decisiones triviales que con delegación podría haber tomado una persona sola.
Ya sabes, ojo con las decisiones innecesarias, elimínalas.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Excelente artículo, los 4 puntos que presentas muy buenos. Continuamente pasa que por burocracia o pensando que mantenemos una comunicación adecuada con los miembros del equipo (que se sientan «frente a nosotros» muchas veces), preferimos enviar un correo antes que tener una conversación, obviando que así posibilitamos que se malinterprete la intención comunicativa.Creo que una conversación (siempre que sea posible) será más efectiva que un intercambio de correos.
Llevo algunos meses siguiéndote Javier y nunca había comentado, pero este post tengo que decir que es de los mejores que te he leído. Este sí que no tiene desperdicio! Simplemente genial.
Quizas una de las razones que hace que el viejo modelo de command and control sea muy ineficiente es porque nos pasábamos la vida trabajando para presentar las cosas sobre las que había que decidir, sabiendo muchas veces cual era la mejor decisión ya de entrada. Y lo peor, es que no eran pocas que se tomaba otra distinta porque el que decidía no tenía el contexto suficiente para decidir bien.