Deprecated: Calling get_class() without arguments is deprecated in /var/www/vhosts/localhost/html/wp-content/plugins/integracao-rd-station/includes/events/rdsm_plugin_uninstalled.php on line 12 Deprecated: Calling get_class() without arguments is deprecated in /var/www/vhosts/localhost/html/wp-content/plugins/integracao-rd-station/rdsm_assets_loader.php on line 14 Deprecated: Calling get_class() without arguments is deprecated in /var/www/vhosts/localhost/html/wp-content/plugins/integracao-rd-station/rdsm_assets_loader.php on line 15 Deprecated: Calling get_class() without arguments is deprecated in /var/www/vhosts/localhost/html/wp-content/plugins/integracao-rd-station/rdsm_assets_loader.php on line 16 Deprecated: Calling get_class() without arguments is deprecated in /var/www/vhosts/localhost/html/wp-content/plugins/integracao-rd-station/rdsm_assets_loader.php on line 17 Warning: Trying to access array offset on false in /var/www/vhosts/localhost/html/wp-content/plugins/schema/includes/integrations/amp.php on line 29 Por que as comunicações em TI não comunicam? IT Forum
All Rights ReservedView Non-AMP Version
IT Forum
  • Homepage
  • CIO
Notícias

Por que as comunicações em TI não comunicam?

Imagem: Shutterstock

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.

As melhores notícias de tecnologia B2B
Acompanhe todas as novidades diretamente na sua caixa de entrada

“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:

  • Expresse interesse: A pessoa ou as pessoas que você está ouvindo precisam ter certeza de que você realmente se importa com o que elas têm a dizer sobre o que pensam.
  • Deixe a outra pessoa falar: Mesmo que ela não esteja falando sobre o assunto que você quer que ela fale, preste atenção no que ela quer falar. Eles precisam tirá-lo do caminho antes que possam se concentrar no que você precisa.
  • Foco: Deixá-los falar é uma coisa. Deixá-los falar para sempre é outra coisa. Em algum momento, incentive-os a se concentrar no assunto sobre o qual você precisa falar com eles.
  • Pergunta (1) — esclareça: Se, como alvo do comunicador, você não estiver certo do que eles querem dizer, peça esclarecimentos adicionais.
  • Pergunta (2) — reafirme: Se, como comunicador, você não tem certeza de que a pessoa com quem está se comunicando o entende, peça a ela que reafirme — nos termos dela, não nos seus.
  • Pergunta (3) — finalize: Como comunicador, pergunte como formular qualquer que seja a conclusão quando chegar a hora de documentá-la.
  • Lembre: Quando a documentação estiver completa, analise-a pessoalmente com os principais interessados para confirmar se ela reflete as conversas que você já teve com eles.

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.

Next Falta um mês para o IT Forum Trancoso 2023! »
Previous « Oracle descarta layoffs e aposta em novo serviço de nuvem
Share
Published by
Laura Martins
Tags: comunicações em TIerros de comunicação TI
3 anos ago

    Related Post

  • Novos executivos da semana: Uncover, Tech for Humans, Diebold Nixdorf, Unico e mais
  • Se o Brasil não organizar seus dados culturais, outro fará isso por nós, alerta Jorge Brivilati
  • CBYK nomeia Maurício Matsuda como novo CEO

Recent Posts

  • Notícias

83% dos CIOs já adiaram projetos estratégicos por restrições de orçamento

A pressão por controle de custos vem alterando a dinâmica das áreas de tecnologia nas…

1 semana ago
  • Estudos

Fintechs brasileiras captam US$ 2,77 bi em 2025 e entram em nova fase de maturidade

O mercado brasileiro de fintechs passou por uma transformação no perfil dos investimentos em 2025.…

1 semana ago
  • Notícias

Sioux aposta em IA e dados para nova fase de experiências digitais e expande atuação para a Europa

O avanço da inteligência artificial e o uso estratégico de dados vêm transformando a forma…

1 semana ago
  • Artigos

Qual é o risco do desenvolvimento de software com IA?

Por Ramon Ribeiro Quase metade do código produzido por assistentes de inteligência artificial contém vulnerabilidades…

1 semana ago
  • Notícias

Se o Brasil não organizar seus dados culturais, outro fará isso por nós, alerta Jorge Brivilati

Peça a um modelo de inteligência artificial que gere a imagem de uma cidade, sem…

1 semana ago
  • Notícias

Novos executivos da semana: Uncover, Tech for Humans, Diebold Nixdorf, Unico e mais

O IT Forum apresenta, semanalmente, os novos executivos e os principais anúncios de contratações, promoções e mudanças…

1 semana ago
All Rights ReservedView Non-AMP Version
  • L