Dirigir un proyecto offshore requiere un método de trabajo muy particular. El acercamiento no difiere demasiado de las metodologías clásicas, aunque tiene en cuenta las especificidades y las limitaciones inherentes al contexto offshore. A este respecto, uno de los elementos clave consiste en escoger, entre toda la gama de metodologías disponibles para los encargados de los sistemas de información, la que mejor se adapte a este tipo de proyecto. Antes de realizar esta elección, es necesario analizar minuciosamente uno de los factores que, en los proyectos offshore, puede marcar una gran diferencia respecto a los proyectos clásicos: la distancia física. La distancia entre los equipos de desarrollo offshore y la gestión del proyecto in situ, el cliente o, incluso, otras partes de los equipos de desarrollo, complica lógicamente la comunicación y la gestión.
Metodologías: flexibilidad ante todo
Podría decirse que esta complejidad es característica de los proyectos offshore, pero también engloba otras dificultades típicas de los proyectos clásicos, dificultades que han llevado a criticar cada vez más las metodologías clásicas -denominadas “de cascada”- debido al encadenamiento sucesivo de etapas bien delimitadas (análisis de las necesidades, diseño, especificaciones, etc.). Normalmente se les atribuyen dos grandes inconvenientes: por un lado, la dificultad para adaptarlas a especificaciones variables que, a menudo, son inevitables en los proyectos de larga duración y, por otro lado, la pesadilla que implica la fase de integración, en la que es necesario sincronizar todos los módulos desarrollados por equipos independientes de desarrollo. Lógicamente, estos dos aspectos se multiplican en los proyectos offshore, en los que la distancia complica la incorporación de las especificaciones y la integración final.
El análisis de estas metodologías, con el tiempo, ha dado lugar a un nuevo tipo, las denominadas metodologías ágiles. Su característica principal es que utilizan ciclos de iteración cortos a lo largo de todo el proyecto y encadenan rápidamente todas sus etapas, desde el planteamiento inicial hasta las pruebas funcionales del módulo desarrollado. La duración de los ciclos puede variar, pero suele ser de unos quince días. Esto conlleva claras ventajas: por un lado, permite adaptarse rápidamente a los cambios y variaciones en las especificaciones, sobre todo los que se derivan del análisis de los resultados realizado por el cliente al final del ciclo; y por otro lado, se simplifica notablemente la integración, ya que se va realizando a medida que avanzan los ciclos. Así pues, una de las primeras recomendaciones que podría hacerse a la hora de trabajar en un proyecto offshore es utilizar este tipo de metodología para simplificar toda una serie de problemas que suelen surgir en este contexto.
Existen varias herramientas de comunicación que pueden utilizarse en los proyectos offshore, pero la más habitual -y también la más eficaz- en la comunicación persona a persona es la mensajería instantánea. Esta herramienta se ha hecho indispensable gracias a sus grandes ventajas. También existen otras opciones, como las conferencias telefónicas (imprescindibles para las comunicaciones de grupo, que son más formales) o las videoconferencias, menos utilizadas. En lo que se refiere a la comunicación escrita, el correo electrónico ostenta un indiscutible primer puesto.
A menudo también son necesarios los desplazamientos. Tanto al inicio del proyecto como de forma regular (cada seis u ocho semanas), resulta muy útil que los directores del proyecto y los representantes del cliente mantengan alguna reunión con los equipos offshore.
Finalmente, hay que tener en cuenta las diferencias culturales, sobre todo cuando se trata de países muy alejados, como la India.
Organización y gestión: equipos offshore motivados
Un primer punto que debe analizarse es la distribución entre los equipos offshore y los equipos locales. Evidentemente, no resulta fácil establecer una norma general, aunque se estima que una buena forma de repartirlos es un 30 por ciento local (pudiendo incluirse aquí los colaboradores del proveedor de servicios informáticos offshore) y un 70 por ciento offshore. Evidentemente, este baremo puede ajustarse en función del contexto en el que se realiza el proyecto. Por ejemplo, si se quiere implementar un paquete de gestión integrada, en el que el aspecto funcional tiene gran importancia, la proporción debería ser de 40/60. Y si hilamos aún más fino, otro punto que merece nuestra atención es la distribución de las funciones locales y offshore. En este caso se recomienda no relegar los equipos offshore meramente a las funciones de desarrollo, sino que se aconseja implicarlos en otros eslabones de la cadena, por ejemplo, haciéndolos partícipes tanto en el diseño como en la integración. Esto garantiza una comunicación más fluida, una mayor motivación y, además, una alta productividad, ya que se reduce su dependencia de los equipos locales.
La productividad es, precisamente, uno de los aspectos que hay que vigilar más de cerca. No debemos olvidar que las relaciones a distancia suelen ser difíciles y, por tanto, resulta crucial asegurar un intercambio constante con los equipos offshore a todos los niveles de la organización y, no menos importante, valorar el trabajo bien hecho.
Cuando la distancia se interpone en la gestión de los equipos (como es el caso de los desarrolladores que trabajan en un mismo módulo), la experiencia nos dice que se necesita disponer de un gestor sobre el terreno para evitar los problemas que conlleva la gestión a distancia. Así pues, no hay que dudar a la hora de utilizar más gestores si queremos mejorar la eficacia.
Por último, no debemos olvidar la figura del coordinador offshore, una responsabilidad que debe confiarse a personas con una experiencia contrastada en este tipo de proyectos.
Aparte de la gestión propiamente dicha, la dirección de la evolución del proyecto debe echar mano de una serie de herramientas e indicadores que permitan evaluarla, lo que nos conduce de nuevo a las metodologías ágiles: el uso de iteraciones cortas y, en esta misma línea, herramientas que permitan producir nuevas versiones constantemente y automatizar las pruebas correspondientes, haciendo de la dirección del proyecto una tarea más simple y fiable. Otra ventaja que ofrecen estas herramientas es que proporcionan indicadores de la evolución real del código, con lo que sólo faltaría el visto bueno de los jefes del proyecto.
Gestión de la calidad: dar prioridad a las iteraciones cortas. En este punto, tan amplio como esencial, debemos empezar por ver si los resultados obtenidos con el desarrollo se ajustan a las demandas del usuario. Aquí, una vez más, las metodologías ágiles resultan las más adecuadas y, por tanto, recurriremos a iteraciones cortas, acompañadas de pruebas que nos permitan visualizar los resultados. Asimismo, la participación de los equipos offshore en el diseño, tanto general como específico, y la comunicación mediante mensajería instantánea entre los equipos offshore y los equipos funcionales son otros recursos que ayudan a garantizan la calidad. Sin embargo, tampoco hay que dejar de lado otros aspectos de la calidad que, a priori, están vinculados al desarrollo, a saber, la formalización de las normas y principios de programación, la trazabilidad de los elementos y las reglas de ergonomía.
