O campo de vendas Agile

Então, suas equipes adoram trabalhar na Agile e estão buscando o maior valor para seus clientes e usuários finais. Ainda seus clientes vivem em um mundo onde "os recursos de compra para preços fixos com prazos contratuais" são o padrão. Isso é muito compreensível como 'O que estamos conseguindo pelo nosso dinheiro?' é uma questão lógica antecipada. Certamente, se suas ligações querem comparar vendedores e decidir sobre o preço.

Então eu continuo questionando como eu comercializo a maneira ágil de trabalhar para um mundo que não está pronto para isso …

Laudo de feedback do software por Jacopo Romei ( CC BY-SA 2.0 )

O contrato

Contratos com alcance fixo geralmente levam a soluções do Big Bang. Você obtém o produto no final do prazo e, com alguma sorte, atende aos requisitos contratuais. O mundo não deve saber agora que os requisitos definidos antecipadamente não são realmente o que é necessário no final. Cerca de 65% dos recursos da maioria dos produtos nunca são usados, então por que os construímos? Só por causa dos contratos? Eu acho que sim … Em vez disso, os agilistas se concentram em entregar o valor que é mais importante AGORA e, em seguida, adaptar o plano após cada iteração à medida que ganhamos mais conhecimento sobre o que funciona eo que é realmente valioso.

"Nossa maior prioridade é satisfazer o cliente através da entrega precoce e contínua de software valioso. A entrega de software de trabalho é a principal medida de progresso. " manifesto ágil

Então, em vez de ter contratos com foco em requisitos, devemos mudá-los para focar em colaboração e flexibilidade. Parece bom, mas como ganho o campo. Meu cliente precisa entender o preço desse novo recurso ou produto antecipado. Isso não deve ser diferente de vender software da maneira tradicional, mas em vez de colocar as estimativas e os requisitos em um contrato sugerem um orçamento de desenvolvimento que atenda o tamanho deste produto. Em cada iteração, os clientes obtêm um software de trabalho e o orçamento diminui de acordo, até que a funcionalidade prevista seja alcançada.

No contrato, dê a sala do cliente para cancelar a qualquer momento. Isso deve tornar a abordagem ágil relativamente livre de riscos, mais do que com um contrato de alcance fixo, onde você só precisa orar (por um milagre), você obtém o que você pagou no final. Por exemplo, o cliente pode cancelar o contrato porque recursos valiosos suficientes foram entregues ou porque, depois de algumas iterações, é claro que esse produto superará o orçamento de forma gigantesca.

A vitória para o cliente pode ser a necessidade de os recursos serem entregues no orçamento. Isso é bastante realista se você sabe como encontrar os 35% dos recursos que realmente serão usados ​​em vez de construir o que foi previsto no início com o mínimo de conhecimento. O produto de software evolui melhor quando usado por usuários reais. Isso leva a entender o que realmente funciona e o que não acontece no mundo real.

A vitória para a equipe de desenvolvimento é que, possivelmente, o cliente está tão feliz com o ritmo de obter o novo recurso entregue que eles continuarão a pagar a equipe indefinidamente para continuar estendendo o produto à medida que o mercado muda.

Adicione uma cláusula no contrato que, se o cliente cancelar uma porcentagem do orçamento restante, é entregue a equipe de desenvolvimento. Isso para dar à equipe o espaço para encontrar um novo cliente ou produto para começar a trabalhar. Uma porcentagem normalmente entre 10 e 20% parece razoável. Jeff Sutherland descreve um cenário como esse em seu último livro .

Como os requisitos ou agora não faz parte do contrato, podemos nos concentrar em colaborar e encontrar os recursos mais valiosos sem se preocupar com alguém no cliente que nos processa, porque não cumprimos nosso contrato em 100%.

Ou como o manifesto Agile diz : "Requisitos de mudança bem-vinda, até mesmo em desenvolvimento. Processos ágeis aproveitam a mudança para a vantagem competitiva do cliente ".

Você precisa de um contrato, mas não um com todos os detalhes lá.