Solucionado (ver solução)
Solucionado
(ver solução)
3
respostas

Contrato de projetos ágeis

Mestre, vimos que hoje em dia é muito comum a contratação de desenvolvimento de software no modelo ágil. Sabemos que existem diversos fatores externos que podem impactar nas entregas das Sprints.

Por exemplo, uma Sprint pode ser cancelada pelo P.O. ou alguns impedimentos podem reduzir a produtividade / velocidade do time. Ou quaisquer outros fatores externos, até a ausência (por motivos pessoais) de integrantes do time, ou mesmo a alta rotatividade.

Para garantir a rentabilidade do fornecedor, muitas vezes o time & material é o melhor caminho.

Mas quando vinculados às entregas, o risco para o fornecedor é muito grande.

Quais seriam as recomendações para minimizar o risco para o fornecedor caso o cliente não aceite o faturamento atrelado ao Time & Material?

3 respostas
solução!

Olá! Oportuna pergunta.

A melhor opção é realmente o mercado entender de uma vez o caráter de adição continuada de valor e fazer contratações "time & material", o que exige, todavia, uma mudança forte de mentalidade e grande confiança na equipe. Ou seja, exigiria adoção do Ágil como ele é!

Podemos colocar um teto de custos nesta modalidade, para o consumidor se sentir melhor.

Seguem algumas alternativas:

“Contrato Money for Nothing, Changes for Free (Jeff Sutherland)”

O cliente concorda em regularmente repriorizar o trabalho remanescente, trabalhando junto à equipe em cada sprint. Nestes pontos de controle, o cliente pode adicionar pontos novos no backlog, mas deverá ou pagar à parte por eles (“time & material”) ou eliminar itens menos prioritários do backlog, mantendo o valor total do contrato.

O pagamento é feito por sprint.

O cliente pode, em qualquer momento, abortar o contrato, pagando por isto 20% do valor remanescente (valor remanescente = valor total do contrato – total de valores já pagos).

O cliente faz isto quando entender que já obteve retorno no investimento suficiente e portanto o custo da implementação da próxima funcionalidade priorizada do backlog é maior que o benefício trazido por ela.

Em tese então o cliente economizaria 80% de um valor cujo investimento não compensaria em vez de ser obrigado a gastar tudo o que foi contratado.

Outra alternativa:

“Segmentar o projeto usando artifícios de métodos híbridos”

Por exemplo:

Definir uma “fase inicial” com prazo fixo onde seriam produzidos a visão, o PB inicial e “um conjunto” de especificações detalhadas (mantendo o escopo aberto, ou seja, sem comprometimento com “qual conjunto”).

Depois, iniciar os sprints de construção, seguindo o Ágil normal.

Olhando para os dois lados (cliente e fornecedor), sempre haverá um risco e portanto um custo por isso. O ideal para um, dependendo das características e maturidade de ambos, pode não ser ideal para outro.

Creio que algumas das alternativas propostas depende muito da confiança de ambos os lados, principalmente do cliente em relação a seu fornecedor. Confiança esta que leva um tempo pra ser adquirida.

Me colocando do lado do fornecedor, também existirão algumas dores, riscos, por isso o tema é bastante delicado e depende muito de evolução, experimentos e negociação.

obrigado pelo retorno.

Confiança é fundamental. Ajuda a economizar uma energia enorme.

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software