| Planificación y seguimiento | Ridiculum Vitae | Gestion Theory |
Objetivos generales 2
Objetivos específicos 2
Introducción 3
Procedimientos 3
¿En qué consiste el equipo de cirugía? 3
Conformación del equipo 4
Resultados 4
Ventajas 4
Desventajas 4
Críticas 5
Opinión 6
Conclusión 7
Recomendación 8
Bibliografía 9
Apéndice 10
Analizar el capítulo The Surgical Team, del libro The Mythical Man-Month, aplicado a la gerencia de proyectos informáticos, trabajo en equipo.
El trabajo en equipo tiene un fin muy claro. Terminar el trabajo lo antes posible con la menor carga de trabajo para cada miembro del equipo. Sin embargo, para lograr esto, se deben de coordinar perfectamente todas las tareas asignadas, so pena de caer en el caos total.
En el presente documento se analizarán los equipos de trabajo y forma de organización para finalizar los proyectos de la manera más eficaz y eficiente posible, con la utilización del menor número de personal, ya que por supuesto esto incurre en grandes costaos para las empresas.
Todo profesional relacionado con la informática, a cargo de un proyecto, debe cumplir con fechas límites y en la mayoría de los casos con un presupuesto limitado, por esta razón, surge la necesidad de idear una forma de aprovechar al máximo los recursos, y a su vez el número de personal para dichos proyectos; para este dilema en la labor de un Gerente de Proyectos, existen variadas recomendaciones de como organizar un equipo de trabajo.
Muchos pensarían que añadiendo la mayor cantidad de trabajadores al proyecto, este sería terminado más rápidamente. Dicha hipótesis no es difícil de intuir, las pirámides de Egipto (según se cree, puesto que no hay datos concisos respecto a este tema en particular) fueron construidas por miles de esclavos, durante largos días de trabajo; en una observación más moderna, las líneas de trabajo, en las cuales se ejecuta una misma función por partes, y al final de la línea queda un producto terminado, finalizan sus labores más prontamente si añaden una mayor cantidad de personal; esto se da porque son trabajos en los cuales se utiliza un mismo método de trabajo, y todos los empleados los realizan de esa forma. No obstante, en proyectos informáticos la situación varía drásticamente, pues los programadores, por ejemplo, utilizan conocimientos adquiridos a lo largo de su carrera para desarrollar un sistema, cada persona tiene una metodología diferente para llevarlas a cabo.
Por lo tanto, el objetivo de este documento es el de dar a conocer una técnica recomendada por Brooks, F, en el libro The Mythical Man - Month, en cuanto a este dilema, así como las críticas recibidas por sus lectores, ventajas y desventajas de la propuesta.
El equipo de cirugía propuesto por Harlan Mills, sugiere utilizar pequeños equipos de tabajo, compuesto pr personas de primera clase (excelentes profesionales), en vez de proyectos compuestos por cientos de programadores.
Él propone emplear un equipo organizado como un equipo de cirugía, lo cual quiere decir, que en vez de que cada "team" trate de solucionar el problema pr separado, un miembro será el encargado de solucionar el problema mientras los demás lo apoyan.
En un equipo convencional, los compañeros simplemente se dividen el trabajo, entregando la responsabilidad del diseño e implementación a cada miembro. No obstante, en un "equipo de cirugía" el cirujano y el copiloto son los encargados del diseño de todo el código, esto asegura una integridad conceptual del trabajo.
Además, en un equipo tradicional, los miembros del equipo se encuentran en un mismo nivel, por lo que surgen diferencias invitables en cuanto a juicios e intereses; lo cual no ocurre en el "equipo de cirugía", pues es el cirujano quien toma las decisiones.
Para algunos, esta recomendación se encuentra desactualizada, pues, proviene de un libro escrito hace más de 20 años.
Para algunos ( específicamente, Sam Wilson(1)), los grupos pequeños que realizan tareas completas, son extremadamente difíciles de manejar. Grupos de trabajo sin dirección (un programador en jefe, por ejemplo), inevitablemente, fallarán. Sin embargo, la implementación del equipo de cirugía, es la solución a estos dos males de la Ingeniería de Software.
Jeremy Arnold, reconoce que no ha leído The MMM , pero que el desarrollo de sistemas abiertos, puede ser igual de satisfactorio, y eficiente comparado a un trabajo en equipo dirigido, como ejemplo Linux, un sistema operativo desarrollado por miles de programadores de todo el mundo, gracias a Internet, mucho más estable que otros desarrollados por empresas tan poderosas como Microsoft.
Es dificil implementar lo sugerido en el libro, los deadlines lo imposibilitan.Stu Charlton.
Martin Vermer, recomienda, no confiar en software diseñado por más de 10 programadores..., la mayoría de los programas desarrollados abiertamente, están construídos por módulos.
Lo sugerido por el libro no es más que una novela, inaplicable a la vida real. Brandon S. Allbery.
Después de analizar la estrategia de trabajo en equipo denominada "equipo de cirugía", hemos comprendido, la diferencia abismal que existe entre un equipo de trabajo diseñado para laborar en una empresa ajena a la informática, y lo complicado que puede ser el establecer técnicas de trabajo para un grupo de programadores y análistas en el cual todos piensan diferente. The MMM ha sido criticado por diversos desarrolladores, la crítica más fuerte que se le ha hecho está relacionada con el tiempo en que fue escrito, para muchos esta publicación está desactualizada. Otro punto importante de recalcar, son los "deadlines", etapa en la cual el proyecto asignado, es terminado ( y en algunas ocasiones, entregado sin sus respectivas pruebas de "debuggeo"), dependiendo de la fecha asignada para la finalización del proyecto, que por lo general son tiempos muy cortos, un gerente de proyecto podría aplicar el método expuesto en The MMM sin embargo la realidad es otra, y sobre todo la realidad nacional, este libro sugiere un cambio total de mentalidad, como experiencias personales, hemos observado como la división del trabajo en un proyecto informático de forma convencional, no tiene como único fin terminar lo más pronto posible, sino, eliminar responsabilidades, así cada quien es responsable de su parte, y si el proyecto fracasa, la responsabilidad recaerá en quien no pudo finalizar con éxito su parte.
Todo esto nos hace pensar, que un metodología de trabajo, tan interesante como "The surigical team", no irá a tener cabida, para un gerente de proyectos experimentado, que esté acostumbrado a una estrategia de trabajo convencional.
Durante muchos años se ha considerado importante una buena organización en el desarrollo de aplicaciones o sistemas en grupo, cada gerente de proyectos tiene una metodología diferente para la solución de los problemas, una de las mayores complicaciones para el desarrollo de las mismas, está relacionada con la cantidad de personas envueltas en la tarea, y lo difícil que es la comunicación entre ellas, las fechas límites son un factor influyente en el éxito o fracaso de cada proyecto, no obstante, hace 25 años, se escribió un libro títulado "The Mythical Man-Month", éste, nos sugiere un tipo de organización similar al de un equipo de cirugía, para muchos es un libro esencial, y totalmente aplicable a la vida real, que puede lograr grandes cambios, para otro no es más que una novela, no utilizable en la vida real. Sin embargo no se puede negar que existen bases para pensar en una mejor organización de los equipo de trabajo para solucioner los problemas que estos nos acarrean, no importa cual método utilicemos, se debe organizar debidamente cada proyecto, y documentar todo lo realizado.
Probablemente, no todo líder de proyecto, o gerente de proyecto, observe con buenos ojos un libro que intenta cambiar drásticamente la forma en que realiza sus tareas, sin embargo, se de debe anotar, que cada profesional debe estar abierto a nuevas técnicas que puedan ayudar en el manejo de sus actividades, este es un my buen ejemplo, sería recomendable poner en práctica esta estrategia de trabajo, y observar sus resultados, algunos de las personas que critican este libro nunca se han tomado la molestia de hacer la prueba, y observar el comportamiento de lo participantes. La lectura y puesta en práctica de estos conocimientos pueden ser la base en un futuro éxito profesional.
Brooks, F, The Mythical Man-Month, Adisson Weley, Aniversary Edition, 1995.
Hemos. Slashdot:Review: The Mythical Man Month: Essays on Software Engineering. 10 Ago 1999.( http://slashdot.org/articles/980805/1148235_F.shtml).
The Newest Solution
by David Jensen (djensen@madison.tds.net) on Wednesday August 05, @12:01PM
<>
Another problem with MMM is that the wrong people read it. Software engineering is all well and good if you know what process you are implementing in software and engineering. Software engineering does nothing if the process is badly designed, obsolete, confusing, misunderstood, or nonexistant. Unless the people defining the processes understand what they want done, software engineering can, at best, only give a well-implemented bad system.
Now, many companies believe that they should buy systems that are prebuilt (BAAN, SAP, PeopleSoft are good examples), but as anyone who has worked with them knows, nothing is solved by that. Instead of having your own badly designed systems that you don't understand, you have someone else's systems that you don't understand. Are the systems good or bad? They may be either, but they are useless if you fail to understand them. Give a copy of MMM to your favorite CEO today, then offer to explain it after he has read it.
[Reply to this comment]
Yes!
by Rob Becker (becker@ab.edu) on Wednesday August 05, @12:06PM
Yes! I think i got the first comment!! And there was much rejoycing(sp?)
Well anyway, couple of friends at UUnet read this and recomended it. Have to check it out...
[Reply to this comment]
'tis a good one
by Sean McDermott (smcdermott@mediaone.net) on Wednesday August 05, @12:06PM
This was compulsary reading when I studied Computer Science but of course I neglected to read it then. Having read this recently after several years of software development I really found I got a lot from it. The examples are a little out of data but the main concepts still holds true to this day. I love his example:
If it takes one woman nine months to have a baby, then logically nine woman could produce one baby in a month, right? It's amazing even now how man-months are split up on major projects as if they are completely divisible across people...
[Reply to this comment]
A good lession for software product managers
by Stoker (david_stokes@yahoo.com) on Wednesday August 05, @12:12PM
Nine women pregnant for one month does not have the same end result as one woman pregnant for nine months. This was originally noted by Werner VonBraun when asked by the US government why tossing scientist at the 'space race' was not helping. More resources are not often better. I've seen many projects that were struggling suddenly inundated with new bodies to the point where it took more time to get the newbies up to speed than to sinish with the original crew.
[Reply to this comment]
1. En un comentario hecho acerca del libro en http://slashdot.org/articles/980805/1148235_F.shtml
