negociação de contratos Ágeis de software gabriel chequer outubro de 2011

Negociação de Contratos Ágeis de Software

Gabriel Chequer

Outubro de 2011

© LES/PUC-Rio

Escopo dessa apresentação

0) Introdução: A importância do Contrato.1) Contrato por Tempo e Material (Ágil).

1.1) Definição

1.2.1) Vantagens 1.2.2) Desvantagens

2) Contrato “Money for nothing, changes for free” (Scrum).2.1) Definição2.2.1) Vantagens 2.2.2) Desvantagens

3) Contrato de Custo Alvo (Ágil).3.1) Definição

3.2.1) Vantagens 3.2.2) Desvantagens

4) Contrato de Preço Fixo (Scrum).4.1) Definição4.2.1) Vantagens 4.2.2) Desvantagens4.3) Procedimento

5) Como convencer o cliente a usar métodos ágeis.

© LES/PUC-Rio

0) Introdução

A importância do Contrato.

• De acordo com o Agile Manifesto:

– “Trabalhar com o cliente é mais importante do que negociar contratos”.

• Mas...

– No início do projeto, temos muito com o que se preocupar do que apenas um acordo verbal.

• O que está em jogo?

Dinheiro, Sucesso

e Risco.

© LES/PUC-Rio

0) Introdução

A importância do Contrato.

• O contrato certo garante o sucesso do projeto?

– Não, mas torna sua vida mais fácil.

• O contrato errado impede o sucesso?

– Não, mas torna sua vida mais complicada.

• As regras corretas aumentam as chances

de sucesso de ambos cliente e fornecedor.

• As regras erradas torna a cooperação difícil

e impede o sucesso do projeto.

© LES/PUC-Rio

0) Introdução

Qual o propósito de um contrato?

• Definir as regras básicas do projeto.

• Distribuir os riscos e refletir a confiança entre as partes envolvidas.

© LES/PUC-Rio

0) Introdução

Issues de Contrato

• São vistos como uma competição onde o objetivo é colocar o adversário em desvantagem, especialmente quando as coisas vão mal.– Quem paga e quanto:

• Se o projeto passar do prazo?

• Se o projeto for mais difícil

do que se esperava?

– Geralmente quem paga é a qualidade.

– Quem se beneficia se o projeto termina antes?

© LES/PUC-Rio

0) Introdução

• Como os advogados pensam e o que valorizam

– Um profissional da lei dirá que foi bem sucedido em um contrato se o cliente foi protegido no maior grau possível contra exposição ou risco.

– Ou seja, proteger os clientes de coisas que eles talvez não saibam.

– Advogados são educados para lidar com o que acontece quando relações se deterioram e a confiança é perdida.

• “Você sabe quando tem um bom contrato quando ambos os lados estão insatisfeitos.”

© LES/PUC-Rio

Projetos de Sucesso X Contratos de Sucesso

• Projetos de Sucesso

– Provêm de relações baseadas em colaboração, transparência e confiança.

• Contratos de Sucesso

– Contêm mecanismos que incentivam a colaboração, transparência e confiança.

– “Colaboração do Cliente mais do que Negociação de Contrato.”

• Prioridade número 1 de todos são Projetos de Sucesso.

© LES/PUC-Rio

1) Tipos de Contratos Existentes

• Escopo Variável:– Contrato Time & Materials.

– Contrato Time & Materials com escopo variável e preço máximo.

– Preço Fixo e escopo Variável.

• Escopo Fixo:– Contrato de Preço fixo e escopo fixo.

– Contrato Time & Materials com escopo fixo e preço máximo.

• Variações:– Phased development.

– Contrato de Lucro Fixo.

– Contrato de Custo Alvo.

– Contrato de Bonus/Cláusulas de punição.

– Contrato “Money for nothing, changes for free”.

– Contrato de Joint Ventures

© LES/PUC-Rio

1) Contrato por Tempo e Material

1.1) Definição

• “Pay as you go”

• Pagamento é feito pelo:

– Número de horas de serviço gastas (desenvolvimento e gerência) com preço fixo .

– Recursos utilizados (compras de hardware e software).

– Margem de lucro da empresa.

© LES/PUC-Rio


• 1.2.1) Vantagens

– Bom para quando não se pode medir a duração e os custos do projeto com precisão de forma antecipada e confiável.

– Bom para o início de um projeto de escopo incerto. – O cliente tem flexibilidade para mudar os rumos do projeto e o fornecedor recebe um valor

justo pelo seu trabalho. – A vantagem do cliente é poder terminar o contrato quando quiser.– É muito usado na cena ágil porque o cliente pode modificar o escopo conforme o valor das

