Ruby on Rails y Scrum o cuando el valor y el precio han de tenerse en cuenta

Hoy en la comida ha surgido el eterno problema de cuando el cliente lleva el desarrollo a términos contables de precio hora. Comentaban sobre la metodología Scrum y cuando lo caro sale barato. Y es cierto.

Llevo más de 20 años en esta profesión y no será ni la primera ni la última vez que un cliente se ha ido a la competencia por precio y ha vuelto más tarde o más temprano a que le arreglásemos el desaguisado.

Yo en mi vida lo he llevado siempre a la práctica el hecho de que "prefiero unos buenos zapatos" aunque sean caros que 20 pares malos. Te ahorras mucho dinero y problemas de salud de todo tipo, sin contar con la comodidad.

Eso de la programación, de dar valor al cliente, aunque sea por las canas que ya vamos teniendo, y las arquitecturas que han de crecer... son muchas cosas que si no se hacen bien se acaban pagando. Yo lo denomino los costes ocultos de una mala decisión en la que el precio era la variable "importante". ¿Cuanto se abrían ahorrado muchos de mis clientes si me hubieran hecho caso cuando les he dado mi opinión, aunque haya sido un poco, nunca mucho, más caro que la competencia. Tengo infinitas anécdotas.

Por eso cada vez estoy más convencido que se ha de considerar el precio pero no únicamente, se ha de evaluar la rentabilidad de hacer el proyecto con un proveedor determinado, de calcular el P&L que nos reporta el proveedor, si, si... hay que cambiar el chip. Es difícil pero no imposible.

Y en esta línea voy descubriendo cosas de Ruby, de Ruby on Rails y de Scrum, que impactan en ese P&L del cliente.

Bueno, lo dejo de momento para reflexionar, pero creo que en la era del conocimiento, hasta las ofertas y los clientes han de cambiar. Pensar en ello.

servido por felipe 1 comentario compártelo