El mito de la burocracia

Con frecuencia me encuentro con rechazo a las tareas a realizar durante el proyecto, y en muchas ocasiones la respuesta tiene una raiz común: la gente las llama burocracia.

Si a un programador le pides que anote las horas que ha dedicado a hacer una tarea, lo tildará de burocracia. Sin embargo, si tiene que probar una nueva tecnología para la que existe la rara posibilidad de que se use en el proyecto, esas horas las considerará una inversión.

Hay una importante corriente de favor por metodologías y prácticas "ágiles", y es sorprendente la facilidad con que todo el mundo se apunta a "ser ágil" (aunque realmente hay poca gente que te sepa decir exactamente qué supone ser ágil). Muchos contestan que ser ágil, es básicamente, eliminar la burocracia.

El problema reside en que primero, esa definición de agilidad no es correcta, y además, tampoco existe un acuerdo en qué es la burocracia. En mi empresa nos hemos certificado CMMi nivel 3, y constantemente leo en internet un constante rechazo a CMMI, en muchos casos recibiendo la calificación de "burocrática".

Sorprendentemente, los equipos de trabajo que usan nuestra metodología raramente se quejan de burocracia. Las tareas que se realizan, hay que realizarlas si o si, ya que proporcionan la única forma de llegar a tener control sobre el proyecto. Además, las tareas que se realizan no se llevan a cabo por CMMI, sino por el valor que aportan al proyecto o a la organización. Las quejas surjen durante las fases de implantación de la metodología, lo que nos lleva a concluir que el problema es de formación y falta de conocimiento.

Por otro lado, la burocracia, se presenta como principal argumento de metodologías ágiles como SCRUM. Se busca en muchas ocasiones rechazar dos conceptos que en realidad tienen poco que ver entre sí, y mucho menos con SCRUM:

• CMMI
• Ciclo de vida en cascada

Para empezar, CMMI no es una metodología, como tampoco lo es el ciclo de vida mencionado. CMMI es un modelo de madurez. El ciclo de vida en cascada, como cualquier ciclo de vida, es un modelo más o menos teórico que presenta una forma de realizar las actividades. Normalmente lo que se busca con afirmaciones de este tipo es conseguir crear en el modelo CMMI una imagen de burocracia y antiguedad. Por confrontación, conseguiríamos obtener una imagen (ficticia como vemos), de modernidad y agilidad en SCRUM.

Vemos entonces que la burocracia, sin terminar de definirse como término (aunque está claro que es negativo), sirve como argumento positivo (por confrontación).

Mi opinión es que en la mayoría de ocasiones nos gusta escondernos en nuestro pequeño mundo, y llamamos burocracia a las actividades que no nos aportan directamente algo a nosotros mismos. En una escala comparativa, tendríamos tareas cuyo beneficio va a parar:

• Al individuo
• Al proyecto
• A la empresa

Las actividades que producen principalmente beneficio al individuo (actividades que producen satisfacción personal, autoformación, investigación, etc), no se consideran nunca burocracia. Los integrantes del equipo se sienten cómodos con ellas.

Las actividades que aportan al proyecto, son calificadas como burocráticas por las categorías más bajas (programadores principalmente). Las necesidades de la gestión del proyecto no les importan, y la supresión de estas actividades, serían a su modo de ver, síntoma de agilidad.

Las actividades que aportan a la empresa, amplían el conjunto de individuos que las rechazan, incluyendo a las categorías medias/bajas.

Como conclusión, vemos que normalmente la definición de burocracia está asociada de forma egoísta o personal a unas actividades u otras, en función de nuestro rol. Se echa en falta pues, una visión más global de las actividades en los proyectos, y de su relación con los distintos roles. Un punto por ejemplo que no se suele tener en cuenta es el coste o beneficio en cada actividad, que suele ser percibido de forma diferente en función del rol en el proyecto.