funcionalidades e conforme vai conhecendo, vendo, e experimentando o software.

• 1.2.2) Desvantagens

– Pouquíssimo risco para o fornecedor. Ex.: Quanto mais ineficiente o fornecedor mais lucro ele tem.

– O trabalho pode se arrastar indefinidamente.– Difícil vender a ideia para o cliente (alto risco para o cliente).– Para reduzir o risco do cliente, o fornecedor pode negociar um limite de tempo para o

contrato. Ex.: não trabalhar por mais de 20 dias com um valor de X reais o dia de trabalho.

© LES/PUC-Rio


Citação

“O contrato por Tempo e Material é favorável em projetos de orçamento apertado ou quando trabalhamos com um consultoria de confiança. Para grandes projetos, ou quando trabalhamos com consultores desconhecidos, preferimos preço fixo, pelo menos inicialmente até identificarmos a capacidade do fornecedor de entregar no prazo.”

© LES/PUC-Rio

2) Contrato “Money for nothing, changes for free”

2.1) Definição:

• O trabalho é, basicamente, em uma base Time and Materials com uma meta de custo, muitas vezes com a intenção de que o projeto não deve usar o orçamento do projeto inteiro.

• Depois de uma certa quantidade de funcionalidade entregue, o cliente deve perceber que valor de negócio foi suficiente gerado e perceber que o desenvolvimento não é necessário. Podendo portanto, cancelar o projeto.

• Uma taxa de cancelamentoequivalente ao lucro remanescente é cobrada.

© LES/PUC-Rio

2) Contrato “Money for nothing, changes for free”


– O risco é compartilhado entre ambas as partes, onde os dois têm interesse em finalizar o projeto com antecedência. O cliente tem custo mais baixo e o fornecedor uma margem maior.

– Escopo pode ser modificado. Features planejadas mas não implementadas podem ser substituídas por outras de mesmo tamanho. Porém, features adicionais têm um preço extra.

– O contrato transforma as vantagens do Scrum e Processos de Desenvolvimento de Software em uma vantagem competitiva.

– Priorizando e entregando valor de negócio incrementalmente, as chances de um fracasso total são dramaticamente reduzidas e essa vantagem é repassada ao cliente.

– Além disso, é um modelo cooperativo e, portanto oferece incentivos à ambas as partes para manter os custos baixos.


– A cláusula de rescisão antecipada recompensa a maior produtividade alcançada com as equipes de Scrum. Do lado negativo, esta cláusula é um pouco como um "pára-quedas dourado", que pode não ser politicamente aceitável na situação econômica atual.

© LES/PUC-Rio

3) Contrato de custo alvo

3.1) Definição

• “Preço alvo” – preço menor que o “preço limite”

• “Preço limite” - o máximo que o seu cliente vai pagar.

• O contrato dá um incentivo financeiro à ambos para alcançar o “preço alvo”.

– Se o fornecedor executa o serviço abaixo do

preço alvo, as economias são divididas igualmente

entre cliente e fornecedor.

Da mesma forma, se o cliente passar do preço alvo,

o custo extra é dividido igualmente entre ambos,

mas somente até alcançar o “preço limite”.

Se o preço limite é alcançado, aí passa a ser como

um contrato de preço fixo.

© LES/PUC-Rio



– Divide o risco entre o fornecedor e o cliente de forma justa.– Alinha objetivos proporcionando aos envolvidos incentivos para minimizar

escopo.– O cliente tem a oportunidade de reduzir custos encontrando formas de

simplificar a complexidade sem sacrificar a qualidade.– O fornecedor é desincentivado à esticar o tempo do projeto para

aumentar o tempo faturável.– Protege o fornecedor do excesso de custos extras significativos.– Oferece flexibilidade suficiente para tirar o melhor do desenvolvimento ágil.– Faz com que cada lado considere o impacto de prazo e orçamento nas

decisões de escopo e equilibre a necessidade vs custo.


– Pouco usado e testado.

© LES/PUC-Rio


• Adicione o buffer de contingência dependendo se:

– O cliente é conhecido.

– O escopo do projeto é bem definido.

• O percentual de contingência:

– 10% para clientes atuais e onde temos um alto nível de segurança com relação ao escopo.

– Até 25% quando o cliente é novo e o escopo é vago.

© LES/PUC-Rio


• As modificações de escopo são classificadas em três tipos:

– Correções – mudanças para atingir os requisitos funcionais implícitos nos storycards existentes.

• Põe na conta do story card, se passar, põe no buffer do projeto.

