Leyendo este post Potencia tu equipo (4) Evita jerarquías y especialistas, no me he podido resistir a hacer mis propias reflexiones al respecto, basadas en lo que he ido viendo durante muchos años de hacer software, viendo como los grupos y departamentos se hacen y deshacen para tratar de mejorar las carencias de la organización anterior.
Mi idea final es que no hay organización buena o mala, sino gente buena o mala. Las cosas no son blancas ni negras, cada organización tiene sus ventajas e inconvenientes, puede ser mejor o peor según para qué, pero al final funciona bien o no dependiendo de la gente que la integra.
Los grupos de especialistas tienen la ventaja de que acaban desarrollando su parte de código muy rápido, puesto que se la conocen perfectamente, y que de forma natural hacen sus propias librerías, ya que ellos mejor que nadie son capaces de ver qué cosas necesitan reutilizar siempre tal cual, cuales pueden reutilizar con algo de configuración y cuales cambian constantemente de un proyecto a otro. Y esta es la pega que he visto cuando se hacen grupos multi-disciplinares. Esos grupos tienden a trabajar aislados y no realizan tantas librerías comunes. Distintas partes de un mismo proyecto tienden a no parecerse unas a otras ni en la manera de funcionar, ni en aspecto visual, ni el estilo del código. Siempre acaban perdiendo bastante tiempo rehaciendo y uniformizando todo más adelante. Al final puedes ver un ejemplo real de falta de uniformidad.
Pero el trabajo por grupos multi-disciplinares tiene una ventaja enorme de la que carecen los grupos de especialistas. Al haber un grupo responsable de una funcionalidad, hay un grupo que se preocupa de que esa funcionalidad vaya bien totalmente. Cualquier bug que aparezca tiene un claro responsable (el grupo) y se suele corregir rápido. En los grupos de especialistas la integración puede/suele ser un infierno. No hay un responsable claro de la funcionalidad y cada grupo se limita a ver que su parte funciona y soltar "el marrón" a otro de los grupos. El resultado es que los bugs tardan mucho en corregirse y es fácil llegar a peleas entre miembros de distintos grupos o incluso grupo contra grupo.
Con todo esto quiero decir que las cosas no son ni blancas ni negras. Cada forma de trabajo tiene sus ventajas e inconvenientes y que debemos estar muy pendientes de los inconvenientes para no dar al traste con el proyecto.
Y lo más importante, la gente. No debes caer en el tópico de que si hacemos una estructura jerarquizada no va a funcionar porque el jefe será un torpe, pero si hacemos un grupo auto-gestionado va a funcionar todo de maravilla porque todos son guays. Cada uno es como es. El usar metodologías ágiles no hace que nadie sea más "guay". Ni hacer un grupo jerarquizado hace que el jefe sea torpe. He visto grupos jerarquizados funcionar estupendamente porque el jefe es capaz de tener a la gente contenta, dejarles las decisiones técnicas que no controla y haciéndoles rendir a tope (en su horario normal). Quizás no es lo habitual, pero tampoco son más habituales los grupos scrum que realmente funcionan como scrum que los que no lo hacen. Como digo, es cuestión de la gente (sea jefe o scrum master).
Da igual qué tipo de organización elijas, funcionará o no dependiendo de la capacidad y predisposición de la gente que haya en ellas. Un grupo jerarquizado funcionará muy bien si el jefe es competente. Los grupos de especialistas funcionarán muy bien si hay "buen rollo" entre ellos a la hora de integrar. Los grupos multi-disciplinares funcionaran muy bien si hay buen rollo entre ellos a la hora de uniformizar las cosas.
Y quiero poner un ejemplo real de falta de uniformidad al hacer las cosas distintos grupos sin comunicación fluida entre ellos. Una ventana con cuatro botones juntos, cada botón hace una cosa distinta y cada botón realizado por un grupo distinto. Lo único común que tienen esos botones es que realizan una consulta a base de datos y muestran una ventana de resultados. ¿Cual fue el resultado real?
- botón 1. Si no hay resultados en bd, no hace nada.
- botón 2. Si no hay resultados en bd, saca una ventana de aviso indicándolo.
- boton 3. Si no hay resultados en bd, saca la lista de resultados vacía.
- botón 4. Si no hay resultados en bd, saca una ventana de aviso indicándolo y la lista vacía.
Me habría gustado que hubiera un quinto botón y un quinto grupo, para ver por dónde salían.
Lo que me reafirma en mi sospecha que en las evangelizaciones sobre metodologias de gestion de proyectos de software hay mucho humo (algo de fuego tambien), mucho libro y mucha certificacion.
Aunque me temo que lo del humo es un caracteristica general del negocio del software.
Hola, la verdad es que coincidimos en lo fundamental, lo importante es la gente. Si lees la serie completa de mis posts sobre «Potencia tu equipo» verás que sí, que estamos en el mismo bando en este aspecto. Pero es importante organizar el entorno de trabajo y los equipos para que la gente no se «queme», dé lo mejor de si mismo y evolucione.
Sobre lo de tener equipos sin comunicación fluida, es un desastre total, de lo peor que puede pasar. Pero eso lo considero independiente de si son multidisciplinares o no.
Como muy bien dices la mayoría de equipos que hacen scrum en realidad no lo hacen, sino que «simulan» hacerlo. Implantar scrum es muy difícil, no se hace de la noche a la mañana y requiere que la gente aprenda a tomar responsabilidad de su trabajo más allá del sueldo que cobran y los jefes a dejar de ser jefes y transformarse en una parte más del equipo. Es un shock cultural.
Una reflexión: siempre me ha parecido misterioso que un jefe que no sabe de tecnología gestione un proyecto tecnológico. Encima parece que los mejores resultados se obtienen cuando ese jefe deja de tomar decisiones «técnicas» y se limita al project, al excel y al power point (tareas típicas de administrativo que se pagan mejor que la de un desarrollador). Que conste que actualmente hago de «jefe» pero me gusta luchar junto a mis tropas en el campo de batalla si es necesario.
Por cierto, me ha gustado tu post (aunque no lo pueda parecer por este comentario), se nota fruto de la experiencia y además ¡me ha hecho ilusión!
P.S. El ejemplo de los botones, ¡ muy bueno !
Hola Enrique, encantado de tenerte por aquí.
Debo decir que yo también soy partidario de las metodologías ágiles y estamos intentando implantarlas. Hemos «metido la pata» en las cosas que comento: grupos con jefes que se meten donde no deben (no todos), grupos de especialistas que no se coordinan bien (no siempre) y grupos multi-disciplinares que no se comunican bien (no siempre).
Yo, personalmente, me he dado cuenta de que es fundamental la comunicación y son fundamentales las reuniones diarias. Dan más sensación de equipo a la gente (dentro de un grupo o entre grupos), ahorran muchísimo trabajo cuando uno expone el problema que le «atasca» y otro más experto es capaz de resolvérselo con una sola frase y el proyecto va más encaminado con objetivos más claros. Las metodologías ágiles claramente potencian la comunicación y eso es muy bueno.
Pero nuestros intentos de implantar scrum, kanban o similar se quedan en eso, en intentos. Algunas de las prácticas sí las llevamos bien, pero no conseguimos ni el 50% de lo que yo creo que debería ser. El funcionamiento de esos grupos y hasta qué punto adoptan realmente scrum, varía mucho, dependiendo principalmente de la gente que hay en ellos. No como programadores, sino de «apertura de mente». Si se hace scrum master a uno «ambicioso», acaba convirtiendo al grupo en un grupo jerarquizado, en el que las reuniones diarias son para que cada uno le de cuentas de su trabajo.
Y veo muy difícil conseguir la comunicación entre grupos, sobre todo porque cada grupo tiene sus propios problemas y cuesta mucho que encuentren tiempo para hablar entre ellos de cosas que aparentemente no son su problema inmediato.
Es por ello que comento en el post que no sólo ser (o intentar ser) ágil es garantía de éxito. Aunque las metodologías ágiles tienen sus ventajas, el que un grupo (o conjunto de grupos) funcionen bien depende mucho más de la gente que compone ese grupo que de la metodología usada.
Se bueno.
En cuanto al ejemplo que mencionas la solución es fácil, … o compleja, según el punto desde donde lo mires. Nosotros teníamos un problema similar porque hacemos muchos proyectos (todos internos) y cada grupo hacía las cosas tal como lo cuentas en el ejemplo, todos de diferente manera. La solución fue crear un libro de estilo, lo cual llevó su tiempo porque hubo que poner de acuerdo a todas las partes, pero hoy en día todas las aplicaciones se realizan de la misma manera y sabes que cuando pulsas el mismo botón en distintas aplicaciones hará siempre lo mismo.
Saludos,
Rodrigo