EQUIPOS DE TRABAJO

Usos de los equipos de trabajo en el software Un equipo de trabajo es algo ms que un conjunto de personas que desean trabajar juntas para formar un equipo, es un nmero de personas pequeo, con habilidades complementarias, que estn comprometidas en un propsito, objetivos de rendimiento y con un enfoque comunes, en el que todos sean responsables ante todos. Tareas espec ficas del equipo! "esarrollo y revisin de requisitos del proyecto. "esarrollo de la arquitectura y las directrices del diseo del proyecto. "efinicin de aspectos del entorno t#cnico. "esarrollo de los estndares de codificacin del proyecto. $oordinar el trabajo en las partes relacionadas del proyecto. "iseo de las partes complicadas del sistema. %evisin del diseo y cdigo de los desarrolladores individuales. "epuracin de las partes ms complicadas. &rueba de requisitos, diseo y cdigo. 'uditor a del avance del proyecto. (antenimiento del soft)are, una ve* construido. 'unque algunas de las tareas anteriores las podr a reali*ar una sola persona, se pueden beneficiar de la participacin de dos o ms mentes, lo cual requiere la interaccin entre los miembros del proyecto. +i las mentes trabajan juntas, a veces el total puede ser mayor que la suma de las partes. +i hay desacuerdo, puede ser menor. Un ,equipo- e.iste siempre que dos cabe*as juntas funcionan mejor que cada una por separado. !" I#portan$ia del equipo de trabajo /os proyectos pequeos pueden pasar sin estudiar cuestiones sobre equipos de trabajo, pero se beneficiarn de su tratamiento. /os proyectos grandes son esfuer*o de grupos, y las caracter sticas de los grupos juegan un papel muy importante en el #.ito. 0ariaciones en la productividad del equipo. /os investigadores han encontrado diferencias del orden de 12 a 1 en la productividad individual. /os investigadores tambi#n han encontrado diferencias importantes en los niveles de productividad de los equipos. "espu#s de anali*ar 34 proyectos, 5arry 5oehm lleg a la conclusin de que los mejores equipos eran al menos 6 veces ms productivos que los peores 75oehm, 14819. "e (arco y /ister identificaron diferencias de productividad de :, 3 a 1 en un estudio de 133 programadores de 18 empresas 7"e (arco y /ister, 148:9. /a diferencia en la productividad se manten a incluso entre grupos de desarrolladores con niveles de e.periencia similares en un factor de ; a 1 y 6 a 1. 0alett y (c <arry informaron de diferencias de = a 1 y ; a 1 en la productividad entre diferentes proyectos del /aboratorio de >ngenier a de +oft)are de la ?'+' 70alett y (c <arry, 14849. /a conclusin es que entre grupos con diferentes conocimientos y diferentes niveles de e.periencia, hay una diferencia de : a 1 en la productividad. @ntre grupos con similares conocimientos y niveles de e.periencia, hay una diferencia en la productividad de =A: a 1. $ohesin y rendimiento. /os miembros de los grupos unidos trabajan duro, se divierten con su trabajo, y emplean gran parte de su tiempo centrndose en los objetivos del proyecto. /os participantes en proyectos con malas dinmicas de equipo normalmente no estn centrados y estn desmorali*ados, y emplean gran parte de su tiempo trabajando en objetivos opuestos.
/aBhanpal 7144;9 descubri que la unin del grupo contribu a ms a la productividad que las capacidades o

e.periencia individuales de los miembros del proyecto. /aBhanpal apunt que los directores normalmente escogen a los miembros del proyecto basndose en el nivel de e.periencia y en las posibilidades individuales. /aBhanpal sugiere que los directivos deber an designar a los desarrolladores basndose en sus posibilidades para contribuir primero a formar un equipo unido, y solo luego basarse en sus posibilidades individuales.

!% &rea$i'n de un equipo de alto rendi#iento /os equipos productivos a veces se caracteri*an por ser equipos que se han ido formando o equipos con una gran unin. Un equipo con una gran cohesin, un alto rendimiento y que se ha ido moldeando a s mismo, tiene una serie de caracter sticas comunes! Una alta visin u objetivo compartidos. Un sentido de identidad de equipo. Una estructura dirigida a los resultados. (iembros del equipo competentes. Un compromiso con el equipo. $onfian*a mutua. >nterdependencia entre miembros del equipo. $omunicacin efectiva. Un sentido de autonom a. Un sentido de enriquecimiento. Tamao del equipo pequeo. Un alto nivel de disfrute. @n 1484, /arson y /a Casto publicaron un estudio en el que encontraron una consistencia poco usual entre los atributos de los equipos altamente efectivos 7/arson y /a Casto, 14849. !( )allo de los equipos de trabajo! )alta de *isi'n $o#+n. @s dif cil que los equipos se formen si no comparten una visin comn. /as organi*aciones impiden a veces la cohesin de los equipos echando abajo sus ideas. $uando la idea se viene abajo, el equipo tambi#n. )alta de identidad. /os miembros del equipo podr an estar dispuestos, pero ninguno desempea la funcin de soporte, y si nadie cuida del equipo, #ste no se puede formar. $ada equipo necesita tener a alguien que se responsabilice de mantener la salud del equipo. /os equipos tambi#n pueden tener falta de identidad si uno o ms miembros estuvieran trabajando de forma individual en ve* de formar parte del equipo. Day muchos sitios apropiados para personas que trabajan de esta forma, pero su presencia puede ser fatal para la formacin de un equipo. )alta de re$ono$i#iento. 'lgunas veces los miembros de un proyecto participan en el equipo de un proyecto en el que ponen su cora*n y su alma, y slo sienten que su esfuer*o no se aprecia. +i una organi*acin desea crear un equipo de gran rendimiento en ms de una ocasin, deber a asegurarse de reconocer el esfuer*o e.traordinario la primera ve* de forma apropiada. Barreras de la produ$ti*idad. ' 0eces los equipos fallan porque creen que no pueden ser productivos. /os equipos no pueden sobrevivir si se les impide reali*ar su trabajo. 'lgunos e.pertos dicen que la primera funcin de un director de soft)are es eliminar las barreras de la productividad, de forma que los desarrolladores que est#n motivados por s mismos puedan ser productivos 7"e (arco y /ister, 148E9 &o#uni$a$i'n inefi$iente. /os equipos no se forman si no se pueden comunicar regularmente. )alta de $onfian,a. /a falta de confian*a puede destro*ar la moral de un equipo. Una ra*n por la que normalmente los equipos no se forman dentro de organi*aciones

burocrticas es porque las organi*aciones Fen diversa medidaG estn basadas en la falta de confian*a. /a falta de confian*a en los empleados suele estar institucionali*ada. /os directivos que prestan ms atencin a los detalles de administracin del equipo que a los resultados que consiguen, demuestran una falta de confian*a. /os directivos que gestionan poco las actividades de sus equipos, que no les permiten reunirse con sus clientes o que les dan fechas l mite falsas, estn dando signo de que no conf an en ellos. Personas proble#-ti$as. 'lgunos programadores intimidan a sus compaeros utili*ando sus planteamientos de diseo. +us compaeros, en ve* de enfrentarse, se conforman con sus demandas de diseo, aumentando su contacto con ellos. +i un responsable tolera a un solo desarrollador al que sus compaeros consideran como un problema, se estar influyendo en la moral de los buenos desarrolladores. /as reclamaciones ms intensas y consistentes de los miembros del equipo eran que los responsables del equipo no estaban dispuestos a enfrentarse y resolver los problemas asociados al mal cumplimiento individual por parte de algunos miembros del equipo 7/arson y /a Casto, 14849. /os desarrolladores consideran esta conducta del responsable como un punto negro muy significativo de la directiva, ya que los directivos casi siempre piensan que sus equipos van mejor de lo que creen sus miembros. /os problemas personales suelen ser fciles de identificar si se sabe dnde buscarlos! Hcultan su ignorancia en ve* de intentar aprender de sus compaeros de equipo. Tienen un deseo e.cesivo de intimidad. +on reservados. +e quejan de las decisiones de los equipos y continan revisando antiguas discusiones despu#s de que el equipo haya terminado. /os otros miembros del equipo se r en o se quejan de la misma persona. /os desarrolladores de soft)are no suelen quejarse directamente, de forma que hay que preguntar si tienen problemas cuando se oye mucho ruido. ?o se ponen a trabajar en las actividades del equipo. @nsear a la persona problemtica a trabajar en equipo a veces funciona, pero normalmente es mejor que lo haga el equipo en lugar de que intenten resolverlo los directivos o los responsables. Dabr a que preparar al equipo sobre cmo manejar al miembro problemtico del equipo. +i la preparacin no produce resultados rpidamente, no tema echar a una persona que no tiene el menor inter#s por el equipo. De aqu las tres ra*ones principales! @s raro ver un problema importante provocado por la falta de e.periencia. @s casi siempre cuestin de actitud, y las actitudes son dif ciles de cambiar. $uanto ms tiempo se mantiene una persona que causa problemas, esta persona adquirir ms legitimidad a trav#s de contactos casuales con otros grupos y directivos, un crecimiento de la base del cdigo que la persona tiene que mantener, etc. 'lgunos directivos comentan que nunca se han lamentado de e.pulsar a alguien. +lo lamentan no haberlo hecho antes. Un directivo se podr a preocupar por la p#rdida de la base si se sustituye a un miembro del equipo, pero en un proyecto de cualquier tamao, se compensar la p#rdida de base por la eliminacin de una persona que est# trabajando en contra del resto del equipo. Day que cortar la p#rdida, y entonces la moral del resto del equipo mejorar. !. &onfi/ura$i'n de equipos a lar/o pla,o! ' continuacin se muestran algunas de las ra*ones por las que es necesario mantener unidos a los equipos estables. 1. 0a1or produ$ti*idad. $on una estrategia de equipo estable, un grupo se mantiene unido si se crea dentro de un equipo, y se disuelve si no lo hace. +i se mantienen unidos a los equipos productivos, se consiguen grandes ganancias. @l efecto total que genera es una

=.

;. 6.

:.

,media superior- del nivel de rendimiento en la organi*acin. &ostes ini$iales #enores. (anteniendo juntos a los equipos efectivos, se mantiene parte de la visin, identidad del equipo, comunicacin, confian*a, y el depsito de buena voluntad derivados de la finali*acin de un buen proyecto juntos. Tambi#n se mantienen los m#todos t#cnicos espec ficos y el conocimiento de herramientas espec ficas dentro de un grupo. 0enor ries/o de proble#as $on el personal . /os problemas personales que surgen por personas que no trabajan bien juntas cuestan al proyecto tiempo y dinero. @stos problemas se pueden evitar completamente manteniendo al equipo unido una ve* formado. 0enos $a#bios de personal. "e(arco y /ister estiman que el =2 por 122 de la medida del gasto total de la compa a se va en cambios de personal 7"e(arco y /ister, 148E9. %esulta menos probable que las personas que se han integrado en grupos unidos abandonen la compa a que las que no lo han hecho 7/aBhanpal, 144;9. /os desarrolladores han encontrado un entorno en el que se divierten y pueden sentirse productivos. El te#a de la ina$ti*idad. @n ocasiones, las organi*aciones se muestran recelosas de mantener a los equipos juntos, ya que tendr an que estar pagando a un equipo que no est haciendo nada hasta que llegue un proyecto apropiado para empe*ar a trabajar. Ista es una objecin vlida, pero la mayor a de organi*aciones, en el fondo, no lo consideran ltimamente como un fuerte inconveniente. /as organi*aciones que miran e.clusivamente el coste del tiempo perdido no tienen en cuenta los costes de reconstruccin de los equipos para cada proyecto nuevo. @l coste de construccin de un equipo nuevo incluye el coste de unir al equipo y el de intentar que el equipo funcione conjuntamente. /as organi*aciones tienden a no tener en cuenta el dinero que se pierde separando un equipo de alto rendimiento. 'lgunas organi*aciones se preocupan de que si se mantienen a los equipos juntos, no les ser posible conseguir equipos para trabajar en ciertos proyectos. &ero otros han descubierto que si dan a la gente la oportunidad de trabajar con las personas que les gusten, trabajarn en cualquier proyecto 7"e(arco y /ister, 148E9. Cinalmente, an est por ver una organi*acin de desarrollos de soft)are con grandes per odos de inactividad. &or el contrario, la mayor a de los proyectos comien*an tarde porque el personal no est disponible hasta que han finali*ado otros proyectos anteriores. 'hora sabemos que entre grupos de personas con caracter sticas equivalentes, los equipos ms productivos son = ; veces como los equipos menos productivos. +on una y media o dos veces tan productivos como la media de los equipos. +i se tiene un equipo que se sabe est a la cabe*a del rango, hay que ser suficientemente inteligente como para permitirles perder el tiempo, durante hasta un tercio e incluso la mitad de su vida labora, para evitar el riesgo de que el equipo se divida y tenga que sustituirlo simplemente por un equipo medio.