– Esclarecimentos – Mudanças que resultaram através do feedback do cliente.

– Melhorias – novos storycards serão adicionados ao sistema.

• Melhoria ao invés de esclarecimento.

• Aumento de escopo do projeto e portanto, justificado como aumento no lucro.

© LES/PUC-Rio

4) Contrato de Preço fixo

4.1) Definição

– É o tipo de contrato mais comum.

– Um contrato de preço fixo é aquele em que o pagamento não depende da quantidade de recursos utilizados.

– As modificações de escopo são dificultadas.

– Tendem a funcionar bem quando os custos do projeto são bem conhecidos com antecedência.

– Quando usados projetos onde as tecnologias não foram muito testadas e desenvolvidas, frequentemente causam prejuízos ao fornecedor por este não conseguir prever os custos do projeto.

© LES/PUC-Rio



– Menos trabalho de gerenciamento para o cliente.– Fornecedor é fortemente incentivado a cortar custos.– As empresas já tem familiaridade e experiência com esse tipo de contrato.– O Cliente já sabe o preço final do projeto desde o início.


– O fornecedor assume todo o risco de escopo do projeto.– O cliente também sofre ao se comprometer com um escopo fixo no início e na

dificuldade de mudanças ao perceber que sua necessidade é diferente.– Sob um tipo de contrato de preço fixo, a tendência é que o cliente não aproveite

os benefícios do desenvolvimento ágil.

© LES/PUC-Rio


4.3) Procedimento:

4.3.1) Defina suas prioridades.

• Classificação do nível de importância de cada item do product backlog em termos de contrato.

• Como isso funcionaria:– Todos os itens com importância:

• Maior que 100 devem obrigatoriamente serem incluídos na versão 1.0.

• 50 - 99 devem ser colocados na versão 1.0, mas podemos terminá-las numa última release.

• 25 - 49 são obrigatórios, mas podem ser feitos na versão 1.1.

• Menor que 25 são especulativos e podem nunca ser adicionados.

© LES/PUC-Rio


• Exemplo

© LES/PUC-Rio


• Deixe os desenvolvedores fazerem as estimativas.

• Mas não os deixem perderem muito tempo nisso.

• Tenha certeza que eles entenderam que as estimativas são apenas uma previsão e não um compromisso.

© LES/PUC-Rio


• Exemplo de estimativas

© LES/PUC-Rio


4.3.2) Estimando a velocidade de desenvolvimento

– Fator foco

• A equipe gasta seu tempo fazendo coisas não planejadas como:

– Ajudando outras equipes.

– Olhando seus emails.

– Consertando seus computadores.

– Falando sobre política etc…

– Logo, vamos supor um fator foco de 50%, o que é muito baixo.

– Geralmente ele gira em torno de 70%.

© LES/PUC-Rio


4.3.3) Estimando a velocidade de desenvolvimento

– Suponha que nosso Sprint dura 3 semanas (15 dias).

– E nossa equipe tem 6 pessoas.

– Cada sprint então tem duração de 90 dias/homens, mas apenas 45 dias/homem podem ser considerados (devido aos 50% de fator foco).

– Então, nossa velocidade estimada é de 45 story points.

– Se cada item de backlog tivesse uma estimativa de 5 dias, teriamos aproximadamente 9 itens de backlog por sprint.

© LES/PUC-Rio


4.3.4) Release Plan

• 3 sprints para terminar os

“must haves” e

“should haves”.

• 3 sprints são 9 semanas,

que são 2 meses.

• Então esse é o prazo final? Não.– Adicione um buffer

• Para se proteger contra estimativas

Ruins e eventos inesperados.

• O tamanho do buffer depende:– Da natureza do contrato.

– Quão fixo é o escopo.

© LES/PUC-Rio


4.3.5) Adaptando o Release Plan

– Velocidade real do sprint X Velocidade estimada.

– Se forem muito diferentes, revise a velocidade estimada para os próximos sprints e atualize o Release Plan.

– Se isso te causar algum problema, reduza o escopo sem quebrar o contrato.

© LES/PUC-Rio


4.3.5) Adaptando o Release Plan

– Ou talvez o cliente ou a equipe tenha alguma ideia para aumentar a velocidade ou o fator de foco removendo algum impedimento identificado durante o sprint.

– Cliente ideal falando:

• “Estamos um pouco atrasados mas acredito que podemos ficar dentro do prazo se removermos a “funcionalidade X” que leva muito tempo pra ficar pronta. Podemos adicioná-la na follow-up release 3 semanas depois da primeira release se você preferir”.

