Financiamento de projetos ágeis

A empresa em que trabalho está se movendo timidamente para uma estratégia de gerenciamento de projetos Agile - tendo experimentado as "alegrias" da cascata de uma vez para muitas. A chave para isso é uma mudança de ênfase no sentido de oferecer funcionalidade, em vez de cumprir prazos rígidos.

Embora o processo de desenvolvimento e o relacionamento com o cliente certamente tenham melhorado com os lançamentos iterativos promovidos pelo Agile, está se mostrando um pouco mais difícil aplicar a mesma lógica às estratégias de financiamento do projeto. Os clientes geralmente não estão acostumados a conceitos como o Agile e expressam grande preocupação com o que percebem como um caso de "estará pronto quando estiver pronto".

Gostaria de ouvir os pensamentos e as experiências das pessoas no financiamento de projetos Agile

edit: Quero enfatizar que não estou pedindo às pessoas que me expliquem os prós e os contras do método Agile , nem que acredito que o Agile seja igual a "estará pronto quando estiver pronto", esse é um medo expresso pelo clientes / empresas com quem trabalhei ao defender práticas de desenvolvimento ágil.

O que me interessa é a experiência que as pessoas tiveram de resolver os conflitos entre os métodos "tradicionais" de orçamento em cascata entrincheirados nos relacionamentos / cliente de negócios e métodos de desenvolvimento mais progressivos - e as estratégias de orçamento adotadas para apoiar essa evolução.

Se você conseguiu fazer uma cotação em um projeto com uma data final exata para todos os recursos, por que você mudou para uma abordagem ágil? Você e todos os outros lutam com isso e uma abordagem ágil está sendo antecipada com esse fato. Use-o como propaganda contra a concorrência. A Southwest Airline não promete a você um assento na ilha como todo mundo que faz e depois o entrega a outra pessoa.

É claro que o cliente deseja uma data de término exata. Eles querem software barato e sem erros, entregue com antecedência, independentemente de quaisquer alterações na solicitação original. Diga à equipe de vendas para aprender como vender um projeto usando princípios ágeis. Quanto mais interações você passar, mais perto poderá saber quando o projeto será concluído. O cliente também aprende a fatorar os efeitos das solicitações de mudança.

Projetos ágeis não funcionam como "estará pronto quando estiver pronto". Essa é uma linha clássica da engenharia em cascata.

Projetos ágeis são concluídos quando o cliente decide que não deseja gastar mais dinheiro em recursos adicionais. Isso pode ser convertido em um ponto de venda importante pelo seu pessoal de vendas. Em vez de comprometer-se com um conjunto fixo de recursos (cuja necessidade pode ou não ser conhecida antecipadamente) por uma quantia fixa de dinheiro, o cliente pode começar com um valor inicial para um conjunto inicial de recursos e depois executá-lo em etapas. Isso garantirá algumas coisas:

• Desde que a lista de recursos seja devidamente priorizada, o cliente sempre receberá os próximos recursos mais importantes, maximizando assim seu benefício com seus gastos (ele obtém "o maior retorno pelo dinheiro").
• Se o cliente ficar sem dinheiro, ele maximizou seu investimento E você foi pago pelo que entregou. Ninguém se machuca, todo mundo lucra.
• O cliente pode mudar de idéia sobre prioridades e recursos a cada volta da roda (a cada ponta de uma interação). Uma vantagem distinta sobre os contratos normais de preço fixo.

Provavelmente há mais, mas as opções acima devem ser suficientes para levar seu pessoal de vendas na direção certa.

Bem, eu não vejo isso como um caso de "Ele estará pronto quando estiver pronto". A metodologia ágil promove a oferta regular de entregas, a cada duas semanas. É por isso que o cliente é uma parte importante e muito ativa do projeto ao longo de sua vida útil, pois fornece orientações em termos de como os recursos do seu produto serão modelados. Se alguma coisa, um cliente começará a ver resultados mais cedo, e não no final de um projeto, como na abordagem em cascata.

Enquanto você reiterar o fato de que o cliente será uma parte ativa do projeto e que ele verá o projeto começar a tomar forma cedo, isso pode garantir que não é um caso de espera até que seja concluído.

Embora o local em que trabalho faça uma terrível bastardização do Agile, acho que os clientes provavelmente preferem o desenvolvimento de software nas iterações do que nas versões completas.

As iterações se prestam a solicitações individuais dos clientes, na medida em que solicitam alguma coisa e a obtêm quando o recurso é implementado, não uma vez feito e todas as outras coisas que foram agrupadas com ele para uma liberação também são feitas.

Nunca vi um cliente dizer: "Queremos esse recurso e esperamos 8 meses para que ele seja entregue com vários outros recursos de que não ligamos".

Que tal estabelecer um ciclo de pagamento que esteja em sintonia com as iterações? A idéia de agilidade é que você realmente pode planejar e estimar em períodos curtos, e o esforço e o compromisso ainda são fortes para esses ciclos curtos. Por que não direcionar o financiamento da mesma maneira - peça aos clientes que contribuam para o trabalho com $$ ao mesmo tempo em que contribuem com orientação. Afinal, se eles não estão conseguindo o que querem, não deveriam pagar por isso.

E então elabore o que acontece na finalização de um projeto - por exemplo, o cliente possui o código ou apenas o executável? Mas isso estaria alinhado com projetos anteriores do tipo cascata.

A idéia do Agile é que você itere rapidamente e estabeleça exatamente o que vai entregar no final de cada sprint; portanto, quando as 2/3/4 semanas do sprint terminarem, você terá recursos tangíveis em seu aplicativo / projeto que você pode apresentar ao seu cliente e obter feedback.

ETA: você pode agrupar 'sprints' em 'marcos', com entregas estabelecidas e receber pagamento por marco.

Não estou convencido de que você deva vender um projeto fixo e lidar com o Agile do seu lado, mas sim vender iterações para o seu cliente.

As iterações são claras de entender e você não mistura os dois conceitos.

Os dois documentos a seguir fornecerão algumas informações sobre o gerenciamento ágil e as interações do processo de vendas:

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