Llegamos a ustedes gracias a:



Columnas de opinión

Los desafíos de calidad y gestión que presenta la externalización del desarrollo de software

Por: Eugenio Valdebenito, director técnico de SoftTest Consulting

[21/02/2012] Actualmente existe una fuerte tendencia a externalizar los desarrollos de sistemas, debido a que presenta varios beneficios tales como: transformar costos fijos en costos variables, dedicar mas tiempo al core del negocio, disminuir los riesgos al contratar proveedores especializados y con experiencia probada, minimizar trabajos administrativos de contratación de personal, capacitaciones, entre otros beneficios.
Sin embargo, el manejo de proveedores externos acarrea nuevos desafíos. Las cosas no funcionan automáticamente como se desearía, y los resultados pueden ser decepcionantes en muchos casos si no se toman en consideración estos desafíos. Es común ver errores que se repiten sin que las lecciones aprendidas hayan servido de algo, en un medio donde deberían trascender estas experiencias, para que podamos aprender y mejorar nuestra gestión de los desarrollo de sistemas, ya sea con desarrollo internos así como también con desarrollos externos.
El objetivo de la gestión de proveedores externos es básicamente establecer y mantener los acuerdos con los proveedores, seleccionar los proveedores más apropiados, monitorear el avance de estos proyectos, conducir revisiones de los productos desarrollados, aceptar las soluciones desarrolladas, conducir la transición a los ambientes productivos, verificar la satisfacción del acuerdo.
Principales errores que se producen usualmente al manejar proveedores externos
* Pobre selección de proveedores. Se debe definir y documentar este proceso, definiendo aspectos de gestión, aspectos técnicos y aspectos económicos, experiencia sobre desarrollos similares, capacidad de gestión, satisfacción de usuarios/clientes, situaciones de excepción, etc.
* No se difunden dentro de la organización las malas experiencias con proveedores, así como tampoco existen políticas de suspensión, cancelación, reanudación. Se debe definir un mecanismo de comunicación sobre estos aspectos, definiendo repositorios compartidos destinados a este efecto.
* Excesiva confianza en las certificaciones (CMMI, Otras). Si bien una certificación aumenta la probabilidad de obtener mejores productos, no lo asegura; en especial que habitualmente los proveedores contratan personas nuevas especialmente para los proyectos, sin que necesariamente tengan conocimiento y práctica con los modelos en los cuales el proveedor está certificado.
Una certificación es una evaluación formal a una organización o individuo acerca que sigue en forma consistente buenas prácticas acerca del desarrollo de software, en sus aspectos de ingeniería y/o gestión. Estas buenas prácticas están definidas en modelos escritos, donde las más comunes son el modelo CMMI (soportado por el Software Engineering Intitute –SEI, dependiente de la Universidad de Carnegie Mellon), Normas ISO 9000, familia de normas de calidad y gestión continua de calidad, establecidas por la Organización Internacional de Normalización (ISO), La certificación PMP verifica conocimientos y habilidades de personas para guiar y dirigir equipos de proyectos con el fin de entregar resultados dentro de las restricciones de tiempo, presupuesto y recursos, ITIL (que mide la calidad de servicios de TI y su alineación con los objetivos de negocios).
* Falta de verificación oportuna de los artefactos que produce el proveedor. La práctica más común es esperar que llegue el producto para efectuar las pruebas funcionales. Lamentablemente puede ser un momento muy tardío para detectar que los requerimientos están incompletos, mal entendidos, inconsistentes. Puede que el costo de mejorar estas deficiencias sea tan alto, que se deba descartar lo hecho y levantar un nuevo proyecto a partir de cero. Las organizaciones deben hacer un esfuerzo en implementar una metodología de aseguramiento de calidad que se aplique a los artefactos relevantes desarrollados internamente así como también aquellos desarrollados externamente.
* Pérdida de control de los proyectos con desarrollo externo. Esta pérdida de control tiende a acentuarse cuando se trabaja con proveedores certificados. Esto se explica porque existe el pensamiento generalizado que por el solo hecho que el proveedor esté certificado -usualmente a montos más elevados- asegura el producto deseado en la calidad y oportunidad deseada. Me tocó vivir la experiencia de proveedores externos a los cuales no se les hizo ningún seguimiento hasta la llegada de los programas a ser certificados, momento en que se detectó fallas que provenía desde el levantamiento de requerimiento, el modelado de datos y de ahí en adelante. Ya había pasado más de un año de desarrollo y fue imposible en ese punto revertir la situación. El resultado final: Una oportunidad de negocios perdida -para beneplácito de la competencia- y rompimiento de relaciones con el proveedor, a pesar que era un proveedor multinacional con las máximas certificaciones.
* Pérdida del conocimiento de los procesos de negocios. La externalización en su grado extremo llega hasta olvidar que nunca debe perderse el control de los proceso de negocios, pues es la garantía de supervivencia en el mercado de las organizaciones. En un banco importante en que me tocó trabajar, el directorio de dicho banco pidió a la gerencia de sistemas que enviaran al experto en cuentas corrientes para ver la posibilidad de efectuar cambios que mejoraban la posición competitiva. Ante esta petición fue enviado un externo como dicho especialista. Como resultado de esto, se despidió al gerente de sistemas, por considerar inaceptable esta situación en que alguien perteneciente al banco no tuviera este conocimiento.
* Entregables comprometidos mal definidos. Es usual que los jefes de proyectos no sepan cuáles son los entregables comprometidos, cuales formatos se usarán, cuales estarán sujetos a control de cambios, quien los hará, quien será responsable de dicho control, si se harán revisiones de calidad como requisito de aceptación. Esta situación impide pasar adecuadamente una auditaría interna que asegure que le porcentaje de avance de los pagos de facturas corresponda con el avance de entregables comprometidos.
* No hay acuerdos sobre criterios de aceptación de los sistemas. Sin estos criterios bien definidos, usando métricas medibles y acordadas, pueden eternizarse la entrega de sistemas. Una buena definición de los criterios de aceptación favorece a ambas partes e incluso ayuda a orientar al desarrollo y las pruebas para satisfacer estos criterios.
* No se acuerda la cantidad máxima de ciclos de pruebas. Sin esto definido se puede llegar a extremos de tener sobre 10 ciclos de pruebas. Una cantidad razonable de ciclos de pruebas son tres o como máximo cuatro. Si se llega a necesitar más ciclos, estos deben ser de cargo del proveedor, los cual debe ser acordado y documentado.
* Canal de comunicaciones inadecuado, para solicitud de servicios, entrega formal de revisiones, entrega formal de artefactos de desarrollo, informar incidencias de calidad, todo esto en un marco de seguridad en la entrega de esta in-formación. Las comunicaciones es usualmente un área de conocimiento de gestión de proyectos muy descuidado.
* Los términos de referencia no tienen revisiones de calidad, para detectar ambigüedades, carencia de criterios de aceptación, acuerdo de cantidad de ciclos de pruebas, formatos que se consideran aceptables, entregables comprometidos, SLA relevantes, que afectan a los tiempos de entrega, entre otros.
* No considerar a los proveedores como socios estratégicos. Contar con proveedores confiables ayuda notablemente a lograr los objetivos de negocios que se busca. Estresar a los proveedores es una práctica común, con peticiones de pasillo, donde el proveedor, usualmente en una posición débil, tiende a aceptarlas sin medir adecuadamente el esfuerzo de que se acumula pos estas peticiones informales, llegando incluso a un punto en que es incompatible con la supervivencia de la empresa. Cuidar a los buenos proveedores es equivalente a cuidar a los mejores miembros del equipo de trabajo.
* No comunicar las experiencias (Buenas y malas) con los proveedores externos. Es común que Jefes de proyectos contraten o extiendan servicios con proveedores que han tenido comportamientos insatisfactorios en proyectos paralelos, así como se desaproveche la oportunidad de desarrollar otros proyectos si su desempeño es satisfactorio, con la consecuente pérdida de esfuerzo en la búsqueda de proveedores cuando este se encuentra en casa.
* Pobres reportes de los problemas encontrados en el desarrollo, relativos a problemas administrativos, de gestión, de recursos, tecnológicos, entre otros. Es conveniente estandarizar la forma de registrar dichos problemas, ya que usualmente quedan pobremente documentados. Al menos se debe indicar cuál fue el problema encontrado, la fecha de detección, la fase donde se produjo, la solución encontrada (si hubo), la métrica que debe usarse la para detectar si se puede presentar de nuevo
*  Definición de requerimientos insuficiente o mal documentados. La base de un buen desarrollo está en una adecuada definición de requerimientos. La poca estabilidad de los requerimientos, con alta tasa de cambios es fuente de fuertes atraso, e incluso puede causar deterioro en la calidad deseada. Es conveniente acordar una métrica para medir la estabilidad, tomando en cuenta la cantidad de requerimientos originales, las adiciones, eliminaciones y cambios debe registrarse en informarse oportunamente y debe estar registrado como riesgo, con medidas de mitigación. Puede estar evidenciando la necesidad de un cambio de usuario que posea más conocimientos de los procesos de negocios afectados. Es esencial poner atención en la gestión de este punto, en particular tomando en consideración que el desarrollo está sujeto a un contrato donde se señala el alcance y los requerimientos involucrados, siendo mas difícil efectuar cambios a los requerimientos durante la marcha, a diferencia de los desarrollos con equipos propios donde existe más libertad para hacerlo.
* Un factor que agrega una complicación más, que debe ser tomada en cuenta y manejada adecuadamente, son las normas legales que limitan las comunicaciones directas con los desarrolladores externos. Esta comunicación usualmente debe ser realizada solo a través de un supervisor o coordinador perteneciente al proveedor externo, para evitar que sea considerado un trabajador de la empresa contratante. Esto acentúa la necesidad de una buena comunicación y por tanto el punto anterior adquiere aún más importancia.
¿Todos estos problemas se evitan al contratar a un proveedor certificado? Contar con proveedores certificados mejora la probabilidad de obtener mejor calidad en el desarrollo, pero sin una gestión proactiva por parte de la organización contratante se pueden cometer grandes errores.
Una práctica moderna en esta orientación, que se ha ido popularizando en países desarrollados, es contratar el desarrollo con una empresa y contratar el aseguramiento de calidad con otra, para evitar el efecto juez-y-parte, que tarde o temprano puede llegar a producirse, con la consecuente pérdida de independencia de juicio, factor clave para asegurar la calidad.
Debemos evitar el deterioro en el nivel de satisfacción de los clientes internos, pero aún más importante es el efecto en la confianza de nuestros clientes externos. Recuperar a un cliente insatisfecho es extremadamente caro, si es que existe esta posibilidad.  
CIO, Perú