Además, en este ecosistema surge una nueva especie, la de los cumplidores, que no son más que una serie de personas que conocen las reglas del juego y la interpretan en su beneficio, siendo su misión seguir el procedimiento a rajatabla ya que mediante esta estrategia van construyendo un salvoconducto ante el posible fracaso del proyecto: «no sé que es lo que ha podido pasar, ya que como podéis ver he seguido todos los pasos que indica el procedimiento», mitigando sus consecuencias y abriendo las puertas para extender o compartir la culpa (con o sin razón) con otras personas: área usuaria y/o equipo de desarrollo.
Esta actitud defensiva no es adecuada para trabajar en un proyecto de desarrollo de software porque no se piensa en el producto sino en cómo conseguir salvarse otra vez en el caso de que las cosas vayan mal. Tampoco se piensa en los compañeros ya que es una actitud eminentemente individualista.
La respuesta de quiénes defienden esta forma de entender la calidad y el desarrollo de software es que el problema no está en los procesos, sino en las personas, que no han sido capaces de hacer bien su trabajo ya sea por falta de conocimientos, por falta de interés, por rebeldía o por negligencia.
Esto da lugar al desgaste en las relaciones entre los equipos afectados, algo que no contribuirá a que la situación mejore, sino a que cada vez las posturas sean más extremas.
¿Y cuál es la respuesta de los responsables de la calidad del proceso? Más procesos, más restricciones, con el objeto de minimizar el impacto de las personas, ¿y cuáles son los resultados? Con más resistencias no se pueden esperar resultados mejores, lo más probable es que empeoren a la par de que se incrementen los costes de desarrollo.
Jummp 