Equipos o cirujanos

Escrito el 25 de Noviembre de 2009 a las 11:16 

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 :-D .

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:

Y se me ocurren varias más, pero entonces este artículo se haría insufrible. ¿Como lo véis vosotros?

Categorías: Gestión, Gestión de Proyectos
Tags: ,,,,
Compártelo

Comentarios

11 comentarios a “Equipos o cirujanos”

  1. Jorge , el 25 de Noviembre de 2009 a las 14:35 | Trackback

    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!.

  2. Ángel , el 25 de Noviembre de 2009 a las 16:18 | Trackback

    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? ;-)

  3. Jorge , el 25 de Noviembre de 2009 a las 17:09 | Trackback

    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 :-)

  4. Ángel , el 25 de Noviembre de 2009 a las 19:17 | Trackback

    Pásate por Nokia, Yahoo, Google, Sun… ¡Oh!, perdón, te referías a empresas españolas… :-D … Bueno, también te puedo presentar unas cuantas. No es requisito haber trabajado conmigo, pero ayuda bastante… :-D :-D :-D

  5. Pau Sánchez , el 27 de Noviembre de 2009 a las 8:43 | Trackback

    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.

  6. Viciosus , el 27 de Noviembre de 2009 a las 21:01 | Trackback

    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.

  7. Sergio Montoro Ten , el 27 de Noviembre de 2009 a las 21:39 | Trackback

    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?

  8. Ángel , el 28 de Noviembre de 2009 a las 13:12 | Trackback

    @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 :-D :-D :-D

  9. Sergio Montoro Ten , el 28 de Noviembre de 2009 a las 17:02 | Trackback

    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.

  10. Sergio Montoro Ten , el 28 de Noviembre de 2009 a las 17:15 | Trackback

    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.

  11. Ángel , el 30 de Noviembre de 2009 a las 9:05 | Trackback

    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 ;-)

Deja tu comentario




Buscar:

Suscriptores:

Kisei Dojo Aikido

Pastafari!

Tags

Que se dice por aquí:

Qué se dice por ahí:

Twitter

    Fotos

    www.flickr.com
    angel.medinilla fotos Más fotos de angel.medinilla
    Cerrar
    Enviar por Correo