© LES/PUC-Rio

5) Como convencer o cliente à usar métodos ágeis.

• A maioria dos clientes querem:– Preço Fixo.

– Prazo determinado.

– Escopo Variável.

• Foram entrevistadas 8 empresas.

© LES/PUC-Rio


• Problemas comuns:

– O maior desafio para a maioria dos fornecedores é a negociação do contrato.

– Preço fixo é a maior limitação ao negociar um contrato.

– Algumas frases dos entrevistados:

• “Preço fixo não funciona bem com desenvolvimento ágil.”

• “Com desenvolvimento ágil, é difícil definir um preço fixo. Como as mudanças são incentivadas, não se pode ter um preço fixo com modificações sendo inseridas à todo momento.”

• “Tudo que os clientes têm feito nos últimos 20 anos são com preço fixo. É muito difícil dizer que agora será diferente.”

© LES/PUC-Rio


• Mudando a cabeça do cliente:

– Discuta sobre as vantagens do desenvolvimento ágil e as desvantagens em se ter um contrato de preço fixo:

• “o foco é entregar valor de negócio o quanto antes – como resultado da entrega dos itens que têm maior importância do ponto de vista do negócio e não do ponto de vista técnico”.

– Discuta com o cliente quantas vezes alguma funcionalidade é raramente usada.

• Destaque como o desenvolvimento ágil evita esse tipo de situação através da prioridade às funcionalidades mais importantes ao negócio, proporcionando maior controle no produto final.

© LES/PUC-Rio



– Dê opções ao cliente:

• Alguns fornecedores encorajam seus clientes à comprar algumas iterações ao invés de assinar um contrato de projeto muito longo.

– “Muitas vezes vendemos algumas iterações...”

– “Tente por um mês, depois compre mais sprints...”

– “Nós costumamos dizer ao cliente que ele não terá nenhum risco [...] ele terá a opção de finalizar o projeto com um sprint de antecedência, ou seja, ele perderá no máximo um sprint [...] e, além disso, eles podem modificar qualquer coisa antes de um sprint”

– Isso ajuda à dar confiança ao cliente com relação ao método.

© LES/PUC-Rio



– Alguns fornecedores encorajam a flexiblidade do método:

• “o cliente após algumas iterações percebe que algumas fucionalidades não serão necessárias e que ele precisa de algo diferente. Logo, ele pode remover ou trocar algumas funcionalidades”

• “os clientes estão sempre abertos à sugestões de se retirarem após alguns sprints.”

• “o cliente pode adicionar modificações com um sprint de antecedência.”

© LES/PUC-Rio


• Caso o cliente não concorde, dê opções:– Feche o preço fixo e mantenha o cliente sem ciência do

processo.• “Nós fizemos projeto de forma ágil, entregando releases frequentes

e pedindo feedback. E o cliente não estava ciente de tudo que acontecia.”

• Dessa forma, para o cliente parece como um projeto tradicional e, para nós um projeto ágil que perdeu valor de negócio.

• “Não há convergência entre o que o desenvolvimento ágil diz e o que o cliente queria. Sim, nós perdemos valor de negócio.”

© LES/PUC-Rio

Referências

Artigo: Selling Agile Target-Cost Contracts.

Negotiating Contracts for Agile Projects: A Practical Perspective.

Henrik Kniberg, Scrum and XP from the Trenches 2006.

Indenpendent Consulting Bootcamp

http://www.independent-consulting-bootcamp.com/time-and-material-contract.html

Contratos de Software – Caderno Sérgio Taborda

http://sergiotaborda.javabuilding.com/2010/06/contratos-de-software/

Agile Software Development – 10 Agile Contracts Peter Stevens

http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts

Money For Nothing, Deliver more value for your client and for you

http://www.gerrykirk.net/money-for-nothing-deliver-more-value-for-your-client-and-you/

Agile Kiwi Target Cost Contracts

http://www.agilekiwi.com/estimationandpricing/target-cost-contracts/

Agile Kiwi Fixed Price Contracts

http://www.agilekiwi.com/estimationandpricing/fixed-price-contracts/

PMP Preparation Blogspot

http://pmp-preparation.blogspot.com/2009/12/advantages-of-fixed-price-contract.html

Fixed-price contracts required by stimulus law By Matthew Weigelt Feb 17, 2009

Heavy going - 8 April 2009, The Economist, "The future of Europe's high-tech military transport hangs in the balance".

http://coactivate.org/projects/agile-contracts/sample-fixed-price-agile-contract

negociação de contratos Ágeis de software gabriel chequer outubro de 2011

Documents