No falla. Cuando en una empresa se decide implantar un sistema de calidad, al principio hay un buen rollo tipo teletubbie considerable. Los primeros procesos se reciben con amabilidad e incluso satisfacción. Y llega el día en que el consultor propone algo que no le convence al Director de Proyectos y el conflicto está servido. ¿Soy el único al que le ha pasado?
Porque no han sido ni dos ni tres veces las que me he encontrado el mismo problema. Y que los programadores o el personal de administración presenten cierta resistencia a la implantación de procesos es hasta cierto punto razonable, sobre todo cuanta mayor experiencia tienen. Pero ¿el Director de Proyectos? ¡Pero si todo esto sólo sirve para facilitarle la vida!
El problema surge por dos motivos muy diferentes, pero que se suelen dar combinados: la diferencia de carácter y prioridades entre ambos perfiles. El consultor es una persona metódica y tranquila que trabaja a largo plazo, con el objetivo de velar porque el equipo no se desvíe de unas prácticas que aseguran el cumplimiento de objetivos. El Jefe de Proyecto es una persona dinámica, sometida a presiones por parte de la empresa para cumplir plazos con independencia de los problemas de producción que aparezcan. Es lógico que los dos entren en conflicto si no hay un claro arbitraje por parte de la gerencia.
Los conflictos pueden surgir por muchas razones. La más normal y comprensible, es que cuando se implanta un sistema de calidad, el Director de Proyecto debe mantener el ritmo de producción habitual al mismo tiempo que se van haciendo los cambios. Lo cual es imposible. No se trata de que las nuevas prácticas sean mejores o peores que las antiguas, sino de que en el método existente la gente sabe a dónde ir y en el método nuevo todo es desconocido. Pasamos de «lo malo conocido a lo bueno por conocer», con el agravante de que lo nuevo no es evidente, que suele entrar en conflicto con lo anterior y que hay que aprenderlo.
Otro motivo de conflicto es que el Director de Calidad se empeñe en implantar procesos burocráticos y pesados, llenos de controles y formularios que hay que cumplimentar (el famoso informe TPS de Trabajo Basura). La burocracia, el sistema que documenta el trabajo de una empresa, es fundamental, pero debe ser la mínima para conseguir ese resultado y nada más. Todo lo que frene a los jefes de proyecto y programadores en su verdadero trabajo (producir valor) es una pérdida de tiempo, que choca con las prioridades de la empresa.
Por suparte, el Director de Proyectos tiene un grave problema de Síndrome de Príncipe Destronado. Es una de las piezas clave de la empresa, porque es quien se encarga de que se cumplan los plazos y, por desgracia, muchas veces tiene que meter mano a resolver problemas técnicos en las empresas de corte funcional. Sabe que es importante y en la empresa tiene un lugar… y de repente llega alguien que le dice que las cosas no se hacen así. Si se implanta Scrum, el Scrum Master tiene la osadía de decirle que no hay «Jefe de Proyecto». Peor… que no puede cambiar los requisitos a mitad del Sprint y que no puede inmiscuirse en las reuniones diarias para meter prisa a la gente. No es que no pueda, no debe.
Al principio lo respeta, por aquello de que la empresa lo ha decidido y que él ha oído que eso de Scrum va bien. Pero llega el día en que hay prisas de verdad, en que hay que sacar las cosas a tiempo o que el cliente ha decidido que el fondo de pantalla es rojo y no violeta. Y en eso momento dice que los procesos están muy bien, pero que tiene prisa y que las cosas se hacen a su manera por narices. Si la empresa está en proceso de certificación CMMI, como me ha ocurrido a veces, acaba de sembrarse la semilla del fracaso.
Lo que ha ocurrido es que alguien acaba de demostrar que los procesos no tienen porqué seguirse. Que están bien de cara a la galería, pero que cuando las cosas aprietan el método tradicional de gestión, el de apretar y gritar, es el que funciona. Si no se llegan a esos extremos, como poco hay un conflicto importante, porque el Director de Calidad basa su prestigio en la consecución de objetivos de certificación y sabe que lo que esta ocurriendo va a tirar por tierra el proceso de evaluación.
La solución a todos estos problemas es simple, pero requiere del compromiso de tres actores:
- El Director de Calidad y/o Scrum Master debe entender que la implantación de procesos debe ser progresiva y que en cada Sprint debe conseguir «un poco más de aceptación», no la ejecución perfecta del método.
- El Director de Proyectos debe entender que el Sprint es un compromiso entre dos partes: tú me das requisitos claros y yo me comprometo a desarrollarlos en un plazo. Algo de disciplina con el cliente y un proceso de gestión de cambios tampoco viene mal de vez en cuando.
- Y, sobre todo, el Gerente debe ayudar a las dos partes a entenderse. No puede permitir que el personal de proyectos cambie las cosas de forma arbitraria, que hagan cambios en los procesos sin avisar, porque entonces la empresa seguirá siendo impredecible. Pero si un proceso, si una práctica de Scrum o lo que sea frena a la gente, debe comentarlo con el ScrumMonster y hayar un punto de equilibrio en el que se respete el método de trabajo, pero eso no impida avanzar con agilidad y reaccionar a tiempo.
En definitiva, todas las partes deben hacer suyo un único objetivo: que la empresa consiga cumplir sus plazos y entregue productos de una calidad aceptable. Si cada uno tiene su propia meta y ésta entra en conflicto con la de los otros, el tortazo es seguro.