Inicio arrow Blog arrow Gestión de proyectos arrow Ponga a los mejores en los proyectos pequeños Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

Ponga a los mejores en los proyectos pequeños
04.09.2007

equipoAl aumentar el tamaño del equipo del proyecto, disminuye la productividad personal. ¿Es porque en los equipos grandes los programadores son peores? ¿Porque la gestión los entorpece?.

Por supuesto que se trata de una generalización, pero es una percepción recurrente, o al menos a mi me da esa impresión, y por eso me ha llamado la atención este consejo del consultor de EE Times, Jack Ganssle:

Ponga a los mejores en los proyectos pequeños.
Los mejores desarrolladores son seis veces más productivos que el más flojo del equipo, pero sólo cuando se mide a ambos en proyectos pequeños.
A medida que el proyecto crece el mejor y el peor son igual de improductivos. Los grandes proyectos tienen grandes cantidades de ruido, reuniones, informes, e-mail...
Un espabilado atiende en las reuniones a la misma velocidad que un torpe.

AddThis Social Bookmark Button

 

 

 

Trackback(0)
Comentarios (9)Add Comment
¿Conclusión?
escrito por Joserra, September 04, 2007
Entonces el corolario de esto es ... ¿que da igual quien desarrollo un proyecto grande? smilies/smiley.gif Por que si "a medida que el proyecto crece el mejor y el peor son igual de improductivos" será por que el mejor tiende a ser como el peor, no al reves. De manera que poniendo a los "peores" en los grandes será lo mismo.

Jeje, no creo que sea tan radical, pero lo que está claro es que contra más personas existen en un proyecto, los problemas dejan de venir del lado tecnológico, sino de la complejidad funcional del mismo o del mismo problema de "crear equipo" y su comunicación. Mi recomendación si llevas proyectos grandes: lee Peopleware!! smilies/wink.gif
No arregla el problema
escrito por martin, September 04, 2007
Estoy de acuerdo contigo, Joserra. Realmente yo no creo que esa política ayude mucho a la empresa a largo plazo, ya que en caso de pasar algo así sería bastante claro que la enfermedad ya está dentro, y que existe un problema importante en el proceso de trabajo dentro de la empresa (i.e. necesita ser más ágil).

Olvidando esto, lo cierto es que a corto plazo la medida no es mala. Por mi experiencia, cuando un super-programador empieza a verse inmerso en un mar de documentación, reuniones, especificaciones, negociaciones, viajes a clientes, etc. etc., inmediatamente el proyecto dejará de ser atractivo para él, y el problema ya no es que pase a ser igual de improductivo que los malos programadores, sino que probablemente se irá de la empresa.

...
escrito por Juan, September 04, 2007
Si, es que yo no me atrevo a sacar una conclusión; o al menos no una simple. Como decís se juntan muchas cosas: cuando el proyecto crece aparecen problemas serios que no son de índole técnica. La organización empieza a hacerse más pesada y "quema" a los buenos programadores...

Como son varias las razones, y además se potencian al combinarse, resumir una conclusión es complicado, pero al ser habitual que en los equipos grandes la productividad personal sea menor, me ha llamado la atención el consejo de Jack Ganssle.

No se si la imagen de comparación siguiente, con la que me represento de alguna manera la situación, está muy bien traída, pero en mi forma de verlo podría valer:

Cuando el tráfico es denso, y la calle está muy normalizada con medidas de regulación y seguridad (semáforos, pasos de cebra...) la diferencia de velocidad entre una bicicleta, un ciclomotor y un deportivo no es significativa.
Si hay menos tráfico y pocas normas, la diferencia entre la bicicleta y el deportivo sí que es importante.
En este último caso interesa que los conductores sean buenos, porque la seguridad depende de su buen hacer más que de las medidas de regulación y seguridad, que son escasas.

Quédate con los buenos!
escrito por J. Babuglia, September 04, 2007
Brooks: "The conclusion is simple: if a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming". (the mythical man-month, p. 30). Saludos!
Muy buena analogía
escrito por martin, September 04, 2007
Muy buena analogía Joserra, me quedo con ella.

ups
escrito por martin, September 04, 2007
Perdón, muy buena analogía JUAN.
Conclusión: divide y vencerás
escrito por joseluisGV, September 05, 2007
Cuando te enfrentas a un proyecto grande (hablamos de número de personas involucradas, entidades -físicas y /o lógicas- y de tiempo de desarrollo), en mi humilde opinión es dividirlo en una cantidad de "mini-proyectos" tal que puedan afrontarse con un número de personas suficientemente pequeño para que deje de ser "grande".
Pongamos por ejemplo, dado el axioma 20/100, dividirlo en grupos de 5 personas (donde al menos 1 será un "crack"), y establecer para el objetivos a corto plazo, documentación mínima, etc, etc...

Mantendrás su entusiasmo, el "flojo" tendrá oportunidad de aprender del "bueno" (trabajarán codo con codo), y verán sus metas cercanas en tiempo y esfuerzo.

En realidad es lo que llevamos haciendo desde hace años con nuestras propias líneas de código... dividir y dividir en métodos cada vez más pequeños para reutilizarlos, depurarlos más facilmente, intentar incluso hacer primero los test...

Con la gente es igual. Los proyectos son iguales que un programa...
Divide a un gran grupo de gente en grupos pequeños, de forma que "hacer grupo" es mucho más facil, marcando objetivos diferentes, etc....

Obviamente, esto SOLO es posible si cuentas con un "product manager" o gestor de proyecto en condiciones, además de tener que dedicar a al menos un grupo de los creados a integrar módulos unos con otros....
En cualquier caso, NADIE es bueno en algo SIEMPRE (y nadie "nació" siendo buen programador), aunque algunos tengan ese "algo" especial que les diferencia del resto...
El problema está en los grandes proyectos y en los grandes equipos
escrito por Daniel, September 06, 2007
Hasta la fecha no he visto un gran proyecto que acabe con un retraso y un sobrecoste medianamente aceptables. En casi todos, las desviación es escandalosa cuando no son directamente cancelados. Sin embargo, si conozco muchos pequeños proyectos acabados en tiempo y coste, que funcionan.
El problema está en que la informática actual es incapaz de desarrollar grandes proyectos. Simplemente no sabemos hacerlo. Es como si a un arquitecto del 1.000 ac. le encargaran hacer un rascacielos de 50 plantas. Tenemos que seguir probando metodologías y herramientas, y continuar desarrollando habilidades para algún día poder afrontar el desarrollo de un gran proyecto con las mismas garantías que los arquitectos, desde el bueno hasta el menos bueno, hacen edificios. ¡Los edificios hechos por los arquitectos no buenos no se caen!
La informática lleva poco más de 50 años y ya pretendemos construir catedrales cuando lo que hemos hecho hasta la fecha bien son chavolas de barro.
La única sólución factible hasta el momento, desde mi punto de vista, es dividir y atacar proyectos pequeños, que si sabemos ejecutar de forma exitosa. Con el tiempo podemos atacar proyectos pequeños pero de mayor tamaño. Y así, hasta que algún día alguien sea capaz de ejecutar con exito un gran proyecto.
Saludos.
Para seguir leyendo....
escrito por Adrian Lasso, September 17, 2007
Hola Juan,

Creo que el post de Jim Highdsmith también nos da una señal de alerta sobre el armado y gestión de equipos de desarrollo.
Muy bueno tu post.

http://blog.cutter.com/2007/09...ng-teams/

Saludos,
Adrian

Escribir comentario

busy
 
< Anterior   Siguiente >
Advertisement





Artículos relacionados

Registrado en Safe Creative