Artigos Engenharia de Software Como vender projetos Scrum

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).

Triângulo de Ferro

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.
Utilização de requisitos de um sistema

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.