Pages Menu
Categories Menu

Posted by on Mar 10, 2015 in General | 4 comments

Tipologías de equipos software (I). El equipo “Control y Mando”

No fue hasta el otro día, en el que, mmm, llamémosle, Paulina, un pseudónimo, claro, me llamó para consultarme “-Cómo crees que debería estructurar mejor mi equipo, ¿ves algo por lo qué no funciona?-“, cuando me di cuenta que algo tan estudiado y sufrido (lo he vivido) como es las tipologías de proyecto no era un tema tan comúnmente conocido como yo creía.

Es por ello, que estoy, comenzando con este, escribiendo una serie de post sobre tipologías típicas a la hora de organizar un equipo de desarrollo software, y porque algunas no funcionan. Comencemos por lo desgraciadamente más común… el equipo “Control y Mando”.

La tipología de equipo “Control y Mando”, desgraciadamente, es la más ampliamente demandada y usada en el mundo del desarrollo software, si bien, ciertamente, no con tanto éxito como espera quien la implanta.

La gestión de equipos tipo “Control y Mando” se basa e inspira en la gestión militar. La idea es tener un grupo pequeño de gestores (mandos militares), un grupo multitudinario de programadores (soldados), todo ello jerarquizado.

La idea es que a la gente se le dice lo que tienen que hacer, sin idea de que piensen, duden o aporten, solo que ejecuten (programen). De ahí que hay quien también llama a esta tipología “Code Monkey” (monos programando).

Este tipo de gestión es otra herencia más de querer encajar el desarrollo software en los modelos de gestión de la industrialización, de la construcción de casas, carreteras, etc., (tema que ya tratamos hace unos años en dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas).

Y viene muy de la mano del ciclo de vida en cascada. Y, sintetizando, de la idea de que en un proyecto software puede haber una única fase de diseño en la que mentes pensantes acoten el trabajo que harán un montón de programadores, muchas veces incluso en otro país, en una única fase de programación, que seguirán esas directrices al pie de la letra y sin pensar.

Los problemas de esta tan demandada tipología de proyectos software han sido expuestos por numerosos autores, por numerosas experiencias, etc., desde hace años (sin el suficiente éxito, también hay que decirlo, a tenor de lo que aún nos, o me, lo encuentro).

Joel Spolsky le dedicó un artículo en su momento, Brooks, Putnam, etc., todos ellos exponiendo las razones por las que este modelo no funciona. Razones que te voy a sintetizar en cuatro puntos.

1 – En el ejército, es posible dar una orden al mismo tiempo a un gran número de personas y que todas la ejecuten. ¡Avancen! Un proyecto software requiere mucho más de “micro gestión”, puede haber “ordenes” generales de alto nivel pero tiene que haber gestión de nivel operativo, raro es que dos personas a lo largo del proyecto hagan exactamente lo mismo, raro es.

2 – En el ejercito, el conocimiento necesario para tomar decisiones estratégicas está más, casi exclusivamente, en la “gerencia”, en software la mayoría de las veces el que tiene más conocimiento de si algo es viable, posible, si vamos a llegar a tiempo, de cómo se hace, si se puede, de hacerlo bien, mal, de si va a explotar al pasar a producción, etc., es aquel que está “en el frente”. Por ello el conocimiento, y al toma de decisiones, debe fluir de arriba abajo y de abajo arriba, no solo de arriba haca abajo.

3 – En el ejercito, el trabajo es de componente muy físico, en software intelectual. Por ello, la odio, la peor frase que puedes decir a alguien de desarrollo es eso, lo he vivido, de “Aquí yo soy el jefe y tu, como en el ejercito, eres un soldado”, porque desmotivarás, la motivación – desmotivación es clave para la productividad. ¿Te has parado a pensar cuánto te cuesta que la gente se vaya de tu empresa?

4 – En el ejercito, se utilizan modelos de gestión pensados para mucha gente, en software mucha gente en un equipo es sinónimo de que vas a fracasar, o de que vas a desperdiciar toneladas de productividad. Mucha gente es más desperdicio el tareas de gestión y aumento innecesario de canales de comunicación. De ahí viene que “Añadir gente a un proyecto software con retraso hace que se retrase más”, algunos detalles y revisiones y de que los equipos con mucha gente (más de 7) son menos productivos. O por qué tener equipos pequeños es una buena práctica (ágil, además)

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

4 Comments

  1. Estimado Javier, cuando se habla del ejército hay que ir con mucho cuidado. De hecho te recomiendo la lectura de la introducción del libro “La muerte de la Wehrmacht” de Robert M.Citino (ed. Crítica, 2009) donde se describen conceptos muy interesantes sobre el modo en que funcionaba el mando en el ejército alemán desde el XVIII. Hay un concepto muy importante, el Selbständigkeit der Untherführer, también conocido como Auftragstaktik, que básicamente quiere decir que el responsable de una unidad en el frente es el qué mejor cualificado está para tomar decisiones y no la jefatura que puede estar a decenas de kilómetros de distancia. Este concepto es muy potente porque dotó al ejército alemán de una gran autonomía y flexibilidad. El éxito de Alemania en la batalla de Francia no se explica sin la aplicación de este principio.
    Otros ejércitos -inglés, estadounidense, soviético- estaban ferreamente jerarquizados de modo que las decisiones se tomaban tarde y mal.
    Cuando he gestionado proyectos, sobre todo si son grandes, siempre he impulsado la aplicación de la Auftragstaktik -mis equipos se quedaban patidifusos pensando que estaba medio loco hasta que veían que funcionaba-. No todas las decisiones eran correctas pero muy pocas fueron erróneas y ninguna puso en peligro la evolución del proyecto. La gente se sentía cómoda y con autoridad: eran parte del proceso de toma de decisiones y su palabra valía.

    Algún día escribiré un blog sobre mi experiencia en la aplicación del “modo de hacer la guerra alemán aplicado a la gestión de proyectos”

    Un cordial saludo

    • Muy interesante, muy interesante… siempre se aprende algo

    • Hola José Luis,
      Muy interesante tu post. Me gustaría saber si tienes más información sobre las experiencias que has tenido aplicando el “modo de hacer la guerra alemán aplicado a la gestión de proyectos”

  2. Felicidades por tu blog Javier Garzas!!
    Me parece muy interesante y acertado el comentario de Jose Luis. Es necesario que haya un lider que demuestre seguridad y autoridad en la toma de desiciones, logicamente siempre estar prestos a oir sugerencias del equipo.
    Escribo desde Santa Cruz de la Sierra – Bolivia

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This