Trabajar a gusto con el proveedor de desarrollo ahorra dinero y facilita las relaciones. La relación solo funciona si hay una percepción “win-win”, si hay un balance equitativo entre el alcance y el valor, tanto esperado como aportado, y, por supuesto, que el precio pagado por ello sea justo para ambas partes.
A menudo, en grandes proyectos, ocurre que las relaciones entre TI y sus proveedores de desarrollo son tensas, afectan al normal desarrollo del proyecto y, en muchos casos, se llega al desastre, no hay más que mirar las estadísticas que regularmente elabora el Standish Group.
El cliente elabora unos requisitos ambiguos, volátiles, no hay suficiente transparencia en su cuantificación ni cualificación y, en consecuencia, la entrega no se ajusta a lo que el usuario demanda. Tampoco ayuda el criterio tradicionalmente utilizado como ganador por el cliente: menor precio en menor plazo, “nadie da duros a cuatro pesetas”.
Y es que, en muchas ocasiones es difícil justificar y argumentar que se entrega la cantidad de funcionalidad inicialmente acordada ya que en los contratos de desarrollo de software los elementos clave son la tarifa y el esfuerzo y no se tiene en cuenta la productividad en términos de producto entregado.
Hay varias formas de mejorar estas relaciones, una de ellas, es disponer de un modelo de productividad, basado en estimaciones y mediciones objetivas de funcionalidad. Realizando al inicio del proyecto estimaciones de la funcionalidad basada en requisitos podremos fijar mejor el alcance al proveedor. Igualmente si hacemos mediciones a la finalización del mismo podremos medir la productividad. Con la experiencia, las estimaciones iniciales cada vez se acercarán más a las mediciones finales.
Esto será factible en función del grado de madurez de la compañía y de una implicación real del CIO. Como cada compañía es única, para evitar traumatismos, este modelo de productividad debe adaptarse, en la medida de lo posible, a su modo habitual de trabajar. Este modelo de productividad ayudará al cliente a poner orden en la diversidad de proyectos y a racionalizar la cartera de proveedores, le permitirá centralizar los acuerdos y, en definitiva, a mejorar las relaciones con los proveedores al poder cuantificar la producción de manera objetiva.
Pero no es solo esto, en breve, dicho modelo también ayudará al proveedor, y es que, una vez que el cliente ha interiorizado este modelo de productividad, se verá obligado a presentar los requisitos de una manera más exhaustiva y rigurosa.
¿Este modelo de productividad es la panacea? Obviamente no es una solución mágica, ni rápida, pero aplicada con rigor a lo largo del tiempo la evolución es tan satisfactoria que merece la pena la apuesta. Los resultados positivos se empiezan a ver a los 3 meses.
Para medir funcionalidad es conveniente utilizar un estándar, por ejemplo, el modelo basado en contar puntos función, definido por IFPUG y que constituye un estándar ISO que permite resultados objetivos aquí y en el otro extremo del planeta. Un fabricante de coches necesita unos determinados tornillos, y podrá elegir a un proveedor de tornillos en cualquier parte del mundo siempre y cuando los fabrique bajo estándares ISO. Si medimos nuestros desarrollos de la misma manera, los resultados serán consistentes. Esto, además, facilitará el hecho de que nos podamos comparar con el mercado (en general, o por sector, o por tecnología,…) a través de un benchmarking.
Es importante poner el foco sobre el producto final entregado basado en una medida de funcionalidad (punto función) y no en una medida del esfuerzo (Horas Hombre), es decir, ¿me vende un litro de leche? o ¿me vende cinco horas de ordeño?
Afortunadamente, desde el 2012, se realizan anualmente estudios de proyectos de desarrollo en los que se analiza la evolución del comportamiento de las tarifas de desarrollo que las compañías pagan a sus proveedores, versus, el precio unitario del punto función (PF). Para la realización de este estudio se parte de una base de datos de más de 18.000 proyectos de desarrollo (estas conclusiones se han presentado en diferentes conferencias internacionales):
1.- Una presión excesiva para bajar las tarifas de los proveedores, por parte de las compañías, provoca que el coste de desarrollar una unidad funcional sea mayor.
2.- No existe una relación lógica entre la tarifa que se paga al proveedor y el precio por PF
3.- Se da el caso de que un mismo proveedor tenga diferencias significativas (incluso de 1 a 4) en el precio por PF en diferentes clientes. Esto se podría deber al perfil técnico asignado a cada cliente, lo que tiene como consecuencia directa una disminución tanto de la productividad como de la calidad, y por ende, un aumento de costes para el cliente.
4.- Clientes con un único proveedor de desarrollo paga un precio más alto por PF
En aquellos casos en que se ha actuado implantando un modelo de control de productividad de desarrollo, los clientes han mejorado y han homogeneizado el precio de la unidad funcional, consiguiendo una reducción de costes fácilmente medibles y que suelen superar el 15% en el primer año.
En definitiva, la implantación de dicho modelo ayuda a la fluidez en las relaciones contractuales con los proveedores, al mismo tiempo que se producen mejoras en la productividad, y por tanto, en el ahorro.
