fbpx Trabajo Colaborativo | SG Buzz

Trabajo Colaborativo

Publicado en

Hoy, la tecnología nos permite y nos obliga a trabajar en forma colaborativa con perfiles de personas cada vez más diversos. Hace pocos años, un equipo de sistemas estaba compuesto por ingenieros que desarrollaban software manejando distintos lenguajes de programación. Con la llegada de las interfaces gráficas, tuvimos que reconocer una rama de la informática a la cual no dábamos mucho crédito: el diseño, y con ello tuvimos que comenzar a convivir con gente que vivía de la estética. Ya no hablábamos entonces de diferentes lenguajes de programación, sino de distintas formas de ver lo mismo. En una pantalla en la cual un ingeniero ve datos, un diseñador ve pixeles.

Así, por ejemplo, en un proyecto en el que trabajaba hace unos años, encontramos que unos datos estaban mal y quise validar el error con alguien del equipo de diseño. Pero cuando le dije : “Tadeo mira: esto está mal, ¿no?”, su respuesta fue: “¡Sí! ¡Está dos pixeles corrido a la derecha!”. En ese momento me di cuenta de que veiamos el mundo desde perspectivas totalmente diferentes. A la larga esto es bueno porque nos enriquece, pero al principio no es sencillo lograr esa colaboración. Si a ello le agregamos nuevas tecnologías y la consabida presión del cliente final, la ecuación se complica aún más, especialmente en grandes organizaciones.

¿Pero por qué resulta tan complejo el trabajo colaborativo? Al fin y al cabo, las organizaciones constan de estructuras, que son válidas y básicas para la operación de las mismas, y que simplemente hay que seguirlas para cumplir con los objetivos del negocio. Sin embargo, muchas veces estas estructuras no resultan tan funcionales a la hora de llevar a cabo los proyectos, generando problemas burocráticos. Esto quizás podría llevarnos a pensar que los proyectos deberían llevarse a cabo en forma totalmente anárquica, pero esta tampoco es la forma correcta.

Antes que nada, ante el planteamiento de un proyecto debemos tener claro cuál es el objetivo del mismo. Por lo general, el objetivo de cualquier proyecto informático es obtener en forma eficiente un producto de alta calidad, que cumpla con las expectativas del usuario final. Para cumplirlo, se necesita la mayor eficiencia en todo el ciclo de desarrollo, desde la recopilación de información hasta la puesta en producción del sistema. Es así que cada uno de los actores en las distintas fases tiene la misma importancia en la obtención del objetivo.

Uno de los factores de fracaso más comunes en los sistemas es que los usuarios finales tienen un bajo índice de adopción de los sistemas nuevos, no porque se nieguen a usarlos o por falta de voluntad, sino porque el sistema no está adecuado a sus necesidades. ¿Cómo puede suceder esto si se ha involucrado al responsable de área desde el principio?

Este es uno de los puntos donde hay que romper con estructuras jerárquicas tradicionales para obtener el mayor conocimiento. Es imprescindible ir a la fuente correcta para obtenerlo, y esta no es otra que el usuario final, el operativo. Por otra parte, cuando el usuario final colabora en el proyecto, podemos lograr que lo sienta como parte de sí y se comprometa con el mismo. Uno de los grandes beneficios de esta forma de trabajo es que se obtiene información de mayor calidad, ya que al ser el usuario parte activa del proyecto aporta valor, esas pequeñas cosas que suelen perderse en las entrevistas porque al parecerle obvias al entrevistado sin querer las omiten y como el entrevistador las desconoce, no pregunta por ellas.

Al trabajar en forma conjunta estos detalles, se puede lograr un gran avance en etapas muy tempranas del proyecto, y conseguir que al final del mismo el usuario ya conozca el sistema. Esto le dará seguridad y confianza para utilizarlo, y para darle apoyo a sus pares.

Trabajando de esta manera, si bien existen roles definidos, todos se sienten tanto parte del sistema como que aportan a la construcción del mismo, y no sienten que es una decisión de laboratorio que alguien definió un día y que ahora le imponen.

Por el lado de desarrollo, los roles son bastante clásicos: un gerente de proyecto cuyas tareas están relacionadas con la planificación, seguimiento y control del proyecto, y quien debe liderar y administrar los recursos, realizar las estrategias para llegar a los objetivos, cumplir cronogramas, administrar los cambios de requerimientos e interactuar con todos los otros miembros del proyecto. Luego tenemos al referente técnico, cargo cuyo perfil es de un desarrollador de muy alto nivel, que debe ser un referente para el equipo, capaz de marcar pautas sobre distintas tecnologías, y las pautas de desarrollo a utilizar, por lo cual debe ser alguien que está muy actualizado. Adicionalmente debe haber un responsable de desarrollo, que es quien liderea al equipo, se encarga de las estimaciones de tiempo de las funcionalidades a desarrollar, organiza el trabajo de los desarrolladores de cada módulo, le brinda apoyo funcional y técnico a los desarrolladores, le hace seguimiento al cronograma y realiza la validación de lo desarrollado. Y finalmente está el desarrollador, quien aplica las pautas de desarrollo en la implementación del sistema, identifica potencialmente nuevas pautas, realiza el testing unitario y el testing integrado, y colabora también con el seguimiento del cronograma. Con un equipo así, aplicando el trabajo colaborativo, se podrá obtener mejores resultados, ya que cada una de sus visiones enriquecerá el producto final.

Bio

Anibal Gonda es Director de Desarrollo de Negocios de GeneXus Internacional. anibal@genexus.com