Por que o levantamento de requisitos tradicional não funciona… E o que fazer a respeito

Tempo de leitura: 17 minutos

Quem nunca teve problemas com o levantamento de requisitos em um projeto?

Ao começar o desenvolvimento, sempre descobrimos dezenas de detalhes importantes que não foram lembrados, ou funcionalidades primordiais que nem sequer foram avaliadas durante a fase de análise e levantamento. Mesmo depois de incontáveis reuniões com o cliente (quando digo “cliente”, não é necessariamente um usuário final, pode ser a pessoa responsável pelo projeto).

E por que isso sempre acontece?

Se você conheceu ou já trabalhou com muitas pessoas diferentes, tente se lembrar de como cada uma delas fazia a análise e levantamento de requisitos. Você vai perceber que a grande maioria trabalha da mesma maneira, usando técnicas e processos bem parecidos.

Ou seja, enfrentamos os mesmos problemas porque fazemos sempre da mesma forma, seguindo os mesmos passos.

Neste artigo, quero te mostrar que há maneiras diferentes de fazer o levantamento de requisitos. Para ser mais específico, vou te mostrar um método que uso há algum tempo e trouxe resultados incríveis.

Vamos lá?

Por que o levantamento de requisitos tradicional não funciona?

Por que não funciona?
Por quê? Por quê?

Vamos falar sobre o processo mais comum, aquele que a maioria aprendeu na faculdade, ou com um amigo da área, ou na pancada mesmo, no dia a dia do trabalho junto com pessoas mais experientes.

O analista faz as entrevistas com usuários e stakeholders (os donos do projeto), para entender os desejos e motivações sobre o quê vai ser desenvolvido. Esses pontos também podem ser apresentados em forma de workshops, ou podem ser obtidos através de observações diretas de suas rotinas e fluxos de trabalho.

Depois de coletar os dados, é hora de gerar a documentação de apoio do projeto: especificações de negócio, especificações técnicas, protótipos, declaração de escopo, entre outros.

Em algumas empresas esses documentos são entregues ao cliente para que sejam aprovados e assinados, criando um comprometimento mútuo entre as partes. Quase um contrato de serviço.

Na teoria tudo parece fazer sentido. Na prática, já sabemos o resultado. Vamos entender os principais motivos que transformam um cenário perfeito em um fracasso eminente.

O cliente fica muito distante da equipe, e isso gera atritos

Briga com o cliente
Não é exatamente assim. Mas é quase.

Depois de todo esse detalhamento, o cliente dá um tapinha nas costas da equipe de TI e diz “Já fiz minha parte, agora é com vocês!”.

Ele sabe que o projeto é sua responsabilidade, mas acredita que não tem influência direta na construção. Logo, o trabalho dele nesse período se resume a três tarefas:

  • Esclarecer dúvidas, embora ele seja uma pessoa muito ocupada e não vai estar disponível sempre que necessário.
  • Acompanhar o andamento através de cronogramas, atualizações de status e outros documentos cheios de números.
  • Brigar com a equipe porque o projeto está atrasado.

O desenvolvimento demora muito para começar

Esperando ficar pronto
Só falta especificar um detalhezinho…

Quanto maior o projeto, maior a quantidade de requisitos para analisar e documentar. E todo esse trabalho demora um tempo. Às vezes, muito tempo.

Tempo suficiente para que tudo o que foi documentado se torne inútildesatualizado.

Passamos meses escrevendo dezenas de documentos, cheios de detalhes e fluxos. Depois de mais alguns meses, quando a equipe entrega o que foi pedido, o cliente diz que as regras mudaram e o que foi feito não atende a necessidade.

Você deve estar pensando “O escopo mudou, logo é preciso renegociar!“. Mas será que o cliente alterou o escopo por um mero capricho? Ou será que era necessário alterar porque o negócio da empresa evoluiu e você não conseguiu acompanhar na velocidade necessária?

A documentação é tratada como um contrato e perde a sua função original

Muita papelada
Também serve de travesseiro.

O caso do parágrafo anterior pode terminar de dois jeitos:

  1. Você trabalha feito maluco, engole o prejuízo e faz as alterações que o cliente pediu no prazo que ele queria.
  2. Você começa uma longa batalha sobre alterações de escopo, documentos assinados e pedidos mal formulados.

A documentação do projeto, que foi criada originalmente para apoiar o desenvolvimento, vira um escudo na negociação de prazos e orçamentos. Se o cliente assinou, ele se comprometeu com o que foi escrito. Se ele assinou e não leu, o problema é dele.

O mais engraçado é que, na maioria dos casos, o desfecho se inicia pelo item 2, e termina com o item 1. Você reclama, reclama, mas faz o que foi pedido para manter o bom relacionamento com o cliente.

Até porque a sensação de não entregar um projeto é bem ruim. Mas o sentimento de derrota é muito pior quando você entrega algo que não tem utilidade ou não é usado.

Uma abordagem diferente: agilidade, histórias e um novo mindset

Uma nova abordagem para o levantamento de requisitos

Como citei no início deste artigo, existem várias formas de fazer o levantamento de requisitos. Porém, mesmo usando técnicas diferentes, todos os métodos mais eficientes seguem o mesmo princípio fundamental: a agilidade.

E agilidade não tem nada a ver com entregar o seu trabalho o mais rápido possível. Para ser ágil você precisa valorizar as coisas certas na hora certa.

Na minha opinião, esse é o conceito mais importante das metodologias ágeis, mas nenhuma literatura fala disso explicitamente.

Vou te mostrar três dicas que você pode implementar no seu processo de levantamento de requisitos. Isso vai te ajudar a entender esses conceitos de agilidade e valor das coisas, ao mesmo tempo que os coloca em prática.

Tente ler sem preconceitos do tipo “isso é impossível”, ou “na minha empresa não vai rolar”, esses pensamentos vão bloquear suas ações. Para evoluir, você precisa mudar o seu mindset.

Você não vai enxergar a forma de fazer determinada coisa enquanto não enxergar, a si mesmo, fazendo essa coisa. – David Allen

Dica #1 – Planeje apenas o mínimo necessário

Muita bagagem
É só pra passar o final de semana.

Aprendemos que é necessário levantar todas as necessidades de um projeto antes de escrever a primeira linha de código. Mas não é bem assim.

Imagine que você decide pegar o carro e ir até o bar tomar um whisky. Você já decidiu que vai sozinho e, quando entra no carro, traça mentalmente a rota que vai seguir. Porém, no meio do caminho, você passa perto da casa de um amigo e pensa que seria legal ter uma companhia para jogar conversa fora. Então, decide mudar sua rota e o convida para ir junto. Chegando no bar, vocês decidem que é melhor tomar cerveja, porque dá para beber mais e ficar menos bêbado.

O plano inicial era ir direto para o bar, sozinho, e beber whisky. O plano executado foi passar na casa do amigo, ir ao bar acompanhado, e tomar cerveja. Nada a ver, certo?

Mais ou menos. Durante a execução do plano, algumas circunstâncias mudaram e o final não foi exatamente como esperado. Mas veja só, o objetivo principal de ir ao bar para beber, foi atingido. E o resultado foi melhor do que o planejado, ainda mais se o seu amigo ficou bêbado e deu vexame no bar.

Cachorro bêbado
Bebe, cachorro…

Tudo na vida é assim, e um projeto não é diferente. Por mais que você planeje com antecedência, sempre vão acontecer imprevistos no caminho que podem melhorar ou piorar o resultado final. Então, não adianta gastar sua energia tentando prever todos os problemas antes de começar.

O que importa não é o que acontece, mas como você você reage. – Bruce Lee

E como fazer isso na prática?

Primeiro, você precisa organizar o trabalho para que isso seja possível.

O cliente sabe qual é o objetivo principal do projeto, só que às vezes ele não sabe descrever com clareza. Extraia isso da cabeça dele e coloque no papel.

Depois disso, junte-se ao cliente para escrever tudo o que precisa ser feito. A grande sacada aqui é descrever apenas a idéia geral, nada de detalhes. Se já tiver algo parecido, ótimo, mas se a sua lista for muito detalhada, reescreva só com as linhas gerais.

Ao terminar esse trabalho, vocês terão uma enorme lista de itens a fazer. Essa lista pode ficar com o cliente, para que ele saiba exatamente o que falta fazer, o que está em andamento e o que já foi feito.

Com base no objetivo principal, o cliente deve ordenar e priorizar a lista, para que os itens mais importantes sejam feitos primeiro. E essa lista deve ser flexível: novos itens podem ser incluídos sempre que necessário, e podem ser repriorizados a qualquer momento.

Bom, eu expliquei que a sua lista não deve conter requisitos detalhados, apenas idéias gerais. Mas como priorizar os itens sem saber os detalhes? A próxima dica vai te mostrar como.

Dica #2 – Escreva os requisitos numa linguagem que todos entendam e que facilite a implementação