!2 0odelos de equipo 'lgunos de los modelos slo afectan al modo interno de funcionamiento del equipo, y pueden ser implementados por el responsable t#cnico o el propio equipo. Htros afectan a la relacin entre el equipo y la directiva, y generalmente requerirn la aprobacin por parte de la misma. EQUIPO DE 3E4O&IOS5 /a estructura de equipo ms comn es la de un grupo de iguales encabe*ado por un jefe t#cnico. 'parte del jefe t#cnico, todos los miembros del equipo tienen el mismo estatus, diferencindose en su mbito de e.periencia. @l jefe t#cnico contribuye de forma activa. @l jefe es responsable de tomar las decisiones finales sobre cuestiones t#cnicas.

"esde el e.terior, la estructura del equipo de negocios parece una estructura jerrquica t pica. $oncentra la comunicacin con la directiva, identificando una persona como responsable principal del trabajo t#cnico del proyecto. &ermite a cada miembro del equipo trabajar en su rea de e.periencia, y permite que el propio equipo decida en que va a trabajar cada uno de sus miembros. Cunciona bien con grupos pequeos y con grupos que llevan juntos mucho tiempo, y pueden estructurar sus relaciones con el tiempo. @s bastante adaptable para trabajar en todos los tipos de proyectos. &ero generalmente #sta es su debilidad, y en muchos casos hay otra estructura que puede funcionar mejor. EQUIPO &O3 PRO4RA0ADOR JE)E O QUIR6R4I&O5 @sta idea de equipo fue concebida por >5( a finales de los sesenta y populari*ada por Cred 5rooBs 714E:, 144:9, #l se refiere al equipo como quirrgico, ambos t#rminos son intercambiables. @l equipo con programador jefe saca partido del hecho de que algunos desarrolladores son 12 veces ms productivos que otros. @n el concepto de equipo quirrgico, la persona ms cualificada se identifica con el cirujano, o programador jefe. @sta persona reali*a la especificacin completa, hace todo el diseo, escribe la mayor a del cdigo de produccin, y es el responsable final de prcticamente todas las decisiones del proyecto. @l resto de los miembros del equipo son libres para especiali*arse. /os miembros del equipo se distribuyen alrededor del cirujano con funciones de apoyo, y el equipo con programador jefe saca partido del hecho de que los especialistas tienden a rendir ms que los generalistas 7Jones, 14419. Day un programador de reserva que apoya al cirujano como cr tico, ayudante de investigacin, contacto t#cnico con grupos e.ternos y cirujano de reserva. Htra persona gestiona cuestiones administrativas. 'unque el cirujano tiene la ltima palabra en estas cuestiones, el administrador libera al cirujano de tener que tratarlas de forma diaria. 'lguien ser el responsable de crear herramientas personali*adas solicitadas por el programador jefe. @l equipo est arropado por un ,especialista del lenguaje-, que apoya al cirujano respondiendo a preguntas espec ficas y peculiares sobre el lenguaje de programacin que est usando el programador jefe. 0arios de los papeles de apoyo sugeridos en la propuesta original de equipo con programador jefe son desempeados actualmente por personas que no son programadores. @sta estructura sigue siendo adecuada cuando se usa de forma oportunista. @ste equipo resulta adecuado para proyectos creativos, en los que tener un cerebro al frente ayudar a proteger la integridad conceptual del sistema. Tambi#n resulta adecuado para proyectos de ejecucin tctica, en los que el programador jefe puede ser una especie de dictador que disee los medios ms e.peditivos para lograr la culminacin del proyecto. EQUIPO E3 7A SO0BRA5 Un equipo en la sombra FsBun)orBsG es una parte integral de la herencia del mundo de la ingenier a. Un equipo en la sombra aglutina un grupo de desarrolladores de productos creativos y con talento, les pone en una situacin en la que son liberados de las restricciones burocrticas habituales de la organi*acin, y les da libertad para desarrollar e innovar. /os equipos en la sombra son tratados generalmente como cajas negras por sus directivos. /a directiva no quiere conocer los detalles sobre como reali*an el trabajo, sino que slo quieren saber lo que estn haciendo. 's , el equipo es libre de organi*arse como mejor le pare*ca. $on el paso del tiempo, puede aparecer un l der natural, o el equipo podr a designar uno desde el principio. /os proyectos en la sombra tienen la ventaja de crear una sensacin de intensa propiedad y compromiso por parte de los desarrolladores implicados. @l efecto motivacional puede ser impresionante. Tienen la desventaja de no ofrecer mucha visibilidad del progreso del equipo. &arte de esto puede ser un efecto inevitable de la impredecibilidad inherente en un

