Agile Aquisições Projeto

Contratos para projetos ágeis – O que preciso saber?

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 Ágil1 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:

  1. Objetivos do projeto e da cooperação entre as empresas. Isto reflete diretamente ao “elevator pitch” e a missão do produto.
  2. Um esboço da estrutura do projeto – processo de Scrum, papéis principais e quaisquer diferenças do Scrum que se aplicam.
  3. Key-Users – quem é responsável nos níveis operacional e de escalonamento e o que é exigido dessas pessoas?
  4. Pagamento e faturamento, incluindo quaisquer cláusulas de bônus e penalidade.
  5. Rescisão antecipada e normal.
  6. “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 benchmarking2 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!

Referências

  1. Manifesto Ágil em PTB – http://agilemanifesto.org/iso/ptbr/manifesto.html
  2. Benchmarking em gerenciamento de Projetos
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.