Agilidade Gramatical: Como ser mais eficiente na comunicação dos requisitos

Umas das frases mais famosas (pelo menos na minha visão) do mundo ágil, principalmente quando o assunto é Requisitos, foi dita por Mike Cohn:

"Software Requirements is a communication problem."  

(User Stories for Agile Requirements)

Um software não nasce no primeiro rabisco.  Muito menos na primeira linha de código ou no primeiro diagrama de classes. Ele nasce bem antes disso. Ele nasce na mente das pessoas que sentem uma determinada necessidade.  Por curiosidade, é provável que alguns dos softwares que conhecemos hoje, tenham sido criados antes do surgimento dos transistores, em 1947.  Na verdade, até mesmo antes da criação do primeiro computador, que acredita-se ter sido o Mecanismo de Anticítera, criado no século I a.C., na Grécia.  Mas isso é outra história.  Ou melhor, isso é História.

Mecanismo de Anticítera

Não é difícil encontrar, nos livros de negociação e empreendedorismo, frases como: "Resolver problemas e atender à necessidades é a arte do sucesso",  "Crie um produto que atenda às suas necessidades e, provavelmente, esse produto atenderá a outras pessoas" ou "Faça um estudo de mercado antes de lançar um produto". Repetir estas frases é quase como dizer que precisamos nos alfabetizar para sermos escritores.  Entretanto, nem sempre o que é óbvio, é seguido.  O desenvolvimento de software segue princípios semelhantes, mas muitos profissionais os ignoram.  O software é um produto.  E como tal, suas necessidades precisam ser identificadas antes da sua concepção.

"A criação de um software é a arte de resolver problemas e atender necessidades  humanas com o uso de programas de computador"  

O escritor Dam Roam, em seu livro The back of the Napkin, afirma o seguinte: 

"A arte dos negócios é a arte da resolução de problemas... Que tal se existisse uma maneira de encontrar os problemas mais rapidamente, entendê-los mais intuitivamente, endereça-los de maneira mais confiável e transmitir mais rapidamente aos outros o que temos descoberto?"

"Descobrir necessidades do usuário é preciso, desenvolver software não é preciso"

A frase acima faz uma alusão ao famoso discurso do general romando Pompeu: "Navegare necesse; vivere non est necesse". Desculpem meus amigos desenvolvedores. Tenho nada contra eles.  Até porque também sou desenvolvedor.  Mas percebi que identificar as necessidades de usuário é mais valioso que desenvolver o software. 

Quer um exemplo? Imagine um automóvel.  Qualquer um. É comum ouvir pessoas dizendo: "Eu preciso de um carro".  No entanto, carro não é uma necessidade, mas um objeto ou produto que nos ajuda a atender a uma necessidade (ou várias). Uma das necessidades que pode ser atendida por um automóvel, e provavelmente a principal delas, seria: "Eu preciso locomover de maneira mais rápida entre locais diferentes".  
Utilizando esta analogia como referência, pode-se concluir que uma das principais habilidades para a construção de um software passa a ser a capacidade de identificar a diferença entre necessidades e objetos.  A dica que dou pra isso é: Use a gramática! 

"Necessidades são os verbos, objetos são os substantivos. 

Se seguirmos a conclusão de Mike Cohn dita no início deste artigo, onde ele afirma que requisitos é um problema de comunicação, podemos fazer um melhor uso da gramática para comunicar requisitos e necessidades dos usuários de uma forma mais eficiente e clara.

Segundo o dicionário, gramática é... 

"... o conjunto de princípios que regem o funcionamento de uma língua; a gramática orienta como as palavras podem ser combinadas ou modificadas para que as pessoas possam comunicar-se com facilidade e precisão. 

A abordagem de como comunicamos os requisitos tem um impacto significativo no escopo de um projeto.  A "forma tradicional" de análise de requisitos impede que o desenvolvedor de software pense. E o pior, impede que o usuário pense.

Preste atenção nos 2 requisitos abaixo:

    1. Eu preciso de um chuveiro.
    2. Eu preciso tomar banho.

Qual a diferença entre eles?
A diferença é que o requisito 1 usa um substantivo (chuveiro) como elemento principal, enquanto que o requisito 2 usa um verbo (tomar) e nos obriga a pensar.  Sei que muitos dos leitores devem estar pensando que ambos os requisitos dizem a mesma coisa, uma vez que para tomar banho, muitos pensariam em ter um chuveiro. Se você é um destes leitores, tente chegar a essa mesma conclusão com os requisitos 3 e 4 abaixo:

    3. Eu preciso de uma Ferrari.
    4. Eu preciso locomover mais rapidamente.

Agora perceba que, apesar de ambos os requisitos parecerem dizer a mesma coisa, o requisito 3, caso seja implementado, pode ser bem mais caro e demorado que o requisito 4, uma vez que, para atender ao verbo locomover, diversas soluções mais baratas que a Ferrari poderiam ser encontradas.

Em resumo, a forma como nos comunicamos interfere drasticamente no quanto gastamos em um projeto de software. E a agilidade gramatical pode nos ajudar, consideravelmente, a amenizar este risco com uso correto de técnicas vindas da agilidade, como as estórias de usuário e o mapeamento destas, e a nossa gramática.