Me encuentro ultimamente con algunas organizaciones que han ido creciendo desde equipos pequeños de personas y, conforme han ido añadiendo miembros al área de desarrollo, han ido evolucionando hacia un modelo de un proyecto – una persona. Se trata (espero) de una adaptación del “paradigma del cirujano estrella” publicado por IBM en los 60-70, en el marco del desarrollo de OS360 (¿alguien ha leido The Mythical Man Month? ). Según este modelo, los proyectos más productivos que IBM había detectado eran aquellos en los que existía un “cirujano estrella” que tenía en su mente la arquitectura y el diseño y realizaba toda la programación rodeado por un equipo de ayudantes (documentadores, testers, administradores…). Según las mediciones de IBM, un programador estrella aportaba 10 veces la productividad de un programador medio. Pilar Jericó, en “Gestión del Talento” (citada por Juan Palacio en su libro, si no recuerdo mal) va más lejos y afirma que en el mundo tecnológico los mejores lo hacen entre 50 y 100 veces mejor que la media, y la cifra aumenta conforme la tecnología se hace más compleja.
Monos y máquinas de escribir, vaya. Quien no se crea estas cifras, que meta a 100 programadores promedio en una sala y a Alan Cox en la otra, y a ver quién termina antes con la pila TCP-IP del núcleo de Linux .
Pero antes de que despidáis a toda vuestra plantilla de programadores promedio (a mi entre ellos, jejejeje) y salgais al mercado a buscar programadores estrella, preguntaos por qué el modelo fue abandonado.
Even though, que dicen los ingleses: suponiendo que el modelo sea válido en todos los casos, el problema es que lo que me suelo encontrar en las empresas con las que trabajo son programadores my buenos, estupendos, con talento… Pero seamos francos y humildes: no somos Alan Cox .
Así que ya tenemos el primer problema de este modelo: encontrar a estas “estrellas” que hacen de todo, que son capaces de enfrentarse a todo tipo de proyectos y productos. Y pagarles. Y fidelizarles. Y que no se conviertan en “Prima Donnas” tecnológicas a la primera de cambio.
Pero incluso obviando el tema de las estrellas, el enfoque de un proyecto – una persona (a veces en relación muchos a uno, jejeje) tiene una serie de problemas considerables, que es por lo que en Agile consideramos los equipos como los bloques de construcción básicos de proyectos, procesos y empresas. Y ojo, que un conjunto de personas que se sientan juntas no es lo mismo que un equipo. Un equipo es una forma de pensar ante todo, y el espacio que comparten no puede ser únicamente físico.
A lo que ibamos, que parezco una abuela divagando. Problemas del enfoque de un proyecto – una persona:
- Escalabilidad: el modelo funciona cuando tenemos cinco o seis personas, puesto que, para ver el estado del portfolio de proyectos, no tengo más que hacer una ronda por estas personas y que me cuenten como va todo. Es el Scrum Diario de Scrum o el stand up meeting de XP. Pero cuando la empresa empieza a ir bien y a crecer el modelo no tarda en colapsarse. Cuarenta personas, todas contándonos el estado de su proyecto (o sus proyectos) todos los días, o todas las semanas… Imposible. No hay más remedio que multiplexar. Cinco grupos de ocho personas, y un responsable por cada equipo. Con eso puedo volver a mis rondas diarias con cinco personas que me resumen el estado de todo. Mejor. Cada proyecto sigue asignado a una persona concreta (por ahora), pero hemos resuelto el problema de la escalabilidad… Formando grupos de personas (aun no equipos).
- Robustez: ok, tengo ya grupos de personas, pero de repente se va Paquito, y hay que traspasar sus proyectos. Como es el único que los conoce, estos proyectos van a sufrir considerablemente. Y lo que es peor: el año que viene nos piden que repasemos algunos proyectos de Paquito y nadie sabe nada de ellos. Relexionamos: en el futuro sería interesante que tuvieramos estándares de como hacer las cosas y documentásemos bien los proyectos para que podamos solucionar estas situaciones de una forma mejor. Pero el problema es que por mucho que le decimos a la gente que documente, como siempre vamos hasta arriba, al final siempre se queda la documentación por hacer. Quizás si las personas estuvieran un poco más al tanto de lo que hacen sus compañeros… Pero es muy dificil, muy dificil. Seguimos haciendo las cosas como siempre y obteniendo los mismos resultados.
- Flujo de conocimiento: cuando alguien comete un error, típicamente lo tapa, lo corrige y listo. Mañana otra persona, en la otra punta de la oficina, cometerá el mismo error. Y pasado otra. Y cada uno da soluciones diferentes. Por otra parte, un día alguien encuentra una solución ingeniosa a una necesidad habitual de los proyectos. Pero nadie se entera. Entonces reflexionamos y decimos que hay que montar un sistema de gestión del conocimiento, y desarrollamos una intranet, un blog, un wiki… Pero nadie los usa. Si hubiera una forma de que las personas se contasen unas a otras sus problemas y soluciones, y que unos revisasen el trabajo de otros… Bah, muy dificil.
- Duplicación: al igual que ocurre con los errores, los desarrollos comienzan a duplicarse. Un día nos encontramos con que dos personas, en dos esquinas de la oficina, han desarrollado dos librerías idénticas para el mismo problema. Vaya por Diox. Si hubiera una forma de sincronizar a todo el mundo…
- Incorporaciones: cuando reclutamos a juniors, sería interesante que pudieran ir aprendiendo de los seniors. Pero los seniors están muy liados con sus proyectos como para andar enseñando a la gente. Sí, ya dijimos antes que deberíamos tener estándares de códificación, sistemas de gestión de conocimiento… Pero no se hacen. Si pudieramos organizar a la gente en equipos, equipos de verdad, no solo grupos de personas, que se sincronicen a diario, compartan tareas y proyectos, programen por parejas de vez en cuando, hagan retrospectivas de grupo frecuentemente, analicen todos los proyectos juntos, distribuyan la carga según ellos mismos convengan… Así sería mas rápido y sencillo que una persona recién incorporada fuera pillando el ritmo y el estilo del equipo.
- Flexibilidad: si una persona está muy cargada y queremos reforzar su proyecto con más personas, significa que esas personas deben coger el proyecto desde el principio y adaptarse al enfoque que el primero ha dado al desarrollo. Si de alguna forma se hubieran hecho revisiones breves del proyecto desde el principio en equipo, no solo se habría podido ir incorporando el feedback de todo el mundo al enfoque del proyecto (¿Crowdsourcing anyone?
), sino que sería más fácil incorporarse al proyecto.
- Estandarización: antes hemos dicho que sería bueno contar con estándares para facilitar el trabajo en equipos, pero los estándares son buenos per se, no solo como herramienta. Permiten, como hemos visto, que las personas que se incorporan se adapten más rápidamente y nos permiten analizar de una forma coherente y estándar el rendimiento de los procedimientos para buscar las mejores soluciones y difundirlas entre los equipos.
- Tribus: asumidlo, los seres humanos somos tribales. Los que no lo eran se extinguieron en la última edad de hielo, muertos de hambre o devorados por los tigres dientes de sable, es una cuestión puramente evolutiva. Y a todos nos gusta pertenecer a una tribu, no ser guerreros cubiculares aislados, por muy romántica que nos parezca la idea del “justiciero solitario”. El problema es que cuando formamos una tribu, lo primero que buscamos es otra tribu a la que declarar la guerra. Y si nuestra tribu es “desarrollo”, le declararemos la guerra a “QA”, a “Infraestructura”, a “Diseño”… Es mejor crear la “tribu equipo”, donde todos colaboramos para sacar adelante los proyectos. E independienteemente de si nuestros equipos son multidisciplinares o no, el pertenecer a una tribu aumenta la motivación, la la motivación aumenta la productividad (quien no crea firmemente en esto debería de reflexionar largo y tendido sobre temas más fundamentales que equipos si / equipos no)
Y se me ocurren varias más, pero entonces este artículo se haría insufrible. ¿Como lo véis vosotros?
Totalmente de acuerdo en todo, pero …
Estarás de acuerdo conmigo en que 1 hora de 5 personas (para una tarea – proyecto) ni de lejos es tan productiva como 5 horas de 1 persona… Para que lo fuera, harían falta 5 tareas, o dividir la tarea en 5, con el sobrecoste en gestión y coordinación que esto conlleva, que al fin y al cabo también son horas.
Cuando un equipo tiene que ponerse de acuerdo en definir una implementación, un procedimiento de trabajo, estrategia, o lo que sea, esto requiere de reuniones (más, o menos informales, pero reuniones), posiblemente actas o correos (si no, se nos olvida), coordinación … con el modelo Juan Palomo todo desaparece o cuanto menos se minimiza, aunque efectivamente Juan tiene que saber CASI tanto Java como Chuck Norris!.
Para mí esto es muy evidente. Tanto, como que nadie sabe de todo (el mejor programador no puede ser un experto en todo … y si no, pon a Alan Cox a programar en .NET), o como se dice en mi pueblo, “Quien mucho abarca poco apreta”. También están las sinergias que en determinadas situaciones se producen, cuando 2 cerebros x 5 minutos resuelven el problema antes que 1 cerebro x 10 minutos (o a lo mejor ese único cerebro no llega a resolver el problema).
Yo creo que no existe una fórmula, y cada situación tendrá una configuración de equipo ideal … otra cosa serán los recursos de los que dispongamos a la hora de buscar esa configuración!.
No es cierto que desparezca en el modelo Juan Palomo, porque al final tienes a un Jefe de Proyecto o comercial o account manager… El que lleva la relación con el cliente, y tienes que estar haciendo informes, updates… Además, la carga del jefe de proyecto crece exponencialmente.
Con un modelo de self-management teams la carga de gestión se redue drásticamente, y por ponerte un ejemplo, si usas Scrum el overhead típico de gestión está entre un 8 y un 14% de tiempo (típicamente un 10%). Considero que emplear menos tiempo en coordinación, gestión y sincronización es muy peligroso. Otra cosa es que consideremos esto como “tiempo perdido” en lugar de “tiempo invertido”.
Ah, por cierto, no se trata de cinco personas metidas en una tarea en una hora. Podemos tener a cinco personas, cada una de ellas centrada cinco horas en su tarea, quizás de un proyecto distinto cada una, pero con una sincronización diaria de diez minutos entre todos, y una pila de tareas y proyectos estimada entre todos, gestionada entre todos y reportada entre todos, sobre la que todos hacemos reflexión a intervalos periódicos (Kaizen).
¿Qué tal te suena?![;-)](http://www.presionblogosferica.com/wp-includes/images/smilies/icon_wink.gif)
Suena muy cool, pero por desgracia (para mí) nunca he llegado a conocer en la práctica esos niveles de autogestión y optimización … ni en grandes empresas consultoras de nivel nacional o internacional (con certificación CMMi de por medio), ni en pequeñas empresas de desarrollo de software con menos carga burocrática y más flexibilidad.
Me parece genial, pero necesitaría verlo para pensar queno es una utopía… en el papel todos los algoritmos compilan![:-)](http://www.presionblogosferica.com/wp-includes/images/smilies/icon_smile.gif)
Pásate por Nokia, Yahoo, Google, Sun… ¡Oh!, perdón, te referías a empresas españolas…
… Bueno, también te puedo presentar unas cuantas. No es requisito haber trabajado conmigo, pero ayuda bastante…
![:-D](http://www.presionblogosferica.com/wp-includes/images/smilies/icon_biggrin.gif)
Yo la verdad es que no se si un programador estrella es 10 o 100 veces mejor que la media.
Lo que yo he visto que funciona en un grupo de muy buenos programadores, es que cada uno se “encargue” de un área del producto, y que como poco, haya otro programador (llamemoslo ayudante), que de vez en cuando solucione algún bug, implemente algún mini-feature, etc.. de tal forma que al final todos saben de todo (o al menos si se te va el programador principal, no te quedas en bragas). Así tienes que cada uno es responsable de un área del producto, y a la vez todos son responsables del producto final.
La cosa se escala porque tienes un manager que lleva al grupo de programadores, y tienes varios grupos, uno por cada proyecto.
Al final puedes ir a hablar con cada jefe de grupo para saber el estado de cada proyecto.
Eso sí, para mi, si un proyecto tiene mas de 5 o 6 desarrolladores, va siendo hora de pensar si se puede dividir en 2 proyectos distintos.
Todo esto es una opinión basada en mi experiencia hasta ahora. No se si funcionará en todos los productos y proyectos, pero donde yo he estado esto funcionaba muy bien. De todos modos, desde mi punto de vista, no había ningún programador medio en el grupo.
Yo creo que al final probablemente no queda más remedio que aceptar que el talento y la capacidad de hacer software de alta calidad simplemente es algo que no escalá ¿Acaso alguien ha preguntado a Ferrán Adriá por qué no piensa convertir su negocio en franquicia?
Me quedo con la reflexión de Joel Spolski al respecto.
Trabajo en Equipo = un grupo de gente haciendo lo que yo digo.
Y, una preguntilla, si tienes un tipo que produce como 10 ¿para que c… quieres a los otros 9?
@Pau , el equipo que describes es ideal. Enhorabuena por haber tenido la oportunidad de conocer un equipo así, te certificao que no todo el mundo pasa por eso en su carrera profesional.
@Vicious , el buen software sí que escala. Mira google o Linux. Lo que pasa es que la mayoría (la GRAN mayoría) de las empresas escalan mal, y si uno paa por diez empresas y en las diez han escalado mal, puede acabar concluyendo que “el buen software no escala”. Eso no excluye que quieras montar un negocio con el modelo Ferrán Adriá de “poco, caro y excelente”. Pero Apple hace excelentes ordenadores por *millones*, por ponerte un ejemplo.
@Sergio, si no fueras tú te contestaría energicamente. Conociéndote como te conozco prefiero mandarte al peo, Scrooge de los huevos!!!
![:-D](http://www.presionblogosferica.com/wp-includes/images/smilies/icon_biggrin.gif)
Por 25 pesetas, reto a cualquiera a citar los casos de software que funcione bien y que haya sido escrito conjuntamente por más de 5 personas (no valen bundles de retales como Debian).
Por ejemplo: Windows Vista.
Creo que una buena forma de entender mi argumentación es fijarse en un equipo de ciclismo o de fórmula 1.
Sin el corredor estrella, ya sea Indurain o Fernando Alonso, el equipo no es nadie.
Sin embargo, ya se ha visto y está más que demostrado, que el mejor piloto sin un buen coche y mecanicos macanudos no gana.
Al final lo que suele suceder es que por un proceso de selección natural, los mejores campeones, acaban conduciendo los mejores coches de los mejores equipos.
Sergio, un equipo de desarrollo no es un equipo de ciclismo o de fórmula uno. Es un equipo de futbol. Hay porteros, delanteros, defensas… Pero todos juegan el partido, y si uno está delante de la portería con el balón no vale decir “no, yo no chuto, que chute el delantero”. Cada uno tiene su especialidad, pero todos estamos en un mismo partido, y ganamos o perdemos juntos. No gana “Alonso” o “Indurain”, gana el equipo. Si concibes los equipos de desarrollo como conjuntos de desarrolladores independientes (fórmula uno, ciclismo, motos…) siempre habrá uno que gana y otros quedan por detrás. Tendrás conjuntos de personas, pero no equipos. No, no es lo mismo![;-)](http://www.presionblogosferica.com/wp-includes/images/smilies/icon_wink.gif)