trabajo altamente creativo. Tambi#n se debe a un equilibrio e.pl cito! p#rdida de visibilidad a costa de incrementar la motivacin. /os equipos en la sombra resultan ms adecuados para proyectos e.ploratorios en los que la creatividad es absolutamente importante. /os equipos en la sombra son raramente la estructura ms rpida cuando se necesita resolver un problema claramente definido o cuando se necesita ejecutar un plan bien entendido. EQUIPO DE PRESTA&IO3ES5 @n un equipo de prestaciones, el desarrollo, el control de calidad, la documentacin, la gestin del programa y el marBeting estn organi*ados con las estructuras jerrquicas tradicionales de responsabilidad. $on esta organi*acin tradicional se encuentran los equipos que toman uno o ms miembros de cada uno de los grupos implicados y les asignan la responsabilidad de una parte de la funcionalidad del producto 7(c $arthy, 144:9. /os equipos de prestaciones presentan las ventajas de potenciacin, facilidad de seguimiento y equilibrio. @l equipo puede potenciarse sensiblemente porque incluye representantes de desarrollo, control de calidad, documentacin, gestin del programa y marBetingK es decir, de todas las partes implicadas. @l equipo considerar todos los puntos de vista necesarios en sus decisiones, y por ello en raras ocasiones dar pie a que estas sean cuestionadas. &or la misma ra*n, resulta fcil llevar el seguimiento del equipo. Tienen acceso a todas las personas que necesitan para tomar buenas decisiones. +i no toman buenas decisiones, slo pueden echarse la culpa a ellos mismos. @l equipo est equilibrado. /os equipos de prestaciones resultan adecuados para proyectos de resolucin de problemas, ya que ofrecen el refuer*o y la facilidad de seguimiento necesarios para resolver las cuestiones planteadas de forma e.peditiva. Tambi#n son adecuados para proyectos de creatividad, ya que la composicin interdisciplinar del equipo puede estimular las ideas. /a gestin adicional generada por los equipos de prestaciones se desperdicia en los proyectos de ejecucin tctica! si todas las tareas estn claramente identificadas, los equipos de prestaciones tienen poco que aportar. EQUIPO DE E0ER&E3&IAS O DE BUSQUEDA 8 RES&ATE5 @ste tipo de equipo se centra en resolver un problema espec fico. Day que combinar un conocimiento especiali*ado de herramientas soft)are y hard)are espec fico con un conocimiento igualmente especiali*ado sobre un entorno comercial determinado. @ste equipo necesita un conocimiento ntimo del terreno en el que va a buscar, la capacidad de responder inmediatamente, y un e.celente conocimiento sobre el modo de estabili*ar el sistema en poco tiempo, controlando el problema de inmediato. @sta estructura de equipo es la ms apropiada para equipos que necesitan centrarse en la resolucin de un problema. @st demasiado dirigido a problemas bsicos como para soportar mucha creatividad, y est demasiado orientado a corto pla*o como para soportar la ejecucin tctica. EQUIPO DE ESPE&IA7ISTAS 94!E!O!:5 @n este tipo de equipo, cada miembro est especialmente entrenado en algn tema. /os equipos se ,entrenan- constantemente, para que cuando estalle una crisis puedan trabajar conjuntamente como un bloque sin fisuras. /a idea bsica es coger un grupo de personas con una slida formacin en una herramienta o m#todo determinado, y dedicarlas a un problema que se adapta perfectamente a ser resuelto con esta herramienta o m#todo. <eneralmente son equipos permanentes, estn habituados a trabajar juntos, y tienen papeles bien definidos. %esultan especialmente adecuados en proyectos de ejecucin tctica. +u trabajo no consiste en ser creativos, sino en implementar una solucin dentro de los l mites de una herramienta o metodolog a que conocen perfectamente. Tambi#n funcionan bien en proyectos de resolucin de problemas. /os miembros del equipo tienen confian*a mutua, y su

