De 23 a 24 de setembro, o
Saint TeamLead Conf 2019 foi realizado em São Petersburgo. Flant participou ativamente: Igor Tsupko (nosso diretor desconhecido) realizou uma reunião em que os participantes entenderam como encontrar e revelar conhecimentos secretos dentro da organização, e Sergey Goncharuk (gerente de projetos) fez uma apresentação “Gerenciando uma equipe distribuída em multi-projeção ". Por tradição, publicamos uma revisão do relatório e
seu vídeo (~ 37 minutos).
"Equipe distribuída" e "multiprojeto"
Sob uma equipe distribuída, diferentes empresas entendem coisas muito diferentes - por exemplo, uma rede de filiais ou escritório e funcionários remotos ... Mas, no nosso caso, não há escritório no sentido "real".
Agora, temos mais de 80 funcionários que moram em mais de 20 cidades da Rússia e além. A maioria de nós se vê “viva” apenas 2 dias por ano, no aniversário da “Flanta”.
O resto do tempo em que moramos em Moscou, Samara, Tyumen, Nizhny Novgorod ou qualquer outra cidade, trabalhamos com canto de pássaros ou com cheiro de café. Em vez de alugar um lugar, investimos dinheiro em algo realmente útil. E como todo mundo trabalha remotamente, não temos uma divisão em "ramos" ou "castas".
E o mais importante - contratamos os melhores, apesar de todos os limites! É isso que "distribuição" em nosso entendimento significa.
Vamos agora lidar com o design múltiplo, mas, para começar, é importante mergulhar um pouco no dispositivo Flanta.
Somos uma empresa de engenharia, temos muitos engenheiros. Cinco a sete engenheiros, sob a orientação do líder e gerente da equipe, compõem a equipe. Existem várias equipes e cada equipe tem seu próprio conjunto de projetos.
Para nós, um projeto é uma infraestrutura de cliente para um produto ou uma equipe de desenvolvimento. Ou seja, o projeto tem limites claros, mas não há restrições ao crescimento e desenvolvimento!
Cada projeto tem suas próprias necessidades, que precisam de alguma forma transmitir à equipe.
Isso é feito pelo gerente. Estes são os princípios básicos do "design múltiplo".
Agora que temos um entendimento comum dos termos do título do relatório, a questão é: o que é necessário para garantir que, nessas condições, tudo não funcione apenas, mas funcione bem?
O gerente da equipe é responsável por resolver esse problema. Ser um "tradutor" do cliente para a engenharia é uma de suas principais competências. O segundo é a organização da comunicação construtiva dentro da equipe e com os clientes. E a terceira competência principal é encontrar um equilíbrio entre o fluxo de trabalho e as reais capacidades dos engenheiros:
Analisaremos cada competência em mais detalhes.
1. Expectativas de transmissão
Mesmo o mesmo cliente pode ter expectativas conflitantes. Por exemplo, os negócios de um cliente exigem que a produção produtora de dinheiro seja estável. Além disso, era constantemente reabastecido com novos recursos que ajudam a aumentar a receita.
Bem, se ocorrer um acidente (a empresa está pronta para o acidente), ela será eliminada o mais rápido possível. Isso parece muito previsível, certo?
Mas este cliente também tem desenvolvedores. E suas expectativas, ao que parece, são completamente diferentes! Para os desenvolvedores, o dev é mais importante do que a produção (afinal, os negócios também os pressionam), e eles também esperam que qualquer solicitação seja ouvida e feita no momento (geralmente isso é descrito pela frase "afinal, são 5 minutos”).
A única coisa que une negócios e desenvolvedores em requisitos é que ambos esperam que as tarefas planejadas sejam executadas com precisão e dentro do prazo.
Vejamos a foto como um todo ... Sim, ela está imediatamente cheia de parágrafos mutuamente exclusivos!
- A adição de novos recursos sempre adiciona novos pontos de falha. Babah! E a produção é instável após o lançamento de sexta-feira.
- Nossos engenheiros realizaram o mais rápido possível durante o dia tudo o que os desenvolvedores solicitavam e as tarefas planejadas permaneceram intocadas por causa disso.
- Ou aqui está a história: em qual ambiente de estabilidade prestar mais atenção? Nós estabilizamos o desenvolvedor alocando recursos para isso, mas após outro lançamento, a produção começou a cair!
- Um caso frequente: a produção quebrou e toda a equipe foi consertá-la. Ao mesmo tempo, é claro, não há progresso nas tarefas planejadas, e mesmo os desenvolvedores da Índia já mudaram para o bate-papo no idioma russo no bate-papo, porque mal podem esperar por uma resposta.
E entendemos que os requisitos em si são contraditórios, o que significa que é impossível transmiti-los diretamente.
2. Comunicações
Realmente há problemas em transmitir expectativas. Bem, talvez pelo menos com as comunicações tudo fique mais fácil?
Para nos comunicarmos com os clientes, usamos o Slack para texto e o Google Meet para reuniões e ocasiões em que é mais fácil falar do que escrever. Porém, em um bate-papo, geralmente recebemos mensagens que não possuem um significado útil ou contêm tantos erros que é difícil reconhecer o significado!
Por que prestamos atenção a isso? O fato é que, por exemplo, somente em julho de 2019, recebemos solicitações de 1993 dos clientes da Slack, exigindo uma resposta obrigatória. E, é claro, com o crescimento do número de clientes, há uma tendência constante no crescimento do número de solicitações. Em julho, gastamos cerca de 165 horas de engenharia na reação a essas ligações. Mas para cada recurso, também era necessário fazer alguma coisa!
Lamentamos muito o desperdício de tempo dos engenheiros, que poderiam ser investidos em tarefas planejadas, reação a outras ligações ou mesmo para reparar acidentes.
O problema com as salas de bate-papo é óbvio, mas a videoconferência provavelmente não tem problemas?
Dissemos acima que usamos o Google Meet para comícios diários da equipe e, durante o resto do tempo, fazemos as tarefas que resolvemos no comício. Todos os dias passamos cerca de uma hora em comícios. Tentamos gastar pelo menos sete horas por dia em trabalho direto, ou seja, restam 6 horas para concluir as tarefas. Mas nossas tarefas têm duração muito diferente.
Acontece que em uma hora do rali poderíamos concluir várias tarefas pequenas, mas provavelmente importantes para as tarefas de nossos clientes. E precisamos entender se assistir às reuniões é realmente necessário ou é melhor ir trabalhar desta vez?
Se você tentar reunir os problemas de comunicação, veremos que o bate-papo gera interrupções inúteis e comícios regulares "consomem" o tempo de trabalho.
Comunicações eficazes não se alinham por conta própria.
3. Planejamento
Bem, precisamos resolver problemas de comunicação e expectativas de transmissão, mas no planejamento, provavelmente, não há armadilhas? Vamos descobrir.
Todos os dias, um grande número de novas tarefas é criado. Gostaria que fechassemos as tarefas o mais rápido possível. Mas na vida, um ideal raramente é atingível. Em primeiro lugar, às vezes algo quebra na infraestrutura. Em segundo lugar, sempre existem algumas pequenas coisas que são mais fáceis de fazer imediatamente. Em terceiro lugar, há tarefas que concordamos em resolver em um comício:
E às vezes acontece que, por causa de acidentes e puxões em ninharias, não é possível chegar aos planejados! Ao mesmo tempo, novas tarefas não param de chegar - todos os prazos prometidos estão quebrados.
Nossa receita
Mas, com todos os problemas com a tradução de expectativas, com as comunicações e o planejamento, o método de encher cones, conseguimos obter, ao que parece, a resposta correta.
Um dos principais processos de negócios que afetam as três principais competências é uma reunião de equipe. E tínhamos a suposição de que, se tornarmos uma reunião de equipe eficaz, podemos alcançar 80% do resultado com vinte por cento do esforço? Nós testamos essa teoria.
Como você se lembra, temos uma equipe atendendo nosso conjunto de projetos. E ela tem uma certa lista de requisitos desses projetos. Mas cada requisito, como regra, é apenas um em uma cadeia de tarefas inter-relacionadas. E assim em todos os projetos! E antes de assumir uma nova tarefa, precisamos entender se concluímos o estágio anterior?
Ontem, a tarefa A-1 foi realizada por Egor, a tarefa B-1 - Semyon e a tarefa B-1 - Jeanne. Mas como podemos mergulhar todos os engenheiros em todos os projetos tão profundamente que Yegor consegue lidar com a tarefa B e Semyon com duas pequenas tarefas A e B. "Por que todas essas dificuldades?" - você pergunta. Sim, o fato é que Zhanna não cumprirá tarefas planejadas nas férias hoje!
Nosso foco são muitas tarefas semelhantes. Em média, recebemos cerca de 25 novas tarefas para cada equipe todos os dias úteis. E, como existem muitas tarefas, as conexões entre elas são confusas e não há entendimento se todas as tarefas do dia anterior foram concluídas. Para desvendar tudo isso, precisamos de uma reunião de equipe e, todos os dias úteis, caso contrário, não conseguiremos gerenciar esse fluxo.
Dado o volume do fluxo, vale a pena se preparar para o rali com antecedência. No treinamento, sem engenheiros, não seremos capazes de entender quais tarefas foram completamente concluídas e quais não. E, é claro, não poderemos transferir conhecimento de engenheiro para engenheiro. Mas somos inequivocamente capazes de determinar as prioridades para levar novas tarefas ao trabalho.
Priorização de tarefas
Em que nos baseamos ao priorizar tarefas? Primeiramente, temos acordos estratégicos com o cliente sobre os objetivos que precisam ser alcançados. Em segundo lugar, uma vez por semana, atualizamos os planos táticos para uma reunião on-line com o cliente. As necessidades do cliente em preparação são atendidas pelo gerente, e a necessidade técnica e o procedimento para concluir uma ou outra tarefa é o líder da equipe. É isso mesmo, com base na
paridade das opiniões do líder e gerente da equipe , uma lista de tarefas para o dia é formada.
Cultura de reuniões de equipe
Assim que determinamos a lista de tarefas para o dia, a fim de esclarecer o que foi feito e mergulhar nossos colegas nos detalhes, iniciamos uma reunião de equipe na qual cada engenheiro deve contar em detalhes o que ele fez ontem, e toda a equipe deve ouvir e, o mais importante, entender as mudanças que ocorreram. Mas isso é mais fácil dizer do que fazer.
Introduzimos uma série de características culturais do rali, o que nos permitiu alcançar o resultado desejado:
No início do rali, enquanto todos estão reunidos, passamos de 10 a 15 minutos conversando sobre a vida. Sobre notícias e eventos não relacionados ao trabalho, sobre hobbies de colegas. Assim, os engenheiros que estão em cidades diferentes e quase nunca se vêem se tornam amigos ou até amigos. E
esses 10 a 15 minutos por dia ajudam a equipe a se unir .
Após a conversa sobre construção de equipes, prosseguimos para a parte substantiva. Vamos voltar um pouco.
Lembra dessa ilustração? O fato é que nem Semyon nem Yegor sabem quais tarefas e projetos serão realizados hoje antes do início do rali. Por várias razões: férias, viagens de negócios, doença, dever, etc. - a tarefa pode alterar os artistas todos os dias até que seja completamente resolvida. E cada engenheiro entende que hoje uma tarefa pode ser atribuída a ela, ou seja, todos os engenheiros já estão inicialmente
interessados em se aprofundar nos detalhes de cada tarefa .
No rali, analisamos os bloqueios que surgiram por toda a equipe. Insistimos em que toda a equipe participe da solução do problema do palestrante. Por isso,
motivamos a mergulhar em tarefas e resolvê-las juntas .
Se a equipe trabalha no escritório, a comunicação informal geralmente ocorre "no ponto mais frio". Mas em uma equipe distribuída, existe a necessidade de tal comunicação. É por isso que, durante uma discussão de tarefas, a conversa geralmente vaza em algum lugar na direção errada. Mas paramos qualquer distração. Como exatamente? Conseguimos fazer isso com bastante facilidade: afinal, há um tempo especialmente alocado para conversas abstratas e agora é hora de trabalhar. Portanto, mesmo o oral usual “vamos direto ao ponto” é suficiente para que todos retornem à agenda de negócios. Ao interromper as distrações no processo de análise de tarefas,
montamos a equipe para trabalhar .
Tentamos controlar o tempo do relatório de cada engenheiro. Às vezes, para mergulhar nos detalhes, precisamos de uma história longa e detalhada sobre a tarefa. No entanto, na maioria dos casos,
tentamos não esticar o rali .
Comícios eficazes - uma bala de prata?
Graças à preparação para o rally com base na paridade das opiniões do líder da equipe e do gerente e nossas características culturais do rally, nós realmente os tornamos eficazes. Mas você conseguiu fechar 80% de todas as competências? Na verdade não.
Fizemos um bom trabalho com as expectativas de transmissão, mas ainda havia problemas com mensagens de bate-papo não informativas nas comunicações e houve interrupções no planejamento que nos impediam de executar tarefas programadas com eficiência.
Sim, mas mensagens de bate-papo não informativas também são interrupções. E precisamos encontrar um mecanismo que nos ajude a lidar com interrupções de todos os tipos com eficiência.
Combate a interrupções
Pensamos: e se tivermos uma pessoa separada que "cubra" conosco uma equipe trabalhando em tarefas planejadas a partir do fluxo de interrupção?
A ideia não é nova e geralmente boa, mas quem exatamente a fará? Consideramos duas opções: encontrar e contratar esse serviço ou usar engenheiros existentes. A busca por novas pessoas exigiu tempo e recursos financeiros, e os engenheiros existentes já foram "testados em batalha" e imersos em todos os projetos da equipe. Portanto, a opção de contratar novas pessoas foi rejeitada.
Resta decidir sobre a questão de como organizar esse serviço dos engenheiros atuais. Aqui a solução estava na superfície: eles simplesmente aplicaram suas tarefas dentro de um cronograma, com uma rotação de engenheiros da equipe. Mantemos a programação de tarefas no Google Agenda, além de configurar notificações no Slack sobre quem está de plantão hoje.
Parece que tudo deve ficar bem agora? Hooray? Não, na verdade o problema permanece. Lembre-se, um pouco antes, dissemos que apenas no Slack recebíamos quase 2.000 hits por mês, ou seja, cerca de 16 hits por dia para cada equipe. Mas, além do Slack, o atendente terá que processar mensagens dos sistemas de monitoramento e, no dia em que:
- 112 - de Prometeu;
- 16 - do okmeter;
- 25 - de sistemas externos de monitoramento de caixa preta;
- 14 - de vários scripts personalizados;
- e até 2 telefonemas de clientes.
São 198 interrupções todos os dias de fontes diferentes! Mas, de fato, existem ainda mais fontes:
- Quase todo cliente tem um Prometheus;
- e o Okmeter está instalado em cada cliente;
- mas scripts personalizados, até um cliente pode ter quantos você quiser ...
Para que qualquer engenheiro da equipe lide com isso sem mágica e superpotências, coletamos alertas de todas as fontes de interrupção em um só lugar. Chamamos essa ferramenta de Madison, e cada mensagem é um incidente.
Mas Madison apenas coleta incidentes e mantém uma fortuna sobre eles. Mas precisamos entender que tipo de incidente ocorrer primeiro, ou seja, executar a triagem, ter uma ordem clara de processamento e escalação, para que possa ser facilmente executado em uma situação estressante.
Também criamos esse instrumento - chamado Polk:
Polk é o local de trabalho do engenheiro de serviço. Ele permite que o atendente se concentre apenas nos incidentes, sem se distrair com as tarefas planejadas, receba incidentes de todas as fontes em um único local, ajuda a determinar a criticidade de um incidente de acordo com uma Gravidade predeterminada, possui um conjunto de status claramente definidos e um algoritmo de processamento que determina o movimento desses status.
Características técnicas e culturais do bate-papo
Excelente: agora o atendente, equipado com uma ferramenta tão poderosa, realmente fecha a equipe de interrupções. Mas, mesmo com essas ferramentas, o relógio é exaustivo, e interrupções inúteis apenas adicionam combustível ao fogo.
Para combater interrupções inúteis no bate-papo, podemos usar um pequeno conjunto de ferramentas técnicas, mas a principal solução para esse problema está definitivamente no plano cultural.
Do ponto de vista técnico, no Slack, compartilhamos informações sobre projetos, criando um canal separado para comunicação com representantes de clientes e, para cada projeto, um canal para os engenheiros discutirem o trabalho nele. Também escrevemos o bot
@flant , quando acessado por Polk, é criado automaticamente um incidente que o oficial de serviço processa.
Além disso, recomendamos que os clientes usem
@flant e
@channel (um evento notificando todos os membros do canal) e
@here (um evento notificando todos os membros do canal on-line) para usar somente nesses casos raros e excepcionais em que você realmente não pode ficar sem eles (por exemplo, quando o bot
@flant indisponível).
No primeiro dia de nossa cooperação com o cliente, publicamos instruções detalhadas sobre a interação no canal. E na primeira reunião regular, discutiremos definitivamente a interação, incluindo a diferença entre
@channel ,
@here e
@flant .
Em particular, focamos no fato de que a chamada para
@flant para nós, antes de tudo, é uma ação com uma reação obrigatória, e
@channel e
@here para a maioria da equipe são apenas uma interrupção, que também é sem endereço e pode ser ignorada. enquanto distrai toda a equipe da resolução de tarefas planejadas, inclusive para este projeto.
Mas novos colegas chegam ao bate-papo de clientes que não estão cientes do bot. Outros apenas esquecem. Se isso acontecer, lembramos gentilmente de sua existência.
Para comunicação entre engenheiros, usamos as mesmas regras para
@channele
@here : não os use, a menos que seja absolutamente necessário. E, no entanto, insistimos em seguir a regra "Não diga" olá "no bate-papo - formule imediatamente um pensamento". Esta regra é uma leitura obrigatória para todos os iniciantes. Quem esqueceu, será lembrado disso - se necessário, implantado.
Total: com a introdução de turnos e a correção de problemas de comunicação no bate-papo, lidamos com a maioria das interrupções inúteis e com a influência das interrupções no desempenho das tarefas planejadas.
Procrastinação e bloqueio
Verificamos como nossos indicadores melhoraram depois disso: na verdade, eles se tornaram claramente melhores, mas ainda havia um problema no planejamento.
Quando o rally da equipe termina, é hora de trabalhar. Mas frequentemente, os engenheiros, especialmente aqueles que trabalham remotamente, tendem a procrastinar. Ou, durante o trabalho, encontre um problema e ande em círculos na tentativa de resolvê-lo.
Vamos tentar lidar com a procrastinação. Como superá-lo? Existem muitas tarefas no Redmine (nosso rastreador de tarefas) - você precisa se concentrar naquelas que estarão em funcionamento hoje. E mesmo entre eles, você precisa entender quais tarefas executar primeiro, ou seja, determinar prioridades. E, idealmente, se você planejar aproximadamente o tempo que estamos prontos para gastar em cada tarefa ...
Criamos uma ferramenta que ajuda a resolver tudo isso e denominamos Ford:
É nele que o engenheiro recebe uma tarefa para o dia útil na forma de cartões organizados em ordem de prioridade. Para todas as tarefas planejadas, anotamos o tempo aproximado que o engenheiro deve aderir ao resolvê-las. O engenheiro leva em consideração o tempo gasto na solução do problema. E se o tempo for aproximadamente o mesmo, mas o problema não for resolvido, este é um marcador de que o engenheiro atingiu um beco sem saída.
O que pode ser feito com isso? Além da prioridade em que os cartões estão localizados,
também introduzimos categorias prioritárias, destacando-as com cores:
- A caixa cinza é usada para tarefas agendadas comuns;
- Campo verde - para tarefas que devem ser iniciadas no dia atual somente se as tarefas em todos os outros campos terminarem;
- O campo amarelo é para tarefas que de repente ocorreram não planejadas durante o dia;
- Campo vermelho - para tarefas que precisam ser resolvidas antes do final do dia útil atual.
Se um engenheiro é bloqueado por uma tarefa nos campos cinza e verde, ele apenas precisa iniciar a próxima tarefa e desmontar a trava na próxima reunião da equipe.
Mas é óbvio que, se um engenheiro for bloqueado por tarefas nas zonas amarela ou vermelha, não espere pela próxima reunião: você precisará pedir ajuda da equipe no canal apropriado para que os engenheiros se comuniquem no projeto em que a tarefa está definida. E, de acordo com a nossa cultura, engenheiros de equipe ou líderes de equipe serão definitivamente resgatados.
Vale ressaltar que as capacidades da Ford são muito mais amplas e tocamos apenas a "ponta do iceberg", que você pode implementar usando outras ferramentas abertas.
Sumário
Acontece que, para combater a procrastinação e o bloqueio, usamos a Ford como uma solução técnica e regras simples na cultura da equipe.
Essas ferramentas nos ajudaram? Sim Mas, por algum motivo, não 100%?
O fato é que o mundo está mudando e avançando. E também estamos mudando nessas condições, lutando pelo ideal, mas, como você sabe, é inatingível.
Para alcançar ideais e o papel de gerente
Todas as grandes coisas que a humanidade criou durante todo o período de sua existência foram feitas por equipes de profissionais que tinham gerentes legais.
Nós, Flant, também somos uma equipe de profissionais. E seria legal se houvesse mais gerentes legais em nossa equipe. Venha trabalhar conosco e ajudar a melhorar nossos processos:
Vídeos e slides
Vídeo da apresentação (~ 38 minutos):
Apresentação do relatório:
PS
Leia também em nosso blog: