Um dos analistas de negócios do meu cliente solicitou minha opinião: “Este é um bom documento de especificação?”, ele perguntou.
Há muito tempo, aprendi – da maneira mais difícil – a sabedoria do ditado “Quando alguém pede um conselho, geralmente está procurando um cúmplice”. Então respondi a sua pergunta com outra, questionando por que ele havia perguntado.
“Eu dei isso a um desenvolvedor, que me disse que era uma especificação ruim. Então eu queria a sua opinião.”
Sim, cúmplice. É.
Ainda assim, eu olhei para a especificação. Era um documento razoável no que diz respeito a essas coisas. Mas, como muitas especificações, era ruim por um simples motivo: o analista de negócios o havia usado para comunicar as especificações ao desenvolvedor.
É um erro comum e não se limita a analistas de negócios e especificações de aplicativos. CIOs, gerentes de TI e, por falar nisso, pessoas em uma empresa típica também fazem isso: eles tentam se comunicar uns com os outros enviando documentos de um lado para o outro.
Embora às vezes seja inevitável, quando se trata de alcançar um entendimento compartilhado de praticamente qualquer coisa, é uma péssima alternativa.
O problema começa em como usar a documentação para se comunicar ignorando a natureza fundamental da comunicação.
As quatro falhas fundamentais da documentação
Se você preferir se comunicar por meio de documentação – e incentivar todos em sua organização a seguir o exemplo – quatro facetas da comunicação estão atrapalhando.
Idioma: Todo idioma natural, seja inglês, latim ou mesmo esperanto, é impreciso na melhor das hipóteses. Os sinônimos são aproximados, não exatos; palavras são definidas por outras palavras, levando-nos ao caminho da recursão infinita; pessoas diferentes trazem vocabulários e suposições diferentes para suas tentativas de interpretar o que estão lendo.
A menos, é claro, que a linguagem que eles usam para escrever a especificação seja pseudocódigo. Isso é preciso e inequívoco o suficiente. Mas então teríamos analistas de negócios escrevendo código em vez de especificações e, então, qual seria o objetivo?
Desambiguação: Não importa o quanto os melhores escritores tentem, eles nunca criarão um documento completamente livre de ambiguidade e lógica emaranhada. Ao fazer a tentativa, muitos se veem trilhando o caminho literário de uma profissão diferente, para a qual a ambiguidade e a probabilidade de má interpretação são igualmente problemáticas: eles escrevem prosa jurídica, em estilo de contrato, que suas vítimas tentam entender com toda a futilidade de tentar entender o EULA médio.
Desentendimentos: Não importa o quão bem um analista de negócios (voltando ao nosso exemplo de desenvolvimento de aplicativo) descreva seu design, as partes interessadas com quem trabalharam para criá-lo nem sempre concordarão em todos os pontos. Os desacordos das partes interessadas inevitavelmente se transformam em compromissos de design e, pior ainda, em especificações inconsistentes.
O documento de defesa orçamentária de um CIO enfrenta desafios semelhantes.
Intermediação: “Desintermediação” é a palavra cara para “eliminar intermediários”, que é exatamente o que a maioria dos escritórios de TI não faz. Em vez disso, eles intermediam. Seguindo nosso exemplo de BA, o papel típico do analista de negócios é, lamentavelmente, servir de intermediário, devido à visão falaciosa de que profissionais técnicos não são capazes de ter conversas produtivas com os stakeholders de negócios de seus projetos.
Essa proposição totalmente absurda tem sido uma doutrina aceita há décadas e já passou da hora de colocá-la de lado. Se profissionais técnicos não conseguem conversar efetivamente com seres humanos não-técnicos, como é que eles se casam com cônjuges que não são profissionais técnicos, criam filhos cujas primeiras palavras são “Mamãe!” (ou, muitas vezes, “Não!”) e não “<p>Texto do parágrafo</p>”, desfrute de churrascos no quintal com vizinhos que (suspiro!) podem ganhar a vida em marketing ou contabilidade ou, nesse caso, treinar cães para responder aos seus comandos de voz?
Não é incomum que os CIOs caiam na mesma armadilha. Eles tratam seu organograma como uma coleção de módulos de software, com formas bem definidas de interação de pessoas de fora – basicamente, como se estivessem invocando subrotinas – e assumem que todos os outros executivos olham para a empresa da mesma maneira.
Mas, assim como não existe um organograma perfeito, também não há uma maneira perfeita de prescrever as saídas de um departamento e as entradas exigidas de outros departamentos para que eles obtenham essas saídas.
A solução é a conversa
O que dá errado não se limita, é claro, aos documentos de design de TI. Isso apenas ilustra o ponto, que é que, quando confiamos na documentação para nos comunicar, estamos pedindo problemas e geralmente nos encontramos nele.
Bem-vindo à solução. Não é particularmente complicado. É que quando as pessoas precisam se entender, elas precisam conversar umas com as outras, de forma interativa, usando as (espero) conhecidas diretrizes para a escuta ativa. Em particular:
Se isso parece um pouco idealizado, talvez seja. Você nem sempre pode ficar cara a cara com todas as partes interessadas, e quanto maior o assunto, mais difícil é.
Também há problemas linguísticos a serem enfrentados: se você e a outra pessoa não tiverem um idioma em comum no qual ambos sejam fluentes, confiar em um documento pode ser mais eficaz do que tentar uma conversa.
Então, no final, temos que aceitar que, às vezes, precisamos confiar na documentação para nos comunicarmos. Como, por exemplo, agora mesmo enquanto você lê estas palavras.