concentracin en una fase determinada del proyecto les permite tratar la reali*acin de esa fase como un nico problema que pueden superar rpidamente. EQUIPO DEPORTI;O5 /os desarrolladores son seleccionados como m nimo tan cuidadosamente como los directivos, y probablemente resultan ms cr ticos para el #.ito del proyecto. @l presidente de un equipo deportivo gestiona las decisiones, entre bastidores, que son importantes estrat#gicamente pero no es el que golpea la bola. @l responsable de soft)are tambi#n es importante, pero no por ninguna de las capacidades de desarrollo. @l papel del responsable es despejar el camino de obstculos y permitir que los desarrolladores trabajen de forma eficiente. /os desarrolladores podr an desarrollar un producto sin el responsable, pero el responsable no podr a sin los desarrolladores. ?o tiene sentido ver al responsable como una persona mejor o que est jerrquicamente por encima de los desarrolladores. /os equipos deportivos tambi#n tienen papeles altamente especiali*ados. @l responsable del proyecto puede contratar a un especialista, por ejemplo en bases de datos, pero no debe esperar de #l otra cosa. @ste modelo espec fico se aplica mejor a los proyectos de ejecucin tctica, que hacen #nfasis en los papeles altamente especiali*ados que desarrollan las personas individuales. EQUIPO DE TEATRO5 +e caracteri*a por una fuerte direccin y una gran negociacin de los papeles del proyecto. @l papel central del proyecto es ocupado por el director, que mantiene la visin del producto y asigna a la gente responsabilidades en reas individuales. /os participantes individuales pueden adaptar sus papeles, sus partes del proyecto, como les dicten sus propios instintos art sticos. &ero no pueden llevar demasiado lejos sus propias ideas, evitando colisionar con la visin del director. +i sus ideas chocan con la visin del director, la visin del director tiene que prevalecer para la buena marcha del proyecto. @n el modelo de teatro, no se est asignado simplemente a un proyecto. +e participa en una audicin, y se acepta un papel. 'ntes de poder aceptar un papel hay una larga negociacin. /a fuer*a del modelo de teatro consiste en que proporciona una v a para integrar importantes contribuciones individuales junto con una fuerte visin central en proyectos de creatividad. $omo afirma Cred 5rooBs, la integridad conceptual es la consideracin ms importante en el diseo de un sistema, y si un sistema necesita tenerla, hay una persona que tiene que controlar los conceptos 75rooBs, 14E:9. @l modelo de teatro resulta particularmente apropiado para equipos soft)are dominados por fuertes personalidades. @s un modelo adecuado para proyectos multimedia modernos. (ientras anteriormente los proyectos soft)are necesitaban integrar las contribuciones de varios desarrolladores de soft)are, ahora tienen que integrar las contribuciones de varias personas pertenecientes a distintas especialidades.