Com todos trabalhando remotamente, pode ser ainda mais difícil conseguir qualquer coisa realizada. Aqui estão dicas de como ter melhores reuniões de qualquer maneira.
Muitos engenheiros de software têm uma compreensão limitada do problema de negócios que o software que eles constroem resolve e o que exatamente ele precisa fazer. Por exemplo, eu trabalho em um sistema de gestão para contratos de estacionamento de veículos. No entanto, como sei muito pouco sobre como funcionam os contratos de estacionamento ou a gestão de estacionamento em geral, conto com um analista de negócios e um proprietário de produto para retransmitir o que exatamente precisa ser feito.
Passar de uma necessidade de negócio para um recurso de trabalho requer que o proprietário do produto peça algo ao analista de negócios, o analista de negócios para apresentá-lo aos desenvolvedores e, finalmente, para que o desenvolvedor que implementa o recurso tenha o mesmo entendimento que o grupo.
Este sistema é funcional em uma reunião presencial. Movimentos de mão, desenhos espontâneos no tabuleiro, e a natureza independente da conversa fazem com que se possa se intrometer. As pessoas podem pular e pedir um esclarecimento espontâneo de um acrônimo que alguém usou ou inserir rapidamente seu ponto durante uma pausa porque você pode ouvir e pensar ao mesmo tempo. Uma vez que alguém termine de falar, o próximo já tem uma resposta.
Quando se trabalha remotamente, muito disso está perdido. Uma reunião presencial força as pessoas a prestar atenção, então, eventualmente, toda a conversa confusa chega ao fim. Todas as respostas são imediatas e as distrações são minimizadas. Quando uma pergunta é feita, ela deve pelo menos ser reconhecida imediatamente. Há menos distrações para afastar alguém por alguns minutos. É mais difícil dormir.
No meu projeto, o proprietário do produto e a maioria dos principais stakeholders trabalham em um edifício completamente diferente, chegando apenas uma vez a cada duas semanas para o planejamento de sprint. Quaisquer esclarecimentos sobre tarefas, mudanças nas prioridades ou novos requisitos do cliente fora do planejamento devem ser comunicados por e-mail ou chat. Desde o surto de coronavírus, agora somos uma equipe totalmente remota e devemos realizar uma reunião de quatro horas de duração com 15 pessoas durante o bate-papo por vídeo. Aqui estão algumas coisas que aprendi antes e durante essa transição.
Tenha uma agenda
Uma reunião presencial permite conversas rápidas entre colegas e colegas que esclareçam sobre o que é a reunião antes de começar. Ele incentiva comentários off-hand, o que dá pistas do que está na mente de todos. Mas em chamadas de vídeo, há apenas um canal de áudio, então fazer perguntas rápidas da pessoa sentada ao seu lado é impossível.
Muitas vezes, durante reuniões remotas, não entendo por que o encontro existe, o que precisa ser alcançado ou qual é o tema básico. Na semana passada, eu estava em uma chamada por meia hora e não contribuí nada simplesmente porque eu não sabia por que estávamos lá.
Para corrigir isso, considere escrever um resumo de 50-100 palavras de reunião e pedir às pessoas para lê-lo no início da reunião. Alternativamente, passe o primeiro um ou dois minutos delineando o que deve ser realizado na reunião. Isso ajudará a garantir que todos estejam na mesma página e entenda por que eles estão lá. Esta é uma boa prática para qualquer reunião, mas crucial quando todas as formas informais de aprender sobre o encontro desaparecem.
Use a terminologia para o domínio empresarial
Durante meses, não aprendi muito sobre o sistema de gestão de contratos além do que fazia parte das minhas áreas de trabalho designadas. Eu falhei em me envolver significativamente além do código que eu tinha que escrever.
O problema com essa abordagem é que a terminologia que tem um significado muito específico para o proprietário do produto e analista de negócios pode ter um significado completamente diferente para você. Para o meu projeto, “licença” e “contrato” são dois conceitos muito distintos e nada que eu faça diz respeito à definição da empresa de “licença”. No entanto, eu continuei me referindo aos contratos como “licenças de estacionamento”, pois é isso que estou acostumado a um contrato de estacionamento sendo chamado.
Isso frequentemente levava a e-mails e mensagens de bate-papo onde eu e os membros não-técnicos de bate-papo passamos 20 minutos se referindo a aspectos completamente diferentes do projeto. Nós só saímos desse loop infinito quando alguém estava confiante o suficiente para perguntar se estávamos falando sobre a mesma coisa.
Você não precisa se tornar um especialista do domínio, mas faça o seu melhor para alinhar o seu uso de palavras com a forma como elas são definidas dentro da empresa. Por mais que o jargão possa inibir a compreensão para pessoas mais novas, ainda é extremamente útil ao lidar com uma equipe estabelecida.
Escreva em pedaços claros e facilmente digestíveis
Conversas presenciais podem vagar, tecer e evitar pausas definidas porque as outras pessoas podem reagir a ela em tempo real. Quando você começa a falar, a pessoa com quem você está falando pode processar imediatamente o que você está dizendo e pensar no que eles querem dizer em resposta.
Com a comunicação de texto, as pessoas só começam a ler o que você está dizendo depois de concluí-la e envie-a. Quando você está terminando seu processo de pensamento, seus leitores estão apenas começando.
Além do atraso que isso pode causar conversas, também faz com que as conversas percam sua linha de pensamento. Várias vezes, tentei fazer algumas perguntas bastante complexas e longas no bate-papo e enquanto eu estava ocupado escrevendo minha resposta, a conversa tinha passado para um tema totalmente diferente. Meu erro foi escrever minha pergunta como um longo bloco de texto em vez de uma série rápida de mensagens.
Se houver várias pessoas em uma conversa de bate-papo rápida, tente manter suas mensagens em uma única frase cada. Isso permite que ele flua mais como uma conversa presencial do que apenas e-mails saltando para frente e para trás. As respostas podem chamar para que ponto a pessoa que responde está abordando, e pensamentos distintos são mais fáceis de reconhecer.
Use analogias
Muitos conceitos em engenharia de software têm nomes ou nomes peculiares que têm significados totalmente diferentes fora da engenharia de software. Em um contexto não técnico, um “padrão de design” envolve cores e arranjos de desenhos de flores.
Como exemplo, considere como explico relações um-a-um versus um-a-muitos e a complexidade relativa em sua implementação. Alterar um recurso de ter um item para vários itens muitas vezes requer uma grande quantidade de tempo do desenvolvedor. Pessoas não técnicas muitas vezes se surpreendem com o quão cara é uma mudança tão simples e querem uma explicação para o porquê. O que eu digo a eles é que um para um é como ter um pai com um filho no zoológico. Um para muitos é como ter três filhos com um dos pais no zoológico, o que é muito mais complicado.
Ao tentar formar uma analogia, considere coisas que seriam geralmente conhecidas no grupo com quem você está falando. Comece com práticas corporativas e contratos existentes. Na minha função atual, o zoológico local é um dos nossos clientes, que é uma das razões pelas quais escolhi esse exemplo.
Esclareça com perguntas booleanas
20 perguntas é um jogo que os computadores podem jogar por uma razão. O possível escopo de um tópico pode ser drasticamente reduzido com a ajuda de perguntas que não exigem nada além de uma resposta verdadeira ou falsa. Ao procurar esclarecimentos, use este método. Perguntas simples como “isso precisa ser concluído até sexta-feira?” ou “este é um recurso voltado para o cliente?” pode ser a diferença entre confusão e compreensão rápida.
Apresentar escolhas limitadas e decisões de força.
Durante nosso último sprint, um recurso carregado muito lentamente ao ponto de um cliente pensar que a página da web tinha ficado presa. Embora houvesse muitas maneiras de corrigi-lo, fundamentalmente as duas opções eram adicionar algum tipo de indicador de carregamento para que o cliente saiba esperar alguns momentos ou dedicar esforço para fazer o recurso funcionar mais rapidamente.
Conversas sobre tais questões geralmente acabam discutindo as muitas soluções logo abaixo dessas duas categorias. Discutimos tudo, desde como podemos otimizar as consultas SQL até formas de reduzir a contagem de chamadas da API até a geração de um perfil de chamada com opção um para todos os diferentes tipos de spinners e mensagens que eram possíveis com a opção dois.
Depois de cinco minutos de não chegar a lugar algum em termos de tomar uma decisão, eu disse ao proprietário do produto que as duas escolhas fundamentais eram implementar um spinner em cerca de três horas de trabalho ou refazer o backend para trabalhar mais rápido a um custo de meia semana de trabalho. Isso resolveu a escolha em 30 segundos porque completar o componente relacionado dentro do sprint sem remover outras características era uma alta prioridade. A conversa então deu um zoom nos detalhes do spinner. Se eu não tivesse feito isso, a conversa poderia facilmente ter durado de 30 a 40 minutos.
Use maquetes e desenhos
Aqueles que trabalham em equipes maiores podem ter alguém dedicado ao design de interface do usuário ou experiência do usuário que já pode estar fazendo isso. Minha equipe não. Qualquer desenvolvimento de interface do usuário deve ser feito por um dos desenvolvedores (geralmente eu) ou pelo analista de negócios. Por mais que as maquetes estejam fora da descrição do trabalho e não faça parte do fluxo de trabalho formal para recursos, elas se mostraram bastante valiosas.
Na semana passada, fui incumbido de mover um botão para um cliente específico. A posição padrão do botão está no lado esquerdo da página e bastante distante. O cliente queria que ele se movesse para a direita e substancialmente para cima, já que o lado direito tem muito espaço branco. A parte que me foi comunicada foi que o botão deveria se mover para a direita.
Foi assumido pela pessoa que me deu as instruções de que mover o botão para a direita era uma instrução geral aberta para eu interpretar, não uma especificação. Eu tomei como uma especificação, então eu movi o botão ao longo do eixo x para o fundo do outro lado.
Este é um problema simples que será fácil de corrigir, mas o cliente agora deve esperar mais duas semanas para que ele seja resolvido na próxima versão.
As maquetes não precisam ser complexas ou feitas de forma profissional. Eu uso apenas uma combinação de Ferramentas de Snipping, Microsoft Paint e as ferramentas de desenvolvedor do Google Chrome para ajustar os componentes existentes para que eles possam ser screenshotados e usados. Parece uma colagem de grau cinco? Às vezes. Eles servem para esclarecer para onde vão as coisas? Absolutamente.
Termine cada conversa de recurso com uma declaração de retorno
Muitas vezes há várias conversas distintas dentro de cada reunião que poderiam ter existido por si mesmas. Se você pensar em uma reunião como o código de um software, o código que pode existir por si só geralmente deve ser transformado em uma função com uma instrução de retorno no final.
A mesma abordagem é útil nas reuniões. Como um tópico está sendo embrulhado, passe 30 segundos resumindo a decisão tomada e os itens de ação. Esse resumo garante que todos realmente sabem o que foi concluído e lhes dá a oportunidade de se oporem se algo estiver errado. Caso contrário, quaisquer erros serão descobertos na revisão de sprint após o trabalho já ter sido concluído.
Como muitos de vocês, reuniões e conversas confusas não são minha parte favorita do trabalho e podem se tornar extremamente irritantes se continuarem para sempre ou levarem a mal-entendidos que fazem com que o trabalho precise ser refeito. Ter essas conversas exacerba remotamente muitas dessas questões, mas espero que essas dicas possam mantê-lo produtivo e não preso no Skype.
