Team & Task Management

This guide below describes in details everything that needs to happen before, during and after some task is planned and executed. This document should be used by managers while managing the team, and each team member must read it to understand what is expected.

Important

  • Usar papel e caneta (nenhuma tecnologia substitui um bloco de notas físico e uma caneta)

  • Primeiro pit stop será realizado duas horas depois do alinhamento inicial e o segundo pit stop 2 horas depois do primeiro

  • Sempre usar VOZ, nunca usar comunicação 1-to-1 (NUNCA USAR CHAT)

  • Antes de sair, a equipe deve primeiro deixar um status por voz e depois por texto no canal #status

  • Sempre exigir que as pessoas estejam com todas as informações antes de pedir ajuda (log, path, caminho para executar o erro)

Before starting any new task

  • Pensar no objetivo da tarefa

  • Se questionar se a tarefa é importante e esse é o melhor momento para realizá-la

  • Essa é a melhor pessoa indicada pra fazer essa tarefa? (levando em consideração a experiência dela ou com o que ela já mexeu)

  • Detalhar o máximo possível a tarefa a ser passada

  • Passar em conjunto com a pessoa os passos de implementação.

  • Com base no roteiro pré-definido pensar em perguntas específicas

    • Encaixar as perguntas no roteiro de perguntas gerais

  • Perguntas de validação:

    • Me conta o que você entendeu com o objetivo dessa tarefa?

    • Me conta quais são os passos de implementação de tarefa

    • Você tem alguma dúvida sobre qualquer ponto abordado no que te foi passado?

    • Olhando o que tem que ser feito, você acha que falta algum conhecimento sobre a linguagem ou código para realizar essa tarefa?

    • Tem alguma sugestão do que poderia ser diferente nessa tarefa?

    • Dado o objetivo da tarefa essa é a melhor forma de implementar?

  • Cobrar a criação do planejamento com base no template e validar o planejamento.

  • Dado o tempo estimado pela pessoa, validar com o tempo que o líder estimou e, se não estiver próximo, falar porque eu acho que ele consegue fazer naquele tempo estimado pelo líder.

  • Entrar em um consenso sobre o tempo de implementação

After the task was initiated

  • Durante o alinhamento, entender em que passo a pessoa está:

    • Se tiver travado com duvida e se fizer muito tempo, perguntar porque não tirou a dúvida e de fato perguntar qual é a dúvida.

    • Se tiver demorando mais do que o esperado, garantir que ela esta fazendo a coisa certa, pedir pra explicar a linha de raciocínio que ela usou pra chegar até onde ela esta e a linha de raciocínio que ela pretende usar até o fim (linha de raciocínio = fluxo de código).

  • Dado o planejamento, garantir que a pessoa está no prazo e, se não estiver, verificar porque não está sendo cumprido.

    • Falta de conhecimento?

    • Dúvida não tirada?

    • Falta de interesse?

    • Se for uma deficiência técnica:

      • Por que não pediu ajuda? Por que não percebeu antes? Não pensou na tarefa? Não perguntou no alinhamento?

      • Passar material de estudo ou fazer workshops;

      • Caso seja uma deficiência técnica simples, tentar ajudar ela a sair do travamento;

      • Caso alguém da equipe saiba, pedir para que essa pessoa ajude quem está com dificuldade ou, em último caso, realocar a tarefa para outra pessoa;

      • Caso ninguém da equipe saiba, comunicar ao Gabriel e deixar a tarefa ON HOLD até que alguém da equipe obtenha o conhecimento. (escolher uma pessoa para estudar esse conhecimento e passa-lo no melhor momento dado o planejamento, se perceber que é um conhecimento que serviria pra toda a equipe organizar um workshop)

    • Se for falta de alguma habilidade geral (soft skill):

      • Por que não pediu ajuda? Por que ainda não foi resolvido? Quando e quais as ações concretas para resolver esse problema?

      • Tentar ajudar perguntando porque ela ainda não tem aquela habilidade e como ela poderia adquiri-la

      • Se for recorrente avisar ao Gabriel quanto a essa postura.

    • Se for desinteresse ou má vontade:

      • Por que está na Simbiose?

      • Notificar o Gabriel para que tire a pessoa da equipe

    • IMPORTANTE: Caso exista a necessidade de pedir ajuda a um outro programador, chamar as 2 pessoas envolvidas para a mesma sala e solicitar que a pessoa com dúvida explique de forma objetiva qual é o problema, para que a pessoa que está tirando dúvida perca menos tempo.

  • Caso o gestor perceba que o planejamento está errado, por algum dos motivos abaixo:

    • Perceber que a tarefa não faz sentido no contexto atual;

    • Chegou em um momento que é impossível ou não é produtivo prosseguir;

    • A tarefa certamente vai estourar o prazo definido ou tem algum risco de isso acontecer.

    • Ação: conversar juntamente com o Gabriel e o João sobre o planejamento.

  • Cobrar mais status durante o desenvolvimento, para evitar tarefas escritas da forma errada

    • Cobrar que tirem dúvidas imediatamente após estar travado por 30 minutos e tendo tentado 3 approaches diferentes para resolver o problema (de 10 minutos cada).

    • Cobrar lista das hipóteses

    • Cobrar lista das formas de validar as hipóteses

    • Cobrar lista das soluções

  • Cobrar o uso das ferramentas de produtividade:

    • Alias

    • Atalhos dos IDEs

    • Atalhos do terminal

  • Sempre tentar forçar que a própria pessoa entenda uma duvida ou uma tarefa, fazer perguntas para que a pessoa chegue na própria conclusão;

  • Dar um feedback para o Gabriel sobre atrasos recorrentes das pessoas nos desenvolvimentos das tarefas;

  • Não aceitar o não conhecimento sobre qualquer módulo ou parte do SlicingDice, perguntar porque não reviu o treinamento e, na hipótese de não ter sido coberto no treinamento, pensar se vale a pena criar um workshop para toda a equipe

When task is finished

  • Cobrar a execução do script de validação definido no template de planejamento;

  • Garantir que o branch dela está atualizado com develop

  • Verificar se a documentação no código e wiki foram atualizadas, em decorrência das mudanças feitas no código

  • Perguntar se o profiler foi passado, se foram identificados pontos de melhoria e se esses pontos foram corrigidos

  • Perguntar se verificou o coverage do código que foi modificado ou introduzido, cobrar que os testes unitários passem por todas as linhas modificadas

  • Se a tarefa foi sobre uma otimização, cobrar um report com o ganho ou a perda que a otimização gerou

  • Garantir que o self-review já foi feito

  • Garantir que todos os testes do CircleCI estão passando, assim como da máquina local

  • Pedir o link do Pull Request e que este seja passado no canal e não no 1-to-1

Other things

  • Não ser compreensivo com falhas claras, como:

    • Priorização errada de tarefas

    • Falta de qualidade

    • Ultrapassar tempo planejado sem justificativa clara ou sem ter pedido ajuda

  • Bater varias vezes nas mesmas teclas (organização, disciplina...)

  • Sempre anotar pontos de deficiência nas pessoas para no futuro tomar ações necessárias

  • Colocar um TODO nos códigos que são comuns de duvidas ou que são de difícil entendimento para que possam ser detalhados melhor ou serem cobertos em um treinamento

  • Não aceitar que as pessoas fiquem sem fazer nada, sempre tem que se alinhar, prestar atenção nas pessoas que estão IDLE

  • Se um erro de atitude e/ou comportamento estiver acontecendo repetidamente perguntar porque a pessoa acha que isso está acontecendo e se continuar ocorrendo comunicar ao Gabriel

  • Ser objetivo (direto ao ponto) e cobrar objetividade

  • Anotar no papel atrasos no planejamento.