10 min leitura • Guide 831 of 877
Modelos de Contratação Ágil
Contratos tradicionais lutam contra ágil. O GitScrum ajuda equipes a gerenciar engajamentos ágeis com visibilidade e métricas que suportam modelos de contratação flexíveis.
Desafios de Contrato
Por Que Tradicional Falha
CONTRATOS TRADICIONAIS VS ÁGEIS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PREÇO FIXO, ESCOPO FIXO: │
│ ───────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CONTRATO: Construir sistema X com recursos A, B, C, D ││
│ │ por R$500.000 até 31 de dezembro ││
│ │ ││
│ │ PROBLEMA 1: Requisitos mudam ││
│ │ Cliente: "Precisamos de E em vez de D" ││
│ │ Fornecedor: "Isso está fora do escopo, ordem de mudança"││
│ │ Resultado: Conflito, atrasos, estouros de custo ││
│ │ ││
│ │ PROBLEMA 2: Descoberta durante desenvolvimento ││
│ │ Equipe: "Recurso B é muito mais complexo que estimado" ││
│ │ Opções: Cortar cantos OU estourar orçamento ││
│ │ Resultado: Qualidade sofre ou estouros de custo ││
│ │ ││
│ │ PROBLEMA 3: Aprendizado ││
│ │ Equipe: "Usuários não querem A realmente, querem F" ││
│ │ Contrato: "Construir A de qualquer jeito, está no escopo"││
│ │ Resultado: Construindo a coisa errada ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TENSÃO CENTRAL: │
│ │
│ PREÇO FIXO assume: ÁGIL assume: │
│ • Escopo conhecido antecipadamente • Escopo evoluirá │
│ • Mudança é um problema • Mudança é esperada │
│ • Planejar então executar • Descobrir enquanto constrói│
│ │
│ OS CONTRATOS NÃO SE ADAPTAM AO PROCESSO │
└─────────────────────────────────────────────────────────────┘
Tipos de Contrato Ágil
Modelos Alternativos
CONTRATOS AMIGÁVEIS AO ÁGIL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MODELO 1: TEMPO & MATERIAIS (T&M) │
│ ────────────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Pagar por: Tempo trabalhado a taxas acordadas ││
│ │ Escopo: Flexível, decidido conforme avança ││
│ │ ││
│ │ ✅ Flexibilidade total ││
│ │ ✅ Pode adaptar ao aprendizado ││
│ │ ⚠️ Sem previsibilidade de custo ││
│ │ ⚠️ Cliente carrega todo risco ││
│ │ ││
│ │ VARIAÇÃO: T&M com teto ││
│ │ "T&M até R$500K, renegociar se aproximando" ││
│ │ Adiciona previsibilidade mantendo flexibilidade ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODELO 2: PREÇO FIXO POR ITERAÇÃO │
│ ─────────────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Pagar por: Sprint/iteração a custo fixo ││
│ │ Escopo: Priorizado no início de cada sprint ││
│ │ ││
│ │ Exemplo: ││
│ │ "R$50K por sprint de 2 semanas, 10 sprints planejados" ││
│ │ Cliente prioriza backlog cada sprint ││
│ │ Pode parar após qualquer sprint ││
│ │ ││
│ │ ✅ Custo previsível por sprint ││
│ │ ✅ Flexibilidade no escopo ││
│ │ ✅ Pontos de saída integrados ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODELO 3: CUSTO ALVO │
│ ─────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Alvo: R$500K para escopo estimado ││
│ │ Intervalo: R$450K - R$550K aceitável ││
│ │ ││
│ │ Se abaixo do alvo: Compartilhar economias 50/50 ││
│ │ Se acima do alvo: Compartilhar estouro 50/50 (até teto)││
│ │ ││
│ │ ✅ Incentivos alinhados ││
│ │ ✅ Ambas partes compartilham risco e recompensa ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Modelos Avançados
CONTRATOS ÁGEIS AVANÇADOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MODELO 4: DINHEIRO POR NADA, MUDANÇA POR NADA │
│ ───────────────────────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DINHEIRO POR NADA: ││
│ │ Cliente pode terminar antecipadamente ││
│ │ Paga 20% do valor contratual restante ││
│ │ Fornecedor obtém receita previsível ││
│ │ Cliente pode parar quando "feito o suficiente" ││
│ │ ││
│ │ Exemplo: ││
│ │ 10 sprints a R$50K = R$500K contrato ││
│ │ Após sprint 6, cliente tem valor suficiente ││
│ │ Restante: 4 sprints = R$200K ││
│ │ Cliente paga: 20% × R$200K = R$40K para sair ││
│ │ Total pago: R$300K + R$40K = R$340K ││
│ │ Economizado: R$160K ││
│ │ ││
│ │ MUDANÇA POR NADA: ││
│ │ Cliente pode trocar itens do backlog de tamanho igual ││
│ │ Sem ordens de mudança para trabalho equivalente ││
│ │ Escopo total permanece igual, conteúdo flexível ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODELO 5: BASEADO EM RESULTADOS │
│ ─────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Pagar por: Resultados alcançados, não trabalho feito ││
│ │ ││
│ │ Exemplo: ││
│ │ "Pagar R$100K se taxa de conversão melhorar 20%" ││
│ │ "Pagar R$X por usuário adquirido através de novo recurso"││
│ │ ││
│ │ ✅ Alinhado no valor, não esforço ││
│ │ ⚠️ Difícil definir para resultados complexos ││
│ │ ⚠️ Desafios de atribuição ││
│ │ ││
│ │ Melhor para: Resultados de negócio claros, mensuráveis ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Construindo Confiança
Mecanismos de Transparência
CONFIANÇA ATRAVÉS DA TRANSPARÊNCIA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ VISIBILIDADE REGULAR: │
│ ───────────────────── │
│ │
│ DEMOS DE SPRINT: │
│ A cada 2 semanas, mostrar software funcionando │
│ Cliente vê progresso, não promessas │
│ Problemas surgem cedo │
│ │
│ MÉTRICAS COMPARTILHADAS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DASHBOARD DO CLIENTE ││
│ │ ││
│ │ STATUS DO SPRINT 6: ││
│ │ Velocidade: 32 pts (méd: 30) ││
│ │ Concluído: 6/8 histórias ││
│ │ Orçamento usado: 58% ││
│ │ Backlog restante: 89 pts ││
│ │ Sprints estimados: 3 mais ││
│ │ ││
│ │ BURNUP: ││
│ │ ^ ││
│ │ 120│─────────────────────────────● (escopo) ││
│ │ 90│ ●───●──── ││
│ │ 60│ ●───●──── ││
│ │ 30│●───●──── ││
│ │ └─────────────────────────► Sprint ││
│ │ 1 2 3 4 5 6 ││
│ │ ││
│ │ Cliente vê progresso em tempo real ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PLANEJAMENTO COLABORATIVO: │
│ ────────────────────────── │
│ Cliente participa do planejamento de sprint │
│ Cliente possui priorização │
│ Sem surpresas sobre o que está sendo construído │
│ │
│ AVISO PRECOCE: │
│ ─────────────── │
│ Problemas levantados imediatamente, não no prazo final │
│ Re-planejar juntos quando problemas surgem │
│ Sem "tudo está bem" até que não esteja │
└─────────────────────────────────────────────────────────────┘
Compartilhamento de Risco
Distribuição Justa de Risco
EQUILIBRANDO RISCO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRADICIONAL (Injusto): │
│ ───────────────────── │
│ │
│ Preço Fixo: │
│ • Fornecedor carrega TODO risco de estimativa │
│ • Fornecedor aumenta estimativas defensivamente │
│ • Cliente paga pelo aumento │
│ │
│ T&M Puro: │
│ • Cliente carrega TODO risco de eficiência │
│ • Sem incentivo para eficiência do fornecedor │
│ • Cliente preocupa com cobrança │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ÁGIL (Equilibrado): │
│ ──────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ MECANISMOS DE COMPARTILHAMENTO DE RISCO: ││
│ │ ││
│ │ 1. CUSTO ALVO COM COMPARTILHAMENTO: ││
│ │ Abaixo do alvo → Ambos beneficiam ││
│ │ Acima do alvo → Ambos compartilham custo ││
│ │ ││
│ │ 2. RESCISÃO ANTECIPADA: ││
│ │ Cliente pode sair com pequena penalidade ││
│ │ Fornecedor obtém alguma proteção ││
│ │ Ambos protegidos contra mau encaixe ││
│ │ │
│ │ 3. FLEXIBILIDADE DE ESCOPO: ││
│ │ Cliente pode mudar prioridades ││
│ │ Fornecedor não precisa absorver trabalho extra ││
│ │ Mudanças negociadas, não combatidas ││
│ │ │
│ │ 4. BÔNUS DE PERFORMANCE: ││
│ │ Fornecedor recompensado por exceder alvos ││
│ │ Cliente obtém melhor valor ││
│ │ Alinhamento ganha-ganha ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRINCÍPIO CHAVE: │
│ Nenhuma parte deve vencer quando projeto falha │
│ Ambas partes devem vencer quando projeto sucede │
└─────────────────────────────────────────────────────────────┘
Elementos de Contrato
Cláusulas Chave
ELEMENTOS DE CONTRATO ÁGIL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CLÁUSULA DE ESCOPO: │
│ ────────────────── │
│ ❌ "Fornecedor entregará recursos A, B, C, D conforme especificado"│
│ │
│ ✅ "Fornecedor entregará valor do backlog do produto │
│ conforme priorizado pelo Cliente cada sprint. Conteúdo│
│ do backlog pode mudar; esforço total permanece similar."│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CLÁUSULA DE MUDANÇA: │
│ ──────────────────── │
│ ❌ "Todas mudanças requerem ordem de mudança formal e aprovação"│
│ │
│ ✅ "Cliente pode substituir itens do backlog de tamanho similar.│
│ Itens variando >20% requerem discussão de estimativa."│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CLÁUSULA DE RESCISÃO: │
│ ───────────────────── │
│ ❌ "Rescisão antecipada incorre em 50% do valor contratual restante"│
│ │
│ ✅ "Qualquer parte pode rescindir após qualquer sprint com│
│ 2 semanas de aviso. Taxa de rescisão: 20% dos │
│ sprints planejados restantes." │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CLÁUSULA DE ACEITAÇÃO: │
│ ───────────────────── │
│ ❌ "Aceitação final mediante entrega de todos requisitos" │
│ │
│ ✅ "Software funcionando demonstrado e aceito cada │
│ sprint. Aceitação de sprint = entrega incremental." │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CLÁUSULA DE COLABORAÇÃO: │
│ ──────────────────────── │
│ ✅ "Cliente fornecerá Product Owner com autoridade para │
│ tomar decisões de escopo. PO estará disponível mínimo │
│ 4 horas por semana para colaboração da equipe." │
└─────────────────────────────────────────────────────────────┘
Fatores de Sucesso
Fazendo Funcionar
SUCESSO DE CONTRATO ÁGIL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REQUISITOS DO CLIENTE: │
│ ───────────────────── │
│ ☐ Product Owner capacitado │
│ ☐ Disponível para envolvimento regular │
│ ☐ Disposto a priorizar, não apenas adicionar │
│ ☐ Confiança no processo transparente │
│ │
│ REQUISITOS DO FORNECEDOR: │
│ ──────────────────────── │
│ ☐ Capacidade ágil genuína │
│ ☐ Transparência radical │
│ ☐ Mentalidade colaborativa │
│ ☐ Disposição para expor problemas │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ESTRUTURA DO CONTRATO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ABORDAGEM RECOMENDADA: ││
│ │ ││
│ │ 1. COMEÇAR PEQUENO ││
│ │ • Piloto de 2-3 sprints ││
│ │ • Construir confiança, validar encaixe ││
│ │ • Compromisso baixo para ambos ││
│ │ ││
│ │ 2. ESTENDER SE FUNCIONANDO ││
│ │ • Engajamento mais longo ││
│ │ • Termos melhores conforme confiança constrói ││
│ │ ││
│ │ 3. REVISAR REGULARMENTE ││
│ │ • Revisão contratual trimestral ││
│ │ • Ajustar termos baseado no relacionamento ││
│ │ ││
│ │ EVITAR: ││
│ │ Contratos longos de escopo fixo antes de confiança estabelecida│
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RELACIONAMENTO > CONTRATO: │
│ Melhor contrato não pode salvar mau relacionamento │
│ Bom relacionamento pode sobreviver contrato imperfeito │
└─────────────────────────────────────────────────────────────┘