Desde hace años las metodologías ágiles han permitido a muchas empresas reaccionar a los cambios, modificando sus sistemas de información a un ritmo adecuado a sus necesidades ( Desarrollo ágil de software ).  A modo de resumen, el concepto de “Metodologías Ágiles” supone el desarrollo de iteraciones cortas e independientes, con objetivos alcanzables, que constituyan funcionalidades básicas dentro de una lista de funcionalidades del proyecto. Este modelo se basa en los principios del “Manifiesto Ágil” (ver manifiesto en: http://agilemanifesto.org/iso/es/).

En la actualidad, disponemos de herramientas que permiten cambiar los sistemas de forma flexible. Google, entre muchas otras cosas, es capaz de hacer una carga a “google docs” mientras el usuario utiliza el programa.

El avance es mucho más moderado cuando hablamos de los cambios organizacionales. Uno de los casos más complejos y frecuentes es el de la subcontratación de servicios de tecnología que implican desarrollos de software ( CRM, ERP, BI…). Los desarrolladores externos, en su esfuerzo por maximizar el resultado del proyecto y el bien del negocio, se ponen al servicio del cliente aceptando los cambios en cualquier etapa del proyecto.

El primer reto que se presenta es lo que en economía se ha llamado problema de la relación de agencia: las dos partes tienen que tomar medidas especiales para asegurar que no se deterioran las condiciones para ninguna de ellas.

La subcontratación típica requerirá como mínimo un contrato y un documento de requisitos.  De acuerdo a las experiencias pasadas del cliente y de la empresa contratada, es posible que se alteren los niveles de aprobación y se incluyan en los mismos a: arquitectos de sistemas,  departamento legal, contabilidad, auditores y responsables financieros.  Si añadimos a éstos, los respectivos departamentos de compras y ventas tendremos muchas reuniones de trabajo costosas.

Ese “sobrecoste” (en tiempo y dinero) introduce retrasos que impiden a las empresas reaccionar a tiempo a los cambios que pide el mercado. Una buena forma de medir este desgaste es preguntarse:

• ¿Cuánto tiempo y cuánto dinero me costaría cambiar una regla de negocio mínima de mis sistemas informáticos externalizados?
• ¿Cómo se desglosa ese coste?
• ¿Cuánto tiempo tardo desde que detecto una necesidad hasta que se firma el proyecto y tengo la funcionalidad requerida en marcha?
• ¿Los requisitos del proyecto salen estables de ese proceso o suelen sufrir cambios?
• ¿Cuánto tardaría el proveedor en conseguir respuesta a una inquietud simple? Ejemplo: si un programador necesita saber las especificaciones de diseño de un texto, en cuánto tiempo obtiene su respuesta?
• ¿Todos los niveles del procedimiento aportan valor? ¿cuál es?

Otro reto importante cuando hablamos de la externalización de servicios, es que a veces el propio cliente dificulta que las empresas a las que contrata puedan seguir los principios y buenas prácticas de las metodologías ágiles.

Algunos aspectos que dependen del cliente son:

• Definir espacios físicos en los cuales los responsables de negocio y los consultores trabajen en conjunto.
• Disponer de mecanismos que faciliten la comunicación “cara a cara” entre consultores y responsables de negocio.
• Establecer mecanismos de retroalimentación periódica sobre las funcionalidades terminadas que se reciben, y la facilidad de adaptación al trabajo diario.

Éstas son prácticas que contribuyen al éxito de los proyectos, y a la maximización del uso de los recursos propios y subcontratados. El reconocimiento de las diferencias culturales y la definición de puntos de integración y comunicación también facilitarán el logro de los objetivos planteados.

Ante estas dos situaciones, el responsable de la contratación debe plantearse las ventajas e inconvenientes según sus propias necesidades. En un mercado cambiante o en proyectos con requisitos ambiguos el tiempo de reacción es crítico. El principio por el que una empresa de nueva constitución puede vencer a una empresa que cotiza en bolsa no es muy diferente. Incluso en sectores tradicionalmente más estables como la banca y los seguros: surgen competidores, cambia el marco jurídico y el entorno.

¿Cuánto tardaremos en actuar cuando lo necesitemos?

¿Soluciones?

Mi lado consultor no puede evitar intentar solucionar un problema. Aún a falta de estudios con los que probar todas las afirmaciones, creo poder dar algunas pinceladas que nuestros lectores sabrán enriquecer o matizar:

• Crear varias vías para subcontratar proyectos:  no podemos tratar igual un proyecto de 1000 que de 100.000 horas. Tampoco cambian igual los requisitos de un proyecto de I+D que la repetición de uno anterior en otro sistema.
• Construir relaciones de confianza con los proveedores: esto  permite contratar sin tener los requisitos cerrados al 100%. En realidad, si el cliente tiene que iniciar un procedimiento legal no será porque el proyecto sea un éxito.
• Documentar y comunicar: si el proceso de contratación y/o cambio de requisitos es complejo ayudará que esté bien documentado y que se informe a los interesados de los cambios, apenas estos se visualicen.
• Construir equipos de trabajos experimentados y calificados de acuerdo a su función: en caso de duda forme el equipo de trabajo con menos trabajadores pero con experiencia verificable. Se reducen los posibles caminos de comunicación y la información fluye de forma efectiva desde el principio. Como beneficio adicional, un consultor experimentado para las labores que así lo requieren, puede tener un gran impacto en la productividad y en el éxito del proyecto.
• Utilizar las bondades de la tecnología para facilitar el flujo de la información y la comunicación entre los participantes:  usar un software de gestión de requisitos de forma compartida entre el cliente y el proveedor podría ayudar a generar rápidamente documentos y rastrear las implicaciones para las partes y los sistemas (considerar la modalidad Saas).
• Construir sistemas flexibles, diseñados para cambiar: centrarse en hacer flexibles los sistemas de cara al exterior. La web, intranet, centralitas telefónicas,  comunicaciones por carta, e-mail o sms son buenos candidatos. Por supuesto un buen CRM  puede permitir adelantarse a los cambios sin olvidar el efecto que tiene sobre los proveedores.

Finalmente, si clientes y consultores unieran sus fuerzas crearían más valor, finalizarían los proyectos antes y las soluciones terminadas estarían más ajustadas a las necesidades presentes y futuras.

Obtener logros y reconocimientos para todo el equipo interno y externo es posible y también necesario.