Introdução: A Importância da Comunicação
No ambiente de trabalho, especialmente em áreas críticas como o desenvolvimento de software, tomar decisões bem fundamentadas é essencial. Argumentos sólidos e bem embasados devem prevalecer, garantindo que as decisões tomadas sejam as melhores para o projeto e para a segurança de todos os envolvidos.Comunicar-se eficazmente e defender suas ideias com base em argumentos racionais é uma habilidade crucial. Quando confrontados com decisões difíceis, é importante avaliar todas as opções, considerar os riscos envolvidos e tomar uma decisão informada. Este artigo explora a importância de priorizar argumentos e compartilha lições valiosas sobre responsabilidade e ética profissional.
O Efeito Dunning-Kruger na Comunicação
O efeito Dunning-Kruger sugere que quanto menos alguém sabe, mais certeza tem de que é eficiente. No meu caso, reconheço que não sei tudo de comunicação e de regra de negócio. Contudo, sei que com esforço consigo obter as informações suficientes para realizar meu trabalho de maneira eficiente. Em contraste, outras pessoas têm tanta certeza de suas habilidades que acabam tomando decisões sem pensar adequadamente. Quando faço perguntas, algumas pessoas respondem como se as respostas fossem óbvias, mas, na verdade, muitas questões são mais complexas do que parecem. Pessoas com alta confiança pode ser um problema, pois tomam decisões precipitadas e as vezes que podem gerar risco ou prejuízo não só a equipe mas a milhares de pessoas. A pergunta que você deve fazer é, "Será que sou realmente tão bom na comunicação quanto acho que sou?".Evitando acidentes e riscos
Trabalhando seja com software de aviões, lojas de e-commerce, agências de publicidade ou em um banco, o melhor sempre é tomar decisões pensando e analisando e depois agindo e não agir sem pensar apenas porque alguém falou, uma comunicação errada, uma decisão errada pode acarretar em riscos e percas irreversíveis. Certa vez eu perguntei a uma professora minha que deu aula para mim na faculdade, também deu aula para mim na minha pós graduação e por fim também foi minha gerente e é algo que vou levar para o resto da vida, o que eu faria se no serviço mandassem eu fazer algo errado, ela falou que eu como profissional eu deveria recusar, e eu perguntei "mas e se isso me afetar ou afetar meu emprego?", ela falou que mesmo assim eu não deveria fazer, porque se eu tivesse construindo um prédio e alguém falasse para fazer algo que pudesse ter riscos do prédio cair, eu deveria recusar, a mesma coisa é com software, pessoas querem jogar a culpa uma na outra ao invés de analisar uma situação, preferem não pensar e culpar o Product Owner por um erro, sendo que você poderia ter identificado um problema e ajudado no refinamento do produto.Refinamento é Contínuo e Não é Algo Feito uma Vez
O refinamento do backlog no Scrum é uma atividade contínua, essencial para manter o backlog do produto atualizado, priorizado e claro. Este processo contínuo garante que a equipe de desenvolvimento tenha histórias de usuário bem definidas e prontas para as próximas sprints, embora o Product Owner seja a peça principal, os desenvolvedores podem identificar, levantar questões e sugerir melhorias, que podem não ser inicialmente evidentes para o Product Owner, e estas questões tem que ser levantadas com clareza e não por impulso, ou seja você deve antes entender melhor a regra para depois passar para o Product Owner e isto não é retrabalho, é falar a coisa certa no momento certo com o argumento correto.A Natureza Contínua do Refinamento
O refinamento do backlog é realizado regularmente, tipicamente uma vez por sprint, mas pode ocorrer com mais frequência, conforme necessário. Durante essas sessões, a equipe de desenvolvimento e o Product Owner trabalham juntos para detalhar as histórias, ajustar prioridades e garantir que os itens estejam prontos para serem puxados para a próxima sprint.
“Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.” — Guia do Scrum
Identificação de Regras de Negócio
Embora o Product Owner tenha a responsabilidade principal de definir e priorizar os itens do backlog, os desenvolvedores também desempenham um papel crucial na identificação e clareza das regras de negócio. Durante o refinamento, os desenvolvedores podem levantar questões, identificar dependências e sugerir melhorias que podem não ser inicialmente evidentes para o Product Owner. Esta colaboração ajuda a garantir que todos os aspectos técnicos e de negócio sejam considerados, resultando em histórias de usuário mais completas e bem definidas. Ou seja o desenvolvedor pode e deve falar de regras de negócio, mesmo não definidas pelo P.O se ele identificou que aquilo pode gerar algum risco.
Benefícios do Refinamento Contínuo
- Previsibilidade: Mantém o backlog preparado para as sprint plannings, garantindo que a equipe tenha sempre histórias bem definidas para puxar para a próxima sprint.
- Adaptabilidade: Permite ajustes contínuos nas prioridades e detalhes das histórias de acordo com o feedback dos stakeholders e mudanças no mercado ou nas necessidades do cliente.
- Colaboração: Promove a colaboração contínua entre o Product Owner e a equipe de desenvolvimento, melhorando o entendimento das histórias e facilitando a entrega de valor ao cliente.
O Medo de Perguntar
Outro desafio é que muitas pessoas têm medo de fazer perguntas. Elas temem que suas perguntas sejam repetidas ou que já tenham sido feitas antes. Estudos indicam que apenas uma pequena porcentagem do que é ouvido é realmente absorvido. Um estudo da Harvard Graduate School of Education revelou que a maioria das informações discutidas em reuniões pode ser perdida ou mal interpretada, indicando que a retenção de informações em reuniões é muitas vezes insuficiente. Isso significa que o que uma pessoa entendeu e ouviu pode não estar claro para outra pessoa. Alguns acham que entendem e sabem tudo, mas isso é um erro. Como um sábio disse, "não existe pergunta idiota, mas sim idiota que não pergunta".Perguntar nunca vai ser prejudicial, agora deixar de perguntar por medo de julgamentos pode ocasionar em perca de informação, riscos e incidentes que poderiam ser evitados.
Dados sobre Absorção de Informação
A retenção de informações em reuniões é um desafio conhecido. Estudos mostram que, em média, apenas uma pequena fração do que é discutido em reuniões é realmente absorvida pelos participantes. Isso reforça a importância de fazer perguntas para garantir que todos os pontos importantes sejam compreendidos.
Um estudo publicado pela National Training Laboratories sugere que a retenção de informações varia significativamente de acordo com o método de ensino. Por exemplo:
- Palestra (5%): Um método passivo onde o aluno escuta o professor falar. A retenção é baixa porque os alunos não estão ativamente envolvidos.
- Leitura (10%): Também um método passivo, mas ligeiramente melhor do que palestras.
- Áudio-visual (20%): Inclui vídeos e apresentações que combinam áudio e imagem. A retenção é melhor porque envolve mais sentidos.
- Demonstração (30%): Envolve mostrar como algo é feito, o que melhora a retenção em comparação com métodos puramente passivos.
- Discussão em grupo (50%): A retenção melhora significativamente quando os alunos discutem e interagem com o material em grupo.
- Praticar fazendo (75%): Colocar em prática o que foi aprendido leva a uma retenção muito maior porque envolve a aplicação ativa do conhecimento.
- Ensinar aos outros (90%): O método mais eficaz, pois ensinar força o professor a organizar o conhecimento de maneira clara e compreensível, consolidando assim a própria compreensão e retenção.
Esses dados destacam a importância de métodos de aprendizado ativos e envolventes para melhorar a retenção de informações. O envolvimento ativo dos participantes durante as reuniões, utilizando diferentes métodos de ensino e garantindo que as informações sejam apresentadas de maneira clara e envolvente, pode aumentar significativamente a retenção de informações.
"Se o grupo permanecer quieto, verifique. Pergunte, 'Por que está quieto? Vocês estão pensando? Confusos? Não interessados?' Você pode perceber que eles não entenderam a pergunta ou que estão distraídos por outro problema." — Harvard Graduate School of Education
Para mais detalhes, confira o estudo completo no artigo "Making Meetings Work" da Harvard Graduate School of Education e as discussões sobre retenção de informações no artigo da Education Corner e do The Peak Performance Center.
A Importância de Perguntar
Um colega pode acreditar que responderia ou perguntaria melhor, mas, na prática, qualquer um pode fazer perguntas mais inteligentes depois que elas já foram feitas, mas nem todos tem a iniciativa e coragem de tomar as rédeas e fazer a pergunta. Às vezes, nem todas as perguntas serão totalmente eficazes, e isso é normal e faz parte do aprendizado. O ideal é quando não fizermos uma pergunta efetiva um cobrir o outro e mostrar como poderia ser feita de maneira melhor.
A Analogia com o Futebol
Pense em uma partida de futebol. Quem assiste sempre diz que faria melhor, que jogaria melhor que o jogador em campo, faria um passe diferente ou que a pessoa não foi eficiente o suficiente. Porém, uma coisa é a visão de quem está assistindo e outra é a de quem está jogando. Claro que existem especialistas em análise de jogo, mas muitas vezes a pessoa que está assistindo não tem conhecimento sobre o jogo, ou seja, sobre a determinada tarefa, e quer opinar dizendo que sabe mais, que entenderia mais rápido ou executaria mais rápido. No entanto, essas observações, muitas vezes feitas com boa intenção, não refletem os desafios reais enfrentados por quem está em campo, e reconhecer essa diferença é fundamental. A mesma coisa é com o software, temos que tomar cuidado ao fazer críticas, sair da plateia e ao invés de criticar jogar junto como um time e criticar como um colega de campo e não como um espectador.A Importância de Treinar a Escuta
Às vezes, o problema não é a falta de clareza na comunicação, mas a falta de interesse ou tempo de quem está ouvindo. Muitas vezes, as pessoas querem apenas que você resolva o problema ou uma determinada tarefa ou até mesmo um bug, sem entender o motivo real do problema. Mesmo explicando com evidências e detalhando, documentando em sistemas como o Jira, falando em grupos como Teams e até falando pessoalmente, algumas pessoas não entendem e culpam o comunicador. O argumento de que não entendeu e a culpa é sua por isso nem sempre é real, pois muitas vezes o desinteresse pelo assunto e a confiança de que está certo é a própria causa da pessoa não ter conseguido entender. As pessoas, por acharem que sabem muito e que estão sempre certas, não importa o argumento que você usar ou a maneira que falar, vão continuar achando que estão certas, e ainda vão usar isso para falar que você não comunica bem, pois não importa o que você fala ou como fala, elas querem que você faça o que elas querem, e se você tomar um caminho diferente, ou ter uma opinião diferente, vão dizer que não se comunica bem.Feedback de Comunicação
Muitas vezes, a comunicação é criticada, mas é essencial reconhecer que uma comunicação eficaz requer esforço contínuo e colaboração de todas as partes envolvidas. Todos podemos aprender a nos comunicar melhor fazendo perguntas e buscando entender antes de julgar. Receber feedback é uma oportunidade para melhorar, mas é importante que esse feedback seja construtivo e baseado em observações objetivas, e não apenas em percepções superficiais.
Conclusão
A comunicação eficaz é uma habilidade vital no desenvolvimento de software, que vai além de apenas fazer perguntas. Envolve reconhecer as próprias limitações, estar disposto a aprender continuamente e utilizar a colaboração para alcançar clareza e entendimento mútuo. O efeito Dunning-Kruger nos alerta sobre a superestimação das próprias habilidades e a importância de avaliar criticamente nossas capacidades de comunicação.
Argumentos sólidos são mais valiosos do que hierarquias e decisões precipitadas podem acarretar em riscos e perdas irreversíveis. A prática de refinamento contínuo no Scrum mostra como a colaboração entre o Product Owner e a equipe de desenvolvimento pode levar a histórias de usuário mais completas e bem definidas, beneficiando o projeto como um todo.
O medo de perguntar e a falta de interesse em ouvir atentamente podem ser grandes obstáculos para uma comunicação eficaz. Estudos demonstram que a retenção de informações em reuniões é limitada, destacando a necessidade de métodos de aprendizado ativos e envolventes para melhorar a absorção de informações. Criar um ambiente onde perguntas são bem-vindas e onde todos se esforçam para escutar ativamente pode transformar a dinâmica de uma equipe, resultando em melhores resultados e menos retrabalho.
Ao treinar a escuta e incentivar a participação ativa de todos os membros da equipe, podemos superar as barreiras de comunicação e construir um ambiente de trabalho mais eficiente e colaborativo. Lembre-se de que a busca contínua por clareza e entendimento mútuo é o caminho para uma comunicação realmente eficaz no desenvolvimento de software.