Vai entender o que o Cliente quer

Série "De Brooks a Berkun" - Continuação da 3ª Parte.



Scott Berkun dedica várias páginas de seu livro para tratar da tal 'Engenharia de Requisitos' (termo que ele não utiliza) e do 'Design' (termo que ele usa insistentemente) de uma solução. Capítulos como "How to figure out what to do", "Where Ideas come from" e "What to do with ideas once you have them" dão o merecido tratamento aos temas.



Para Berkun, a Perspectiva do Cliente pode ser obtida de duas formas: Requisitos e Pesquisas. E sugere que para cuidar das funções relacionadas à esses tipos de levantamentos deveríamos alocar dois tipos de experts: Engenheiros de Usabilidade e Designers de Produtos. Mas Berkun observa: "Mesmo que na última década muito progresso tenha sido feito no refinamento de métodos de pesquisa e compreensão de clientes, grande parte dele não foi assimilado pelo corpo gerencial – ou em organizações centradas na engenharia. Ainda é incomum que times de projetos tenham um expert em pesquisa de cliente, design de interfaces e usabilidade disponibilizado para os tomadores de decisão". Na sugestão que apresentei na 2ª parte desta série, o Desenvolvedor de Interfaces realiza tais funções. Trabalhando bem próximo do Analista de Negócios.

Muito se fala, e eu não tenho dúvidas, de que o tema 'requisitos' responde por mais de 50% dos problemas em nossos projetos. Berkun nos apresenta 5 dicas para a obtenção do que ele chama de "Requisitos de Alta Qualidade":

• Planeje as negociações de requisitos e as iterações
  Identificados nossos clientes e demais atores do projeto, torna-se factível a elaboração de uma Agenda para a Coleta de Requisitos. No pior cenário, uma RFP deve dar pistas suficientes para o rascunho de um plano inicial.
  

• Elimine as Suposições Erradas
  Como identificá-las? Só perguntando. Como diz o Berkun, "se você é o coordenador do projeto ... religiosamente faça perguntas esclarecedoras, como 'por que precisamos disso?', 'que problema isso resolve?'", e assim por diante. Só não permita que seu time assuma como verdadeiras solicitações que podem nem mesmo ter partido do cliente, ou dos verdadeiros usuários.
  

• Busque as Informações que Faltam
  "Os mais notáveis erros em requisitos são erros de omissão". A coleta e análise bem realizadas devem tornar bem visíveis todas as peças que faltam no tabuleiro do projeto.
  

• Defina Prioridades Relativas para todos os Requisitos
  Costumo solicitar, ainda na coleta, que o cliente/usuário defina se aquela solicitação é Fundamental, Importante ou Acessória. Uma classificação clara e simples assim ajuda muito em diversas tomadas de decisão.
  

• Refina ou Elimine a Linguagem Ambígua não-Intencional
  "Palavras como rápido, grande, pequeno, bonito e usável requerem métricas relativas para serem entendidas. Em alguns casos, pode ser do interesse de todos que elas permaneçam 'em aberto' até momentos posteriores do projeto". Mas, a princípio, devemos eliminar toda redação que não permita um entendimento único de um requisito.
  

Cabe aqui outra intromissão minha. Ainda há muito trabalho a ser realizado antes do Analista de Negócios/Sistemas repassar os requisitos para o time de Arquitetura da Solução. As dicas do Berkun listadas acima são úteis mas não suficientes. No meu ponto de vista, todos os requisitos coletados devem ser estruturados, formando uma 'base de conhecimentos'. Existem algumas ferramentas desenhadas especificamente para isso. Mas o mais importante é o modelo da base. Nesta palestra, já meio velhinha (apresentada em 2003 em evento da SUCESU/PMI), apresento uma sugestão de um modelo 'mínimo'. Em "Requirements-Led Project Management"[1], de Suzanne Robertson e James Robertson, há um modelo um pouco diferente, que eles chamam de 'Requirements Knowledge Model'. Uma base persistida em um gerenciador de bancos de dados, ao invés de documentos textuais ou planilhas eletrônicas, é mais gerenciável. Fica mais fácil manter a tal rastreabilidade bi-direcional dos requisitos e também seu relacionamento com todos os demais artefatos produzidos no projeto.

