Quem se beneficiará com este artigo?
O artigo será útil para líderes e membros de pequenas equipes de projeto de 5 a 10-15 pessoas.
O que usar e por quê?
Usamos pessoalmente o Slack para comunicar e compartilhar informações.
Muito do que está escrito a seguir, de uma forma ou de outra, pode ser organizado em outros mensageiros.
Razões para usar o Slack:
- Conveniência na organização de chats em grupo (canais)
- A presença de threads - a capacidade de criar ramificações de diálogo
- Diferenciação entre diálogos de trabalho e não de trabalho. Trabalhe no Slack. Outro - em telegrama / watsap / onde quer que
- Disponibilidade de reações
- Disponibilidade de lembretes
- A capacidade de integrar o Slack com muitas ferramentas
Se houver alguma alternativa no Slack para a qual todos os 6 pontos acima sejam verdadeiros, diga-me nos comentários. E para tal alternativa, diga-me quais recursos interessantes ele tem e costuma usar em sua equipe.
Quais são as regras de comunicação na equipe e por quê?
1. Não se comunique no PM
Deixamos comunicação no PM apenas para dois casos:
- Discutindo algo que requer privacidade.
- Memasiks / piadas e outras inundações.
Para todo o resto, usamos canais de comunicação comuns.
Agora vou te dizer para que serve. Eu direi um pouco mais tarde como organizar os canais de comunicação comuns de forma que não haja confusão e caos.
Por que essa regra é necessária?
Esta regra é necessária para:
- Foi possível captar situações em que alguém se desviou do curso e começou a fazer algo errado.
- Foi possível captar situações em que alguém começou a fazer algo errado.
- Não houve situações em que duas pessoas concordassem em algo e outra pessoa sofresse com isso.
- Os gestores poderiam monitorar a coordenação do trabalho em equipe.
- Os gestores podiam rastrear a ocorrência de conflitos, ressentimentos e a ocorrência de outras negatividades.
2. Identifique aqueles a quem o recurso vai
Qualquer mensagem deve ter um destinatário. Um ou mais.
Ao se referir a alguém, você deve marcá-lo.
Ao se dirigir a várias pessoas, marque todos, não todos no canal.
Por que essa regra é necessária?
Esta regra é necessária para:
- Nem todos os participantes do bate-papo foram distraídos por mensagens em conversas / conversas em grupo, mas apenas aqueles que foram marcados.
- A probabilidade de o destinatário exibir uma notificação era máxima. Por exemplo, no Slack, as notificações às vezes são perdidas.
3. Reaja às mensagens
Qualquer mensagem enviada por alguém (não automaticamente) não deve ser ignorada pelos destinatários desta mensagem. O destinatário, ao receber uma mensagem, deve dar uma resposta. Se houver vários destinatários, todos devem reagir.
Para não escrever as frases “ok”, “entendido”, etc., o Slack tem um recurso conveniente - as reações. Os membros da nossa equipe costumam colocar a reação: olhos:. O líder usa a reação: olho:.
Por que essa regra é necessária?
Esta regra é necessária para que o remetente saiba que sua mensagem “não foi perdida”.
4. Use tópicos
O Slack tem um recurso como threads - a capacidade de criar uma “linha de conversa” e conduzir um diálogo nela, e não no fluxo de mensagem principal.
Esse recurso é adequado para discutir um único problema.
Por que essa regra é necessária?
Essa regra é necessária para não bagunçar o fluxo principal de mensagens, aumentando a estrutura das informações e a facilidade de navegação por ela.
5. Registre conversas que ocorreram fora do Slack
Se algum diálogo ocorreu, por exemplo, na chamada, então é necessário adicionar um protocolo baseado nos resultados da chamada - um conjunto de teses que refletem os resultados da conversa.
Por que essa regra é necessária?
Esta regra é necessária para:
- Certifique-se mais uma vez de que os participantes do diálogo se entenderam corretamente
- Não esquecemos o que combinamos
- Estavam cientes do que estava acontecendo quem não aceitou no diálogo, mas se interessou pelo tema do diálogo
- Foi possível referir os resultados da conversa
- ... e os mesmos argumentos do primeiro parágrafo sobre canais de comunicação comuns
Os protocolos devem ter destinatários e receber respostas!
Nem todos devem ser colocados como destinatários, mas sim aqueles a quem o tema deste diálogo diz respeito.
6. Inicie uma chamada / reunião se o problema não for resolvido em 15 minutos de correspondência ativa
Tudo é simples aqui: se você perceber que tem que escrever muito texto, se começar uma bagunça no chat, você precisa iniciar uma chamada e discutir tudo com uma voz.
E como resultado da chamada - envie o protocolo para todos.
7. Conduzir reuniões diárias por escrito
Uma reunião diária é uma reunião de grupo em que cada membro da equipe deve responder a várias perguntas candentes e discutir questões / problemas atuais para sincronizar a equipe. Exemplo de um conjunto de perguntas para reuniões diárias:
- O que você fez ontem?
- O que vou fazer hoje?
- Que problemas eu tenho no meu caminho?
Realizamos reuniões diárias das 11h30 às 11h35 em um bate-papo em grupo dedicado. O gerente escreve por último - às 11h36. Qualquer pessoa que cancelou a assinatura depois de ser considerada atrasada. O trabalho educacional deve ser realizado com os retardatários. Todos devem, sob a mensagem de todos, afixar a reação: olhos:. Essa reação é a confirmação de que todos leram cada mensagem diária.
Nosso modelo de mensagem diária:
- O que eu fiz?
1. Método API / Olá
2. Método API / como você - O que vou fazer?
1. Método API / tchau - Perguntas:
1. Alice, quanto tempo você acha que sua tarefa vai demorar? - Problemas:
1. A implantação falha. Socorro!
Ao discutir questões / problemas, não se esqueça da regra número 6 - se a questão / problema não for resolvido em 15, nós o levamos para a contagem.
Na maioria das vezes, nossa diária leva 15 minutos do tempo de todos, levando em consideração o tempo de preparação para o rally.
Por que essa regra é necessária?
Esta regra é necessária para que o tempo de trabalho da equipe seja efetivamente aproveitado. E paciência.
Não importa o quão otimista o nosso mundo de Scrum esteja tentando tornar-se, na prática, diariamente, quando um membro da equipe fala, não o resto da equipe o ouve, mas 1-2 pessoas. O resto está apenas esperando na fila. Normalmente, para equipes de 10 pessoas, essa diária dura de meia hora a uma hora, o que significa que a maior parte da equipe fica sentada e torta a maior parte dessa hora. A tradução para o formato de texto torna o dia a dia rápido, conciso e, entre outras coisas, fixo.
8. Bônus: Em equipes internas, discuta em formato de texto tudo relacionado aos produtos e o processo de sua criação
Minha experiência pessoal é que a vida fica melhor quando você discute por escrito:
- demandas
- Projeto
- realização
- processos de trabalho
- sugestões e problemas
Na prática, isso nem sempre é 100% possível.
Então, quando algo da lista acima for discutido ao vivo, os resultados da discussão devem ser registrados.
Por que isso é necessário?
A fim de resolver os seguintes problemas nas equipes internas:
- Sempre: os gerentes pensam que têm um dedo no pulso, mas na realidade eles praticamente não veem como a equipe está indo. Tudo o que pode ser detectado ao se comunicar em chats em grupo é praticamente inacessível no formato ao vivo
- Frequentemente: as decisões são tomadas na sala de fumantes, que não são transmitidas a todas as partes interessadas
- Às vezes: a discussão de questões de trabalho é acompanhada por conversas sobre "nada" em grande número
Como configurar um messenger?
Para que os canais sejam convenientemente ordenados, usamos um sistema de prefixo.
Como nossa equipe está envolvida em projetos diferentes, criamos um prefixo para cada projeto e o usamos nos nomes dos canais.
Por exemplo, temos 2 projetos - GoldFixing e Aurrency. Para esses projetos, usamos os seguintes prefixos: gf para GoldFixing e aurm para Aurrency. Então, todos os canais associados com GoldFixing começarão com o prefixo gf_ e se parecerão com gf_somechannel. Da mesma forma com Aurrency - os canais serão parecidos com aurm_somechannel.
Ao mesmo tempo, também pode haver muitos canais dentro do projeto. Para organizá-los, criamos uma categorização dos canais de acordo com sua finalidade. E para cada categoria, eles têm seu próprio prefixo.
Os canais podem ser divididos em 4 categorias:
1. Mercearia
Esses são canais dedicados aos produtos criados no projeto.
Prefixo: prdct_
Os canais nesta categoria discutem todos os problemas que de uma forma ou de outra se relacionam com este ou aquele produto.
Assim, se no âmbito do projeto GoldFixing são criados dois produtos - uma plataforma e um back office, então para eles criamos os seguintes canais:
- gf_prdct_platform
- gf_prdct_backoffice
2. Informação
Os canais desta categoria não se destinam à comunicação, mas sim à divulgação de informação.
Prefixo: info_
Os canais desta categoria recebem todos os tipos de notificações e mensagens para fins organizacionais. Por exemplo, as notificações do gerenciador de tarefas vêm exatamente aqui.
Assim, se usarmos JIRA no projeto GoldFixing, teremos o canal gf_info_jira.
3. Equipe
São canais dedicados a equipes com base em suas profissões.
Prefixo: equipe_
Os canais nesta categoria discutem questões que estão vinculadas a uma disciplina profissional específica (frontend / backend / etc) e não relacionadas a outras disciplinas.
Por exemplo, se houver vários desenvolvedores de front-end no projeto GoldFixing, teremos um canal gf_team_frontend.
Se as mesmas pessoas estiverem envolvidas em vários projetos, você pode omitir o prefixo do projeto e simplesmente nomear o canal - team_frontend.
4. Temporário
Estes são os canais nos quais você deseja discutir algo com o qual não deseja carregar pessoas não relacionadas.
Prefixo: tmp_
Por exemplo, se no projeto GoldFixing é necessário discutir a compra de copos com o logotipo do projeto, então criamos um canal gf_tmp_brand-cups.
Se você precisa discutir algo que não está vinculado a um projeto específico, omitimos o prefixo do projeto.
Configuração básica de canais de informação
Apesar de essa configuração ter sido feita para a equipe de TI, acho que algo pode ser emprestado por equipes que não são de TI.
- gf_info_general - para tudo relacionado à parte organizacional: declarações, acordos de fixação e processos. Normalmente dirigido a todos e requer uma resposta de todos.
- gf_info_daily - aqui todos cancelam a assinatura de suas mensagens diárias
- gf_info_changelog — , //wireframes/api , - - , Change Report , , ,
- gf_info_jira — JIRA
- gf_info_confluence — Confluence
- gf_info_deploy — . :
— Instance — Repository —
— Branch —
— Pipeline — gitlab
— Job — gitlab
— Triggered by — Slack ,
— Commit — - gf_info_sentry — Sentry
- team_backend — backend
- team_dlt — DLT
- team_frontend — frontend
- team_qa — QA
Advanced JIRA
Se você derramar notificações sobre tudo o que acontece no JIRA em um canal, o canal se transformará em uma confusão de mensagens.
Para fazer isso, ajustamos as notificações e criamos não um, mas vários canais para o JIRA:
- gf_info_jira_comments - para notificações de comentários no JIRA
- gf_info_jira_qa - para notificações de controle de qualidade sobre a aparência de tarefas prontas para teste. Este canal tem apenas QA e um gerente
- gf_info_jira_qa_verdict - para notificações sobre a transferência de ingressos do status “TESTE” para “CONCLUÍDO” ou “REWORK”
Configuração avançada de notificações do Sentry
Temos várias instâncias de projeto (estandes) em cada projeto:
- Dev stand - significa desenvolvedores
- Bancada de teste - bancada para testadores
- Posição de lançamento - uma posição para executar candidatos a lançamento
- Stand de produção - stand de produção
Para cada um deles, criamos um canal de sentinela separado.
E para que os desenvolvedores de front-end não se mexam quando ocorre um erro no back-end e vice-versa, eles também dividem esses canais em grupos de front-end / back-end.
Acontece que:
- gf_info_sentry_back_dev
- gf_info_sentry_back_test
- gf_info_sentry_back_release
- gf_info_sentry_back_prod
- gf_info_sentry_front_dev
- gf_info_sentry_front_test
- gf_info_sentry_front_release
- gf_info_sentry_front_prod
Assim, as frentes não se movem devido a erros no backend e vice-versa.
Para posições diferentes, a urgência diferente da resposta dos desenvolvedores é aceitável.
Devido ao fato de que a instância de produção do projeto está localizada em um cluster e todas as outras instâncias em outro, estamos pensando em como agrupar canais por clusters e obter:
- gf_info_sentry_back_dev-cluster
- gf_info_sentry_back_prod-cluster
- gf_info_sentry_front_dev-cluster
- gf_info_sentry_front_prod-cluster
Exemplo de organização de canal
Perguntas para o público
- Quais regras de comunicação você adicionaria às que listei?
- Que outras coisas úteis você pode configurar / usar no messenger no nível de toda a equipe?