Sabe o que está escrito?
Um documento só é útil quando todos entendem o que foi escrito. Aliás, esse texto está de cabeça pra baixo.

Todos nós aprendemos que os requisitos devem ser uma descrição de como o produto deve funcionar, e esse pensamento está correto. O grande problema é a forma como descrevemos.

Temos o hábito de descrever qualquer coisa de acordo com o nosso ponto de vista. É difícil se colocar no lugar de outra pessoa, mesmo quando você sabe que é necessário.

Um exemplo muito simples dessa situação é um acidente de trânsito entre dois veículos. Se você perguntar para os dois motoristas, um sempre vai dizer que o outro estava errado.

É por isso que o cliente sempre escreve um documento com ênfase no negócio, e o analista de TI gera um documento mais técnico. Geralmente, a construção é baseada apenas na descrição técnica, mas a maioria dos projetos gera os dois documentos.

Com tudo isso em mente, é mais fácil entender porque é mais produtivo juntar-se ao cliente para chegar a uma documentação única que atenda às necessidades de todos os envolvidos.

As metodologias ágeis costumam chamar os requisitos de user stories, ou histórias do usuário. São pequenos textos com estruturas bem definidas, que fazem sentido para usuários e desenvolvedores, e que formam um contexto maior quando agrupados.

As histórias vão compor a sua lista de itens a fazer, por isso devem descrever funcionalidades, e não o quê ou como fazer. Deixe os detalhes para a fase de construção. Neste momento, o importante é conseguir mensurar a quantidade de trabalho a fazer, e não o tempo que vai demorar.

Uma história deve conter 3 elementos principais:

  • Um ator, o elemento que interage com o produto.
  • Uma funcionalidade, a descrição do quê o produto deve fazer.
  • Um benefício esperado, a explicação do valor que a funcionalidade trará quando for implementada.

Veja um exemplo simples sobre uma consulta de vendas:

Como um Gestor de Vendas, eu gostaria de ver um relatório com o valor das vendas de cada vendedor em um determinado dia, para que eu possa avaliar qual deles teve o melhor desempenho no dia.

E como fazer isso na prática?

A grande sacada aqui é começar pensando de forma abrangente e dividir em partes menores até chegar às funcionalidades.

Vamos usar o exemplo do sistema de vendas. Sua primeira história poderia ser:

Como um Gestor de Vendas, eu gostaria de ter um sistema de gerenciamento de vendas, para que minha equipe possa cadastrar as vendas do dia e para que eu possa analisar os resultados.

É algo bem genérico e difícil de mensurar. Porém, o texto deixa claro algumas funcionalidades e atores, então podemos usar essas informações para reescrever em duas partes:

Como um Vendedor, eu gostaria de cadastrar as vendas do dia, para que o meu desempenho possa ser avaliado.

Como um Gestor de Vendas, eu gostaria de consultar as vendas cadastradas, para que eu possa avaliar o desempenho dos vendedores.

Melhorou, certo? Vamos seguir com a segunda história. Durante o levantamento, o cliente diz que é importante que essa análise seja diária. Então podemos reescrever a segunda história com mais detalhes:

Como um Gestor de Vendas, eu gostaria de ver um relatório com o valor das vendas de cada vendedor em um determinado dia, para que eu possa avaliar qual deles teve o melhor desempenho no dia.

E por aí vai. Sei que parece muito retrabalho, mas essa abordagem vai evitar que você fique paralisado, sem saber por onde começar.

Nosso mindset de programador é treinado para pensar sempre de baixo para cima, do detalhe para o todo. Com o tempo e a prática, você vai perceber que é mais produtivo pensar de cima para baixo.

Uma última sugestão: desenhe um protótipo. Pode ser à mão mesmo, numa folha de papel. É mais fácil para que todos visualizem as possíveis funcionalidades.

Agora que o trabalho está organizado, é hora de colocar a mão na massa. E esse é o assunto da última dica.

Dica #3 – Agrupe os requisitos em pacotes pequenos para entrega-los em intervalos mais curtos

Caminhão de entrega
Quanto maior o pacote, maior o trabalho para entregar.

Entregar seu trabalho em partes menores e constantes é a chave para reduzir a pressão, porque diminui a ansiedade do cliente. Se ele vê periodicamente que uma nova parte está pronta e funcionando, não vai encher o saco da equipe. Ele visualiza de fato o que está em andamento, e não apenas um cronograma com percentuais de conclusão.

E essa mudança se reflete de forma interessante no trabalho de levantamento de requisitos.

O detalhamento das atividades deve ser feito a cada pequeno pacote, e apenas os requisitos que serão entregues devem ser analisados. O resto fica para o próximo pacote.

Você verá que isso reduz os conflitos em relação às mudanças nos requisitos. As funcionalidades são implementadas de acordo com as necessidades do momento atual, e não com o que foi identificado meses atrás.

Mudanças ainda podem ocorrer, mas a tendência é que elas apareçam naturalmente depois que o requisito já foi desenvolvido. E, se a atividade estiver em andamento, você pode avaliar junto com o cliente se é melhor parar agora ou se isso pode ser implementado na próxima entrega.

E como fazer isso na prática?

O único pré-requisito é ter uma lista priorizada do que precisa ser feito. Se você seguiu a dica anterior sobre planejar apenas o necessário, já deve ter essa lista. Se não tem, providencie. Entregar os requisitos mais importantes nos primeiros pacotes faz toda a diferença.

Para começar, defina um período de tempo fixo para cada pacote. Pense em algo entre 2 e 4 semanas, nem mais e nem menos. Esse tempo será suficiente para construir uma quantidade de requisitos razoável, e é um bom período para que o cliente veja coisas novas.

Avalie a lista priorizada e selecione os 5 cinco primeiros itens que você imagina que podem ser feitos no período definido. Pode ser mais ou menos que 5, vai depender da sua equipe e do tamanho de cada item.

Ao escolher os itens, lembre-se de pensar não apenas no esforço de implementação, mas em tudo que envolve a entrega: detalhar requisitos, testes, implantações, etc.

E finalmente, para detalhar os requisitos, você pode criar cenários de teste. É uma forma muito prática de descrever uma funcionalidade, porque fornece detalhes sobre o que deve ser feito ao mesmo tempo que materializa um meio de verificar se foi implementado corretamente.

Você pode usar o padrão do BDD (Behavior Driven Development) para descrever os cenários, basta identificar os itens abaixo para cada teste:

  • Uma ou mais condições para que a situação ocorra.
  • Uma ou mais ações do ator identificado na história.
  • Um ou mais resultados esperados.

No exemplo da última história do sistema de vendas:

Como um Gestor de Vendas, eu gostaria de ver um relatório com o valor das vendas de cada vendedor em um determinado dia, para que eu possa avaliar qual deles teve o melhor desempenho no dia.

Podemos criar dois cenários de teste:

Dado que a data da venda foi informada, quando o Gestor de Vendas clicar no botão “Consultar”, então deve ser exibida uma lista com o nome dos vendedores e a soma do valor vendido por cada um deles na data informada.

Dado que a data da venda não foi informada, quando o Gestor de Vendas clicar no botão “Consultar”, então deve ser exibida a mensagem “Informe a data da venda.”.

Simples, não é? Note que a linguagem não é técnica e nem de negócio, ela apenas descreve como o produto deve se comportar de acordo com as ações dos usuários.

Concluindo…

Time trabalhando

Muitos problemas e discussões que surgem durante um projeto podem ser evitados se você mudar a forma como faz o levantamento de requisitos. Temos o hábito de direcionar o foco para melhorar a execução, e ignoramos o impacto da organização e análise das atividades.

Lembre-se:

  1. Planeje menos, para que seja mais fácil se adaptar às mudanças.
  2. Crie documentos com uma linguagem que todos entendam, isso vai reduzir a burocracia e aproximar o cliente da equipe.
  3. Entregue aos poucos e em ciclos rápidos, o cliente vai ver resultados e não vai ter tempo de te encher o saco.

Seguindo apenas essas 3 dicas, tenho certeza de que a sua vida profissional vai ficar muito mais tranquila.

Se esse artigo foi útil para você, utilize os botões abaixo e compartilhe com seus amigos e colegas de trabalho. Quem sabe ele possa ajudar mais pessoas.

Deixe também o seu comentário abaixo. Adoraria saber a sua opinião e debater sobre o assunto!

Abraço!

P.S.: muitas coisas que foram citadas neste artigo são retiradas do Scrum, que é a metodologia ágil mais conhecida no mercado. Sendo assim, algumas práticas que recomendei podem não parecer 100% corretas diante do método, mas o objetivo aqui é explicar os conceitos que podem mudar o seu mindset e proporcionar um aprendizado gradual.

Conteúdo VIP

Cadastre o seu email e receba gratuitamente as atualizações do blog e conteúdos exclusivos! Você também vai ganhar o ebook 10 hábitos simples para turbinar a performance do profissional de TI.>