Uma vez gravado, um requisito nunca mais pode ser deletado. Parece boba, mas se trata de uma regra fundamental. Cada mínima alteração na redação do requisito ou em algum de seus atributos significa a inserção de um novo requisito, que substitui o anterior mas mantém um vínculo. Assim conseguimos rastrear todas as mudanças que ocorreram desde os instantes iniciais de um projeto. Portanto a 'base de conhecimentos' acaba se tornando um dos, senão o principal subsídio para o Gerenciamento de Mudanças (tema da próxima semana).

Obs.: Como prometido na coluna "What needs to be done?" ao lado, espero em breve (abr/2006) disponibilizar o modelo completo da base de conhecimentos para download.


Perdidos no Espaço (entre os Requisitos e a Solução)

Constatação inquietante de Berkun: "Por razões que não consigo explicar totalmente, muitas pessoas têm dificuldade com o planejamento do trabalho criativo. Na maioria dos livros que li sobre gestão de projetos e desenvolvimento de software, há pouca cobertura sobre como sair de uma lista de requisitos do que deve ser implementado para um bom design. Cronogramas apresentam uma data para quando os requisitos supostamente estarão finalizados, e outra data para quando as especificações supostamente estarão prontas, mas poucas instruções são fornecidades para a execução daquilo que está entre essas duas datas".

Para Berkun, tão logo estejamos com os requisitos 'no lugar', "os designers podem explorar o território desenhado pelos requisitos. Há um largo espaço, chamado 'Espaço do Problema', de maneiras potenciais para resolver o problema colocado. Dependendo dos requisitos, este espaço pode ser bem grande; por exemplo, há um infinito número de possibilidades para se desenhar uma casa, um sistema de contabilidade, um web site ou seja lá o que for que esteja lhe pagando. Portanto, até que você tenha alguma noção das possibilidades que existem, não é muito esperto se comprometer com qualquer coisa descoberta nos momentos iniciais".

É a fase em que temos só uma folha ou um quadro branco. Brancos e vazios. É a fase das Idéias - apaixonante para alguns e apavorante para outros. As idéias vêm das pessoas, lembra Berkun: "nenhuma idéia na história da humanidade brotou de uma pilha de pedras, ... , de livros de auto-ajuda, de seminários de criatividade ou de sessões de brainstorming". Por que então a fase de design (Arquitetura da Solução) seria tão negligenciada? Para Berkun, "talvez seja porque as pessoas temem a exploração [de idéias], especialmente quando estão sendo observadas".

Berkun diz ter "evidências irrefutáveis de que há um número infinito de idéias prejudiciais, horríveis, inúteis, comicamente estúpidas e embaraçosamente ruins". Ele solta essa pérola ao questionar a máxima (segundo ele oriunda de comerciais de TV e de sessões de brainstorming – ou de comerciais de TV vendendo sessões de brainstorming) que diz que "não existem más idéias". Lógico que elas existem. Aos borbotões. Dentre outras coisas, ele sugere algo muito simples: "Boas perguntas atraem boas idéias!"

Para Berkun existem dois tipos de perguntas 'Boas' e um tipo de pergunta 'Ruim' quando estamos envolvidos em um trabalho criativo:

• Perguntas Direcionadoras (Boas)
  "Chamam a atenção do time para algo importante, útil ou mesmo central para o trabalho em execução". Tipo: Como o usuário saberá que deve clicar neste botão para ir para a próxima tela?
  

• Perguntas Criativas (Boas)
  Ao contrário das questões direcionadoras, estas devem "levar o time para territórios ainda não explorados do problema em questão". Algo como: Haverão outros meios para o cliente chegar na próxima tela?
  

