Quem explora e desenvolve requisitos deve se preocupar com sete questões fundamentais. São testes executados várias vezes e em diversos momentos de um projeto. Segue a lista¹:

É Necessário?

O requisito realmente dá alguma contribuição, ainda que pequena, para a realização dos objetivos do negócio? Apesar de nossa insistência em perguntar a clientes e usuários pelo valor de cada requisito, a revalidação se paga. Porque podem aparecer funções, atributos ou restrições que, depois de certo tempo, perdem o sentido.

Também não pode existir, em nenhum tipo de projeto, um requisito que não se relacione com nenhum outro. Tratamos aqui de relações de dependência ou complementaridade, como visto anteriormente. Não há uma conta “diversos” em  projetos minimamente sérios.

É Compreensível?

No frigir dos ovos, um requisito é só “uma condição necessária para alcançar certo fim” (Houaiss). Nada justifica que seu entendimento seja difícil. Requisito é informação. E informação é “dado investido de relevância e propósito” (Peter Drucker). Informação é “a diferença que faz diferença” (Gregory Bateson). Por isso enriquecemos cada requisito com um conjunto de características que o explica e justifica: fonte, perspectiva, valor, relações e estado, pelo menos. Cada característica aumenta nossa compreensão sobre o requisito. Claro que, antes de qualquer coisa, a redação do requisito deve ser clara e objetiva. A estruturação não nos isenta da boa escrita.

Está Completo?

Um requisito que apresente pendências não deveria avançar em seu ciclo de vida. O solicitante aguarda alguma informação ou ainda precisa confirmar algo com alguém? Devemos oferecer nosso apoio, resolver as pendências e só então incorporar o requisito.

A recomendação é outra quando a pendência é fruto da insegurança de quem manifestou o requisito. Se é algo de muito valor, então acelere ou antecipe a realização daquele requisito. Coloque-o no topo da fila e faça com que entregas preliminares tranquilizem o cliente ou usuário. Mais sobre isso no último item da lista.

É Verificável?

Se não há a menor ideia sobre como a realização do requisito será testada, é provável que não seja um requisito. Atributos pra lá de ambíguos (tela bonita, processo rápido, operação fácil etc) também comprometem a testabilidade de uma solução. Eles devem ser evitados a todo custo. Todo bom requisito sugere, de maneira clara, pelo menos um teste que comprova sua realização.

É Viável?

O valor atribuído a cada requisito ou grupo de requisitos possibilita seu posicionamento vertical (eixo benefício) na matriz ao lado. Estimativas de custo de cada alternativa de solução² indicam a posição horizontal. Temos assim uma ferramenta que apoia a análise benefício/custo³ de todo o escopo de um projeto.

Pesadelos são descartados sem dramas. Dado o baixo valor agregado de determinado requisito, sua realização só faz sentido quando for uma bobeirinha – algo fácil e barato de construir. É a metade superior da matriz que merece nossa atenção. Se todas as alternativas fossem sonhos, com certeza você não estaria aqui. Projetos dignos de nota sempre oferecem algum tipo de desafio – módulos de muito valor cuja realização envolve alguma complexidade técnica e, consequentemente, alto custo.

Utilizamos valores relativos, tanto para benefícios quanto para custos, quando os números reais ainda estão distantes. Podemos utilizar escalas simples (Fundamental=3, Importante=2, Opcional=1) ou um pouco mais sofisticadas (a sequência de Fibonacci, por exemplo). Esta validação nos ajuda a definir o escopo ideal de uma solução. De quebra, ela sugere prioridades.

Está Priorizado?

A melhor imagem do escopo de qualquer projeto é uma fila indiana. Cada requisito incorporado merece uma posição única. No topo, temos tudo o que é fundamental para a realização dos objetivos do negócio. No fim, tudo o que pode ser cortado sem choro nem vela.

Quando é possível colocar em produção as entregas parciais, então os sonhos serão prioritários. Desta forma antecipamos a realização de valor. Caso contrário – quando tudo deve ser entregue em conjunto – começamos pelos desafios. Depois de entregar o que realmente importa, em havendo tempo e dinheiro, desenvolvemos algumas bobeirinhas.

Está Correto?

Enfim, resta saber se o requisito está correto. E o que garante sua correção? A assinatura do cliente ou usuário no documento de requisitos? Um contrato redigido pelo mais competente escritório de advocacia? Nada disso pode garantir que um requisito esteja correto. Só conseguimos 100% de certeza quando o requisito não é mais “uma condição para alcançar determinado fim”. Só temos total certeza de sua correção quando o fim é alcançado. Isso só é possível com a solução entregue e em funcionamento. O que pode demorar dias, semanas ou até meses para se confirmar.

