El equipo de proyecto

La estructura básica de un equipo de proyecto está formada por un jefe de proyectos, un analista y un conjunto de programadores (incluyéndose en este grupo a los analistas-programadores).

A este equipo habría que sumarle diferentes colaboraciones, como por ejemplo otros técnicos de apoyo a nivel funcional, diseñadores gráficos, maquetadores, arquitectos, analistas de sistemas, grabadores, etc…

Como es lógico, en función de la naturaleza del proyecto podría haber más de un jefe de proyecto, actuando por encima de ellos un gerente u otro jefe de proyectos, existir más de un analista o incluso existir un arquitecto con una dedicación más o menos continuada al mismo. Por tanto, configuraciones posibles para un equipo de proyecto hay todas las que uno quiera, aunque normalmente no existe (salvo en proyectos con características concretas) muchas variaciones en cuanto a perfiles entre unos y otros, más bien las diferencias sobre todo serán de carácter numérico y en el nombre que se le da a determinados perfiles.

Dado que las personas que forman parte del equipo pueden cambiar, de hecho cualquier componente del mismo puede tomar la decisión de irse a otra empresa cuando lo considere conveniente, el cliente puede llegar a un acuerdo con el proveedor (o viceversa) para sacar a técnicos del equipo de proyecto (o no siquiera haría falta para un servicio orientado a resultados en el que el acuerdo de nivel de servicio marque las reglas del juego) hay que intentar que el conocimiento no esté encerrado en la cabeza de nadie, estando a disposición del equipo de proyecto y de la empresa. Esto se consigue a través de procesos que aseguren que el conocimiento queda plasmado de alguna manera y a través de unas dinámicas de trabajo que sean comunes.

De esta forma se tratará de cambiar unas piezas por otras, sin embargo no es tan sencillo. A través de los unos procesos ejecutados correctamente quienes entren en el proyecto tendrán los medios para adquirir el conocimiento necesario para desarrollar su trabajo, sin embargo, esto no se consigue de inmediato y en función de la etapa en la que se encuentre el proyecto, la complejidad del mismo y la posibilidad de recibir apoyos del resto del equipo se puede tardar más o menos en comenzar a ser realmente productivo.

Esto no es como una maquina donde se cambia un componente por otro y ésta se pone a funcionar, en este caso lo que se ha hecho es, efectivamente, cambiar una pieza por otra y tener el “lubricante” que proporcionan unos procesos ejecutados de manera adecuada, pero para que todo vuelva a funcionar como antes se necesita un período de rodaje.

Un aspecto a tener en cuenta es que mientras se pueden fabricar dos componentes iguales no tendremos nunca a dos personas iguales, esto implica que aunque se pueda, tras pasar un tiempo necesario, volver a una situación de aparente normalidad, para que los resultados sean tan buenos como antes, es necesario que el técnico que entre a formar parte del proyecto tenga, al menos, la misma calidad del que se ha ido, en caso contrario los resultados se pueden resentir, se seguirá avanzando pero no con la misma intensidad y calidad que antes (como es lógico, la naturaleza del proyecto puede hacer que las diferencias entre el técnico anterior y el actual se hagan más visibles o se atenúen).

Yo soy partidario de equipos de proyectos donde las personas que participen tengan una cierta vinculación al mismo desde el momento en que empiezan a desempeñar funciones en los mismos, es decir, no creo en proyectos donde, por ejemplo, unos analistas participan solo en la parte de definición funcional y después quedan totalmente desvinculados del proyecto. Es cierto que si, por ejemplo, en un proyecto han participado tres analistas, ya no sea necesaria tanta carga de este perfil en el proceso de construcción, pero desde mi punto de vista es necesario que uno de ellos, aquel que se haya encargado del análisis de la mayor parte de la aplicación o de las funcionalidades más críticas tenga una participación activa en el proceso de construcción, ya que de esta forma se tendrá un puente entre las fases de análisis y diseño y la fase de construcción, evitándose la formación de dos mundos, el funcional y el de los desarrolladores.

About these ads
2 comentarios

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.225 seguidores

A %d blogueros les gusta esto: