Como cliente ou fornecedor de serviços de software no início de um projeto de desenvolvimento, você sabe que há muito em jogo para trabalhar apenas com um acordo verbal, contratos para projetos ágeis soam como algo paradoxal ao Manifesto ágil.

Embora o Manifesto Ágil¹ valorize a colaboração do cliente acima dos contratos, os contratos são necessários ao trabalhar com fornecedores externos. Um contrato é realmente apenas um conjunto de “regras do jogo” escritas.

As regras certas aumentam a chance de sucesso de ambas as partes. As regras erradas dificultam a cooperação e impedem o progresso.

Quais tipos de contrato são melhores para projetos ágeis de desenvolvimento de software?

Este é o primeiro de dois artigos. Neste artigo, veremos o objetivo e o conteúdo de um contrato e alguns critérios para avaliar contratos ágeis.

Na próxima semana, veremos alternativas de contratação de projetos de software Scrum e examinaremos seus pontos fortes e fracos.

Qual é o propósito de um contrato?

Contratos definem as regras básicas de jogo para o projeto. Em teoria, eles são livremente inseridos por ambas as partes para criar as condições ideais para concluir com sucesso o projeto.

Na prática, os contratos são frequentemente vistos como jogos competitivos, em que o objetivo é colocar a outra parte em desvantagem, especialmente se as coisas correrem mal.

Contudo empresas muito grandes e o governo geralmente têm condições padronizadas que precisam ser aceitas “em bloco” como um pré-requisito para que você consiga fazer negócios com elas.

Essas condições raramente são justas, portanto, um resultado razoável do projeto depende muito de um bom relacionamento com o cliente real e de evitar o recurso ao contrato ou à lei – O Manifesto Ágil está certo neste ponto: os relacionamentos com os clientes são mais importantes do que os contratos escritos!.

Mesmo que os contratos negociados nem sempre busquem uma relação ganha-ganha, você pode precisar da ajuda de especialistas.

No entanto, da perspectiva do cliente, os contratos não produzem valor agregado. Eles são um produto residual, portanto, o esforço gasto na negociação e produção deve ser minimizado.

Um contrato distribui o risco e reflete a confiança entre as partes.

O que acontece se algo der errado? Quem paga quanto o projeto é mais difícil do que o esperado? Quem se beneficia se o projeto for concluído antes do planejado?

As regras de jogo erradas podem ser prejudiciais para o sucesso do projeto. Regras ruins podem levar a preços irrealistas, prazos ou expectativas pouco funcionais. Relações de ganhar/perder são prejudiciais para o sucesso do projeto – A qualidade sofre mais frequentemente – Você quer que a “Equipe A” ou a “Equipe B” trabalhem no seu projeto? Pense cuidadosamente sobre quanta pressão você coloca no fornecedor.

Como avaliar as formas de contrato

Os contratos comerciais podem assumir muitas formas. Quais são as alternativas de contrato adequadas para projetos de desenvolvimento ágil? Para qualquer contrato, eu olharia:

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) ?

Se eu não elaborasse o contrato, também procuraria por armadilhas – a negociação de contato pode ser um jogo competitivo – A questão aqui é o que você faz se encontrar uma? – Tentar eliminá-lo ou aceitar e seguir em frente? Vamos chamar isso de “decisão de negócios“.

Quais informações devem ser incluídas em um contrato?

Quanto mais confiança existir entre cliente e fornecedor, menos você precisará anotar. Na minha experiência, há alguns pontos que pertencem a todos os contratos:

Objetivos do projeto e da cooperação entre as empresas. Isto reflete diretamente ao “elevator pitch” e a missão do produto.
Um esboço da estrutura do projeto – processo de Scrum, papéis principais e quaisquer diferenças do Scrum que se aplicam.
Key-Users – quem é responsável nos níveis operacional e de escalonamento e o que é exigido dessas pessoas?
Pagamento e faturamento, incluindo quaisquer cláusulas de bônus e penalidade.
Rescisão antecipada e normal.
“Detalhes legais.” Dependendo da lei local e dos costumes legais, pode ser necessário limitar a responsabilidade civil, especificar local, garantir a separação (que partes do contrato permanecem em vigor, mesmo que partes do contrato sejam consideradas inválidas) ou incluir outras cláusulas no texto para evitar que várias coisas ruins com bases legais aconteçam. Exemplos de contratos de referência da sua região e realizar benchmarking pode ser muito útil (e são mais baratos que um advogado!).

Você precisa incluir o escopo no contrato?

Frequentemente o escopo está presente (pelo menos nos contratos do governo que eu participei, o escopo foi incluído por lei), mas se concentrar o contrato no escopo também faz com que o escopo fique inflexível.

Se possível, é melhor especificar como você gerenciará o escopo (por exemplo, Backlog do produto, contrato do Sprint), mas detalhes operacionais devem ser deixados para a equipe do projeto.

Os pontos 2, 3, 4 e 5 determinam as regras de jogo para o seu projeto. Se você acertar, você terá a base para um bom projeto. Mas quais são as melhores regras? Há pelo menos meia dúzia de tipos diferentes de contrato, de tempo e materiais a preço fixo, escopo fixo.

No próximo artigo vou trazer alguns tipos de contrato que vão “clarear” um pouco mais sua mente neste quesito. Até semana que vem!

Contratos Ágeis – 10 tipos de contrato

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

Além disso, 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

Contratos ágeis – 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.

Contratos ágeis – 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.

Contratos ágeis – 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.

Contratos ágeis – 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.

Contratos ágeis – 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.

Contratos ágeis – 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.

Contratos ágeis – 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.

Contratos ágeis – Lucro Fixo

Estrutura: Qualquer orçamento de projeto consiste em custos efetivos e lucro. As partes concordam com o lucro antecipadamente, por ex. R$ 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.

Contratos ágeis – 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.

Contratos ágeis – 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, colocalizada, 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 nothing³. Um projeto de contrato está sendo desenvolvido pelo Agile Project Group, iniciado por Gerry Kirk.

Arquivo para Tag: Tempo e Materiais

Contratos para projetos ágeis: tudo que você precisa saber