Tamanha distância não nos livra da busca pela correção dos requisitos. Qualquer coisa – modelos, protótipos, versões alpha e beta e paliativos afins – que minimize o frio na barriga das partes interessadas pode e deve ser utilizada. Desde que haja consciência de que apenas o produto final, devidamente entregue e em funcionamento, terá as respostas definitivas.

Notas

1. A lista acima não tem nada a ver com os famigerados checklists que divertem ou enganam leitores de algumas revistas populares. Porque não é simples como: sim, não, sim, sim, não, não, sim = 17 pontos: tô gordo! Não é possível aplicá-la em um ponto específico do projeto. São validações e testes que analistas e demais envolvidos executam diariamente. Obsessivamente.
2. É de quem vai construir a solução a responsabilidade por apresentar alternativas e respectivas estimativas. Para que esta ferramenta funcione direitinho, a turma de negócio fala sobre benefícios e o time técnico sobre custos. O embate, a tensão criativa, tende a fazer emergir a melhor solução possível.
3. Não estou inventando moda. Foram Tom DeMarco e Timothy Lister, em Peopleware (Dorset House, 1999), que sugeriram a análise benefício / custo. A grafia “análise custo X benefício” carrega dois equívocos: i) a suposta operação ( multiplicação ou subtração) não faz nenhum sentido matemático; ii) a colocação do custo antes do benefício é coisa de gente mesquinha.
4. Este artigo é uma releitura das sugestões apresentadas por Karl Wiegers em Software Requirements (Microsoft Press, 1999).

Relembrando e reforçando as duas provocações que apresentei:

• Não devemos seguir espalhando por aí que “o importante é que a Análise de Negócios seja realizada, não importa por quem”. Esta colocação, por bem intencionada que seja, gera dois efeitos muito negativos: i) parece diminuir a importância e simplificar (no mal sentido) a Análise de Negócios; e ii) deprecia todos que escolheram a Análise de Negócios como profissão. Pergunta (retórica): na ausência de analistas de negócios, como podem a profissão e respectivo corpo de conhecimentos evoluir?
• Apesar de dever seu ressurgimento à TI, está chegando a hora da Análise de Negócios decretar sua independência. Por definição, analistas de negócios ajudam uma organização a descobrir e desenvolver soluções para problemas de negócios. Qualquer tipo de problema! Mas…

Definições Destroem

A definição destrói Não há nada definitivo neste mundo. – Bob DylanNão precisamos ser radicais como Dylan, mas é sempre saudável alguma reflexão sobre definições e nomes. Pense um pouco sobre o termo “Análise de Negócios”. Talvez você perceba, como eu (depois de monte de gente¹), que ele é ruim pra chuchu. Veja o que diz o Houaiss:

• análise s.f. 1 estudo das diversas partes de um todo 2 investigação; exame
• negócio s.m. 1 transação comercial 2 local onde se realiza essa transação 3 algo que não se sabe ou não se lembra o nome; qualquer coisa; trem (em mineirês e fora do Houaiss)

Pegando apenas o que nos diz respeito, podemos concluir que Análise de Negócios é “o estudo das diversas partes de um local onde se realizam transações comerciais”. O estudo por si só? Não faz sentido. Ou faz tanto quanto propor “a investigação de um trem“.

Reforço a definição que sugeri no início do artigo: “analistas de negócios apoiam a descoberta e o desenvolvimento de soluções para problemas de negócios”. Os analistas apoiam – o que significa que suas atividades nunca são um fim em si mesmas. Eles apoiam dois tipos de atividades: de descoberta e  desenvolvimento (de soluções para problemas de negócios). Veja o diagrama abaixo:

O losango já foi utilizado por vários autores para ilustrar o caminho para a solução de problemas, dentre eles Scott Berkun² e Tim Brown³. Berkun o chamou de “espaço do problema”. A figura indica que nós aumentamos esse espaço – cogitando e validando alternativas de solução – antes de selecionar, desenhar e construir a mais adequada. Brown nomeia as pontas do losango de maneira um pouco diferente. A primeiro seria de divergência – quando criamos escolhas, a segunda de convergência – quando fazemos escolhas. Quase escondo a provocação nas palavras entre parênteses: a análise – o estudo das diversas partes de um todo – é só parte do trabalho! Ela não tem sentido nenhum sem sua cara metade, a síntese. Houaiss:

• síntese s.f. 1 reunião de elementos diferentes num todo coerente 2 operação intelectual que apreende o todo partindo dos elementos que o constituem 3 exposição abreviada e genérica; resumo

Se a análise é o estudo das partes, a síntese as combina na elaboração de um todo. Não há processo ou método para solução de problemas que não obedeça essa ordem. Exatamente por isso o termo “análise” é tão ruim¹. Não se trata de chatice de dublê de filólogo. Nomes e definições podem ser perigosos ou até mesmo destrutivos. Se não, como explicar que muitas empresas utilizem analistas de negócios apenas em 1/5 das funções sugeridas no diagrama acima?

Ainda não cheguei ao cúmulo de sugerir a troca do nome da disciplina ou da profissão. Não sou louco o suficiente. Apenas insisto para que a Análise de Negócios seja vista de forma mais ampla. Reparem, ela nem se limita ao losango no modelo acima. Existem outras três áreas, não limitadas aos projetos, que merecem o apoio dos analistas de negócios. São elas:

• Gestão de Relacionamentos: se os analistas de negócios funcionam como uma ligação entre todas as partes interessadas de um projeto, é natural que se espere deles uma considerável contribuição na gestão de relacionamentos: gerenciamento de expectativas; resolução de conflitos; averiguação da satisfação de clientes e usuários etc
• Gestão do Conhecimento: uma responsabilidade muito maior do que a danosa e usual percepção de que os analistas devem “documentar tudo”. Existem documentos – existe a necessidade deles, mas há algo muito maior sendo gerado a cada projeto, por menor que ele seja. É conhecimento novo. Algo que, se não for corretamente gerenciado, será desperdiçado.
• Manutenção da Qualidade: algo que deve ser incorporado em toda e qualquer função. Os analistas de negócios têm condições de zelar não apenas pelo que desenvolvem, mas também pela qualidade de todo o trabalho executado em um projeto e fora dele.

Para Pensar e Repensar

Você pode estar perguntando, com razão, o que esse papo tem a ver com as duas provocações que abriram este artigo. Tudo:

• Cabe um mundo inteiro na distância entre analistas de negócios e tiradores de pedidos. A Análise de Negócios lida com domínios cognitivos de maior dificuldade: Solução de Problemas, Análise e Síntese; Pensamento Criativo; Pensamento Sistêmico; Complexidade etc. Entender ou pretender que qualquer outro profissional possa executá-la, mesmo em projetos aparentemente mais simples, é ingênuo e perigoso.
• Mais importante é entender que a Análise de Negócios não existe sem os analistas. A disciplina definhará se não houver quem a defenda e estude  como uma especialização.
• Ao propor o modelo acima forço um distanciamento de TI. Até então utilizava disciplinas da Engenharia de Software – Modelagem de Negócios e Requisitos – para mostrar o que os analistas de negócios podem fazer. Elas seguem existindo e continuam importantes para os analistas. Mas devem ser percebidas como itens de uma caixa de ferramentas que precisa ser consideravelmente maior e mais diversificada. Todas as empresas estão carentes de bons solucionadores de problemas. Um time especialista em solução de problemas, qualquer tipo de problema, seria uma cartada e tanto. Você não acha?

Notas

1.  Esse papo de Análise + Síntese é quase tão velho quanto andar pra frente. Só foi requentado neste artigo porque parece esquecido ou ignorado quando o assunto é a Análise de Negócios. Gerald M. Weinberg, falando para analistas de sistemas em “Redefinindo A Análise e o Projeto de Sistemas” (McGraw-Hill, 1990), já tinha feito o mesmo. Pelo que sei, Weinberg foi o primeiro a destacar o quão ruim é o termo “Análise” e a propor um tal Sintetista. Desta leitura derivei outra provocação: o analista de sistemas falando para o analista de negócios, “eu sou você amanhã”.
   Weinberg teve vários títulos publicados no Brasil mas, salvo engano, estão todos esgotados. Analistas de negócios deveriam ler todos que encontrar nos sebos da vida.
2. Em “A Arte do Gerenciamento de Projetos“, Bookman (2008).
3. Em “Design Thinking – Uma Metodologia Poderosa para”, Campus (2010). A editora deu uma bela barbeirada no título, tanto que temo pela  tradução. Se puder, opte pelo original: “Change by Design” (Harper Business, 2009).
4. A Extensão Ágil do BABoK®, em fase de revisão pública, é muito feliz ao sugerir uma divisão muito parecida com aquela ilustrada pelo losango acima. Só há um termo diferente: Delivery (entrega) ao invés de Desenvolvimento.