Todos los equipos toman decisiones, continuamente. El problema es que muchas veces no son conscientes de las elecciones que hacen, ni cuándo las hacen, y por lo tanto terminan actuando con menos intención, sintiéndose menos responsables de sus propias acciones. Los equipos de desarrollo de software que quieran crear el mejor producto posible deben ser totalmente conscientes de una libertad básica humana: el poder de elegir.
En este primer artículo vamos a repasar los problemas en la toma de decisiones de equipo y las consecuencias de mecanismos deficientes, para lograr tener un primer panorama de la situación.
La libertad de elegir
Las elecciones demuestran la existencia del libre accionar, y son un signo de presencia y compromiso. Las personas son libres. Si se les quita esta libertad, se pretende que no la tienen, o se permite que pretendan que no la tienen, su propia naturaleza humana va a estar fuertenemente comprometida. Un equipo nunca va a poder sobrepasar los límites de sus miembros indivuales a menos que logren dominar, crecer y ejercer el su propia libertad. Un individuo nunca puede ser parte - ni tampoco identificarse - de un equipoque como precondición de pertenencia requiera la entrega de su libertad. Y paradójicamente, es esta entrega de la libertad la que impide una unión verdadera al equipo.
Tomar decisiones es una forma para que el equipo cree y aplique la intención del grupo, y para que identifique, incorpore y genere libertad. "Decidir como uno" requiere que un equipo logre:
- recolectar y aplicar su información acumulada
- revelar sus cualidades deseables
- inhibir sus cualidades no deseables
- especificar su comportamiento subsecuente
Los equipos que no deciden son inútiles
La calidad de vida de un equipo está en su mayor parte determinada por la calidad de las elecciones que toman (una elección no es una decisión a menos que genere obligaciones explícitas para un comportamiento futuro específico). A medida que el equipo logre prestar más atención, intención, creatividad, pensamiento y foco en sus propias elecciones, su vida se va a volver más enriquecida, y en consecuencia el producto del equipo será mejor.
Sin un proceso de toma de decisiones explícito, el equipo no va a conocer sus propias elecciones hasta que sean reveladas por el mismo comportamiento. A menos que el equipo pueda hacer responsable a todos y cada uno de sus miembros para los resultados de sus decisiones, no van a lograr trabajar como uno en mejorar sus elecciones.
No se pueden mejorar las prácticas del equipo sin mejorar sus decisiones. Por supuesto, las decisiones siguen ocurriendo aunque no haya mejoras - tanto sean buenas o malas. Cada reunión, cada acto creativo, expresa una elección de equipo. En un mal escenario las elecciones son incoherentes, y se pierde el potencial de compromiso.
Las decisiones pasivas
Las decisiones son elecciones particularmente vívidas o importantes. A menudo se las suele registrar, y cualquier decisión se expresa por el comportamiento subsecuente que surge.
Cuando un equipo decide, elige hacer algo, o no hacer algo. Desafortunadamente, en muchos equipos ocurre que los miembros del equipo ignoran sus propias decisiones. Pueden no saber:
- qué es lo que decidieron,
- cuándo lo decidieron,
- qué obligaciones surgen de la decisión, o
- qué transacciones constituyen a la decisión.
A estos equipos les falta una habilidad cognitiva. Y naturalmente, esta falta de claridad y precisión complica enormemente al comportamiento del equipo. Si un equipo no puede reconocer una "decisión de equipo", ¿puede decirse que los miembros realmente decidieron?
Este comportamiento de "decisiones pasivas" crea un vacio en el desarrollo de productos de software. Más aún, la calidad del comportamiento que resulta de una decisión casi nunca mejora la calidad de la decisión que la determinó.
Prácticas de decisión incorrectas
Existen muchas técnicas para la toma de decisiones, y se pueden dividir rápidamente en tres tipos:
- sin resistencia aparente
- regla de la mayoría
- el jefe decide
Estos tres métodos tienen debilidades importantes a la hora de construir de forma colaborativa el mejor producto de software posible.
Sin resistencia aparente
Este método de toma de decisiones "de tipo de consenso" no suele dejar ningún registro sobre quién estuvo de acuerdo con qué. La ausencia de resistencia visible no es indicativo de un apoyo completo, ni predice buenos resultados de forma consistente, en parte por la propia imprecisión en la responsabilidad de la decisión.
Los humanos son capaces de complejos actos de sabotaje conscientes e inconscientes, que se suelen manifestar de acuerdo al siguiente ciclo:
- Alguien disciente con el plan (es decir, con una o más decisiones del grupo). Si esta persona discidente no tiene la iniciativa y el coraje para manejar estas objeciones de forma directa, va a manejarlas de forma indirecta, a menudo de formas que reducen la efectividad general del equipo.
- Incluso aunque quien disciente tenga buenas intenciones (un discidente silencioso ya es sospechoso por la calidad de sus intenciones), es dificil que una persona crea una cosa y actue de otra en un período sostenido de tiempo. Como mucho, un discidente pasivo va a mostrarse sin compromiso y sin participación en el equipo; en el peor de los casos, va a infectar con cinismo a los demás, o va a fomentar otro tipo de comportamientos negativos en el equipo.
- A menudo, la resistencia encubre complicaciones técnicas o de procesos. Incluso una única persona con resistencia puede detener un proyecto mientras que el resto de los miembros del equipo se quejan o esperan.
Se debe exponer la resistencia para que el equipo pueda manejarla. Una política simple de "seguir adelante si no hay resistencia aparente" simplemente no funciona. En estos procesos simplistas no hay un mecanismo para exponer y resolver las bases de la resistencia antes de que surja el sabotaje inevitable. Cuando no se pone energía en ver un problema, se pone energía en ignorarlo.
En el desarrollo de software, incluso si la resistencia se logra evadir o reprimir, se van a ver consecuencias en el producto final del equipo.
Regla de la mayoría
Una estrategia de "regla de la mayoría" es tan inefectiva para el desarrollo de software como el de "sin resistencia aparente". Los discidentes que están en la minoría van a ser vocales al respecto, o silenciosos. Ignorar a esta minoría sólo conduce al sabojate o a la rebelión.
El jefe decide
Sin importar que tan bien disfrazado esté, no funciona dictar soluciones desde un nivel jerárquico superior, porque atropella los aspectos de la naturaleza humana que se necesitan para crear grandes productos de software en equipo. En este caso, este vacio de poder en la toma de decisiones se llena de manera simbólica por un jefe "inmediato", o peor aún, por un jefe todavía más distante.
Cuando el jefe "manda" el equipo delega toda la responsabilidad y compromiso. Este sistema no muestra respeto, y perpetúa un sistema de "la culpa la tiene el otro". El jefe sabe que depende del equipo y usualmente sólo "decide" lo que le aconsejan los miembros más respetados del equipo. El equipo, que es en donde se origina el poder, las ideas y la pasión, termina siendo menos responsable de sus resultados.
Y entonces, ¿cómo decidimos?
El verdadero trabajo de un líder es asegurarse que el equipo reconozca su propio poder, avance para lograr resultados, y asuma responsabilidad por sus decisiones. El jefe efectivo brinda al equipo con la tecnología necesaria para crear un equipo cognitivo y autónomo.
En el próximo artículo vamos a explorar el Protocolo de Decisión, que es un proceso confiable que busca tomar decisiones de forma unánime en el equipo.