En este blog podréis ir viendo el desarrollo día a día de un proyecto software bajo la Métrica v3 del grupo 3 de Ingeniería del Software III (Ingeniería Informática) de la Universidad Carlos III de Madrid.

viernes, 4 de enero de 2008

Consejos para lograr un buen trabajo en grupo

Hola a todos. Ya estamos aquí de nuevo. Sentimos no haber escrito durante estas fiestas pues son épocas de irse a los pueblos de los padres y resulta difícil tener acceso a Internet. Sin embargo, las ideas no han parado de surgir y para estos días tenemos un montón de entradas ya pensadas.

Lo primero de todo es desearos un buen día de Reyes y que hayáis pasado una buena Noche Buena y entrada de año. Lo segundo es que pronto sabremos si nos hemos clasificado para la fase final del concurso de blogs; el resto de compañeros ha trabajo fuerte durante esta segunda fase, aunque esperamos un resultado positivo y poder luchar para la gran final.

En cuanto a la entrada que expondremos a continuación, creemos que va a ser una de las mejores y más divertidas. Lo que se va a hacer es lo siguiente: hicimos una serie de preguntas a dos personas con una experiencia consolidada en la gestión y dirección de proyectos, comparando al final sus procedimientos y formar para coordinar y conseguir un buen trabajo en grupo.

Por una lado y de color amarillo estarán las contestaciones de D. Ricardo Colomo Palacios, nuestro profesor de la asignatura, y por otro lado y de color turquesa D. Juan de Castro Paredes, director de la compañia GMV-SGI. Bueno, sin más rodeos se muestran los resultados obtenidos:

Está claro que para lograr una buena coordinación en el equipo de trabajo es muy importante que el jefe de proyecto tenga un buen liderazgo y que los miembros del equipo estén dispuestos a colaborar. ¿Consideras alguna de estás condiciones más importante que la otra?

Con toda probabilidad ambas condiciones están muy ligadas. Así, existen innumerables casos de equipos de trabajo poco motivados de forma inicial cuyos responsables han sabido estimular para lograr el éxito del proyecto, pero también de lo contrario, es decir, equipos motivados arruinados por líderes incompetentes. Para mí, una de las dos condiciones se tiene que dar de forma obligada, y si me tengo que quedar con una, confío en los líderes.

Ambas son fundamentales. Lo que sí es cierto es que mediante el liderazgo y capacidad de gestión del Jefe de Proyecto de alguna forma se puede conseguir que el equipo colabore, ya que es su responsabilidad motivar al equipo y conseguir que todo el equipo funcione como una única entidad atómica hacia el objetivo común que es el éxito del proyecto.


A la hora de repartir tareas entre los miembros del equipo, ¿qué criterios sigue? (Evidentemente análisis será para los analistas pero ¿reparte las diversas partes del análisis o delega esa partición del trabajo?)

En los últimos años la Ingeniería del Software está trabajando en lo que se denomina "encaje persona puesto". Yo soy partidario de asignar las tareas a los mejores, por lo menos desde el punto de vista de resultados, sin embargo, también creo que el desarrollo profesional de las personas pasa por darles oportunidades de crecimiento. Por ello, los sistemas de evaluación de competencias tienen mucho de aportar en las asignaciones desde el punto de vista del plan de carrera y el crecimiento competencial. Así, el criterio resultadista debe ser obligatoriamente combinado con la formación del capital intelectual del equipo de trabajo.

Depende claramente de la dimensión del equipo de proyecto. En proyectos complejos y equipos de proyecto medios o grandes, el reparto de responsabilidades o tareas ha de realizarse de forma delegada, dado que de forma paralela hay que hacer el seguimiento del estado de cada tarea y el Jefe de Proyecto no podría seguirlas todas. En equipos de proyecto más pequeños puede estar involucrado directamente en la repartición y seguimiento de todo el trabajo. Como criterio de asignación obviamente el fundamental es la experiencia y capacidad de cada miembro del equipo, sin perder nunca de vista la importancia de ofrecer retos a cada miembro del equipo para que cada uno evolucione en su carrera profesional y se encuentre motivado en todo momento.


Una de las partes más importantes para lograr planificaciones de calidad es la estimación del esfuerzo que cada tarea requiere. ¿Cree que la estimación del esfuerzo de cada tarea debe recaer en el jefe de proyecto o éste puede delegarla al encargado de dicha tarea?

El jefe de proyecto es, desde luego, el responsable de la planificación. Sin embargo, creo que en el liderazgo consultivo que tiene que llevar a cabo (o, al menos esta es mi opinión), debe contar con miembros de su equipo para distintas tareas, entre ellas, la planificación.

El responsable último de la planificación de cada tarea ha de ser el Jefe de Proyecto. Sin embargo, también es fundamental que cada miembro del equipo vea dicha planificación viable y se comprometa con los plazos establecidos. Por lo tanto, siempre es conveniente realizar la planificación con todo el equipo o por lo menos revisarla con cada uno de los involucrados.


Si en algún caso delega la estimación del esfuerzo, ¿Confía totalmente en que no le engañen para trabajar menos?

La confianza es un tema muy interesante. Considero que en lo que a la ciencia del Management se refiere, la confianza es una función de una desviación típica y un tamaño de muestra. Por ello, y esta es una respuesta casi general, depende.

