Texto escrito em 2013
A humanidade levou milênios para aperfeiçoar a arte de transmissão do conhecimento. Infelizmente muitos preferem uma visão "retrô". Neste post pretendo discutir uma idéia que passeia na minha cabeça a um bom tempo: o efeito negativo do excesso de conteúdo gráfico pode causar em uma equipe de desenvolvimento. Vou além: como vou mostrar neste post, acredito que chegue a causar demência. É a velha questão do determinismo linguístico que me assombra de novo. :)
O problema
Pra variar o problema está no uso inadequado da ferramenta: o conteúdo visual na documentação que normalmente aparece sob a forma de UML. Vi o problema se manifestar de forma concreta em uma equipe em que atuei. No caso, acredito que o problema tenha sido decorrente de um certo deslumbramento com a ferramenta usada: o Enterprise Architect da Sparx Systems (que diga-se de passagem é fantástico). Toda documentação gerada era composta apenas por diagramas UML.
Neste caso via-se claramente uma inversão: o conteúdo imagético que deveria ser um acessório ao texto era o foco e o texto passara a ser um mero acessório. Sei que soa absurdo e nítidamente é um caso extremo porém antes de rotular estes profissionais é fundamental tratarmos aqui de algumas falácias que podem levar a esta situação para, mais à frente, entender os danos que este tipo de situação gera.
"Uma imagem vale mais que mil palavras" - Ouch!
Esta é a primeira falácia e acredito que tenha seu fundamento no desespero em se obter a máxima produtividade da equipe. Convenhamos, escrever é difícil e sempre será: não há como fugir. Para começar quem escreve precisa conhecer o objeto a ser descrito. Infelizmente não há conhecimento imediato: ao toparmos com um novo objeto o processo que gera o saber é lento: você precisa interagir com a coisa, dissecá-la, estudá-la. E este é apenas o primeiro passo.
O segundo passo é tentar externalizar este conhecimento. Aparecem pela primeira vez representações gráficas do objeto sob a forma de desenhos, diagramas, esboços, grunhidos ou seja lá o que você gostar. O interessante destes esboços é que normalmente representam apenas o nosso conhecimento instintivo: a impressão sensível que temos daquilo que tentamos abraçar. Sabe quando o conhecimento realmente surge? Quando conseguimos conceituar o objeto, ou seja, no momento em que é possível verbalmente gerar uma descrição sucinta e precisa: o conceito. Sem excessos ou faltas:o essencial. O conceito captura a essência da coisa. E todo conceito é verbal: não existe conceito representado de forma pictórica.
Só é possível garantir o conhecimento de alguém sobre determinado assunto quando esta pessoa consegue descrevê-lo de forma inteligível e sucinta verbalmente. Isto fica muito claro no exemplo a seguir. Observe a imagem abaixo que contém duas definições de um triângulo: a primeira de forma pictórica e a segunda conceitual.
A representação pictórica sempre é um processo baseado no ato de apontar. Te mostro uma imagem e digo: "esta imagem é uma ocorrência deste tipo de coisa". Não há conceito sendo formado, apenas mostro um exemplo. Além disto a imagem sempre é interpretativa. Levando a interpretação de um triângulo do ponto de vista apenas imagético, eu poderia pensar que todo triângulo possuí a ponta superior com uma pequena deformação, tal como desenhei. É uma interpretação estúpida porém totalmente válida neste contexto.
Já o conceito não: define exatamente o que é o objeto e não abre espaço para novas interpretações. Se nunca tiver visto um triângulo na vida mas tiver internalizado sua descrição sou capaz de identificá-lo na hora independente da forma como este se manifesta. Outro detahe: o conceito é curto.
Se uma imagem vale mais que mil palavras ela não pode representar um conceito pelo fato de possuir informação em excesso. Isto aniquila a primeira falácia. Dado que o papel do analista de requisitos é descrever o que deve ser implementado da forma mais precisa possível a imagem jamais pode ser o foco.
"Diagramas são mais fáceis de entender que o texto" - Uh!
Já sabemos o que é um conceito. Se o diagrama for mais fácil de entender que o texto, de duas uma: ou quem recebeu a especificação não gosta MESMO de ler ou não há qualidade no texto recebido. Conceitos por definição são simples, fáceis de serem entendidos. E se não forem fáceis de entender isoladamente devem possuir ao menos uma estrutura ao redor que ajude o leitor a entendê-lo. Ei: esta estrutura auxiliar pode vir na forma de imagens como diagramas. Repare: são estruturas auxiliares e não centrais.
Quando o assunto a ser tratado é bem descrito e o leitor encontra-se interessado no assunto a leitura sempre é prazerosa. Além disto entra em cena também a responsabilidade e maturidade do desenvolvedor. Documentação está ruim? Consulte o analista de requisitos. Continua ruim? Suba a bola pro superior hierarquico, procure seus colegas, se vire. O que não pode ocorrer é você irresponsávelmente implementar aquilo que não conhece.
"Mas o analista de requisitos é muito mais produtivo gerando diagramas" - Ai ai ai!
Já sabemos que a boa documentação gera bons conceitos que são por definição um produto verbal. Dado que produtividade implica na produção de algo que seja de interesse do grupo se seu analista está gerando o que não é conceitual temos aqui produtividade nula. Simples assim.
A involução linguística
Históricamente vê-se a evolução do alfabeto partindo do pictórico em direção ao fonético. A razão por trás deste caminho é simples: precisão. O alfabeto egípcio (veja imagem ao lado) era composto por hieróglifos que funcionavam na época de forma bastante precária. O significado de cada um variava bastante de acordo com o contexto e interpretação do leitor. Imagine escrever uma especificação desta maneira.
Quando o imagético assume o foco estamos voltando ao hieróglifo. O leitor possuí um espaço interpretativo significativamente maior do que o fonético (por favor, não me venham com exemplos de especificações poéticas ok?). Vêmos portanto uma involução linguística clara.
O diagrama que emburrece
Finalmente, minha teoria. Escrever bem requer prática. Uma vez obtida a qualidade, esta se perde com a ausência do exercício contínuo. Se um analista de requisitos gera apenas conteúdo imagético no final das contas este acaba se "desalfabetizando". A descrição verbal (conceituação) cede seu lugar ao apontar. Pronto: temos um analfabeto funcional, e não mais alguém cuja escrita é o objeto de trabalho.
Então diagramas são ruins? UML não presta Kico?
Diagramas são ótimos quando estão em seu lugar, ou seja, como estruturas acessórias ao entendimento de um conceito. Há situações nas quais podem ser usadas como o foco? Sim, mas são raras: de imediato penso no diagrama de classes. Porém, mesmo este isolado não é de grande valor: como justificar a presença de um atributo sem antes um conceituar a seu respeito. Preciso descrever até os elementos mais óbvios? Na minha opinião, sim. Um léxico sempre é bem vindo, especialmente se levarmos em consideração o fato de que o significado de uma palavra varia muito de acordo com o contexto em que esta é empregada.
Concluindo
Não se iluda achando que apenas com diagramas você está livre da escrita. Só sabemos aquilo que conseguimos conceituar.
PS: existe um texto muito bacana chamado "Death by UML fever" que talvez lhes interesse. Segue o link.
Top comments (0)