por Juan Palacio, 19 septiembre 05

Las empresas de sistemas de software dan, o deberían dar, un cierto miedo a sus clientes porque trabajan con probabilidades muy altas de fracaso.

Las estadísticas y los gráficos de los informes anuales de nuestro sector están resultando tan tozudos como contundentes, y a pesar de los conocimientos teóricos sobre procesos y calidad, se resisten a cambiar.

Como los sistemas de software rezuman técnica, lo normal es que los clientes no sea expertos, y de no ser empresas de cierta envergadura con departamentos informáticos propios, o de no contar con un servicio de asesoría especializado en procesos de adquisición de soft (que son muy difíciles de identificar), suelen gestionar la selección del proveedor, y demás tareas del proceso de adquisición (ISO/IEC 12207 5.1) con una mezcla de suerte e intuición.

Para afrontar la adquisición de un sistema de software los clientes se suelen apoyar en tres estrategias:

1. Asesoría profesional para la adquisición de software.
2. Currículum del proveedor (certificaciones oficiales, experiencia…).
3. La mencionada intuición.

Y aunque esta última pudiera parecer la menos rigurosa o profesional, bien guiada puede ser la más útil de las tres.

Los proyectos problemáticos son una manifestación más del Principio de Pareto: la mayor parte de sus problemas proceden directa o indirectamente de un número muy reducido de causas, y con un poco de olfato o de intuición se pueden detectar con bastante puntería.

Las otras dos estrategias también son efectivas, aunque convendría observar algunos consejos para esquivar los errores comunes, que las pueden mudar en ineficaces o contraproducentes; pero por ser limitada la extensión que se espera de un artículo, será más provechoso dedicar este a la intuición, empezando así por el factor fuerte de Pareto; y dejando a las otras dos como temas para posteriores artículos, que podrían cerrarlo a modo de trilogía.

INTUICIÓN

Las primeras respuestas que busco en cada nuevo proyecto son:

• ¿El cliente sabe realmente qué es lo que quiere conseguir o mejorar?. ¿Sabe lo que necesita?, o en caso contrario ¿Sabe que no lo sabe, y que ésta es su principal prioridad?.

• Los presupuestos, estimaciones, charlas, reuniones y en general las conversaciones que se han mantenido con él ¿estaban encaminadas a medir la profundidad del futuro sistema, a conocer el ámbito del problema que tiene que solucionar el software, y el nivel de análisis que ya ha realizado el cliente?; o por el contrario su objetivo ha sido no “dejarle enfriar” y conseguir que firme en un contrato una operación de la que no se tiene claro su alcance.

• ¿El cliente va a colaborar con el equipo durante el proyecto?, o ha hecho el pedido y se ha quedado a esperar el día de la entrega.

En mi experiencia estos son los factores clave o los que podríamos llamar “factores de Pareto�. Cuando se gestionan bien, los proyectos no suelen fracasar. Por el contrario, cuando surgen problemas, la mayor parte tienen origen directa o indirectamente en una de estas tres causas:

1. Clientes que buscan programas.
2. Proveedores que buscan dinero.
3. Clientes que no se implican en el proyecto.

1.- Clientes que buscan programas.

Los clientes que buscan programas dan una orientación a las tareas de adquisición que atrae factores de riesgo hacia el proyecto.

Sin duda los clientes no necesitan programas. Necesitan soluciones.

Aunque a primera vista esto pueda parecer un simple juego dialéctico, lo cierto es que esta diferencia de enfoque transmite implicaciones importantes al proyecto.

Si lo que el cliente quiere es una página web, es posible que su proveedor le entregue una más o menos bonita, pero lo que no sabemos es si con ella mejorará la calidad en la atención a sus clientes, o se reducirán las llamadas al centro de soporte telefónico, o recibirá feed-back del mercado, o…

¿Cuántas empresas han “comprado” un CRM o un ERP que funciona, pero que no han conseguido las mejoras que se esperaban?.

En los proyectos de clientes que quieren programas se suelen descuidar actividades clave como el análisis del problema, de los requisitos del sistema, el estudio y comparación de las posibles opciones de solución, o de los criterios que se emplearán para la validación y verificación del producto generado.

La Ingeniería del Software y la experiencia conocen muy bien las consecuencias de estos descuidos.

2.- Proveedores que buscan dinero.

Hay empresas (no sólo de software) que tienen como objetivo aportar beneficios o valor a los clientes a través de sus sistemas, y la consecuencia de ese trabajo es una facturación directamente proporcional al número de clientes y a la cantidad de valor proporcionado.

Otras tienen como objetivo ganar dinero, y para conseguirlo venden productos o servicios a sus clientes.

También aquí puede parecer que se trata de una misma cosa, vista desde ángulos diferentes; pero no es así. Quizá en otros negocios las consecuencias de uno u otro enfoque no sean muy significativas, pero en el nuestro cada una de estas visiones transmite implicaciones muy importantes a los proyectos, y los puede predisponer al fracaso.

El primer tipo de empresa forma a su personal, mide sus resultados, elabora su estrategia y su táctica para conseguir que los negocios de sus clientes triunfen, sabiendo que de esta forma cada vez ganará más dinero.

En el segundo tipo de empresa la estrategia, la medición de sus procesos y sus esfuerzos se dirigen a aumentar las cifras de ventas, pero no a solucionar los problemas de los clientes.
Las consecuencias de trabajar con la segunda estrategia suelen ser:

• Las estimaciones de precio y agendas responden a razones estratégicas, no a la realidad del sistema.
• El análisis y la gestión de los requisitos se realizan de forma inadecuada.
• Se acaban desbordando agendas y presupuestos.
• Se inyecta presión al proyecto.
• Se generan sistemas de baja calidad: tasas de errores altos, arquitecturas parcheadas o diseños para salir del paso
• Las deficiencias de los requisitos hacen difícil validar y verificar los productos obtenidos

3.- Clientes que no se implican en el proyecto.

El descubrimiento temprano de desviaciones sobre la planificación, de modificaciones o sugerencias no descubiertas en los requisitos iniciales es la mejor estrategia para evitar el re-trabajo y conseguir una eficiencia alta en el proyecto.

Por muy bien que se haya realizado el análisis de requisitos del sistema y del software, cuando el cliente vea el resultado descubrirá atributos o funcionalidades que no se han implementado como él esperaba, o que necesitan algunas ampliaciones que no se consideraron al principio.

Como resultado se terminan descubriendo en el momento más caro del ciclo de desarrollo: en la validación del sistema.
Los desencuentros en ese momento suelen generar recelos entre cliente y proveedor, de mayor o menor calado, que en ocasiones terminan como el rosario de la Aurora.