Precisamos rever como os projetos são vendidos !
Scrum é um dos frameworks mais adotados pela indústria quando falamos de agilidade, e grande parte do mercado conhece seu modelo incremental para gestão de projetos. Baseado em pequenos ciclos, sua abordagem faz muitos vibrarem com a possibilidade de interagir com o produto e interferir diretamente no seu sucesso. Lindo, né? Mas o que isso significa de verdade?
Apesar de muitas empresas o adotarem, elas ainda se prendem a algumas práticas dos modelos antigos de gerenciamento de projetos, ferindo a própria filosofia dos métodos ágeis. Afinal, não basta só os desenvolvedores trabalharem com Scrum. Todo mundo precisa estar no mesmo barco.
Então, se alguém espera fechar um projeto assim, por que não comprá-lo como tal? Isso implica em repensar como os projetos são vistos, desde o surgimento da demanda até a hora de pagar a conta. Em outras palavras, precisamos entender se Scrum realmente combina com escopo ou valores fixos!
Por isso, vamos te levar para entender de verdade o que significa esse framework e, assim, abraçá-lo completamente. Seguimos cronologicamente com um pouco de história, antes das primeiras provocações.
Falando de agilidade e Scrum
Um estudo publicado em 1995 chamou atenção ao verificar que 81 bilhões de dólares seriam gastos naquele ano com projetos software que não veriam a luz do dia nos Estados Unidos. Cancelados ou com um produto que não seria utilizado, eram um desperdício de tempo, esforço e dinheiro graças a um modelo de gerenciamento de projetos que não funcionava.
Chamado de Waterfall, como em uma cascata em que água vai e não volta, as etapas desse processo eram muito bem definidas ao seguir um fluxo “sem voltar atrás”. Na prática, não era isso que acontecia e os projetos retrocediam por alguma razão sempre que surgia algum problema no estágio seguinte. Tudo demorava meses, ou até mesmo anos, e a realidade do produto quando concebido era completamente outra de quando entregue.
Questionando se é realmente possível evitar mudanças — ou se você as abraça — diversos frameworks e movimentos apareceram para responder isso pensando no conceito de agilidade. Foi então em 2001 que surgiu o Manifesto Ágil, declaração que rege a maioria dos frameworks de agile e lean software development. Falando de Scrum, o método mais difundido, a ideia é quebrar o modelo tradicional em pedaços menores e incorporar os feedback loops dentro do processo normal.
Com o mínimo necessário de planejamento, construção e teste, já temos um entregável. Isso é um Sprint. Releases incrementais de normalmente uma a três semanas, que se repetem até completar o projeto.
O que significa não planejar um projeto do começo ao fim, mas sim, se adaptar ao longo do seu andamento com um escopo aberto. Sem budget ou entregáveis fixados. Para que isso funcione, o Scrum se apoia em três pilares.
- Com transparência você assegura a produtividade e as entregas. Isso implica que o cliente saiba o quer, e que contratado e contratante sejam realmente parceiros.
- Com inspeção, a cada iteração você verifica como o ciclo foi realizado para então se adaptar para o próximo.
- Com adaptação você vê o que funcionou e mantém, vê o que não funciona e corrige. É o famoso PDCA, em que as entregas parciais se aproveitam do feedback do cliente.
Legal, mas…
Parece que para o mercado só os benefícios fazem sentido. Todo mundo quer projetos que saibam lidar com mudanças, sejam mais rápidos, mais baratos e que abriguem relações transparentes e de cooperação. Então por que firmar um acordo que apoie o que a metodologia ágil prega é tão difícil?!
O medo do escopo aberto e dos gastos inesperados
Para alguns, um acordo desses não permite vislumbrar “o fim”, os fazendo temer por potenciais gastos inesperados. Ou seja, a resistência se dá pela fixação por um modelo tradicional de compra onde o cliente paga por um valor fechado e têm na ponta do lápis o quanto foi gasto e o que ele recebe. Alguém que compra software mantendo essa lógica de bens de consumo não percebe que isso não se aplica à projetos de desenvolvimento por duas razões:
“For a new software system, the requirements will not be completely known until after the users have used it.”
Watts Humphrey, IBM Researcher
“Uncertainty is inherent and inevitable in software development processes and products.”
Hadar Ziv, University of California
Um projeto de software está em constante transformação. Por isso ele é diferente de um carro, por exemplo. Um carro normalmente é comprado com um investimento inicial alto e mantido com pequenos gastos posteriores, previstos com economia. Isso faz sentido para a realidade imutável de um automóvel, mas não faz sentido para tecnologia.
O falso conforto do escopo fechado
Hoje, a maioria dos projetos (inclusive na Taqtile) são acordados com um escopo fechado, e isso obriga o cliente a se comprometer com um escopo desde cedo. Seria como comprar uma SUV e descobrir que o espaço extra não teria utilidade lá na frente porque sua família não cresceu como esperado, ou comprar um carro compacto e se surpreender com trigêmeos. Resumindo, o escopo não pode mudar conforme forem descobertas novas necessidades do projeto.
Então, o escopo fechado que se apresenta como segurança é, na verdade, um limitador pretendendo evitar qualquer “gasto inesperado”. Para isso acontecer de fato, quando estimado o valor de um projeto com preço total pré-definido, contam-se todos os riscos possíveis . Isso na verdade acaba tornando-o mais caro! Por exemplo, um projeto em Scrum de 8 a 12 semanas — que já vê uma quantidade significativa de redirecionamentos — resultaria no formato tradicional em algo com cerca de 16 a 24 semanas. Ou seja, mais longo (e mais caro) graças a funções retiradas ou mudadas drasticamente.
E isso é indiferente ao tamanho da empresa ou escopo. Os problemas enfrentados em um projeto pequeno são os mesmos que em um projeto grande, mas em escalas diferentes. A diferença é que projetos pequenos são mais sensíveis a mudança e riscos, uma vez que os grandes têm mais “gordura” para absorver o impacto das mudanças e imprevistos.
Ok, e agora?
A chave do sucesso está em uma alternativa em que o cliente não tenha aversão a riscos. Se sentir confortável para gerenciá-los faz parte da estratégia de uma companhia e é crucial para o sucesso. Mas sabemos como isso é delicado na hora de aprovar um investimento, principalmente falando do mercado brasileiro.
Varejo, por exemplo, é normalmente o segmento menos propenso a aceitar um contrato “aberto” por causa da sua própria natureza. As margens são mais apertadas e, apesar de ser possível vislumbrar os ganhos de uma abordagem diferente, um preço fixo é preferido em detrimento de eventuais benefícios. Mesmo que isso implique num produto mais caro e em um processo mais longo e cansativo.
Uma alternativa é alinhar o interesse das duas empresas em contratos orientados a custos — como proposto nesse estudo pela Cyrus Innovation. Eliminando o ambiente win-lose e deixando as duas partes focadas em reduzir custos e complexidade, o objetivo é desmistificar aquela visão que alguns clientes têm dos vendedores como adversários (o que restringe o potencial de sucesso quando um se limita a pensar em “vencer” o outro para pré-definir o valor de um escopo).
Trabalhando com Scrum, temos o desafio diário de conciliar metodologias ágeis com escopos fechados. Claro, existe maleabilidade para mudanças, mas no fim, o projeto é orientado a um valor teto e a um escopo de trabalho relativamente fixo. Nossa experiência nos permite sugerir o que acreditamos ser o melhor, mas nem sempre vamos conseguir chegar a um consenso. O que acaba sendo comum é, à medida que o projeto vai fluindo, termos em mente o que pode ser substituído e deixado no backlog para a manutenção, caso a realidade do projeto vá se tornando outra. Aí sim, na manutenção, nos focamos no Scrum com horas de trabalho e prioridades acordadas mês a mês — o que permite maior maleabilidade tanto para nós, quanto para o cliente.
O caminho à frente
O que funciona para a realidade das empresas brasileiras? Não sabemos. Inclusive, não chegamos na resposta nem para a própria realidade da Taqtile. Mas, apesar de ainda não sabermos em qual direção seguir, temos notado uma movimentação progressiva do mercado em busca de opções. Aos poucos, mais e mais requisições de proposta chegam chamando atenção ao buscar formatos diferentes de relacionamento. Ainda é uma parcela pequena do todo, mas já significa alguma coisa.
Por isso, gostaríamos deixar alguns questionamentos sobre qual seria a melhor forma de se negociar projetos em Scrum. Queremos saber como as empresas têm enfrentado esse desafio e se tem dado certo! Comprador, vendedor, desenvolvedor, não importa. Queremos sua contribuição (ou ao menos sua reflexão).
Afinal, nosso único desejo é que, aos poucos, alternativas aos contratos de preço fixo sejam mais difundidas, pensando em um mindset propício para agilidade. Nos aproximando da abordagem de confiança que rege contratos de manutenção — atualmente só possível com o estabelecimento de uma relação prévia — caminharemos juntos a favor de um ambiente mais saudável e positivo para todos.
Por hoje, paramos por aqui.
Obrigado pela leitura e até a próxima!
Vá mais fundo conhecendo sobre nosso processo de desenvolvimento e manutenção e fique à vontade para compartilhar suas ideias, nos dizendo sua opinião sobre como negociar projetos em Scrum.
Referências
- Uncertainty Principle in Software Engineering
- Chaos Report
- Manifesto Ágil
- Selling Agile: Target-Cost Contracts
Créditos
- Ícones — Denis Sazhing
- Fontes — Chocolate Covered Raindrops
Colaboradores
- Max Brunner
- Pedro Leão
