O cenário
Uma equipe Scrum trabalha com as premissas das metodologias ágeis como: escopo flexível, entregas constantes, inspeção, adaptação, etc.
Um cliente de software, ao entrar em contato com uma empresa de desenvolvimento procura obter basicamente duas respostas: "Quanto tempo levará para entregar o que estou pedindo?" e "Quanto isso vai me custar?".
A partir dessa diferença de visões, é comum ouvirmos frases como: "Scrum é muito bonito na teoria, mas impraticável no mundo real".
O triângulo de ferro
Nas metodologias "tradicionais" de desenvolvimento de software, muito se fala do “triângulo de ferro” formado pelas três variáveis do projeto: Escopo, Prazo e Custo (Figura 1).
Figura 1: Triângulo de Ferro
Ao fazer um orçamento, o cliente procura fechar esse triângulo definindo um escopo (ou imaginando definir) e exigindo um comprometimento da equipe quanto ao prazo e custo do projeto.
Na prática, esse modelo é ruim para todas as partes:
- Para o cliente: Ele tem que definir no começo do projeto tudo que ele quer que seja feito, estando sujeito a cobranças adicionais cada vez que identificar uma nova necessidade;
- Para a equipe: Ela precisa se comprometer com um prazo e custo no início, quando normalmente não possui todas as informações necessárias para saber exatamente "o tamanho da encrenca".
Para a empresa, um projeto nesses moldes também é desvantajoso. Quanto tempo seria necessário para levantar tudo que é necessário em um sistema e "chutar" (é exatamente esse o termo) um prazo de término?
E se o cliente não fechasse o contrato, quem pagaria esse prejuízo? O cliente estará disposto a pagar "apenas" por um chute de prazo? A empresa está disposta a gastar tempo e dinheiro analisando um sistema inteiro, sem certeza alguma do fechamento do contrato?
Note que na figura acima a qualidade está oculta. Idealmente, ela é uma "constante" e está no centro do triângulo.
No entanto, conforme o projeto caminha o que se nota é que caso algo não saia como o planejado a qualidade é a primeira coisa que varia e, inevitavelmente, varia pra baixo.
Gordura
No cenário descrito acima, todos se deixam enganar e enganam o próximo pela chamada "gordura".
A cada nível que uma estimativa sobe, do desenvolvedor para o gerente, do gerente para o responsável pelo comercial, do responsável pelo comercial ao cliente, etc., ela ganha uma "gordurinha extra". Dessa forma, é comum que algo que o desenvolvedor acredite poder fazer em 2 horas chegue para o cliente estimado em 18 horas, num verdadeiro jogo de "me engana que eu gosto".
Quebrando paradigmas
Para vender projetos ágeis é necessário mostrar ao potencial cliente o quão nociva para a relação comercial é, normalmente, essa maneira de negociar contratos.
Em contrapartida, trabalhando com Scrum temos diversas vantagens a oferecer ao cliente:
- Entregas frequentes (e rápidas);
- Software rodando mais cedo;
- A qualidade é, realmente, uma constante;
- Transparência.
Garantias
Com certeza, a maior parte das pessoas ao ser questionada sobre um contrato nesses moldes pensará na falta de garantia quanto à execução do serviço contratado, por diversos motivos. Mas pensando bem, realmente não há garantias?
Garantias para o cliente:
- Uma equipe Scrum trabalha com ciclos curtos de desenvolvimento (sprints) de, no máximo, um mês. Logo, após um mês do fechamento do contrato (no máximo) o cliente terá uma porção do software (definida por ele) rodando e poderá avaliar o serviço executado.
- Caso não goste do resultado ele pode cancelar o projeto e buscar um novo fornecedor. Em um contrato "tradicional" normalmente quando não se gosta do resultado já é tarde demais...
- O cliente faz parte do projeto (de verdade) em equipes ágeis. Ele é sempre comunicado e consultado sobre qualquer problema que ocorra no projeto. É ele quem define o que será feito, quando e como. Se ele mudar de ideia (ou descobrir novas necessidades) não pagará nada mais por isso bastando apenas encaixar esse novo requisito no Product Backlog, na ordem que ele julgar necessária.
- Quando o cliente julgar que o software está pronto, ele pode encerrar o projeto.
Garantias para empresa:
- O time Scrum vai fazer o que realmente gosta, que é desenvolver software recebendo feedback rápido do cliente;
- O cliente próximo faz com que a empresa tenha a cada término de sprint uma visão da satisfação em relação ao produto sendo entregue;
- Projetos de software mudam constantemente. Dificilmente um software pode ser considerado "pronto". Com o cliente tendo liberdade de incluir e retirar requisitos, e com uma entrega com qualidade, em muitos casos o projeto durará muito mais se comparado a quanto duraria um projeto de escopo fechado.
Vantagens
Esse modelo de projeto apresenta vantagens extremamente positivas para todos os envolvidos. No entanto, o cliente deve estar ciente dos princípios do manifesto ágil e da importância de estar presente para o bom andamento do projeto.
Um projeto transparente, onde a comunicação flui de maneira direta garante uma grande parceria entre fornecedor e cliente acabando com a cena de conflito constante entre as partes.
Software entregue rápido, testado rápido, problemas menores e entendimento de pequenas porções por vez são algumas das principais vantagens para o time.
Software rodando e gerando valor mais cedo, ter o projeto na mão e poder mudar sem precisar aturar "caras feias", aditivos de contrato, alterações de prazo (que já não são cumpridos na maioria das vezes) são algumas das principais vantagens para o cliente.
Argumentos finais
Alguns argumentos que justificam essa mudança de paradigma:
- Segundo um estudo publicado em 2002 pelo Standish Group (Figura 2), apenas 20% dos requisitos de um sistema são utilizados com frequência. Isso equivale dizer que 80% de tudo que é implementado é muito pouco utilizado sendo que 45% dos requisitos nunca serão utilizados. Pensando em dinheiro. Em um projeto de R$ 100.000,00, estamos dizendo que R$ 45.000,00 serão, literalmente, jogados no lixo.
- Propaganda negativa: É sabido que a propaganda negativa é muito mais feroz que a propaganda positiva. Basta uma rápida pesquisa sobre qualquer estabelecimento para notar que a quantidade de reclamações será muito superior à de elogios. Dessa forma, quando uma empresa atrasa projetos, estoura custos, não é transparente com um cliente, ela automaticamente fecha as portas com diversos outros clientes em potencial. Trazendo o cliente para o projeto, fazendo com que ele entenda e acompanhe as dificuldades do processo, sendo transparente em todos os momentos, a quantidade de projetos que falham cairá drasticamente e, por consequência, a propaganda negativa gerada por eles.
Figura 2: Utilização de requisitos de um sistema
Bom, por enquanto é isso. Apesar do tema ser polêmico, foi apresentada uma solução (baseado na experiência após enfrentar diversos problemas, tanto como fornecedor quanto como cliente). Qualquer dúvida estou a disposição para debatermos. Abraços.