• Perguntas Retóricas (Ruins)
  "Gêmeas das questões criativas, diferenciam-se pelo fato de serem insinceras, perguntadas sem a intenção de se obter uma resposta". Por exemplo: Aí 'cai a ficha' e o cliente de repente descobre que tem que ir para outra tela, certo?
  

Mas, independente da qualidade (e da inteligência) de nossas perguntas, devemos esperar diversas idéias 'ruins, comicamente estúpidas, hilariantes' etc. Triste é o ambiente pouco tolerante a elas, porque, além de sisudo e monótono, inibe a participação de todos os membros da equipe, mina o espírito de colaboração que deveria existir durante todo o projeto. Além de desperdiçar boas piadas, né?

Seguindo com Berkun: "É melhor que a gente suje as mãos e cometa vários erros nesta fase. Quanto antes isso acontecer, mais rápido a gente chega às boas idéias."

"As duas mais importantes ferramentas de um arquiteto são a borracha na sala de desenhos e a marreta na construção"
- Frank Lloyd Wright


"A mais importante ferramenta do físico é sua cesta de lixo."
- Albert Einstein

Berkun também detona outro 'mantra', comum em certos círculos por aí, o tal (sorry, mas só o vejo sendo usada em inglês): "think outside the box". "Não é a eliminação das 'caixas' a parte mais difícil – é exatamente saber quais 'caixas' utilizar e quando. Restrições estarão sempre presentes". E completa: "faça o que você quiser com a caixa. Pense dentro da caixa, fora da caixa, debaixo da caixa, corte-a e faça fogo com ela, qualquer coisa, desde que você gerencie para resolver os problemas identificados como críticos para o projeto".


O Problema do Tamanho do 'Espaço do Problema'


"Idéias fogem do controle", diz o título de um sub-capítulo do livro de Berkun. Por isso, "se é difícil encontrar boas idéias, é muito mais complicado gerenciá-las". Berkun diz que um erro muito comum é tratar o processo de design como se fosse um grande 'interruptor'. Para ilustrar melhor a questão Berkun apresenta o gráfico abaixo:



A partir de uma sólida base de (bons) requisitos, começamos a explorar alternativas de solução. Com o passar do tempo a tendência é que o número de alternativas (cenários) aumente. Aumentamos assim o tamanho do 'Espaço do Problema'. Um dos riscos, segundo Berkun, é não saber o momento de parar com a geração de idéias e começar a filtrá-las. Para tal Berkun sugere a fixação de alguns pontos de checagem. Como ilustra o gráfico abaixo, são 6 os grandes check-points que deveriam nos guiar no processo de arquitetura da solução:

1. Visão e Prova de Conceito
   Nosso ponto de partida deveria ser um documento de visão e uma prova de conceito. Traduzindo para Pindorama: será a tal 'proposta técnica' para muitos corajosos colegas.
2. Agrupamentos de Idéias
   Depois de um certo tempo jogando conversa fora, digo, idéias 'para fora', é conveniente que elas sejam agrupadas e analisadas.
3. Três Alternativas
   Naquele que deve ser identificado como 'meio do caminho' desta etapa do projeto, é indicado que a lista de alternativas seja filtrada, gerando de 3 a 5 alternativas mais viáveis.
4. Duas Alternativas
   Pouco tempo depois deveríamos ser capazes de escolher apenas 2 alternativas de implementação.
5. Um Design
   E então apenas um design (ou Arquitetura da Solução).
6. Especificações
   Então, com a Arquitetura definida, geramos a especificação técnica da solução.
   

Concordo com o que o Berkun disse em um dos trechos de nossa viagem pelos "Castelos de Areia". Não é comum ver este tipo informação em livros de gerência de projetos e desenvolvimento de sistemas. Mas as "marés (mudanças) são inevitáveis", não? Semana que vem conversamos sobre elas.


===

1. Suzanne Robertson e James Robertson, "Requirements-Led Project Management", Addison-Wesley (2005).

Marcadores: de_brooks_a_berkun, gerenciamento_de_projetos, livros