Palestra DevCamp 2018 - Rodrigo Romero: Armadilhas no processo de contratação de um projeto ágil: desafios a serem superados para quem compra e para quem vende
Semelhante a Rodrigo Romero - Armadilhas no processo de contratação de um projeto ágil: desafios a serem superados para quem compra e para quem vende (20)
Conferência SC 24 | Gestão logística para redução de custos e fidelização
Rodrigo Romero - Armadilhas no processo de contratação de um projeto ágil: desafios a serem superados para quem compra e para quem vende
1.
2. Head da área de negócios da Dextra há 5 anos tem observado de
muito perto a transformação digital nas empresas que têm como
centro da sua estratégia a tecnologia. Formado em Engenharia de
Computação pela Unicamp já atuou como desenvolvedor, arquiteto
de integrações e gerente de projetos. Nos últimos 10 anos atua na
área de desenvolvimento de novos negócios com ênfase em projetos
de TI baseados em metodologias ágeis. Com passagens em
empresas como Promon, PeopleSoft e Oracle. Na Dextra desde 2012
3.
4. Manifesto Ágil - Fevereiro/2001
1. Indivíduos e interações mais que processos e ferramentas
2. Software em funcionamento mais que documentação abrangente
3. Colaboração com o cliente mais que negociação de contratos
4. Responder a mudanças mais que seguir um plano
Sem dúvida fantástico ! Sem dúvida mudou a maneira de se pensar em desenvolvimento de
software ! Como engenheiro de computação trabalhando com desenvolvimento na época
fiquei muito empolgado com essa nova forma de fazer projetos.
Entre as 17 pessoas envolvidas no manifesto ágil não havia nenhum comercial e ninguém de
compras e certamente ninguém pensou em como vender ou comprar software desenvolvido
dessa forma !!!!
12. ● Estamos realmente passando por um ciclo de transformação digital, e até
o momento o foco ainda está dirigido para:
○ Tecnologia
○ Gestão de pessoas
○ Agile Modernization - mudança na gestão de projeto
○ IT Modernization - arquitetura e infraestrutura que dê suporte
○ Cultura corporativa
● Mas precisamos pensar na parte comercial:
○ Como fazer um contrato que garanta tudo o que mudamos acima
○ Como passar pela esteira de compras (procurement) e não cair na armadilha de "fechar
escopo" só para poder ser competitivo e ser comparado a outros fornecedores
○ Como fazer esse contrato ser aceito pelo jurídico de grandes empresas
13. ● Hoje o que já se percebe é que tanto Compras como Jurídico já
entenderam que existem mudanças grandes em progresso
● Já colocam algumas "buzzwords" em seus documentos, já ensaiam alguns
discursos mais atuais, mas a grande maioria das RFPs ainda chegam no
modelo de negócio mais tradicional
14.
15. Seja claro em relação a sua oferta
● Logo de início seja muito claro em relação ao modelo de
desenvolvimento e consequente modelo comercial
● Não "doure a pílula" … seja franco, claro e direto desde as primeiras
conversas
○ Trabalhamos com metodologia ágil
○ Não fechamos escopo de projeto
○ O que vendemos é um time de desenvolvimento por determinado espaço de tempo
○ Não existe o conceito de "aceite" de sprint. Sprint é "Time Box"
○ Erros encontrados em um sprint devem ser priorizados e serão backlog de sprints futuros
● Decline de uma negociação se ficar claro que não vão usar metodologias
ágeis
16. ● Esse é o primeiro projeto utilizando metodologias ágeis ?
● Se não, como foram as outras experiências ? Foi projeto interno ou
envolveu fornecedores ?
● A motivação veio do C-Level ou está vindo de baixo para cima ?
● A TI está pronta ("IT Modernization" e "Agile Transformation") ?
Esse passo é muito importante porque define a criticidade dos riscos desse
projeto. Dependendo das respostas, pode ser necessário uma fase de
"Aceleração Digital" anterior ao projeto em questão
Defina a maturidade digital do seu cliente
17. ● Antecipe o contato com compras e jurídico
● Peça a eles o modelo de minuta de contratação e antecipe a discussão de
cláusulas que estejam "tortas" em relação a metodologia ágil
● Compartilhe a sua minuta de contrato e não tenha receio de discutir
pontos "delicados"
● Não perca a oportunidade de "evangelizar" o maior número de pessoas
sobre sua metodologia de trabalho. Novamente seja muito claro nos
conceitos e na maneira que um projeto desse tipo deve ser tocado
○ Peça uma reunião com "compras"
○ Traga exemplos/cases reais
○ Compartilhe contatos e contratos
Antecipe as conversas sobre contrato
18. ● Nos passos anteriores nos preocupamos em ser muito claro em relação a
forma em que acreditamos que um projeto de TI deve ser tocado. Ceder a
cláusulas "tortas" em contrato mostra uma fragilidade no seu discurso ou
uma necessidade de "vender a qualquer custo". Nenhuma dessas
percepções soa bem ...
● A chance de ter cláusulas que vinculam fim de sprint ao pagamento e a
aceite de uma entrega devem ser evitadas. Lembre-se que o que estamos
vendendo é um time por determinado tempo de projeto
● Os contratos devem ter cláusula de saída muito simplificadas. Essa deve
ser a contrapartida...Se o cliente não estiver satisfeito ele pode sair do
projeto rapidamente, sem multas e sem dificuldades - "Fail Fast"
Não ceda a pressões de negociação
19. ● Tenha respostas seguras para perguntas do tipo:
○ "Por esse contrato entendo que o risco do projeto está somente do meu lado. É isso
mesmo ?"
○ "Quer dizer que por essa cláusula se vocês terminarem um sprint e não houver sido
entregue nada do que foi planejado eu tenho que pagar do mesmo jeito ?"
○ "O que acontece com os erros que aparecerem ao final de um sprint? Entra na garantia?"
● Compartilhe minutas de contrato descaracterizadas para o seu futuro cliente
● Apresente pessoas de outras empresas que trabalham ou já trabalharam com
sua empresa
● Compartilhe casos onde não houve tanto sucesso e mostre o que foi
aprendido com isso
● O mais importante é ser transparente e passar confiança. A verdade é
inegociável!!
Argumente com segurança
20. ● Entregue o que foi vendido !
● Durante a execução do projeto é muito importante não ceder a pressões e mudar a
regra do jogo:
○ sprint é time box
○ bug vira backlog
○ documentação e treinamento são backlog
○ sprint de homologação é para homologação e não desenvolvimento
○ horas trabalhadas precisam ser repassadas para o cliente
○ mantenha o foco no valor do negócio e não deixe seu cliente se desviar disso
○ não se esqueça que seu time e sua empresa é co-responsável pelo sucesso do projeto. O sucesso
e o fracasso são compartilhados !!!
● Um projeto bem executado facilita em muito futuras vendas
Entregue o que foi vendido
21. 1. Seja claro em relação a sua oferta
2. Defina a maturidade digital do seu cliente
3. Antecipe as conversas sobre contrato
4. Não ceda a pressões de negociação
5. Argumente com segurança
6. Entregue o que foi vendido
22. "O anexo A apresenta o backlog de atividades nas quais a
CONTRATADA se baseou para estimar o projeto. Entende-se que
o projeto será desenvolvido utilizando metodologia ágil e
alterações de itens e repriorização de estórias poderão
acontecer e serão negociadas entre CONTRATADA E
CONTRATANTE
Os pagamentos são vinculados a finalização do Sprint (10 dias
úteis) e não a entrega dos itens do backlog no anexo A."
23. "Os serviços serão prestados pela CONTRATADA utilizando
exclusivamente a metodologia ágil de desenvolvimento de software
SCRUM
O escopo inicialmente desejado pela CONTRATANTE para o Software
poderá mudar ao longo da execução do projeto em função das
definições e redefinições de prioridades pela própria CONTRATANTE,
de acordo com suas necessidades ao cenário dos negócios vinculados
ao objeto deste contrato. As PARTES reconhecem que não existe um
escopo definitivo para o presente momento para entrega pela DEXTRA
para a CONTRATANTE, e poderá não existir mesmo ao final deste
contrato."
24. Cláusula Original:
"Caso quaisquer testes demonstrem que o Software não está implementado
de acordo com a sua especificação, em virtude de culpa ou dolo da
CONTRATADA, a CONTRATANTE notificará a CONTRATADA para que,
solucione o defeito, incidente, ou problema exigido para a continuidade do
projeto, conforme prazos acordados, dessa forma, a CONTRATADA tomará as
medidas corretivas exigidas para garantir que o Software seja aprovado nos
critérios de aceitação em todos os aspectos materiais. A equipe da
CONTRATADA deverá ser mantida no projeto até que o defeito, falha ou
problema seja resolvido. e sem quaisquer ônus para a CONTRATANTE."
25. Cláusula Final:
"Os Testes e Aceitação em um projeto ágil com escopo negociável (SCRUM) seguem
sempre o ciclo de desenvolvimento denominado Sprint de 2 (duas) semanas.
A CONTRATADA garante que em cada Sprint de desenvolvimento executará os testes
necessários e acordados entre as partes antes de entregar o produto na reunião de
Review para que a CONTRATANTE possa realizar a Homologação dos resultados deste
Sprint. Desta forma o resultado entregue ao final do projeto terá sido testado a cada duas
semanas ao longo de todo o projeto.
Em todos os projetos antes da liberação de um release, haverá ao menos um Sprint de
Homologação.
Ao final de cada Release à CONTRATANTE deverá testar o Software "
26. Cláusula Original:
"O pagamento poderá ser retido se a CONTRATANTE não aceitar os serviços
prestados em razão de não estarem nos termos deste contrato e desde que as
correções solicitadas pela CONTRATANTE não tenham sido realizadas a
contento pela CONTRATADA e nos moldes do ora acordado pelas Partes."
Cláusula Final:
REMOVIDA !!!
27.
28. São Paulo (SP) +55 11 3014-0305
Campinas (SP) +55 19 3256-6722
Complexo Pólis de Tecnologia
Rod. Campinas Mogi Mirim (SP 340), km.118,5
Prédio 20 - Campinas, SP
CEP 13086-902
Rodrigo Romero
Head of Business Development at Dextra
rodrigo.romero@dextra-sw.com
(19) 9 9236-6472