Desarrollo de software. Contratación ágil IV

¿Es suficiente realizar estos planteamientos al cliente para que acepte el desarrollo de sistema de información aplicando una metodología ágil, teniendo en cuenta que lo mismo está acostumbrado a contratar según un modelo clásico y monolítico y existen otros proveedores que pueden aceptar esas condiciones?.

Si el cliente no conoce los beneficios de la aplicación de los principios ágiles y su instrumentación mediante metodologías podrá ver el enfoque que se plantea alejado de la ortodoxia y ya sabemos todos lo complicado que resulta salir de la zona de seguridad aunque te vaya mal en ella.

Por tanto, si existe la oportunidad de hacer pedagogía con los clientes y mostrarles las ventajas de un enfoque ágil en el desarrollo de software, no solo te estarás ayudando a ti, sino también a toda la profesión y a todo el sector.

No obstante, el desarrollo iterativo incremental ofrece diversas cartas bajo la manga que pueden resultar muy atractivas para el cliente (y también para el proveedor):

– ¿Por qué no incluir en el contrato la posibilidad de que el cliente pueda dar por finalizado el proyecto antes de ejecutar todo el presupuesto?.

Esto se puede plantear de muy diversas formas: Darle la oportunidad a que lo pueda hacer en cualquier momento, a que lo pueda hacer con un mínimo de un % del presupuesto ejecutado, etc… En cualquier caso, el proveedor debería tener como compensación, además de lo ya ejecutado, un % del presupuesto restante (salvo que se haya pactado que un incumplimiento del acuerdo de nivel de servicio pueda suponer que esa compensación se elimine).

En este planteamiento todos ganan:

Si el cliente no está contento puede anular el proyecto, si el proveedor tiene una versión del producto que le parece suficiente no tiene por qué seguir invirtiendo en funcionalidades que lo mismo van a ser innecesarias.

El proveedor en el primer caso, no conseguirá los ingresos inicialmente estimados, pero a cambio se evita el camino a ninguna parte y lleno de desgaste al que iba el proyecto. En el segundo caso, el proveedor obtiene como premio además del beneficio por el trabajo ejecutado, el % extra de la compensación (sería como una prima por hacer las cosas bien).

– ¿Por qué no abordar un modelo relacionado con el esfuerzo necesario para realizar la tarea en el que todos ganen?.

En este caso al esfuerzo planificado se le aplica un buffer de esfuerzo, de manera que si el esfuerzo es t, nos quedemos con un rango válido de [t-buffer,t+buffer]. Si se consigue terminar la tarea con un tiempo entre [t-buffer,t] el beneficio se reparte entre cliente y proveedor y si la tarea termina con un tiempo entre [t,t+buffer], se reparten los gastos.

En el caso de que se superen los límites, habría que estudiar, antes de aplicar cualquier medida el motivo de tal desviación.

Anuncios
4 comentarios
  1. Juan mari Huarte dijo:

    Sencillamente felicidades!!!

    He disfrutado leyendo tus artículos con una visión de comprensión y entendimiento del cliente que pocas veces he visto.

    Yo soy de la parte contratante. Todavía no he visto un comercial que me haya presentado con solvencia un proyecto ágil y hecho de menos un argumentario sencilo y eficaz. También lo necesitan muchos clientes para venderlo internamente, por cierto.

    También, a veces pienso que nos focalizamos demasiado en el plazo y el coste y olvidamos que un proyecto ágil tiene muchas probabilidades de ser más barato y eficaz que uno tradicional. Si realmente creemos que con una manera de trabajar ágil somos más eficientes, quizás lo adecuado ser invertir en comunicar la forma en que nos vamos a relacionar, comunicar, entregar,..

    Un saludo y, por favor, sigue escribiendo 😉

  2. Germán dijo:

    Gracias por estos 4 artículos!!
    La exposición que has realizado es muy fácil de entender ya que realiza un gran resumen práctico de las metodologías ágiles. Otra cosa es llevar todo esto a la práctica, ya que como bien sabrás cualquier proyecto se complica muchísimo cuando entran en juego muchos actores (usuarios-finales, clientes-técnicos, clientes-jefes, proveedores, subcontratas, departamento de sistemas…etc.).

    No obstante opino que para proyectos software no demasiado grandes, esta es la línea que se ha de seguir para que tanto clientes y proveedores salgan ganando.

    Gracias y no dejes de escribir.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: