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.

Software de Qualidade mais que Software Funcionando

Em 2011, quando Fortaleza sediou o Agile Brazil, os participantes do evento tiveram a oportunidade de assistir a um Keynote entitulado: "Liderança adaptável: acelerando a agilidade organizacional".  Durante os dias do evento, pude conhecer um pouco mais sobre Jim Highsmith, o preletor desta palestra e um dos autores do Manifesto Ágil. Em uma das conversas com ele, uma frase ficou gravada na minha mente: "Qualidade é Pessoal."

Na verdade, eu já havia escutado esta frase várias vezes, mas nunca da boca de Jim Highsmith.  Ele falara de forma tão precisa e profunda, que acreditei haver algum material de sua autoria na internet falando do assunto.  Encontrei um artigo dele chamado When Quality is Personal.  Também encontrei um outro artigo entitulado Quality is Personal, escrito por Israel Gat. Indico a leitura dos dois.

Comecei a ver o conceito Qualidade de forma diferente. Anteriormente, software funcionando mais que documentação abrangente, já me dizia tudo. O tempo e a experiência me fizeram perceber que não há como definir qualidade de software, tendo em mãos, "apenas" um Software Funcionando.   Segundo o dicionário,  "Qualidade é um atributo, condição natural, propriedade pela qual algo ou alguém se individualiza, distinguindo-se dos demais; maneira de ser, essência, natureza..." 

Entretanto, no desenvolvimento de software, conseguimos encontrar um outro conceito para a palavra qualidade: 

"Experiência agradável (ou desagradável) pela qual passa um usuário ao utilizar um programa de computador"

Atualmente, há uma tendência em valorizar empresas que investem grandes volumes de recursos financeiros em qualidade de processos, desenvolvimento de pessoas e melhoria no ambiente de trabalho. Mas "apenas isso" não é suficiente para criar um produto de qualidade.  

Por exemplo:

O Brasil é, hoje, um dos maiores produtores e consumidores de café do planeta. Em uma recente pesquisa feita pela ABIC (Associação Brasileira da Indústria de Café), foi constatado que um brasileiro chega a consumir 83 litros de café por ano. É muito café! Acredito que eu tenha uma parcela de contribuição nesta estatística.

O resultado dessa pesquisa não é surpresa. Durante anos, os produtores de café fizeram grandes investimentos na lavoura, na industrialização do café e na logística de entrega. Grandes quantias em dinheiro são gastas, anualmente, para alcançar elevados níveis de qualidade nos processos de fabricação.

Mas o que isso nos interessa?  Simples.  Eu gosto de café, mas detesto café forte. Não adianta o melhor processo de produção, guiado pelos mais conceituados profissionais do planeja... se eles me entregarem uma xícara de café forte... vou fazer careta! 

"A boa qualidade de um produto não depende do processo de fabricação ou da competência técnica dos profissionais envolvidos, mas da experiência agradável vivenciada pelo consumidor. "

Equipes de desenvolvimento de software que realmente buscam a qualidade, estão preocupadas com a Experiência do Usuário com o produto. O processo de "industrialização" do software é secundário.

Essa é a razão pela qual muitos dos nossos colegas falam em User eXperience (UX). Um trecho de uma entrevista feita a Steve Jobs, em um artigo de 2003 entitulado "The Guts of a New Machine" ("As entranhas de uma nova máquina") publicado no The New York Times por Rob Walker, já resumia o que hoje chamamos de UX :

...

 ''Most people make the mistake of thinking design is what it looks like,'' says Steve Jobs, Apple's C.E.O. ''People think it's this veneer -- that the designers are handed this box and told, 'Make it look good!' That's not what we think design is. It's not just what it looks like and feels like. Design is how it works.''

...

O foco deste post não é falar sobre UX.  Irei escrever um outro artigo sobre isso futuramente.  No entanto, para quem interessar, sugiro o material WHAT IS UX DESIGN? por Ross Popoff-Walker.

Finalizo este post com a simples conclusão de que não adianta falar de qualidade sem proporcionar aos usuários/clientes a experiência de usar nosso software. 

Como dizer ao cliente que ele é importante?

Nos últimos anos, tive a oportunidade de lidar com diferentes clientes e empresas.  Algumas das pessoas com as quais conversei, absorveram a importância delas (clientes) em participar dos projetos. Não somente validando resultados, mas direcionando o desenvolvimento.  Entretanto, grande parte dos clientes não se interessa pela execução do projeto. Uma das razões pra isso é que nós, pessoas que constroem o software, não sabemos como dizer a eles, pessoas que usam o software, a importância da sua participação. Este post não tem a pretensão de ensinar como fazer isso, mas tentar mostrar como uma analogia pode mudar todo o entendimento. Então, como deixar claro que a participação dos nossos clientes/usuários é decisiva? 

Leia a analogia abaixo:

---

Imagine uma Ferrari Enzo.  Agora, se conseguir, imagine um fusca. Ambos são carros e têm um objetivo em comum: transportar pessoas (sem piadas com o fusquinha, por favor).  No entanto, existe uma "pequena" diferença na potência desses carros. Uma Enzo pode chegar a 800 cavalos enquanto um fusca chega a 200.  E daí?  Calma! 

Pergunta: Qual dos dois carros o leitor gostaria de ganhar de presente?  A maioria esmagadora das respostas seria óbvia, a Ferrari.  Mesmo os apaixonados por Fusca ainda escolheriam a Ferrari.  A venda dela daria para comprar vários Fuscas. 

Mas a questão não é essa. 

Vamos dar vida a essa história. 
Suponha que você ganha na loteria.  Algumas dezenas de milhões de reais.  Mas o prêmio será entregue em outra cidade à 2000km de distância.  Você tem duas opções de transporte: a Ferrari Enzo ou o Fusca (vamos levar em consideração que você não está no Brasil, uma vez que não temos rodovias decentes pra suportar uma Ferrari). Cada um dos carros com um motorista.  Qual dos dois veículos você escolheria?  Parece fácil, mas tem um detalhe... um dos motoristas não sabe o caminho, além de ser um bêbado estressado (isto é só um exemplo. Se beber, não dirija!), enquanto o outro é um GPS humano e nunca colocou uma gota de álcool na boca.  Qual dos carros seria escolhido?

A resposta é: Depende em qual dos carros está o motorista bêbado e estressado. Nesse caso, a decisão não depende do carro, mas da pessoa que irá guia-lo. É bem mais seguro gastar uma semana para percorrer 2000km em um Fusca, com um motorista sóbrio, do que entrar em uma Ferrari com a certeza absoluta de que o bêbado estressado vai levar você, e talvez ele (o "motorista" quase sempre escapa), para o túmulo.

---

No mundo corporativo, é fácil encontrar equipes tão potentes quanto uma Ferrari sendo guiadas por pessoas estressadas que não sabem aonde ir. Já vi times de desenvolvimento de software de alto nível fazerem entregas pífias, bem como Sprint Reviews de times inexperientes que resultaram em pedaços de software verdadeiramente úteis.

É importante, pra não dizer essencial, que o cliente entenda que ele não é "somente" um Product Owner (dono do produto) no sentido literal da palavra.  Ele é a parte mais importante deste conjunto multi-disciplinar de elementos que envolve um projeto de software. Ele é "O Guia" do projeto.