Democracia y desarrollo de software

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.

2 comentarios sobre “Democracia y desarrollo de software”

  1. En esencia estoy bastante de acuerdo contigo… sin embargo, fijate que partes de la idea de que un «dictador benévolo» es el que inicialmente forma el equipo. Ciertamente, de ser así, habrá depositado su confianza en gente que se la merezca. Implantará la democracia en un equipo no viciado, de profesionales capacidados para tomar decisiones con responsabilidad (y evidentemente, de forma razonada y justificada). Esto se parece más a la aristocracia de Platón que a una democracia, tal y como es conocida en occidente (http://es.wikipedia.org/wiki/Aristocracia). Si hablamos de ese escenario, tengo que admitir que estoy de acuerdo contigo.

    Sin embargo, sabes tan bien como yo que no es el escenario más habitual. El escenario habitual es aquel en el que el equipo es impuesto. En este tipo de escenario, la mediodridad puede ampararse en la democracia para vertir opiniones no justificadas ni sustentadas en nada, que cuanto menos hacen perder el tiempo al resto de integrantes del equipo. Sin llegar a caer en el diseño por comité (que sabes tan bien como yo que es muy habitual) el simple hecho de «poder hablar» suele ser el combustible para que los guiados por la ignorancia y la vanidad sean capaces de decir cualquier cosa con tal de que el resto del equipo sea consciente del moreno de solarium que ha adquirido en los últimos meses. Se lo que me responderás a esto… «lo que pueda decir ese tipo de personas se suele caer por su propio peso». Sí, es cierto, pero durante su intervención han conseguido perder su propio tiempo y lo que es más grave, el tiempo de los que se sienten obligados a escucharle.

    Otro punto a discutir, relacionado con el Scrum y el reparto de poderes, sería el de hasta qué punto tienen voz los miembros que participan puntualmente en el proyecto. Quiero decir, según el Scrum, cualquier persona (o «pig» :-))que participe durante un sprint es parte del equipo y debe considerarse un miembro (entiendo que igual a los demás). Significa eso que la opinión de un consultor especializado que viene a sacar las castañas del fuego sobre un tema concreto, vale lo mismo que la de aquellos que le han llamado? ¿O tal vez «alguien» debiera tener un voto de calidad? ¿quién? ¿debería ser elegido democráticamente?

    En resumen, creo que la aristocracia es una herramienta muy potente aplicada al desarrollo del software. La democracia occidental, me temo que lleva obligatoriamente al antipatrón de «diseño por comité».

    En fin, ¿qué opináis?

  2. Creo que este modelo nace algo viciado. Para mi el punto de partida, en ésta democracia, es que el pueblo son los usuarios, de modo que el equipo de desarrollo ha de verse como el equipo de gobierno. Desde este punto de vista, el presidente selecciona a sus ministros, etc. (si esto no se da, que quieres que te diga,…) Pero lo más importante es que el presidente (director de proyecto) ha de enfocar su labor, de modo que su pueblo (usuarios y posiblemente clientes) obtengan lo que necesitan para poder desarrollarse como personas (realizar su trabajo,…).
    Pero nadie piensa que al presidente de un país lo han de votar los ministros¿?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *