Reuniões eficazes da equipe

Sou líder de uma equipe de 8 programadores em uma empresa com cerca de 20 pessoas técnicas. Eles estão trabalhando em uma variedade de projetos, esses projetos também envolvem pessoas de outras equipes que estão fora do meu controle. Minha organização não está desenvolvendo um desenvolvimento ágil adequado e é um pouco resistente a mudanças, mas tenho realizado reuniões diárias de pé em pé dentro da minha equipe e todos as achamos úteis e todos estão envolvidos e terminamos 10-15 minutos. Também tenho encontros semanais individuais com cada membro da equipe, onde discutimos vários tópicos gerais (técnicos e não técnicos) em mais detalhes, bem como várias reuniões tópicas ad-hoc.

No entanto, estou lutando com minha reunião semanal da equipe. Está perdendo força e não consegui manter as pessoas interessadas.

Ainda quero realizar uma reunião mais longa, mesmo que seja quinzenal ou mensal. O objetivo era discutir vários tópicos que não podem ser feitos durante uma reunião de pé, porque exigem mais tempo. As minhas atualizações incluem um resumo de todos os projetos atuais em que estão trabalhando (seja dentro do cronograma, vários atrasos, etc.), quaisquer mudanças de direção, projetos futuros, mudanças no processo de desenvolvimento, etc. No entanto, acaba sendo uma palestra minha, e pelo menos duas pessoas estão obviamente divididas, e as demais estão no mínimo levemente interessadas.

Tentei fazer as pessoas ficarem mais engajadas, fazendo com que elas conversassem sobre a semana delas, mas com 8 pessoas leva muito tempo e (em parte porque muito do trabalho delas não passa por tanto tempo assim), a maioria dos demais não se importam com o que os colegas de trabalho estão trabalhando com mais detalhes (eles obtêm uma visão geral de alto nível durante os levantamentos).

Então, durante essas reuniões, pelo menos algumas pessoas ficam muito entediadas, e é quase constrangedor para mim continuar segurando isso. É um contraste gritante com nossas reuniões energéticas da manhã.

Algum conselho sobre o que posso fazer para manter as pessoas mais engajadas e interessadas? E como posso fazê-los apresentar coisas ou iniciar discussões que envolvam todo mundo, em vez de ser um monólogo de mim?

Você disse que as reuniões parecem estar dando palestras para elas. Se você se sente assim e a equipe não parece interessada no que você tem a dizer, por que ainda tem a reunião? Se você está apenas jogando informações nelas, e elas não estão prendendo a atenção delas, por que não resumir tudo em um email semanal?

Se você quiser fazer uso dessa hora que tem com toda a equipe, considere executar uma retrospectiva. Você pode apresentar a retrospectiva com honestidade simples de sua parte: diga a eles que você não acha que as reuniões anteriores foram produtivas e que deseja tentar algo diferente para ajudar todos a se beneficiarem da hora em que estão juntos.

