A Relação Cliente e Fornecedor na Contratação de Projetos de Framework Ágil
Autoria: Carlos MAGNO da Silva Xavier (Doutor, PMP) - Diretor da Beware.
Coordenador e coautor do livro “Gerenciamento de Aquisições em Projetos” (FGV)
Para entender como tem sido no Brasil a relação entre cliente e fornecedor, quando da contratação de projetos que utilizam, em seu desenvolvimento, um framework ágil, realizei no 1º trimestre de 2020 uma pesquisa na Internet. O questionário possuia 15 perguntas e obtive 77 respostas até o dia 20 de março. A pesquisa continua aberta em https://forms.gle/ACD2Z6CvVb6qmA7B9 e, caso não tenha ainda respondido, será muito útil a sua participação.
O objetivo deste texto é apresentar o resultado dessa pesquisa, com a minha interpretação das respostas recebidas. É importante ressaltar que não há nenhuma comprovação estatística de que a amostragem das respostas represente corretamente o que está acontecendo nesse tipo de contratação no Brasil.
Comentário: Conforme esperado, os tipos mais comuns de projetos contratados que utilizaram métodos ágeis foram: sistemas de Informação (desenvolvimento de software); consultoria; desenvolvimento de produtos e serviços (inclui projetos de novos negócios); e defesa, segurança e aeroespacial.
Comentário: Os papéis mais comuns dos respondentes foram: Gerente de Projeto / programa; consultor externo; scrum master / agile coach; e VP / Diretor / Gerente Funcional. Interessante que poucos eram Product Owner (PO). Uma possível explicação é que no meu ciclo de contatos existem mais profissionais da área de gerenciamento de projetos.
Comentário: A maior parte utilizou scrum / scrum of srcums / scrumban, sendo ainda relevante o percentual de métodos desenvolvidos internamente.
A título de comparação, veja no gráfico abaixo o que estavam usando os respondentes do 13th-annual-state-of-agile-report, divulgado pela COLABNET em 2019, com maior incidência do Scaled Agile Framework® (SAFe®) e Scrum of Scrums.
Comentário: A proporção é praticamente meio-a-meio, na relação cliente / fornecedor, de quem estabelece o framework a ser utilizado. A vantagem de a definição ser feita pelo contratante é que será mais fácil o acompanhamento pelo cliente, caso ele já utilize um framework. Se for definido pelo contratado, como ele será o executor, aproveitará a sua expertise no framework.
Comentário: Visão do produto, histórias de usuários, requisitos detalhados e roadmap foram os mais presentes documentos na RFP (Request for Proposal). Estranho a presença de requisitos detalhados, uma vez que não faz sentido detalhar os requisitos se o escopo vai ser priorizado e definido a cada sprint. Vemos aqui o resquício da cultura tradicional do cliente de querer o escopo fixo para ter o preço fixo no contrato.
Comentário: O fato de ter um alto percentual em que o Product Owner (PO) não era funcionário do contratante reflete a cultura, ainda existente, de pouco envolvimento do cliente quando da relação contratual e do costume tradicional de entregar um escopo detalhado e aguardar a futura entrega dos produtos para aceite.
Comentário: O resultado indica que os PO tinham, na sua maioria, uma dedicação de menos de 24 horas por semana ao projeto, sendo o maior percentual para dedicação abaixo de 8 horas. Em um projeto com framework ágil, a presença constante do PO é fundamental para a implementação do ciclo evolutivo do escopo do produto ou serviço.
Comentário: O fato de cerca de 50% dos contratos serem de preço fixo reflete a cultura, ainda existente, de contratar com escopo fechado e preço fechado. O preço unitário com planilha de preços por hora de profissional e o preço unitário por iteração / sprint, sem fixação do número de iterações, foram os que vieram a seguir em utilização.
Considero o contrato de preço unitário como o mais adequado para que aproveitemos ao máximo o desenvolvimento evolutivo em um framework ágil. Em razão das incertezas de valor final, é importante utilizar cláusulas de incentivo e penalidade, o que será abordado na próxima questão. Além disso, como a seleção do fornecedor tem de ser mais técnica, recomendo utilizar um modelo de técnica e preço para a avaliação das propostas. Um exemplo de modelo pode ser visto no artigo "A Teoria da decisão na escolha dos fornecedores para projetos."
Comentário: As cláusulas de incentivo e penalidade de valor final não fazem sentido no contrato de preço fixo. Levando em consideração, pelas respostas da pergunta anterior, que cerca de 40% dos contratos foram de preço unitário ou de custos reembolsáveis, podemos dizer que metade desses contratos tinham esse tipo de cláusula.
Comentário: Uma cláusula de preço máximo garantido (PMG) também não faz sentido em contratos de preço fixo. Levando em consideração que cerca de 40% dos contratos foram de preço unitário ou de custos reembolsáveis (que têm valor final incerto), podemos dizer também que cerca de metade desses contratos tinham esse tipo de cláusula. Aliás, é fundamental termos cláusulas de incentivo e penalidade, de valor final, quando temos cláusula de PMG.
Comentário: O fiscal do contrato é responsável por fazer com que as cláusulas contratuais sejam cumpridas pelos envolvidos. O resultado da pesquisa aponta que os PO, em sua maioria, não eram os fiscais do contrato. A minha opinião é que, principalmente em pequenos e médios contratos, eles podem acumular esse papel, uma vez que são os responsáveis pelo aceite das entregas.
Comentário: A pesquisa apontou que a ferramenta mais usada (54,5 %) foi o Excel, seguida pelo Kanban em quadro físico com post its, Trello e Jira. Isto reflete o pouco uso de ferramentas que apoiem de forma mais completa o gerenciamento desse tipo de projeto.
A título de comparação, veja na figura abaixo o que os respondentes do 13th-annual-state-of-agile-report recomendaram como ferramenta. Importante ressaltar que a pesquisa foi feita pela COLABNET, proprietária da ferramenta VersionOne, e teve 1.319 respondentes. Na minha pesquisa ninguém utilizou essa ferramenta.
Como na figura não fica claro, vou listar abaixo as respostas que tiveram mais de 30%:
- Falta de conhecimento ou experiência do cliente com métodos ágeis – 48,1 %
- Cultura organizacional do cliente ser contra a agilidade – 42,9 %
- Cliente não saber o que quer – 40,3 %
- Resistência da Organização do cliente a mudanças – 40,3 %
- Dificuldade na definição / utilização dos critérios de aceite (done) pelo cliente – 40,3%
- Problemas com governança / compliance / Papéis e responsabilidades nãos claros – 32,5 %
- Falta ou inconsistência de métricas do projeto – 31,2 %
Como podem ver, os itens mais apontados têm a ver com a cultura do cliente e resistência à agilidade. Isto mostra a necessidade de Change Management, ou seja, mudar o mind set. Recomendo a leitura do meu artigo “Não adianta querer um projeto ágil se a organização é lenta”, disponível em https://www.linkedin.com/pulse/n%C3%A3o-adianta-querer-um-projeto-%C3%A1gil-se-organiza%C3%A7%C3%A3o-%C3%A9-da-silva-xavier/.
A título de comparação, veja na figura abaixo que os respondentes do 13th-annual-state-of-agile-report apontaram os mesmos desafios culturais para a adoção de métodos ágeis.
Comentário: Qualidade das entregas, entrega no prazo, resultados / benefícios para o negócio e satisfação do cliente / usuário foram as respostas mais comuns. Percebam um foco maior na gestão técnica do projeto do que na gestão estratégica do negócio, o que não considero adequado. Recomendo o meu artigo “O novo “Gerente de Projetos” e a repaginada do “Analista de Negócios”, disponível em https://beware.com.br/destaques/o-novo-gerente-de-projetos-e-a-repaginada-do-analista-de-negocios/. Embora de 2015, creio que o tema ainda é atual, principalmente quando vemos a discussão PO x Analista de Negócios x Gerente de Projetos x Scrum Master x Agile Coach.
A título de comparação, veja na figura abaixo que os respondentes do 13th-annual-state-of-agile-report apontaram os mesmos 4 critérios como mais utilizados, embora em uma ordem inversa.
Comentário: Se não computarmos as respostas “Não sei”, verificamos que cerca de 50% das organizações vêm utilizando métodos ágeis há menos de 1 ano, e somente cerca 20% há 3 ou mais anos. Vemos que a grande maioria das organizações que contrataram esses projetos têm baixíssima maturidade no tema.
A título de comparação, veja na figura abaixo que os respondentes do 13th-annual-state-of-agile-report eram bem mais experientes. Importante lembrar que aquela pesquisa, diferente desta, não foi especificamente para contratação, sendo bem natural que as empresas tomem a decisão de contratar algum serviço justamente por não ter a expertise necessária.
Conclusão
Como resultado desta pesquisa, podemos concluir que temos muito a evoluir para que melhoremos a eficiência e eficácia da contratação de projetos com framework ágil.
Como sugestão para os futuros contratantes, recomendo:
- Dissemine a cultura (mind set) ágil na sua Organização.
- Antes de iniciar o processo de ida ao mercado, reúna os principais envolvidos e realize uma breve reunião para identificação, análise e respostas aos riscos dessa contratação.
- Não vá ao mercado solicitar propostas com os requisitos detalhados, pois não faz sentido no desenvolvimento ágil.
- Defina qual framework ágil e ferramenta de gestão do projeto devem ser utilizados pelo contratado no desenvolvimento do projeto. Se não tiver maturidade para definir, deixe por conta do contratado essa definição. Capacite, nesse framework e ferramenta, o pessoal que irá interagir com a contratada.
- Defina métrica(s) de sucesso do contrato, principalmente em relação aos resultados / benefícios para o negócio e satisfação do cliente / usuário. Se possível, associe parte da remuneração do contratado ao alcance de metas, podendo também ter cláusula de bonificação no contrato.
- Evite utilizar contrato de preço fixo, pois haverá a necessidade de estabelecer um escopo fixo ou limitar recursos e número de sprints.
- Utilize, preferencialmente, contrato de preço unitário, com cláusulas de incentivo e penalidade em relação ao valor final do contrato. Quando possível estabeleça cláusula de preço máximo garantido. O contrato de custos reembolsáveis também é uma opção, principalmente quando o escopo é complexo e não se tem ideia dos recursos que serão necessários para o desenvolvimento do produto ou serviço.
- Se possível em sua Organização, utilize um modelo de técnica e preço na avaliação de propostas na escolha do fornecedor que será contratado.
- Selecione um Product Owner (PO) que tenha disponibilidade de tempo para participar do projeto.
- Se não tiver maturidade na contratação do desenvolvimento de produtos e serviços que irão utilizar framework ágil, faça antes um bechmarking com empresas que tenham essa expertise ou contrate um especialista para dar o apoio necessário na preparação do processo.
Sobre o autor:
Carlos Magno da Silva Xavier ( Doutor, PMP)
Diretor da Beware - magno@beware.com.br
Carlos Magno da Silva Xavier foi eleito, em 2010, uma das cinco personalidades brasileiras da década na área de gerenciamento de projetos. É Doutor pela Universidad Nacional de Rosário (Argentina) e Mestre pelo Instituto Militar de Engenharia (IME). Sócio-Diretor do Grupo Beware, sua experiência profissional, de mais de vinte e cinco anos, inclui a consultoria na sistematização do gerenciamento de processos, projetos, programas e portfólio em várias Organizações (TIM, Eletronuclear, BR Distribuidora, Eletropaulo, Marinha do Brasil, Iguatemi, Emgepron, SESC-Rio, Petrobras e outras).
Magno é também autor/coautor de dezoito (18) livros, dentre eles “Metodologia de Gerenciamento de Projetos – Methodware” – eleito em 2010 o melhor livro brasileiro da década na área de gerenciamento de projetos. É certificado “Project Management Professional” (PMP) pelo Project Management Institute (PMI) e professor de MBAs da Fundação Getúlio Vargas, Fundação Dom Cabral e UFRJ.