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.
Ótimo texto, Henrique. Você sabe que passei pela mesma situação que você e o quanto ela já foi prejudicial aos projetos em que atuei. É espantoso ver profissionais que, de outra forma, seriam excelentes, se reduzirem a maus diagramadores de ideias pouco assentadas em suas mentes pela falta do exercício da conceituação.
A experiência que tive foi “interessante” porque mostra que mesmo em diagramas que misturam um pouco mais de texto com os elementos pictóricos (diagrama de fluxo, da forma que era usado), a transmissão da ideia e do conceito era absolutamente truncada, faltava conexão e fluidez do “texto”, dando margem a falhas e faltas de interpretação. Isso *sempre* ocorreu.
A ideia de imagem valer mais que mil palavras deve funcionar no marketing, em que a imagem dá uma ideia geral e um indicio de quão bom e necessário algo deve ser, deixando a mente do receptor preencher as “lacunas” da ideia (e, muitas vezes, ao custo de comportamentos irracionais (no sentido econômico) do consumidor). Num detalhamento de requisito não se quer indícios, o objetivo é precisão, não ambiguidade. Portanto isso deve ser feito através de um texto bem escrito e criterioso.
ainda bem que a gente não comete este erro hein? A proposito, no meu vôo pra Brasilia hoje tive uma ideia que preciso disvutir vim você urgentemente! Coisa boa!
Bom…
Concordo, mas em parte. Principalmente, porque a aplicação dos diagramas foi simplesmente mal aplicada pelos “hypistas”, como o Kico costuma chamá-los.
As representações simbólicas são sim, muito úteis, e o texto em si na realidade tem um exemplo perfeito disso. O grande problema ao meu ver é que hoje escrever, e nesse contexto documentar detalhadamente é quase considerado “perda de tempo”, dependendo do caso…
A idéia dos diagramas sempre foi padronizar a documentação, e diminuir a verbosidade de sua parte textual. Anular sua parte textual simplesmente introduz um buraco enorme no entendimento. Mas existe (creio) uma progressão entre a visão da empresa sobre a documentação que está diretamente relacionada à verba de TI, e consequentemente ao tamanho da equipe, prazos, etc.
Apenas pra fechar com o caso do triângulo que citei acima, imaginemos que alguem se deparasse somente com o texto descritivo. Ele não poderia implementar o desenho como algo assim?
|_|
Isso é uma figura geométrica de tres lados e os angulos internos soman 180 graus. O detalhe que poderia entregar a falha na descrição está na imagem – o triângulo é uma figura fechada. O analista pode então sanar a dúvida antes de uma eventual correção de código, etc.
Uma imagem vale mais que mil palavras não quer dizer que esta substititui o texto, e sim que o receptor pode usar da sua própria cultura para fazer uma leitura dela que, algumas vezes, o emissor da mensagem não declarou conscientemente. Algumas vezes essa frase é dita como “um Símbolo vale mais que mil palavras”. E, nesse sentido, fica clara a intenção dos diagramas, que era a de diminuir a verbosidade do texto, porque o texto que poderia descrever a operação completa pode facilmente ser reconstruído na presença de ambos – o diagrama E o texto que o complementa.
Mais uma vez, parabéns pelo artigo! O site da Itexto pra mim virou bookmark, to visitando sempre que posso. Foi uma das melhores descobertas que fiz no ano passado, junto com o grail Brasil… E as duas são obra sua, então… tu é o cara!
Abraços!
bons pontis Flavio.
O que vejo como grande problema é a negação do vetbal que vemos quando os diagramas passam a ocupar o foco.
Eles fornecem um vocabulario e padronização que nos ajuda? Yeap! Mas é apenas como acessório, não como foco.
Sim, sim! Antes do artigo eu nem via isso como problema, agora tenho definitivamente que prestar mais atenção a essa questão. Realmente abriu meus olhos…
Clap, clap, clap, clap! Excelente texto Kiko. Por coincidência, esta semana resolvi voltar a “blogar” por motivo semelhante: uma necessidade imensa de externalizar e documentar o que venho aprendendo e aplicando no trabalho.
“Compreender um pensamento e produzir um pensamento são quase a mesma ação.” – Joseph Joubert –
Opa, valeu Mr. Alexandre!
Sim, eu estou sentindo muito estas compulsões nestes dias.
Quando olho pra trás e vejo burradas gigantescas sendo repetidas over e over e over again não consigo me conter. :)