Como he comentado anteriormente, la planificación debe estar dirigida por el Jefe de Proyecto. Pero como respuesta a la pregunta planteada, uno de los pilares del buen funcionamiento de un equipo de proyecto profesional es la confianza entre los miembros, por lo que a priori no se debe contar con que ninguno vaya a engañar en su estimación. De cualquier forma el Jefe de Proyecto ha de tener la experiencia y conocimientos suficientes para saber valorar la propuesta de planificación que cualquiera de los miembros aporte, y perfectamente se puede detectar una planificación sobreestimada (o infraestimada). A la pregunta sobre el engaño, si en cualquier momento el Jefe de Proyecto percibe dicha situación ha de hablarlo con la persona en cuestión y dejar claro que situaciones así no se pueden permitir dado que generan situaciones de injusticia en el equipo.

Como jefe de proyecto, ¿Qué recomienda para incrementar la productividad de sus subordinados? ¿Mano dura o blanda? ¿Alguna medida en particular en cualquiera de los dos sentidos?

La productividad de los desarrolladores depende de un gran número de factores. Uno de los que los investigadores señalan es la relación que se tenga con sus superiores. En este sentido, el jefe de proyecto debe saber los mecanismos para el gobierno del grupo en conjunto y de los individuos de forma aislada. Sobre las medidas, sólo una regla general: imperativo categórico.

La mano dura puede ser productiva a corto plazo pero no suele ser una buena solución a medio/largo plazo dado que genera tensiones entre el equipo. La mano blanda tampoco es una buena solución porque en un entorno profesional es fundamental la transparencia y comunicación entre el equipo y hay que comunicar claramente tanto los logros como las equivocaciones. En este sentido y para maximizar el fruto de un equipo de proyecto, es fundamental la 'asertividad', entendida como "un comportamiento comunicacional maduro en el que la persona ni agrede ni se somete a la voluntad de otras personas, sino que expresa sus convicciones y defiende sus derechos" (Wikipedia), que visto desde el punto de vista del Jefe de Proyecto hace que la relación sea sincera y transparente, dejando claro la responsabilidad de cada uno, repasando el estado de cada compromiso en cada momento, y otorgando en todo momento los reconocimientos positivos o negativos que cada miembro del equipo se merezca.


En caso de que alguien no realice la parte del proyecto que le fue asignada o que la realice muy mal, ¿Qué medidas toma? ¿Sigue asignándole otras partes?

Se deben analizar las razones para el fracaso. Y depurar las responsabilidades con la cabeza fría. Los recursos humanos conforman el capital intelectual de las organizaciones. Y las organizaciones de desarrollo de software son intensivas en este tipo de capital. Siempre hay que intentar reenganchar al recurso, nunca abandolarle o condenarle al ostracismo.

Como he comentado anteriormente, el punto fundamental es la comunicación transparente con dicho miembro de forma que sepa qué medidas o herramientas puede utilizar para que no vuelva a suceder en un futuro. Hay que saber distinguir entre los errores que todo el mundo comete como parte de su evolución y aprendizaje, de aquellos que suceden por falta de interés o compromiso ya que el mensaje a transmitir varía enormemente: en el primer caso hay que realizar labores de coaching para ayudarle en su evolución profesional y hacerle comprender que son naturales (manteniendo su motivación), mientras que en el segundo caso hay que analizarlo con la persona en cuestión para no vuelva a suceder. Como resumen hay que entender que todas las personas cometen errores en su desempeño profesional pero que, lejos de ser puntos negativos, han de considerarse como oportunidades de aprendizaje si así se entienden por ambas partes.

Para tener en cuenta toda la organización de todo el equipo, ¿Qué herramientas y dispositivos usa para gestionar la planificación, calendario, reuniones, etc.?

Se pueden aplicar multitud de técnicas, son las herramientas de trabajo del JP. Se encuentran en los manuales, sin embargo, a mi me gusta pensar que , además de los instrumentos científicos, el JP cuenta con herramientas propias: escuchar, analizar y tomar decisiones en base a estos análisis. Su trabajo es, en buena parte,ese. En muchos casos, los miembros del equipo de trabajo piden a gritos que les escuche un JP "sordo", aislado de su entorno. Sin caer en la figura del "ladrón del tiempo", el jefe de proyecto debe comunicarse de forma regular con su equipo, en algunos casos de forma planificada, y en otros, y a mi juicio estos contactos son en muchos casos los más enriquecedoros, de forma informal.

Las herramientas a utilizar varían fundamentalmente del tamaño, naturaleza y complejidad del proyecto. Los básicos en cuanto a gestión de la planificación son mantener el calendario del proyecto con los detalles de cada subtarea, el detalle del responsable de cada una de ellas, análisis del camino crítico, establecimiento de puntos claves de planificación (que permitirán lanzar alertas tempranas sobre posibles desviaciones de planificación), así como asegurarse de que cada miembro del equipo conoce sus tareas y plazos en todo momento (de nuevo enfatizar la comunicación!).


Ante todo, muchas gracias a los dos por colaborar desinteresadamente en nuestro blog y gastar vuestro valioso tiempo. En cuanto a las conclusiones que hemos sacado de las resultados son las siguientes:

* Sus estilos de dirección son muy similares: piensan que liderazgo y colaboración están ligados, confian en la delegación de las responsabilidades, consideran el error como punto de aprendizaje y reenganche de la persona que ha cometido el error y enfatizar la comunicación del grupo para conseguir una buena organización del grupo (aunque no cayendo en el error de convertirse en un jefe "ladrón del tiempo" como bien dice Ricardo Colomo).
* En cuanto a las diferencias, se centran a detalles bastante concretos: mientras Ricardo Colomo sigue una línea más resultadista en el reparto de tareas, Juan de Castro se guía por la experiencia del Jefe del Proyecto.
* Un aspecto que queremos resaltar son los nuevos conceptos aprendidos: como ya hemos dicho el "ladrón de tiempo" y también hay que señalar el imperativo categórico y la asertividad de Ricardo y Juan respectivamente en la gestión de la productividad del equipo de desarrollo.

No hay comentarios: