Como você acompanha o que você e sua equipe estão trabalhando no dia-a-dia?

Eu falo com eles.

A tecnologia não pode resolver problemas sociais. Você tem pequenos levantamentos matinais. O que você fez ontem? O que você vai fazer hoje? Quaisquer impedimentos?

Se algo parece estranho (ou estou curioso), paro e faço perguntas: "Você estava trabalhando na XYZ ontem, como foi?". Isso força as pessoas a prestar atenção e realmente saber o que está acontecendo. Também mantém o líder da equipe no circuito (e prestando atenção e sabendo realmente o que está acontecendo). Esse precisa estar no horário e curto (10 minutos max ). Qualquer outra coisa e pessoas não "arquivam" o trabalho. Eles vão parar e esperar pelo standup e, em seguida, ter tempo para começar de novo. Alguns farão isso de qualquer maneira, mas é inevitável.

Então eu paro na mesa de todos à tarde. Não todas as tardes (embora possa ser mais do que todas as tardes para pessoas novas), não ao mesmo tempo, mas quase ao mesmo tempo (por isso é informal e regular). "Algum problema? Quaisquer impedimentos?"

Você ficará surpreso com a frequência com que encontrará problemas quando as pessoas forem uma a uma.

Se as pessoas não tiverem problemas, ótimo; Volta para o trabalho. Se eles não têm problemas toda a semana ? Problema. Você não está desafiando-os o suficiente, ou eles não estão se abrindo. Pergunte como XYZ (que eles mencionaram em standup) está indo. Faça-os explicar coisas.

Isso não é microgerenciamento. Você não está dizendo a eles como fazer o trabalho deles. Você não está cuidando deles. Você está lá para remover os impedimentos do seu dia a dia. Você precisa de informações para fazer isso. Contanto que você mantenha sua equipe fora das reuniões e os gerentes de projeto de seus cubos, então uma pessoa parando para ajudar uma vez por dia não vai causar-lhes tristeza. Mas todas essas interações precisam vir da veia "Estou aqui para ajudá-lo".

Outra coisa que vou fazer é rever changesets (sozinho, informalmente). Posso ver com que frequência as pessoas fazem check-in, o tamanho de suas alterações, como isso corresponde ao que relataram, com que frequência eles refazem as coisas, quantas correções de bugs têm e assim por diante. Um item de trabalho que altera o status para "concluído" é quase sem sentido. Olhe o código. Parece feito?

nota: Um ponto extremamente sério: qual é o tamanho da sua equipe? São mais de 7 pessoas? É claro que você não será capaz de acompanhar tudo o que acontece se o seu time for muito grande.

Não microgere seus desenvolvedores!

O desenvolvimento de software produtivo requer longos períodos de esforço mental concentrado. Não é realista esperar que eles produzam resultados constantes. Se você começar a medi-los diariamente, eles reestruturarão seu trabalho para que eles sempre produzam alguns artefatos discerníveis para você ver todos os dias. Isso pode ou não ter um impacto positivo na qualidade do seu software. Isso quase certamente terá um impacto negativo na eficiência de seus desenvolvedores.

Como Robert Harvey sugere , não faça o microgerenciamento da sua equipe. Dê à equipe algumas tarefas prioritárias com valor comercial concreto e deixe sua equipe descobrir melhor como fornecer esse valor comercial.

Se a equipe fornecer valor comercial, você deve ser feliz. Como eles se certificam de que entregam os recursos solicitados devem estar com eles.

No entanto:

Cards will stay in progress for days on end without an update at the daily stand-up

Isso poderia indicar que há uma deficiência no processo.

Poderia ser a equipe que não está realmente funcionando como uma equipe e não se interpor para ajudar uns aos outros quando estão presos. Também poderia ser a comunicação com o negócio. As tarefas são muito grandes, então fica difícil descobrir o que é necessário. Especificações não são claras.

Também pode ser que não exista nenhum problema real. Talvez a equipe trabalhe bem com cartões representando trabalhos importantes que levam dias para serem concluídos, e talvez a equipe esteja trabalhando bem para conseguir isso.

Acho válido usar a retrospectiva como uma plataforma para expressar sua preocupação. Às vezes é bom receber observações do lado de fora.

Mas deixe a equipe descobrir se há um problema e qual é a causa disso. E esteja pronto para aceitar que talvez você precise ajustar a maneira como as tarefas são entregues à equipe.

Lembre-se de que o apoio diário é uma ferramenta para a equipe ajudá-los a organizar o trabalho; NÃO é uma ferramenta para os gerentes acompanharem o que a equipe está fazendo.

'Envio de mensagens' e não 'envio de mensagens'

Um desenvolvedor costuma chegar a um dos seguintes estados que são importantes para você:

1. Yaaay, eu fiz X!
2. Estou trabalhando no X, mas parece que vai demorar muito tempo ...
3. Estou preso ao problema Y, estou pesquisando, mas preciso de conselhos;
4. Estou bloqueado porque estou esperando por A, B e C.

O ideal é que você tenha informações razoavelmente atualizadas sobre esses status sem interromper a produtividade real. Constante "Já chegamos lá?" é contraproducente, mas pode ser que você possa fazer algo útil para os estados 2-4, então você precisa se informar sobre eles.

O que vai funcionar é uma cultura de 'push messaging', preferencialmente de forma automatizada. Talvez você não precise examinar todo o log de confirmação, mas é possível criar um "painel de controle" no qual você vê o último commit ou o último ticket resolvido (para bugs ou recursos) de cada membro da equipe. Para o resto das situações, você pode fazê-las enviar e-mails proativamente com tais atualizações (esperamos que sejam mais raras do que commits) ou perguntar se você não está vendo progresso contínuo em qualquer painel - se você tem um acordo interno de que ficar preso precisa ser levantado (pode ser que algum recurso não seja necessário se o custo for de 80 horas e não 8 horas), ou então eles vão mantê-lo atualizado ou incomodado por você.

Alternativamente, você pode fazer uma cultura de algo como link relatórios diários que vão para toda a equipe - isso vai garantir que os outros estejam na mesma página também.

Uma alternativa para algumas das outras respostas (comunicação focada) é que talvez as tarefas em seus cartões de nota possam ser divididas em partes menores , nas quais você poderá obter feedback mais cedo.

Com peças menores, a equipe se sente como se estivesse realizando algo todos os dias , o que deve refletir no stand-up.

A desvantagem é que esses cartões separados provavelmente dependem muito um do outro. Uma equipe que é capaz de se comunicar muito facilmente entre si é benéfica aqui, ou as peças podem não combinar tão bem quanto deveriam. Você também pode precisar reter algumas das cartas se precisar que certas coisas sejam feitas primeiro.

Dito isto, as pessoas ainda ficarão presas ou descobrirão que uma tarefa é muito mais desafiadora do que elas, ou você, antecipada de tempos em tempos. É por isso que ainda é útil discutir questões abertamente no stand-up, onde outras pessoas podem oferecer conselhos sem julgar a pessoa com problemas.

Para responder à questão da microgestão como algumas das outras respostas surgiram: mesmo que as pessoas realizem pequenas tarefas todos os dias, será necessária uma visão mais ampla do trabalho realizado para obter uma perceber o quanto cada pessoa realmente está sendo realizada, em vez de julgá-las por suas realizações diárias.

Eu sugiro isso porque eu trabalho em uma equipe de 8 pessoas, onde a comunicação é muito fácil e as pessoas são muito acessíveis. Recebemos tarefas que nunca devem demorar mais do que dois dias de trabalho. Às vezes, essas tarefas estão intimamente relacionadas e precisamos nos manter atualizados sobre como cada um de nós aborda nossa própria obra. Cada um de nós é responsável por relatar o que realizamos a cada duas semanas ao nosso gerente.

Depois de ler a pergunta novamente, percebo que você pode estar perguntando isso como um membro da equipe, não como um líder e, portanto, você pode não ter controle sobre suas tarefas.

1. Você poderia sugerir ao seu líder para dividir as tarefas mais
2. Se o seu trabalho estiver sendo bloqueado ou depender do trabalho de outro membro da equipe, sinta-se à vontade para consultá-lo e realizar uma tarefa diferente, se necessário.

O ponto comum em ambos os casos é que você precisa ser capaz de facilitar sua equipe e criar a sensação de que você confia neles. Você não está julgando seu desempenho, mas está tentando ser compreensivo e prestativo em tornar sua experiência divertida e fácil.

Agora suponha que você é apenas um gerente, como eu disse acima, nesse caso, mesmo que algum desenvolvedor esteja realmente enfrentando algum problema sério relacionado ao desenvolvimento, você pode não ser capaz de ajudá-lo. O problema real pode ser demorado e exigirá concentração também. Além disso, assumindo que o desenvolvedor é realmente sincero ao seu trabalho e pagando em tempo integral (até mesmo tempo extra) para resolver esse problema, mas infelizmente ainda não é capaz de resolvê-lo. E em tal situação (quando você não é capaz de compreender completamente o problema), você continua perguntando sobre o assunto, tendo progresso todos os dias e até informalmente, duas vezes por dia. O resultado seria extrema frustração e perturbação para o desenvolvedor. Quer seja um aplicativo para reunir o progresso diário ou a sua reunião diária apenas em pé, ambos podem ser frustrantes.

Por outro lado, mantendo todos os outros fatores iguais, apenas suponha que você tenha uma sólida formação técnica e tenha trabalhado nas mesmas tecnologias no passado. Nesse caso, fazer progresso diário ou ter reuniões em pé é realmente útil. Os desenvolvedores certamente confiarão em você e em seus conhecimentos e se sentirão à vontade para discutir o grande desafio que estão enfrentando. Você fornecerá algumas sugestões que podem ser úteis ou, mesmo que não sejam diretamente úteis, ajudarão a fornecer algumas abordagens alternativas.

No entanto, as reuniões stand-up diárias em qualquer caso devem criar uma sensação de que você é um membro da equipe e não um chefe / líder / gerente. A menos que os membros da sua equipe considerem você no mesmo nível em que estão, eles não poderão comunicar suas preocupações / sugestões / problemas / comentários etc. Outro ponto a ser considerado é o tamanho de sua equipe e o tempo que você tem para gerenciá-los, antes de pensar em usar algum software de rastreamento de progresso automatizado ou aumentar sua interação. Você precisa ter certeza de que quaisquer preocupações levantadas por sua equipe, você é capaz de resolvê-los o mais cedo possível. Um grande fator de desmotivação para um membro da equipe é que suas preocupações / sugestões / feedback não são levadas a sério ou não são valorizadas. Conhecer o progresso diário é importante, mas apenas no caso de você estar totalmente envolvido no trabalho em equipe. Se você também estiver envolvido em algumas empresas paralelas, não tente interagir mais com sua equipe. Pense em uma situação em que a resposta de sua equipe é esmagadora e eles estão enviando suas tarefas bem antes do tempo, levantando preocupações e perguntas, mas você não consegue fornecer feedback e resenhas em tempo hábil. Em tal situação, sua influência como líder de equipe será bastante reduzida

Crie e faça bom uso de várias salas de bate-papo de mensagens instantâneas para as várias configurações. Alguns podem ser amplos como @engineers e alguns podem ser específicos, como @newFeatureA

Considere fazer uma apresentação diária incluir uma revisão de bilhetes em voo.

Use um ambiente aberto que ofereça suporte à colaboração e certifique-se de que o QE e o proprietário do produto principal estejam no meio dos desenvolvedores. Você vai ouvir muito e ter uma ideia de ver telas ao seu redor.

Como Robert ressalta, acima de tudo, não se deve considerar o microgerenciamento (observe o uso de "ser visto", isto é, independentemente de sua intenção real).

Estou surpreso que ninguém aqui tenha mencionado mensagens de repositório "seguidas" ou "marcadas com estrela" embutidas em sistemas como o GitHub ou o BitBucket.

Nossas partes interessadas técnicas (líderes de projeto, gerentes de desenvolvimento e suporte) seguem nosso problema e confirmam históricos de atualização sobre seus projetos relevantes. Nós temos uma pequena equipe (15 FTE + contratados), mas isso parece funcionar para nós

Ninguém é avaliado em nenhuma dessas coisas, mas além dos relatórios de status semanais das PMs, isso dá uma visão diária do projeto para, pelo menos, manter todos conscientes de quais áreas estão sendo trabalhadas, de modo que ninguém fique sem visibilidade.

Ele também ajudou a aumentar a transparência entre desenvolvedores e contratados e nossos contatos comerciais, o que ajuda a todos a prestar contas aos seus agendamentos de entregas.

Quando combinados com feeds RSS associados a repositórios específicos ou em toda a nossa organização, conseguimos limitar os e-mails (quando desejado) e oferecer um conjunto semelhante de dados em tempo real e, em resumo, por meio de leitores de RSS. Para alguns usuários, isso é o Outlook, então é basicamente um e-mail para eles, embora um pouco diferente, mas para outros usuários eles usam um cliente RSS completo com toda a filtragem extra necessária para personalizá-lo de acordo com suas necessidades.

Tivemos algumas preocupações semelhantes sobre o volume de e-mail, mas nossos usuários finais criaram o sistema RSS sem que a Org. de Engenharia fizesse muito além de sugerir clientes para aqueles que não usam o Outlook. Trabalhou para nós, mais uma vez em torno de 20-30 FTE + Contractors ao longo do ano em vários escritórios e fusos horários. YMMV, obviamente.

Esta é uma adição muito marginal (e não é específica do programador), mas eu tive um bom sucesso com Asana em recentes projetos.

Para integração com ferramentas de colaboração on-line existentes, não procure mais que Slack . Ele é construído em torno de uma sala de bate-papo, mas serve como um hub bastante minimalista para outras ferramentas, incluindo Asana, GitHub e Bitbucket. Ele tem uma coleção decente dessas "integrações", ambas pré-criadas e feito pela comunidade , usando a API que, claro, permite que você construa o seu próprio.