Financiamiento de proyectos ágiles

La compañía en la que trabajo se está moviendo tentativamente hacia una estrategia de gestión de proyectos ágil, habiendo experimentado las "alegrías" de la cascada una vez para muchos. La clave para esto es un cambio en el énfasis hacia la entrega de funcionalidad en lugar de cumplir con plazos estrictos.

Si bien el proceso de desarrollo y la relación con el cliente ciertamente han mejorado gracias a los lanzamientos iterativos promovidos a través de Agile, está resultando un poco más difícil aplicar la misma lógica a las estrategias de financiamiento para el proyecto. Los clientes a menudo no están acostumbrados a conceptos como Agile, y expresan una gran preocupación por lo que perciben como un caso de "estará listo cuando esté listo".

Me gustaría escuchar los pensamientos y experiencias de las personas en la financiación de proyectos ágiles.

editar: Quiero enfatizar que no le estoy pidiendo a la gente que me explique los pros y los contras del método Agile , ni que creo que Agile equivale a "estará listo cuando esté listo", este es un temor expresado por el clientes / empresas con las que he trabajado para defender las prácticas de desarrollo ágil.

Lo que me interesa es la experiencia que las personas han tenido al resolver los conflictos entre los métodos de presupuesto en cascada "tradicionales" arraigados en las relaciones / clientes comerciales y los métodos de desarrollo más progresivos, y las estrategias de presupuesto que han adoptado para apoyar esa evolución.

Si ha podido ofrecer una cotización de un proyecto con una fecha final exacta para todas las funciones, ¿por qué cambió a un enfoque ágil? Usted y todos los demás luchan con esto y un enfoque ágil es estar al frente con este hecho. Úselo como propaganda contra la competencia. Southwest Airline no le promete un asiento en la isla como todos los que lo hacen y luego se lo da a otra persona.

Por supuesto, el cliente quiere una fecha de finalización exacta. Quieren un software económico y sin errores entregado con anticipación, independientemente de cualquier cambio en la solicitud original. Dígale a su equipo de ventas que aprenda a vender un proyecto utilizando principios ágiles. Cuantas más interacciones tenga, más cerca podrá saber cuándo finalizará el proyecto. El cliente también aprende a factorizar los efectos de las solicitudes de cambio.

Los proyectos ágiles no funcionan como "estará listo cuando esté listo". Esa es una línea clásica de la ingeniería en cascada.

Los proyectos ágiles se completan cuando el cliente decide que no quiere gastar más dinero en funciones adicionales. Su personal de ventas podría convertirlo en un punto de venta clave. En lugar de comprometerse con un conjunto fijo de características (cuya necesidad puede o no conocerse por adelantado) por una cantidad fija de dinero, el cliente puede comenzar con una cantidad inicial para un conjunto inicial de características y luego llevarlo por etapas. Esto garantizará un par de cosas:

• Siempre que la lista de funciones tenga la prioridad adecuada, el cliente siempre obtiene las siguientes funciones más importantes que se entregan a continuación, maximizando así su beneficio de su gasto (obtiene "la mayor inversión por su dinero").
• Si el cliente se queda sin dinero, ha maximizado su inversión Y le han pagado por lo que ha entregado. Nadie sale herido, todos se benefician.
• El cliente puede cambiar de opinión sobre las prioridades y características en cada giro de la rueda (cada final de una interacción). Una clara ventaja sobre los contratos normales de precio fijo.

Probablemente haya más, pero lo anterior debería ser suficiente para que su personal de ventas avance en la dirección correcta.

Bueno, no lo veo como un caso de "Estará listo cuando esté listo". La metodología ágil promueve la entrega de productos en forma regular, como cada dos semanas. Es por eso que el cliente es una parte importante y muy activa del proyecto a lo largo de su vida, ya que proporciona orientación en términos de cómo tomarán forma las características de su producto. En todo caso, un cliente comenzará a ver resultados antes, en lugar de hacia el final de un proyecto, como en el enfoque de cascada.

Siempre y cuando reitere el hecho de que el cliente será una parte activa del proyecto, y que verá que el proyecto comienza a tomar forma temprano, eso podría asegurarles que no se trata de esperar hasta que esté terminado.

Aunque el lugar donde trabajo tiene una horrible bastarización de Agile, creo que es más probable que los clientes prefieran el desarrollo de software en iteraciones que en las versiones completas.

Las iteraciones se prestan a solicitudes individuales de los clientes, en el sentido de que solicitan algo y lo obtienen cuando se implementa la característica, no una vez que se realiza y todas las otras cosas que se han agrupado para un lanzamiento también se hacen.

Nunca he visto a un cliente decir: "Queremos esta característica, y queremos esperar 8 meses para que se entregue con un montón de otras características que no nos interesan".

¿Qué tal establecer un ciclo de pago que esté en sintonía con las iteraciones? La idea de ágil es que solo se puede planificar y estimar en períodos cortos, y el impulso y el compromiso siguen siendo fuertes para estos ciclos cortos. Entonces, ¿por qué no enfocarse en la financiación de la misma manera? Haga que los clientes contribuyan al trabajo con $$ al mismo tiempo que contribuyen con orientación. Después de todo, si no obtienen lo que quieren, no deberían pagar por ello.

Y luego averigüe qué sucede al finalizar un proyecto; por ejemplo, ¿el cliente posee el código o solo el ejecutable? Pero eso estaría en línea con los proyectos anteriores de tipo cascada.

La idea de Agile es que iteres rápido y establezcas exactamente lo que vas a entregar al final de cada sprint, por lo que cuando terminen las 2/3/4 semanas de tu sprint, tienes características tangibles en tu aplicación / proyecto que puede presentar a su cliente y obtener comentarios.

ETA: podría agrupar 'sprints' en 'hitos', con entregables establecidos, y recibir el pago por hito.

No estoy convencido de que deba vender un proyecto fijo y manejar Agile de su lado, sino vender iteraciones a su cliente.

Las iteraciones son claras de entender y no se mezclan los dos conceptos.

Los siguientes dos documentos le proporcionarán información sobre la gestión ágil y las interacciones del proceso de ventas:

http://www.nayima.be/html/fixedpriceprojects.pdf & http://www.nayima.be/html/agilefixedprice.pdf