Ayer, hablando con unos colegas sobre experiencias que han tenido en sus trabajos (todos en equipos de desarrollo), un amigo me contó una cosa que le ocurrió en un trabajo, y que como poco me pareció una curiosa forma de explicarle como iban las jerarquías en esa empresa :o) obviamente no voy a decir nombres.
Empecemos contando la curiosa visión de las jerarquías que le pusieron a mi amigo:
- Su jefe, le sentó, cogió un papel, dibujó un hombrecillo, y le dijo “este eres tú en la empresa”
- A continuación dibujó un árbol y en las ramas dibujó otro hombrecillo, y le dijo “este soy yo”
- Por último, pintó otro hombrecillo en la copa del árbol, y dijo, “y este es mi jefe”.
La conclusión que le dijo a mi amigo, es que como podía ver en el dibujo (una representación sin más de la jerarquía), el estaba por encima, y por tanto tenía una “visión más amplia” de todo, así como su jefe por encima de el, con lo que cuando el (el jefe de mi amigo) le “ordenase” algo, no debía cuestionarlo, puesto que el tenía una visión más amplia, así como cuando su jefe le decía algo el no lo cuestionaba.
En fin, una visión curiosa de como funcionan en algunos sitios, lo primero que se puede observar aquí, es que los marrones siempre van a caer de arriba hacia abajo, cosas de la ley de Newton. Lo siguiente que se me ocurre, si a mi me dicen eso, es que la comunicación, no va a fluir precisamente, facilitando la toma de decisiones en el equipo, si no que me van a tratar como “cadena de montaje”, o “picapedrero”.
Por supuesto, los crasos errores en los que estaban cayendo en este equipo son muchos de los que se pretenden evitar con las metodologías ágiles:
- Los equipos jerárquicos, en el desarrollo de software, está sobradamente que no funcionan, debemos formar un equipo de “iguales”, todos con su responsabilidad correspondiente a la hora del éxito o fracaso de l proyecto.
- Falta de comunicación, cuando alguien te dice que no cuestiones sus “órdenes” puesto que el tiene información que tu no tienes, y que con esa frase demuestra que ni siquiera te va a proporcionar, malo. La información tiene que ser algo compartido en el proyecto, el equipo tiene que ser partícipe de las decisiones, tener la información para organizarse, decidir y apoyar el éxito del proyecto. La comunicación es algo fundamental y básico para el éxito.
- El equipo de desarrollo no es un equipo al que se le tira “la carnaza” del trabajo desde arriba y esperamos a que nos suban los resultados, los equipos de desarrollo tienen que ser partícipes en todo momento del proyecto, son los responsables más directos de lo que se va a generar: el software, y tienen que tener la capacidad de organizarse del modo que más convenga a todo el equipo, de tomar sus propias decisiones técnicas, basándonos en toda la información de que disponen, no son cadenas de montaje, son equipos que toman sus decisiones informadas en todo momento, para el éxito del proyecto.
Bueno de esto realmente se podría hablar mucho más, se pueden poner diferentes puntos de vista, opiniones, etc, la mía, personal, de Luis Fraile (que luego no haya equivocaciones), es que esa visión del hombre en el árbol, no es válida para un equipo de desarrollo de software maduro, y probablemente esté avocada, a lo mejor no al fracaso, porque es indudable que así se funciona en muchos sitios, pero si está avocada a que el equipo de desarrollo se frustre poco a poco, se de rotación, se produzca código de peor calidad, y nunca consigamos tener un equipo maduro de desarrollo.