Gobernabilidad en el Desarrollo de Software Offshore

La industria del outsourcing ha aumentado considerablemente en los últimos años principalmente por la masificación del internet de banda ancha en diferentes países que hoy son potencia en esta industria, como la India, Filipinas y México.

El aumento de opciones en outsourcing ha favorecido la diversificación de servicios, entre ellos el conocido como Offshore Software R&D, que se encarga de la ejecución de la etapa de construcción de aplicaciones en el ciclo de vida del desarrollo del software.

[Nota del editor: Este tipo de centros de desarrollo de software remoto se conocen también como “fábricas de software”, aunque en los últimos años ese término ha caído en desuso, principalmente para alejarse de la percepción de que el software se manufactura de la misma forma que productos físicos repetibles.]

Aunque se viene haciendo desarrollo de software offshore desde hace un par de décadas, y algunos países y empresas ya tienen prácticas bastante maduras en este sentido, en la mayoría de las empresas en nuestra región es una práctica relativamente nueva, por lo que existen muchas áreas de oportunidad que son importantes mencionar y resolver para poder incrementar nuestra ventaja competitiva como país —zonas horarias compatibles, cultura empresarial similar, entre otras— a comparación de nuestras contrapartes en Asia del este.

Las áreas de oportunidad a las que nos enfocaremos en este artículo están principalmente relacionadas a los canales de comunicación y a un flujo de trabajo con más control en el intercambio de productos y artefactos de trabajo entre las organizaciones. De parte de los clientes, en muchos casos permea la sensación de pérdida de control del avance en las actividades que realizan los proveedores offshore. Otro problema común es que los componentes de software entregados, a pesar de cubrir los criterios de calidad establecidos, no proveen la funcionalidad que el cliente esperaba.

Ante esto, existe una creciente demanda de apertura, de permitir mayor colaboración del cliente en el ciclo de construcción de las piezas de software. Permitir la agilidad, cambios constantes e identificar el avance y resolución de todas las tareas también es parte de estas demandas.

Los beneficios del uso de herramientas

Para enfrentar estos retos, dos mecanismos de gran ayuda son la adopción de metodologías de desarrollo ágiles y la utilización herramientas para automatizar tantos los procesos como las comunicaciones.

Las herramientas para favorecer esta automatización y simplificación de las comunicaciones, así como el incremento de la gobernabilidad del proceso, son herramientas que deben de tener las siguientes funcionalidades y beneficios:

Trazabilidad entre tareas. Más allá de poder tener listas de tareas, una herramienta debe permitir llevar el registro y monitoreo de cómo se relacionan las tareas entre sí, y cómo es que los requerimientos y tareas de alto nivel se descomponen hasta llegar a tareas atómicas. Estas tareas atómicas son aquellas unidades básicas de trabajo que pueden indicar esfuerzos de hasta horas de una sola persona o recurso, estas tareas también se les denomina Work Items (WI) o elementos de trabajo. Esta relación permitirá conocer a detalle el esfuerzo específico que se requiere para resolver un requerimiento, caso de uso, o historia con las actividades que ejecutan dicha tarea de alto nivel. De esta manera, es posible tener un estimado más acertado en la planeación de los tiempos de construcción necesarios para las diversas actividades.

Capacidades para administración del cambio. Mediante el apoyo de la herramienta para la implementación de ésta disciplina es posible llevar el histórico y seguimiento de cómo los requerimientos y tareas originales van cambiando con el paso del tiempo y el avance del proyecto. Es importante mencionar que, a la velocidad de cambio de las diversas industrias, las necesidades cambiantes del mercado y los cambios de regulaciones de industria y gubernamentales; es cada vez más demandado la inclusión de dichos cambios de manera ágil en las mismas actividades de construcción.

Inclusión de repositorios para administración de versiones y código fuente. Esta funcionalidad deberá permitir tener disponibles los códigos fuente de las aplicaciones que se están construyendo y así mismo relacionar dichas piezas de código con las actividades asignadas conforme se van atendiendo. El código fuente de los sistemas debe estar disponible en todo momento para los clientes, no debe ser algo que los proveedores escondan para “amarrar” a los clientes. La fidelidad y continuidad debe ganarse mediante ventajas competitivas basadas en prácticas y comunicación.

