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)

• Acerca de
• Últimas entradas

jgarzas

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.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023