Re.qui.si.to s.m. 1 condição necessária para alcançar certo fim; quesito

Com pequenas variações, é assim que nossos dicionários definem Requisito. A engenharia, segundo a Wikipédia, entende requisito como uma “definição documentada de uma propriedade ou comportamento que um produto ou serviço deve atender.” Daí para entregável (sic) foi um pulinho. Um entregável inegociável, veja bem. Porque a explicação diz que o produto ou serviço “DEVE atender” aquela condição. 

Requisito nunca foi o nome ideal para embalar as necessidades, vontades e restrições de nossos clientes e usuários, muito pelo contrário. É um termo ruim pelo que significa – uma condição – que piorou com o uso. Passamos décadas culpando os requisitos e quem os verbaliza (e muda!) pelos problemas e fracassos em nossos projetos. Enfim, se palavra tivesse ficha corrida, a do requisito seria tão extensa quanto a especificação funcional dos infernos. O que nos impede de aposentá-la?

Substantivo Ruim atrai Verbos Horrorosos

Requisito é campeão neste quesito. Por exemplo: COLETAR REQUISITOS. Nós coletamos lixo; coletamos material para exames clínicos. Pra que colocar requisitos na mesma cumbuca? Além disso, o verbo coletar dá a entender que requisitos são como frutos maduros no pé. Coitados. Eles despencam de velhos. Maduros, nunca estão.

LEVANTAR REQUISITOS nos leva para um caminho diferente e igualmente mentiroso. Dos 15 (!) significados do verbo levantar apresentados no Houaiss, apenas um nos atenderia parcialmente: listar como resultado de pesquisa. Pesquisar ou investigar (inquiry) fariam melhor serviço do que listar. Quem lista parece estar tirando pedidos. Alguém tira requisitos?

Dados os mal entendidos e usos, uma turma legal daqui do Brasil achou por bem tropicalizar o verbo to elicit e assim ganhamos o ELICITAR (sic) REQUISITOS. Elicit significa tirar, extrair. A gente tira dentes e extrai leite de pedra. Mas não conseguimos arrancar requisitos não. Ou seja, abrasileirado ou não, o verbo é ruinzinho também. 

Não é curioso que a gente ignore a sugestão apresentada no título de um dos melhores livros sobre requisitos já escrito¹, EXPLORAR REQUISITOS? 

Eu costumo sugerir o DESENVOLVER REQUISITOS. Mas não adianta não. Porque requisito, na cabeça de muita gente, continua sendo um entregável inegociável.

Repare: uma disciplina com tantos anos de vida ainda busca por um verbo para chamar de seu. Dá uma certa vergonha, não dá? Insisto: o que nos impede de aposentar o termo requisito e seus verbos desajeitados?

Substantivo Ruim Não Funciona, Complica

Não funciona porque não explica. Ruim que é, acaba ganhando complementos igualmente ininteligíveis. 

Para descrever tudo o que um produto ou serviço deve fazer usamos a combinação REQUISITO FUNCIONAL. Teria sido bem mais simples falar FUNÇÃO. Mas houve um tempo em que as pessoas eram pagas pelo número de letras digitadas. Houve? Sei lá, é uma explicação plausível para tamanha complicação (19 toques ao invés de 6). Piora!

Porque todo produto ou serviço é repleto de ATRIBUTOS. Como a gente chama essas coisas? De REQUISITOS NÃO-FUNCIONAIS!?  

Se a Ideia Ágil nasceu para combater as complicações, e nasceu, então é questão de coerência a eliminação incondicional dessas aberrações. Elas são de outro tempo. 

Substantivo Ruim é imune aos bons Adjetivos

Não adianta apelar para REQUISITO ÁGIL. Imagina: REQUISITO ÁGIL NÃO-FUNCIONAL. Se esta foi uma tentativa de gerar um oximoro, tipo silêncio ensurdecedor, não funcionou; E não teve graça também não. Aliás, esse artifício de anexar o adjetivo ÁGIL quase sempre depõe contra o substantivo e todo o seu passado. Se bobear, compromete o seu futuro também. 

Enfim, parece que não há adjetivo que renove e dê esperanças para a palavra requisito. Requisito merece o mesmo destino do disquete, um museu. Ou o mesmo castigo do termo requerimento, ficar restrito ao uso por juízes e advogados. Precisamos aposentá-la. Neste caso, qual seria a melhor substituta?

HISTÓRIA

Kent Beck queria só assim mesmo: HISTÓRIA. Esse negócio de história de usuário veio depois. Desnecessariamente. 

Mas, por favor, entenda: História não é sinônimo de requisito. Não há uma relação 1:1 entre eles. Uma história pode conter ou esconder diversos requisitos. O que não faz dela um épico – outro engano comum. Uma história pode ser uma pequena crônica, um conto ou um grande romance. 

Requisitos nos dão a impressão de algo estático. São documentos entregáveis. São condições para a realização de um objetivo. Ponto.

Histórias são dinâmicas. Você não as levanta, não coleta e nem elicita. Histórias se desenvolvem. Elas são contadas. São feitas de personagens, ação e contexto. Histórias têm sentido!

Contamos histórias desde que a gente é gente. De certa forma, para o bem ou para o mal, elas nos ajudaram a chegar até aqui. Ainda bem!

Já pensou se a nossa evolução dependesse de requisitos ágeis não-funcionais misturados com regras de negócios em uma especificação funcional? 

Notas

1. Explorando Requerimentos do Sistema foi como essa obra prima se chamou aqui no Brasil. De Donald Gause e Gerald Weinberg (Makron Books, 1991).
2. Foto de Viktor Talashuk no Unsplash

Um dos mais famosos, “O Mítico Homem-Mês“, de Fred Brooks (Campus, 2009), só foi publicado aqui 34 anos depois de seu lançamento original. Não sei se isso explica o fato dele ter vendido menos de mil unidades. A verdade é que, com números assim, não devemos esperar que outros clássicos ganhem novas edições. Sorte nossa que existem os sebos. Foi em alguns deles, que conheci via Estante Virtual, que pude encontrar vários trabalhos de Gerald M. Weinberg.

Weinberg é autor de dezenas de livros, inclusive romances. O conhecia por causa de dois títulos, “Quality Software Management” (Dorset House, 1991) e “Exploring Requirements – Quality before Design” (Dorset House, 1989), escrito a quatro mãos com Donald C. Gause. Não são poucos os que consideram este o melhor livro sobre requisitos já escrito. Para minha surpresa, ele foi publicado no Brasil. “Explorando Requerimentos de Sistemas” saiu aqui pela Makron Books em 1991. Não dê bola ao título – é sobre requisitos, não necessariamente de sistemas (de informação). Tanto que nos dados de catalogação constam: Desenho Industrial e Produtos Novos. É coisa fina, Clássico com “C” maiúsculo. Leitura mais que obrigatória para todos que lidam, de uma maneira ou de outra, com Requisitos.

Enquanto elaborava o novo Programa {FAN} paquerava minha surrada edição do “Exploring”. Me perguntando se teria tempo para algo “tão antigo”. Tentei apenas folhear aleatoriamente e pimba!, me vi obrigado a relê-lo de cabo a rabo. Foi então que surgiu a curiosidade por outras obras do cara.

“Seus Olhos Estão Abertos?” aparece na seção de “auto-ajuda” de alguns sebos. É hilário. Equívoco talvez provocado pelo sub-título: Como Definir, Analisar e Resolver Problemas… Seus… e dos Outros. É obra curta, com 140 páginas, e leve. Também foi escrito com Donald Gause e publicado por aqui pela Makron Books em 1992.

Mais provocador e pesado é “Redefinindo a Análise e o Projeto de Sistemas” (McGraw-Hill, 1990). Se os analistas de sistemas tivessem prestado atenção ao que sugeria Weinberg, talvez hoje os analistas de negócios não fossem necessários. A quarta parte deste livro, por exemplo, ensina a entrevistar. A anterior, a observar. Pois é, habilidades raras e caras aos atuais analistas de negócios.

Uma das melhores provocações aparece quase no final do livro, na parte VII chamada “A Mente do Projetista”. O autor mostra a reação de espanto de um cliente que estava recebendo seu sistema três meses antes do previsto e por 60% do custo orçado. Ilustra o espanto através de um diálogo tão didático, mas tão didático, que nos deixa por entender porque até hoje discutimos formas de contratação de projetos de software. Weinberg não tem segredo nem fórmula mágica nenhuma: “seria ridículo se as matérias importantes fossem deixadas por último”. Ou seja, ele cortou do escopo tudo o que não era importante para o negócio daquele cliente, só isso. Neste caso, cerca de 20% do backlog era formado por “bobeirinhas” (ah, naqueles tempos esses termos não eram utilizados).

Por fim, mas não menos recomendado, um livro diferentão: “O Líder Técnico“. Lançado em 1994 pela Makron Books, prometia no subtítulo ser “Um Guia Personalizado para Desenvolvimento de Líderes Solucionadores de Problemas”. Entendeu porque o livro pulou em minhas mãos? Pois é, o tema tem tudo a ver com aquele profissional que (ainda) chamamos de Analista de Negócios. E um livro que diz que as escolas estão erradas porque não nos ensinam a errar, roubar e copular merece toda a atenção do mundo! Explicando (mais ou menos): “Não é por acaso que o erro, o roubo e a cópula são as três principais estratégias para se desenvolver ideias”. Liderança, Inovação e Solução de Problemas. Três temas quentíssimos (hoje) tratados com maestria em um título com 26 anos de idade (o original é de 1986). Torna perdoáveis até as quedinhas para a “auto-ajuda” e a citação de “Como Fazer Amigos…”

Weinberg navega com tranquilidade por várias disciplinas, não poupando exemplos de outras áreas quando eles facilitam o entendimento de algum conceito. Mas sua escrita – ô inveja! – é de uma clareza e um bom humor raríssimos. Alguns trechos surrupiados aleatoriamente dos títulos citados:

“Sem liderança para administrar o fluxo de ideias, dois técnicos especializados em uma sala formam uma discussão, três uma passeata e quatro um motim.”

“Se você não puder achar pelo menos três coisas que possam estar erradas com sua compreensão do problema é porque não entendeu o problema.”

“A parte mais complicada de certos problemas consiste justamente em reconhecer sua existência.”

“Em qualquer trabalho com requisitos, todo tipo de envolvimento dos usuários deve ser empregado.”

“Um projeto que esteja em estado de emergência durante o trabalho de requisitos estará em estado moribundo na etapa de entrega.”

“Poderíamos evitar a maioria de nossos transtornos segurando nossas línguas na saída, quando estamos inclinados a fazer promessas que iremos lamentar. Se deixarmos a especificação suficientemente vaga, teremos uma maior folga para manobrar quando descobrirmos o que queremos ou não fazer. Se fizermos isto corretamente, poderemos até convencer o cliente de que as falhas são características.”

“São necessárias incontroláveis necessidades e exagerada auto-imagem para ser um analista/projetista de sistemas – para estudar o que as pessoas fazem e dizer-lhes como reprojetar suas atividades. Em outros contextos, em outros tempos, teríamos sido chamados moralistas ou inquisidores. E todos nós sabemos quanto bem fizeram os inquisidores.”

“Tenho certeza de que o mundo seria um lugar melhor se os escritores e o pessoal dos sistemas fizessem uma pausa agora e recordassem para si mesmos quão pouco eles conhecem realmente. Se fizessem isso, seguramente admitiriam um maior equilíbrio em suas palavras e em seus trabalhos.”

]]> https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2012/03/13/gerald-m-weinberg/feed/ 5