Capacidades de reportes basados en la información vaciada en los repositorios de la herramienta. Una vez que la información ha estado siendo alimentada hacia la herramienta, debe de ser posible extraer reportes del proyecto para que todos los involucrados —líderes de proyecto, codificadores, analistas, etcétera— tengan la misma visión del estatus del proyecto y este repositorio se vuelva la “verdad única” sobre la relación entre la factoría y el cliente.

Interfaz web. Es necesaria una plataforma agnóstica, que permita que cualquier involucrado pueda acceder a la información relevante sin tener que instalar una aplicación cliente para visualizar la información.

En el mercado existen algunas herramientas que contienen estas funcionalidades y que favorecen la agilidad en las comunicaciones entre estas organizaciones, entre ellas: IBM Rational Team Concert, Microsoft Team Foundation Server y Atlassian Jira, por mencionar las más conocidas.

Visiones unificadas

En mi experiencia, el aprovechamiento de éstos métodos y herramientas puede resumirse en algunas tareas, actividades y funcionalidades. Los detalles pueden variar dependiendo de qué herramienta se use y quien la proporciona (ya sea el cliente porque es un requisito para los proyectos que subcontrata o el proveedor porque la da como valor agregado). Dichas variaciones pueden ser mínimas, pero el concepto general se mantiene:
Los Work Items (WI), junto con la documentación que describe dicha actividad y el código fuente relevante cuando exista, son registrados en la herramienta. En el lado del proveedor de desarrollo de software, el líder de proyecto asigna al codificador apropiado el WI, de acuerdo con la experiencia, disponibilidad y conocimiento de la funcionalidad específica.

El cliente puede revisar quien es el (los) responsable(s) de dichos WI, para cuando está planeado la resolución de los mismos y cómo se van resolviendo o terminando cada uno de ellos. Esto permite al cliente tener algo de predictibilidad de que funcionalidades y piezas de código se irán entregando conforme el proyecto avance.
Cuando las necesidades o requerimientos iniciales cambien por parte del cliente o existan defectos identificados o mejoras necesarias a los WI iniciales, el cliente puede acceder directamente a ellos, y hacer las modificaciones pertinentes para mantener vigentes todas las funcionalidades del aplicativo contratado. La bitácora de los WI pendientes de terminar, está siempre disponible para todos. Esto permite tener elementos suficientes de negociación para definir cuáles son las funcionalidades importantes y necesarias a implementar de acuerdo con los tiempos destinados para finalizar el aplicativo.

El código fuente reside en el repositorio de la herramienta y cada WI que se dé por terminado, contiene el código correspondiente a la resolución de dicho WI. De tal manera que siempre está disponible la última versión del código y el cliente sabe exactamente qué funcionalidades ya se encuentran implementadas en el código liberado.

Al momento de facturar los servicios otorgados, el proveedor puede extraer los WI trabajados y resueltos e identificar el trabajo realizado. Por el lado del cliente, tiene el soporte necesario para justificar los pagos no sólo en términos de horas-hombre aplicadas, sino en avance del proyecto y funcionalidades implementadas.

Conclusiones

Un punto de vista unificado en el estatus del proyecto y avance de las tareas en el proyecto  permite a las organizaciones hablar y negociar bajo los mismo términos y contexto. Aún con la apertura de comunicación que favorecen los repositorios centralizados y automatización de administración del cambio, la factoría de software mantiene su capital intelectual e independencia en términos de la metodología de desarrollo especifica a utilizar, prácticas de codificación y ambientes de desarrollo. Estas herramientas serán agnósticas a esos elementos.

El control de ambas organizaciones en el proceso de gerenciamiento de proyectos y predecibilidad de los mismos se incrementa, al tener la capacidad de saber que se va a entregar. Adicionalmente, es conocimiento de las organizaciones cuándo y cuáles son los cambios que se requieren y tener la capacidad de tener a la mano la información necesaria para poder negociar y determinar de manera conjunta las prioridades del proyecto.

Y finalmente, con estos elementos de comunicación común, poder mantener una relación de negocios abierta, sana y sin fricciones importantes.