Em retros onde eu trabalho, teremos três colunas em um quadro branco, geralmente colocando um smiley, meh, e triste rosto no topo, por exemplo :), :|e :(. Em seguida, os membros da equipe colocam qualquer coisa no quadro sobre a qual gostariam de conversar com todo o grupo.

Na coluna feliz, você pode comemorar sucessos (como parabenizar Alice e Bob pelo lançamento de um projeto em que trabalharam juntos) e declarar vitória com novos processos que está tentando (como o novo rastreador de bugs é muito melhor que o antigo).

Na coluna meh, você coloca coisas que não são exatamente felizes ou tristes durante a semana. Talvez você tenha adquirido licenças para a nova versão do seu IDE e alguém não tenha visto nenhuma vantagem do novo IDE - eles podem colocar isso em prática para descobrir se todo mundo sente que a atualização não vale nada ou se outras pessoas têm encontrou maneiras de ser realmente superior à versão anterior.

Na coluna triste, você coloca coisas que não correram bem durante a semana. Identificar os pontos problemáticos da semana é provavelmente o maior benefício de uma retrospectiva na minha opinião. Toda a equipe começa a discutir soluções para um problema real. Em equipes que trabalham em uma única base de código, por exemplo, alguém pode dizer que a classe FooBar é impossível de manter e foi a causa de horas de depuração. De repente, você descobre que todo mundo na equipe também perdeu várias horas esta semana para o FooBar, mas ninguém gastou tempo para limpá-lo. Nesse caso, a equipe pode decidir coletivamente que faz sentido que alguém gaste algum tempo refatorando esse código na próxima semana.

Depois que todos escrevem os tópicos propostos no quadro, gosto de abordar brevemente cada tópico e pedir ao autor que dê uma explicação de 10 a 30 segundos sobre o tópico. Esta seção da reunião é fácil de descarrilar; portanto, você deve ter cuidado para manter as pessoas no tópico - por exemplo, alguém dirá que X foi um problema e outra pessoa começará a falar sobre uma solução para o problema; as soluções não devem ser discutidas até depois da votação. Ao apresentar os tópicos, você pode encontrar maneiras de agrupar vários tópicos estreitamente relacionados.

Após as apresentações, todos recebem três votos que podem ser distribuídos entre os tópicos da maneira que acharem melhor. Finalmente, os votos são computados, e o tópico que tiver o maior número de votos é o que a equipe discute. Para cada tópico, determine se há uma ação que precise ser executada. Celebrar um sucesso geralmente não possui um item de ação, mas a refatoração de um código específico pode ser atribuída a uma pessoa. Os itens de ação geralmente devem ser concluídos por uma pessoa, mas às vezes são itens de ação de "equipe inteira", como estar atento a ter boas mensagens de confirmação.

A maioria dos retros tende a se concentrar nos tópicos da triste coluna, e praticamente nenhum deles discute tudo o que está escrito no quadro. A reunião tende a terminar sempre que o tempo acabar. Imediatamente após a reunião, verifique se os itens de ação são atribuídos a pessoas específicas; faça isso da maneira que fizer sentido para sua organização.

Eu tive um grande sucesso com retrospectivas. Eles são uma ótima maneira de criar coesão em uma equipe e são uma ótima maneira de refletir sobre a semana anterior e refinar seu processo. Eu acho que se você tentar isso com sua equipe, eles ficarão muito mais engajados nas suas reuniões.

Bem-vindo ao mundo da gerência intermediária!

Você vai encontrar esse tipo de problema acontecendo MUITO!

Você tem 3 opções:

Big Stick Faça isso ou você será demitido - nunca funciona. Não faça isso.

Propriedade Faça com que eles facilitem as reuniões. Dê um passo para trás e nomeie outra pessoa. Tê-lo como uma posição rotativa, onde uma pessoa diferente hospeda cada vez.

Fale o que não foi dito Pelo que você disse, todo mundo está entediado - então por que não perguntar isso a eles? Você está entediado ? / Isso é perda de tempo, etc. Por que estamos ouvindo? Qual o valor disso?

Não ficou claro em sua pergunta por que você deseja fazer isso. Se você é o único que sente que isso é valioso, está disposto a mudar? Pergunte o que eles querem. Eles são pessoas de software, seu trabalho é resolver problemas o dia todo - resolver este!

Tente dar mais valor aos desenvolvedores em suas reuniões. Alguns exemplos podem ser:

• pequenas demonstrações mostrando novos recursos desenvolvidos no recente sprint. (apresentado por todos)
• uma discussão com lições aprendidas, na qual eles têm a chance de mudar a maneira como a equipe trabalha e melhorar (a discussão levou sua mão direita à equipe, e você está lá para justificar suas decisões de gerenciamento. semelhante a uma sessão de ventilação individual mas maior)
• uma palestra sobre um novo projeto de código aberto que possa ser relevante ou uma linguagem de codificação diferente, como Lang ou Golang funcional ou tópicos verdes em python. (talvez apresentado por um dos desenvolvedores mais jovens ou na forma de um vídeo on-line)
• uma discussão liderada por um engenheiro de vendas que descreve um problema de engenharia extremamente difícil que seu cliente está tentando resolver. (o mesmo acordo com o gerente de suporte / serviços tentando reduzir os custos de suporte melhorando a usabilidade do produto)
• uma manjedoura que revela as várias alternativas estratégicas que a empresa poderia ter adotado e como isso afetaria a engenharia, dado o cenário competitivo.
• um consultor externo que oferece sessões de consultoria sobre tecnologias que você já usa, mas não ao máximo (geralmente nosql, cep, RDBMS, rede, segurança, monitoramento ...)
• um passo a passo no qual todos podem aprender novas dicas de codificação, depuração ou teste de produtividade (por esse desenvolvedor que possui 10x de produtividade).
• uma sessão de codificação em que nenhum mouse é permitido. Aprenda os atalhos do IDE.
• falar por um contador sobre dinheiro 101 questões relacionadas a pensão, investimentos
• fale sobre programação social e carreira (troca de pilhas, twitter, github, blogs pessoais, LinkedIn, encontros na sua área)

Pode a reunião ou realizá-la com muito menos frequência. Escreva suas palestras em um e-mail regular e envie para todos.

Só faça reuniões se as pessoas nelas realmente tiverem motivos para participar delas. Caso contrário, você realmente está desperdiçando o tempo das pessoas.

Não realize longas reuniões e aproveite o software de gerenciamento de projetos. Se você deseja manter as pessoas interessadas, condense e destaque o que importa e guarde o restante para os logs e relatórios do projeto. Concentre-se em marcos, entregas, destaques e metas e, se apenas se aplica a 1/3 das pessoas, guarde-o para um tópico de discussão do projeto.

• Mantenha suas reuniões curtas
• Alavancar o software de gerenciamento de projetos
• Mantenha-o pessoal, objetivo e conecte-se com emoções e objetivos
• Solução de problemas em grupos focais, não em fóruns
• Obtenha feedback de seus colegas

Além disso, não permita que outras pessoas entrem na conversa e continuem com seu trabalho, a menos que tenham definido pontos que desejam abordar. Se você deseja feedback, prepare-o ou guarde-o para um tópico de comentário em algum lugar on-line onde as pessoas tenham tempo para abordá-lo. Esse é um dos problemas mais irritantes das reuniões; dando tempo à palavra aos colegas por respeito. Mantenha essas coisas no final depois de ter abordado tudo o que você precisa transmitir.

Adote uma diretiva sobre a abordagem de gerenciamento de projetos e incentive boas práticas de desenvolvimento liderando pelo exemplo.