Agile Aquisições Projeto

Contratos para projetos ágeis – 10 tipos de contratos ágeis

Vamos falar novamente sobre Contratos para Projetos ágeis? Neste artigo veremos 10 tipos de contratos ágeis. Logo após o artigo da semana passada Contratos para Projetos ágeis – O que preciso saber?1 Descobrimos que não só os projetos tradicionais precisam de contratos, mas e esse tal de Scrum?

De acordo com Peter Stevens2, levantamos 10 tipos de contratos ágeis que podem fazer a diferença em seus projetos de software.

Além disso, na semana passada, analisamos o propósito e o conteúdo de um contrato e identificamos critérios para avaliar contratos para projetos Scrum e ágeis. Onde sugeri 4 pontos para comparar formas de contrato:

  • Como o contrato é estruturado? Quais são as regras básicas para entregar o escopo e o faturamento?
  • Como distribuir o risco e a recompensa entre o cliente e o fornecedor?
  • Como ele lida com mudanças nos requisitos?
  • Que modelo de relacionamento com o cliente ele promove: competitiva (minha vitória é sua perda), cooperativa (ganha-ganha), indiferente (não me importa – você perde) ou dependente (cara-eu-ganho-coroa-você perde) ?

Nesta semana, vamos analisar vários contratos possíveis e ver como eles funcionam com projetos de desenvolvimento ágeis e do Scrum:

  • O “Contrato de Sprint”
  • Preço Fixo / Escopo Fixo
  • Tempo e Materiais
  • Tempo e Materiais com Escopo Fixo e Teto de Custo
  • Tempo e Materiais com Escopo Variável e Teto de Custo
  • Desenvolvimento Faseado
  • Cláusulas de bônus / penalidade
  • Lucro Fixo
  • “Dinheiro para nada, mudanças de graça”
  • Empreendimentos conjuntos /Joint Ventures

Contrato de Sprint

Trabalhando com o Scrum, descobri que a metáfora de um “Contrato de Sprint” que é útil para entender (e às vezes reforçar) o relacionamento entre o Product Owner e a equipe de implementação.

Estrutura: Este não é realmente um contrato comercial, mas simplesmente o acordo entre o Dono do Produto e a Equipe para um sprint.

Escopo: A equipe de implementação concorda em fazer o melhor para entregar um conjunto de recursos (escopo) acordado para um padrão de qualidade definido até o final do sprint. (Idealmente, eles entregam o que prometeram, ou até mesmo um pouco mais.) O Product Owner concorda em não alterar suas instruções antes do final do Sprint.

Risco: Um projeto Scrum pode ser considerado como uma série de mini projetos com parâmetros fixos: Tempo (Sprint), Escopo (Backlog), Qualidade (Definição de pronto) e Custo (Tamanho da Equipe * Comprimento da Sprint). Apenas o escopo pode variar e isso é medido a cada sprint.

Dica: Confirmar “o contrato de Sprint” via e-mail ou publicá-lo no (Wiki/base de conhecimento) do projeto no início de cada Sprint é geralmente uma boa ideia. Cria confiança, independentemente da forma contratual subjacente.

Dica 2: O contrato da Sprint pode ser referenciado no contrato comercial. Descobri que, depois de alguns lançamentos, o contrato comercial pode se reduzir a um contrato de tempo e material de uma página, talvez com um teto de custo para o trimestre ou para o próximo grande lançamento.

Preço Fixo / Escopo Fixo

Estrutura: Concorde com as entregas, entregue-as – Envie uma fatura – Os clientes gostam de projetos de preço fixo porque lhes dá segurança (ou pelo menos eles pensam assim).

Escopo: O nome diz tudo, não é? O jogo de solicitação de alteração (correção: processo de solicitação de alteração) destina-se a limitar as alterações no escopo – Esse processo é caro e as alterações geralmente não são evitáveis – Como o cliente quase por definição quer sempre mais escopo, encerrar o projeto pode ser difícil.

O fornecedor quer que o cliente seja feliz, então o fornecedor geralmente produz. As palavras “etcetera” são muito perigosas na especificação de um requisito de preço fixo.

Risco: O risco óbvio está do lado do fornecedor. Se as estimativas estiverem erradas, o projeto perderá dinheiro. Riscos menos óbvios são o jogo de solicitação de mudança, através do qual o fornecedor negocia receita adicional através de mudanças de escopo. Se o fornecedor subestimou mal o esforço ou risco, ou cotou um preço irrealista baixo, as perdas podem até ameaçar a existência do fornecedor, o que também representa um problema para o cliente.

Relacionamento: De competitivo para indiferente – O cliente geralmente quer ter mais e o fornecedor quer fazer menos – O fornecedor quer que o cliente seja feliz, então normalmente o fornecedor produz.

Dica: Especifique os requisitos funcionais com histórias do usuário.

Tempo e Materiais

Estrutura: Vá e trabalhe por um mês e envie uma fatura ao cliente. Fornecedores gostam disso, porque o cliente corre o risco de mudar de ideia no meio do caminho.

Escopo: A priori não fixo. Mais cedo ou mais tarde, o cliente não quer pagar mais, então o projeto chega ao fim.

Risco:  São carregados em 100% pelo cliente. O fornecedor tem pouco incentivo para manter os custos baixos. O esforço para garantir que apenas esforços e despesas legítimos sejam faturados pode ser substancial.

Relacionamento: Indiferente. O fornecedor fica feliz quando há mais trabalho porque mais trabalho significa mais dinheiro.

Dica:  Recomendado para projetos em que o cliente possa gerenciar melhor o risco do que o fornecedor. Isso geralmente é combinado com um teto de custo. Quão bem funciona pode depender de como o escopo é tratado.

Tempo e Materiais com Escopo Fixo e Teto de Custo

Estrutura: Igual ao preço fixo, escopo fixo, exceto se o fornecedor concluir antecipadamente, o projeto passa a custar menos, porque somente o esforço real é faturado.

Escopo: O mesmo que preço fixo, escopo fixo.

Risco: Neste caso esse contrato parece representar o “melhor dos dois mundos” do ponto de vista do cliente. Se requer menos esforço do que o esperado, custa menos. Mas uma vez que o teto de custo foi alcançado, ele se comporta como um projeto de preço fixo.

Relacionamento: Dependente – Do ponto de vista do fornecedor, o objetivo é atingir exatamente o limite de custo – Não há incentivo para o fornecedor entregar abaixo do custo máximo orçado. O cliente provavelmente tratou o projeto internamente como um projeto de preço fixo e, portanto, não tem incentivos para renunciar ao escopo para economizar dinheiro.

Tempo e Materiais com Escopo Variável e Teto de Custo

Estrutura: Igual ao tempo e materiais, exceto um teto de custo, que limita o risco financeiro do cliente.

Escopo: O mesmo que um preço fixo, projeto de escopo fixo.

Risco: O orçamento expira sem atingir o valor comercial necessário para o cliente. O cliente não recebe tudo o que ele pede.

Relacionamento: Cooperativa. A combinação de orçamento limitado e escopo variável enfoca o cliente e o fornecedor na obtenção do valor comercial desejado dentro do orçamento disponível.

Dica: Por experiência, eu diria que este tipo de contrato combina bem com o Scrum. O cliente tem controle sobre cada sprint individual. Um relacionamento construtivo significa que, mesmo que os problemas se desenvolvam no caminho, as emoções estão certas em chegar a uma solução mutuamente aceitável.

Desenvolvimento Faseado

Estrutura: Divulgue os lançamentos trimestrais e aprove fundos adicionais após cada lançamento bem-sucedido.

Escopo: Não explicitamente definidas pelo modelo. Lançamentos estão em vigor na caixa de tempo. O conhecimento de que haverá outro lançamento no próximo trimestre torna mais fácil aceitar o adiamento de um recurso para alcançar a caixa de tempo.

Risco: O risco do cliente é limitado a um trimestre de custos de desenvolvimento.

Relacionamento: Cooperativa. Tanto o cliente quanto o fornecedor têm um incentivo para que cada lançamento seja bem-sucedido, para que o financiamento adicional seja aprovado.

Dica: Os capitalistas de risco geralmente trabalham nessa base. Isso combina bem com tempo e materiais com escopo variável e um teto de custo. É um trabalho muito prático quando utilizamos este modelo. Nós simplesmente especificamos a meta de liberação, a taxa horária e o teto de custo no contrato comercial. O cliente fornece o Product Owner. Todo o resto é determinado nos contratos de sprint.

Cláusulas de bônus / penalidade

Estrutura: O fornecedor recebe um bônus se o projeto for concluído antecipadamente e pagar uma multa se chegar atrasado. A quantia de bônus ou penalidade é uma função do atraso

Escopo: Difíceis de aceitar, porque as mudanças potencialmente impactam a data de entrega, o que certamente não é permitido.

Risco: O cliente tem um incentivo para conclusão antecipada? Os argumentos do ROI devem ser convincentes e transparentes. Caso contrário, o cliente obtém uma solução mais barata e mais demorada.

Relacionamento: Pode ser cooperativo, mas pode degenerar em indiferença se o cliente realmente não precisar do software até a data acordada.

Dica: Geralmente aplicado a projetos de construção, por exemplo estradas, túneis e pistas, para o qual funciona bem. Mudanças no escopo não são problema e custos econômicos genuínos levam o cliente a cumprir o prazo também.

Lucro Fixo

Estrutura: Qualquer orçamento de projeto consiste em custos efetivos e lucro. As partes concordam com o lucro antecipadamente, por ex. US $ 100.000. Independentemente de quando o projeto é concluído, o contratado recebe os custos incorridos mais o lucro acordado.

Escopo: O escopo é fixo.

Risco: O risco é compartilhado. Se o projeto termina antes do previsto, o cliente paga menos, mas o fornecedor ainda tem seu lucro. Se o projeto exceder o orçamento, o cliente paga mais, mas o fornecedor não obtém lucro adicional. Após a data de entrega prevista, o fornecedor não poderá faturar mais nenhum lucro, apenas cobrir seus custos.

Relacionamento: Cooperativa – ambos têm um claro incentivo para terminar antes. O cliente economiza dinheiro e o fornecedor tem uma margem de lucro maior.

Dinheiro para nada, mudanças de graça

Estrutura: Isso funciona com projetos de software ágil porque há pouco ou nenhum trabalho em andamento. Após cada sprint, a funcionalidade está completa ou não iniciada. O trabalho baseia-se basicamente em uma base de tempo e materiais com uma meta de custo, geralmente com a intenção de que o projeto não use todo o orçamento do projeto.

Depois que uma certa quantidade de funcionalidade foi entregue, o cliente deve perceber que o valor de negócio suficiente foi percebido que o desenvolvimento adicional não é necessário e, portanto, pode cancelar o projeto. Uma taxa de cancelamento igual ao lucro remanescente é devida.

Escopo: Pode ser alterado. Recursos planejados, mas não implementados, podem ser substituídos por outras histórias do mesmo tamanho. Recursos adicionais custam extra.

Risco: Compartilhado. Ambas as partes têm interesse em concluir o projeto cedo. O cliente tem custos mais baixos, o fornecedor tem uma margem maior.

Dica: Se o orçamento for excedido, as regras dos contratos de teto fixo de custo ou custo fixo podem ser aplicadas. A abordagem de lucro fixo é mais consistente com o objetivo de promover um relacionamento cooperativo.

Empreendimentos conjuntos/Joint Ventures

Estrutura: Dois parceiros investem em um produto de interesse comum. É improvável que o dinheiro flua diretamente entre os parceiros na fase de desenvolvimento, mas cada parte deve ter um ROI, que pode vir da divisão de receita ou apenas se beneficia do uso do software.

Escopo: Definido para atender às necessidades da parceria.

Risco: Dois de tudo. Cadeias de decisão podem ficar longas. Rivalidades podem se desenvolver entre as equipes. Modelos diferentes para extrair valor do produto podem levar a diferentes prioridades que diferem pela vontade de investir.

Dica: Trate o projeto como uma empresa separada: uma equipe, co-localizada, com desenvolvimento e marketing de produto / papel do proprietário do produto. Pense de maneira realista sobre cenários de separação amigáveis ​​e não tão amigáveis.

Conclusão

Um contrato estabelece as bases importantes para um projeto bem-sucedido. E o Manifesto Ágil acertou: trabalhar com o cliente é mais importante que o contrato. Então faça o que fizer, mantenha o relacionamento com o cliente positivo!

Leitura adicional Jeff Sutherland – Money for nothing3. Um projeto de contrato está sendo desenvolvido pelo Agile Project Group, iniciado por Gerry Kirk.

Referências

  1. Contratos para Projetos ágeis – O que preciso saber?
  2. Peter Stevens – http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts
  3. Jeff Sutherland – Money for nothing
Coimbra, PMP on FacebookCoimbra, PMP on LinkedinCoimbra, PMP on TwitterCoimbra, PMP on Youtube
Coimbra, PMP
Como fundador da Projetos e TI, ajudo as organizações a se tornarem ecossistemas adaptativos, responsivos e auto-organizáveis, implementando novas práticas, estruturas, ritmos e tecnologias que permitam transparência, abertura, inovação e uma forma progressiva de liderar. Caso queira saber mais entre em contato comigo, inscreva-se na minha newsletter, ou me convide para uma palestra.

Graduado em Gestão de Tecnologia pelo Centro Universitário Barão de Mauá.
Pós-Graduado em Gerenciamento de Projetos, com as práticas do PMI® pelo SENAC.

Certificado como PMP® pelo PMI®. Six Sigma White Belt pela Voitto.
Especializado em BPMN2 pela Anelox, PMCanvas pela PM2.0 e Análise de requisitos

Mentor e influenciador de gestão de projetos, agilidade e transformação digital.

Comentários

Deixe uma resposta

This site uses Akismet to reduce spam. Learn how your comment data is processed.