O mapa não é o território!

"Até onde as leis da matemática se refiram à realidade, elas estão
longe de constituir algo certo, e na medida em que constituam
algo certo, não se referem à realidade." Albert Einstein

"O mapa não é o território" é uma expressão que aprendi durante minha formação em Programação Neurolingüística (PNL), e que é atribuída a Alfred Korzybski, um engenheiro, filósofo e matemático polonês que publicou esse conceito num encontro da American Mathematical Society em 1931. É uma expressão que se refere à forma como o ser humano interage com a realidade na qual ele se encontra. Ela representa o fato de que não temos acesso direto à realidade em si, mas sim às percepções da realidade em que vivemos.

Enquanto a realidade é representada pelo "território" na expressão de Korzybsky, a nossa percepção da realidade é o "mapa mental" que construímos para descrever o território em que vivemos. Algo semelhante ao pensamento budista, existente há mais de 2500 anos, que diz que você vê mas não consegue perceber a realidade subjacente. Os mapas mentais do mundo não são o mundo em si, mas nossas representações desse mundo. É por isso que fazemos parte de um número ilimitado de "mundos" criados por todas aquelas pessoas ou seres que interagem diariamente conosco. Para cada um desses mundos, nosso comportamento poderá ser aceitável ou inaceitável. Tudo dependerá das sensações e interpretações que causamos naqueles que interagem conosco.

Pois bem, compreender isso no universo do desenvolvimento de software faz com que percebamos que os requisitos de produto e de projeto são reflexos das crenças e valores daqueles que os criam e os defendem. Um requisito passa a ser visto como fruto de reflexões baseadas em mapas mentais sustentados por critérios objetivos e subjetivos de negócio, tecnologia, metodologia, qualidade, tempo, esforço, recursos, entre outros fatores. Ou seja, tudo aquilo que é dito por clientes, usuários, analistas de negócio, analistas de sistemas, gerentes de projeto, programadores, testadores e demais integrantes de um projeto pode estar associado a uma visão parcial ou distorcida do problema, reflexo de um mapa mental limitado pelas percepções de seu dono. É por isso que muitos requisitos podem fazer sentido para uns e nenhum sentido para outros, principalmente quando não há uniformidade de conhecimento e experiência entre os mapas mentais dos membros da equipe.

Nos últimos anos, tenho observado que é possível aumentar a qualidade dos requisitos de produto e de projeto utilizando técnicas especiais de captação e análise baseadas neste conceito de mapa mental. Essas técnicas permitem investigar a consistência das informações captadas com um aumento considerável do desempenho e da eficácia do analista durante momentos de comunicação interativa com as partes interessadas. Dentre as mais importantes para esta finalidade, destaco a prática de "rapport", a "estrutura da mudança" e o "metamodelo" criado por Richard Bandler e John Grinder (discutirei as três em posts futuros). Somente com estas três técnicas fui capaz de diminuir significativamente o tempo de captação de requisitos (de dias para horas) e conquistar a total satisfação do meu interlocutor em praticamente 100% das reuniões.

Ok, mas o que você pode fazer a curto prazo para minimizar os efeitos da incompatibilidade de mapas mentais num projeto de software?

1. Conscientizar os membros da equipe sobre os modelos mentais, representacionais e de tomadas de decisão debatidos na PNL, bem como em técnicas de investigação de modelos mentais baseadas na estrutura da linguagem (dê preferência para um Trainer Certificado);
2. Definir claramente o contexto para o qual será desenvolvido o produto de software utilizando modelos de processo (aqui utilizo a notação IDEFO) e da estrutura da mudança (estado presente x estado desejado);
3. Definir claramente o escopo de produto necessário para realizar a transformação do contexto (aqui um modelo simples e eficaz é o de User Stories - Título, Descrição, Critérios de Aceitação, Tamaho e Prioridade);
4. Estimular a comunicação direta entre os membros da equipe de desenvolvimento e as partes interessadas no produto (cliente e usuários).

Entender esta forma de pensar e saber lidar com suas implicações sobre nossas vidas faz com que saibamos tratar das fragilidades da comunicação caricaturizada pela imagem da figura 1, em que o analista, o projetista, o consultor, o líder de projeto e os desenvolvedores entendem e constroem algo bem diferente daquilo que é desejado pelo cliente.

Figura 1: Fragilidades da comunicação.

Captar rapidamente o que o cliente deseja como produto e entregar o pedido no prazo e com qualidade é algo que não tem preço! Para mim, este novo cenário só se tornará efetivo na área de software quando passarmos a repetir continuamente o novo cenário da figura 2 ...

Figura 2: Excelência na comunicação.