Discutía el otro día con un amigo sobre los valores democráticos (separación de poderes, libertad de expresión, el concepto de ciudadanía y las elecciones son algunos de ellos). Sin duda los valores democráticos son buenos en esencia y están universalmente aceptados en los países democráticos con pequeñas variaciones. Pero la discusión (más bien el intercambio de ideas) no se planteaba en términos políticos, si no en términos de gestión de proyectos de software. En concreto nos planteábamos si ¿Son los valores democráticos trasladables a la gestión de un proyecto de software? La verdad es que no llegamos a ninguna conclusión totalmente clara, pero si surgieron ideas que considero interesantes y que voy a compartir con vosotros.
La separación de poderes es el concepto de establecer ámbitos claros de actuación, que no se solapan entre sí, con autoridades claras que actúan con autonomía e independencia. Sobre la separación de poderes el principal problema que se plantea es definir el poder en los proyectos de software. Yo creo que una definición útil puede ser: "la capacidad para inducir cambios en el comportamiento de otros miembros del equipo o en el devenir del proyecto". Es curioso que los temas relativos al poder aparezcan a menudo cuando se trata con proyectos que están en problemas, sin embargo no conozco ninguna metodología que aborde este problema de manera clara. Solo las metodologías ágiles entran en el tema, de manera lateral, tratando de establecer un equipo de iguales, donde el poder se diluye, no esta concentrado en ninguno de los miembros del equipo. Scrum hace especial hincapié en este aspecto, haciendo al equipo de desarrollo todo poderoso en lo relativo a completar un sprint. Partiendo de la base de que todos los miembros del equipo van a usar el poder para favorecer el curso del proyecto, es fácil llegar a la conclusión de que cuanto más distribuido este, más gente podrá aportar sus capacidades para llevar el proyecto a buen puerto. Esto esta muy bien como principio y me parece una buena practica, que funciona muy bien en equipos que han demostrado su capacidad para trabajar juntos, es el equivalente a la descentralización. Pero creo que la máxima debe ser que el jefe de proyecto es quien debe detentar todo el poder en lo relativo a la gestión del proyecto y tiene que tener la capacidad para distribuir este poder entre los miembros del equipo y recuperarlo cuando necesite realizar cambios de rumbo radicales y forzados (lo que en principio solo seria necesario si el proyecto se encuentra en graves problemas). La capacidad de que ciertos miembros del proyecto puedan reclamar todo el poder en momentos críticos es imprescindible, a mi modo de ver, puesto que hay ocasiones en que es necesario tomar decisiones claras sabiendo que si te equivocas solo tu, como jefe de proyecto, serás el responsable para bien o para mal.
Entrando a fondo, en el tema de la separación de poderes, es evidente que existen diferentes ámbitos de poder, ámbitos de poder que durante el desarrollo normal de un proyecto deben estar separados. En esencia es sano que haya autoridades claras en las diferentes aspectos del proyecto, es una cuestión de simple economía de recursos, es más económico tener un responsable de, digamos, la arquitectura del acceso a datos que permitir que todos los arquitectos de tu proyecto tenga algo que decir sobre el acceso a datos. También se derivan ventajas de la especialización. Claro que eso no quiere decir que los proyectos de software deban renunciar a los órganos de control con los que cuenta la democracia, en los proyectos el principal órgano de control con el que contamos es las revisiones. Todo debe ser revisado, por excelente que sea nuestro arquitecto encargado del acceso a datos, se puede equivocar. Ojo, un error habitual es sustituir las revisiones, la especialización y la autoridad por el diseño por comité, antipatrón lo suficientemente descrito en la literatura sobre gestión de proyectos.
Otro tema clave en democracia, del que a menudo se habla en la gestión de proyectos es la ciudadanía. Entendamos la ciudadanía como el "sentirse parte del proyecto". Es un valor que debemos promover en los proyectos, MSF 4.0 lo incorpora de manera explicita a los “mindset”, aquellos principios que deben guiar el desarrollo. Todos los participantes deben sentir que son necesarios en el proyecto, que sus aportaciones son valoradas. El concepto de ciudadanía es un reto para los proyectos gestionados de manera autoritaria, porque son los ciudadanos los que reparten la autoridad, no hay castas, no hay jerarquías naturales. En esencia, en democracia, todos los ciudadanos valen lo mismo, no son más valiosos unos que otros. Esto es difícil de llevar a cabo en los proyectos de software gestionados por jefes de proyecto rígidos. Es la cuestión habitual que se plantea cuando tratamos responder a la cuestión ¿Qué es más valioso para un proyecto un analista o un programador? En España, y atendiendo al sueldo la respuesta esta clara. Pero que la respuesta este clara no quiere decir que sea correcta. Yo creo que la respuesta correcta es que es más valioso quien mejor hace su trabajo, sea cual sea este dentro del proyecto. Esto que parece una obviedad no se tiene en cuenta a menudo en los proyectos.
Promover la ciudadanía en los proyectos supone sin duda desde el punto de vista del jefe de proyecto, perder control. Esta perdida de control, se deriva de que si todos los participantes en el proyecto lo sienten como suyo, todos quieren tener capacidad para tratar de influir en la marcha de "su" proyecto. Nosotros debemos como jefes de proyecto debemos articular los mecanismos necesarios para que la gente pueda influir en el devenir del proyecto de una manera en la que esa participación sirva para favorecer el proyecto. El trabajo principal del jefe de proyecto debe ser lograr que la gente pueda dar lo mejor de si mismos. La motivación es el principal combustible de la productividad, que mejor manera de lograr equipos motivados que el que se sientan parte del proyecto, sin duda es el principal factor por el que los proyectos GPL triunfan, porque todos son parte del proyecto.
La única manera en la que los "ciudadanos" de un proyecto pueden llegar a sentirse como tales, es si se dan las condiciones necesarias para que puedan participar con libertad en el mismo y aportar todo lo que puedan aportar. Para ello es condición necesaria la libertad de expresión. Cada vez más, la herramientas de gestión de proyecto, incluyen foros o lugares donde los "ciudadanos" del proyecto de manera anónima o no (siempre a su elección) pueden expresar sus opiniones. La necesidad de un canal anónimo de comunicación es algo que muchos de los grandes autores sobre gestión de proyectos han considerado clave. Sin duda como jefes de proyecto debemos tener todo el interés del mundo en oír las malas noticias cuanto antes, y muchas veces esto no va a ocurrir si no tenemos un canal anónimo de comunicación. Los integrantes de un equipo de desarrollo siempre temen dar malas noticias, retrasan este momento, principalmente por el temor a que "se culpe al mensajero". El canal anónimo de comunicación en los proyectos es el equivalente a la libertad de expresión en democracia, para bien y para mal. No hay mejor manera de que un jefe de proyecto este totalmente informado de que ocurre en su proyecto que un foro anónimo sobre el mismo. Pero ojo, al igual que en democracia, hemos de ser tremendamente cuidadosos para no caer en la tentación de cambiar gestión, por populismo. No debemos sobre reaccionar a las noticias que recibamos por canales anónimos, sino investigar si esas noticias se sostienen en hechos, en métricas y si este es el caso, actuar.
Pero si algo caracteriza a la democracia es la celebración de elecciones. Los ciudadanos votan. Evidentemente esto no es trasladable directamente a la gestión de proyectos. No podemos organizar elecciones para elegir al jefe de proyecto, a los analistas etc… El reparto de poder, del que hablaba antes, no se puede hacer en base a votaciones. Aunque hay que reconocer que seria un ejercicio interesante. Dicho esto, es evidente que los "ciudadanos" de nuestros proyectos votan. No de una manera directa, traducible en porcentajes, pero si de una manera clara. ¿En que desarrolladores del equipo confían más los otros desarrolladores? ¿Cuáles reciben más consultas? ¿Cuáles son más admirados por el resto de miembros del equipo? ¿Cuales son los portavoces de el resto del equipo cuando hay problemas?. Evidentemente los desarrolladores que dan respuesta a estas preguntas han sido claramente votados por el resto del equipo, y sin duda como jefes de proyecto, tendremos mucho más apoyo del resto del equipo si cuando "repartimos poder" lo hacemos sobre estas personas. Básicamente el principio es el mismo que en democracia, dar poder a quien tiene autoridad. Esto es importante por que las decisiones que se perciben como injustas, son dañinas para la motivación del equipo, y eso ya sabemos mina la productividad.
Como conclusión, si es que hay conclusión posible, creo que la democracia es en cierto modo trasladable a la gestión de proyectos y que es un ejercicio interesante y sano. La clave de quienes gestionan la democracia, es sin duda, crear un entorno donde la gente pueda vivir mejor, como jefes de proyecto la clave es crear un entorno donde la gente trabaje mejor, si la democracia ayuda a lo primero quizás pueda ayudar también a lo segundo.
Espero que este post, suscite cierto debate.
Nota: Este post va sobre gestión de proyectos, no sobre política, por lo tanto cualquier comentario al mismo con tintes única o marcadamente políticos serán eliminados.