archivo

Archivos diarios: mayo 5, 2009

Los proveedores de servicios de desarrollo de software se encuentran en innumerables ocasiones con clientes difíciles. Esa dificultad puede ser debida a múltiples factores. En este post me voy a centrar en una de las más usuales: el cliente que está continuamente cambiando los requisitos en todas las fases del proyecto y que provoca que el proyecto no termine de cerrarse nunca.

Estas situaciones provocan casi siempre, a no ser que el proyecto esté muy holgadamente presupuestado, una pérdida económica por parte del proveedor. Por esta razón siempre comento, que es muy recomendable saber cuánto se gana y cuánto se pierde en cada proyecto, porque si un cliente te hace perder sistemáticamente dinero, ¿para qué continuar trabajando con él?.

Ante las situaciones donde un cliente te cambia los requisitos constantemente, tienes dos opciones principalmente, la primera es decir a todo que sí (en este caso hay que valorar muchas cosas, es decir, si el presupuesto permite decir a todo que sí, si el cliente en la mayoría de los casos es bueno, pero en este caso en concreto no lo es, si el cliente es muy bueno y las pérdidas en este proyecto se compensan con ganancias en otros presentes y futuros, etc…) y la segunda, con tacto, mucho tacto, intentar reconducir el proyecto, para intentar minimizar en lo posible los cambios funcionales, sobre todo cuando el proceso de construcción del software haya comenzado, ya que ahí los cambios son más costosos, coste que se va incrementando conforme va evolucionando dicha construcción.

Hay un aspecto en el que todos los clientes coincidimos, seamos buenos o malos y es que queremos que el producto final funcione y cumpla el propósito para el que fue contratado (además de verificar toda la relación de requisitos no funcionales) y eso es lo que tiene que aprovechar el proveedor, es decir, si el cliente cambia continuamente las funcionalidades, es porque no sabe lo que quiere o bien, sabe lo que quiere, pero no ha sido capaz de transmitirlo correctamente, ya sea por la lejanía que existe en ocasiones entre un informático y un no informático o porque no tiene completo en su cabeza el puzzle que supone el sistema de información. En cualquiera de estos casos, el proveedor tiene mucho que decir y tiene que intentar ayudar al cliente para que éste le transmita correctamente los requisitos. Para esto es fundamental la comunicación, aplicar técnicas que faciliten al cliente la comprensión del problema y aconsejar, ¿por qué no? Por muy cabezota que sea el cliente, si el consejo es bueno, lo aceptará, más pronto o más tarde, pero lo aceptará.

En cualquier caso, el proveedor debe actuar, ya sea para minimizar las pérdidas o para hacer que el proyecto sea rentable, ante una situación de cliente difícil, la peor solución es no hacer nada, porque todos conocemos la naturaleza humana, hoy te doy un dedo y te coges la mano, mañana te doy la mano y te coges el brazo, etc…

En un mercado tan competitivo y difícil como es el del desarrollo de software todo cuenta y la habilidad de tratar con clientes fáciles o difíciles es algo que se paga caro, ya que el retorno de la inversión es prácticamente inmediato. Por este motivo digo que no todo en un proveedor de servicios de desarrollo de software es la ejecución, la técnica, ya que de nada sirve si no se combina con una buena calidad en los análisis, en la capacidad para conseguir contratos y en la capacidad para tratar con los clientes.