Os relatórios diários podem diminuir a produtividade de um desenvolvedor? [fechadas]

Em outra pergunta , perguntei por que os desenvolvedores podem não gostar do scrum diário . Conversamos com os desenvolvedores e decidimos não realizar o scrum diário por um tempo (para experimentar e customizar o scrum em nossa primeira tentativa). Essa é a saída da consulta direta aos desenvolvedores.

Por outro lado, não queremos perder boas partes do scrum diário, como ter a chance de coordenar os desenvolvedores todos os dias ou assistir o progresso do trabalho como um Indicador Chave de Desempenho, para tomar ações antecipadamente.

Como alternativa ao scrum diário, estamos pensando em pedir aos desenvolvedores que forneçam relatórios diários com as seguintes condições:

1. Não é necessário seguir nenhum formato específico. Todo e qualquer formato é aceito.
2. Mesmo se o trabalho não for concluído, queremos ouvir a quantidade de progresso.
3. Não há necessidade de mencionar o tempo gasto em cada tarefa.
4. Os obstáculos ao desenvolvimento e os requisitos de coordenação devem ser mencionados.
5. Não há necessidade de ficar obcecado com relatórios diários. Não é tão estrito.

Você acha que isso pode diminuir a produtividade deles? Você já teve alguma experiência com relatórios diários? Você tem alguma sugestão para nós, para que possamos ter certeza de que não estamos gerenciando microgerenciamento ?

Como alternativa ao scrum diário, estamos pensando em pedir aos desenvolvedores que forneçam relatórios diários com as seguintes condições:

Que ideia terrível.

Você acha que isso pode diminuir a produtividade deles?

Sim.

Por quê? Uma apresentação verbal em uma reunião combina escrever e n pessoas "lendo" o relatório em uma atividade simultânea. Conversando e ouvindo. Acabado e acabado. Perguntas respondidas imediatamente.

Escrever um relatório é uma perda de tempo, pois haverá perguntas e você terá que revisá-lo com pessoas que (a) têm perguntas e (b) realmente não as leram.

Relatórios diários, não serão lidos. Eles rapidamente se transformam em ruído na caixa.

"Não há necessidade de ficar obcecado com relatórios diários". Nesse caso, por que eles?

Você tem alguma sugestão para nós, para que possamos ter certeza de que não estamos gerenciando microgerenciamento?

Sim. Tenha um stand-up diário. Demora alguns minutos e pronto.

Se o seu stand-up diário demorar mais do que alguns (15?) Minutos, você estará compartilhando muitos detalhes e precisará agendar reuniões separadas para esses detalhes. Os levantamentos diários são fáceis de fazer. Após um resumo de 2 minutos, tudo o resto é provavelmente detalhes, não para toda a equipe, e precisa ser levado a uma reunião de acompanhamento. A reunião passa para o foco da próxima pessoa do dia.

Eu já fiz isso no passado, mas de manhã em vez do final do dia. Geralmente, levava menos de cinco minutos para preencher, então não, não vejo como haveria uma diminuição na produtividade de um desenvolvedor. O bom de fazer isso de manhã foi que fez você pensar sobre o que vai fazer pelo resto do dia.

Tendo dito isso ...

Descobrimos que eram mais vezes do que não, não era o método mais eficaz de comunicar o que havíamos feito no dia anterior e o que íamos trabalhar naquele dia. Por quê? As pessoas geralmente não as liam. Era uma tarefa agendada do Outlook, para que todos os enviassem todos os dias, mas eles eram ignorados ou perdidos por completo (exceto por leads ou gerenciamento).

Descobrimos que ter os levantamentos diários era muito mais valioso, pois as pessoas tendiam a se ouvir. Além disso, se houvesse um mal-entendido, ele seria liberado de vez em quando, o que é mais provável que aconteça do que alguém que responde a um e-mail de status diário para fazer mais perguntas.

Com toda a honestidade, permitir que qualquer pessoa relate sem restrições parece um pouco longe demais para o lado liberal da equação. Onde trabalho, fazemos um círculo e cada desenvolvedor fornece o seguinte:

1. O que foi feito no dia anterior. Nem todos os pequenos detalhes, mas no geral.
   • Se o acima não estiver concluído, se não, o que é necessário para terminar e quanto tempo levará.
   • Se as etapas acima forem concluídas, qual é a próxima tarefa, o que é necessário e o tempo que levará.
2. Bloqueadores. Se você estiver trabalhando no Foo, que depende da barra, e a barra não estiver concluída, isso precisa ser esclarecido.

A configuração de um esquema geral para todos seguirem pode facilitar a passagem por um determinado relatório. Você pode configurar facilmente algum método para que todos recebam um email com os relatórios diários e, assim, permitir que qualquer pessoa descubra o que está acontecendo.

Na IMO, qualquer tipo de reunião / relatório diário diminui a produtividade porque, para ser franco, fede a microgerenciamento. Sim, eu conheço o Scrum e coisas do tipo e não são tão ruins, desde que sejam breves atualizações de status ("Ei, como o Projeto X está chegando?"), Mas acredito firmemente que é um insulto aos desenvolvedores profissionais manter o controle nós naquele nível mais baixo; é semelhante a usar cartões de ponto para garantir que estamos no escritório 8 horas por dia ou garantir que não haja paredes para que você possa espionar os computadores das pessoas para ver quais janelas elas abrem em um determinado momento.

Se você precisa acompanhar todos para garantir que eles estejam funcionando, isso significa que você não confia neles. Se você não confia neles, existe um problema maior no trabalho do que aquele com o qual você está se preocupando.

Minha equipe faz scrum há cerca de um ano. Antes disso, realizávamos duas reuniões por semana, durante as quais cada membro da equipe relatava sobre sua atividade nos últimos 2, 3 dias. Cada reunião durou entre 30 minutos e 1 hora. Caso precisássemos trocar informações e coordenar nosso trabalho, costumávamos ir até nossos colegas e conversar com eles (o que ainda fazemos, é claro).

Agora que estamos fazendo scrum, muitas vezes temos a impressão de que uma reunião por dia (apesar de durar apenas 15 minutos) é demais. Muitas vezes, os relatórios de alguns membros se resumem a: "Nada de novo desde ontem". Muitas vezes tivemos a impressão de que o esquema de 2 reuniões por semana era mais eficaz.

Outra desvantagem é que a reunião diária é uma interrupção planejada (veja, por exemplo, o artigo de Paul Graham , ponto 1. Evite distrações): como você sabe que a interrupção ocorrerá, você não começará nada difícil antes da reunião (as reuniões diárias podem ocorrem uma a uma hora e meia após o início do trabalho).

Por último, mas não menos importante, embora o feedback inicial tenha vantagens ("Ah, você está trabalhando nesse problema, devemos discuti-lo!"), Às vezes é mais eficaz iniciar uma discussão somente quando você já tiver organizado suas idéias em sua mente , você tem perguntas específicas e se sente pronto para discutir. Em vez disso, os relatórios diários podem rapidamente causar um monte de brainstorming desnecessário e não estruturado. Portanto, cuidado com o feedback muito cedo : isso pode confundi-lo e atrasá-lo.

Assim: em alguns casos, os relatórios diários diminuíram nossa produtividade. Em média, não tenho a sensação de que eles tornaram nosso trabalho mais eficaz.

ATUALIZAR

Escrevi minha resposta original há alguns anos e, enquanto isso, troquei de equipe. Na minha equipe atual, estamos realizando reuniões diárias sob demanda, ou seja, quando sentimos que precisamos de uma breve atualização de status. Portanto, todos os dias há a possibilidade de realizar uma reunião, mas não a fazemos se ninguém solicitar. Temos uma reunião retrospectiva semanal. Isso é basicamente muito semelhante à abordagem que estávamos usando originalmente em minha equipe anterior, não ágil: reuniões semanais fixas mais reuniões sob demanda adicionais durante o restante da semana.

Se o que você realmente deseja é um status aproximado e para anotar todos os obstáculos, a melhor maneira é solicitar um breve "email de status diário". Se você enfatizar demais, ou fizer uma lista do que deve ou não deve conter, pelo menos alguns de seus desenvolvedores passarão um tempo extra elaborando-o para atender aos requisitos. Em vez disso, basta pedir um email simples. Quando as coisas acontecem ao longo do dia, diga coisas como "ah, coloque isso no seu email do fim do dia" e se você receber um email muito longo no final do dia, mencione casualmente "você não precisa ser tão detalhado todos os dias".

É muito útil esclarecer o propósito de qualquer reunião ou relatório, especialmente um realizado por todos os dias. Você diz que o motivo é:

não queremos perder boas partes do scrum diário, como ter a chance de coordenar os desenvolvedores todos os dias,

O que você quer dizer com coordenar desenvolvedores ? Que tipo de trabalho precisa de coordenação e não foi coordenado ad-hoc pelos desenvolvedores e seus gerentes quando necessário? Existe alguma maneira de identificar tarefas que precisam de coordenação e se comunicar apenas nesses casos?

ou assistindo o progresso do trabalho como um Indicador Chave de Desempenho, para tomar ações antecipadamente.

Muitos bons KPIs (como tempo de resposta do site ou número de bugs críticos) serão mensuráveis ​​mecanicamente e você não precisará impor um custo aos desenvolvedores para fazê-lo.

Eu tive que fazer relatórios diários em vários formatos diferentes no local de trabalho. De um modo geral, acho que os relatórios diários tendem a agregar valor apenas aos gerentes, não aos próprios desenvolvedores. Embora os gerentes se beneficiem dos relatórios diários, sendo capazes de informar o status geral de cada projeto e a carga de tarefas de cada funcionário em um curto período de tempo, na minha experiência, a maioria dos desenvolvedores não se incomoda em ler os relatórios de status uns dos outros.

No entanto, parece que, ao não impor um formato para seus relatórios diários, você dificulta a leitura e o processamento de relatórios para gerentes e colegas desenvolvedores, agravando a questão do tempo perdido do desenvolvedor.

Se você decidir avançar com relatórios diários para seus desenvolvedores, posso sugerir o uso de um wiki interno em vez de relatórios por email? Dessa forma, você não envia spam para as caixas de entrada das pessoas, mantendo o histórico dos status diários de todos.

É uma ótima idéia personalizar seus métodos Agile para adequá-lo a você - então, parabéns por isso.

Então, nos relatórios diários, eu diria que isso não é muito melhor do que uma reunião diária, ainda é a mesma abordagem "diga-me o que você está fazendo", você acabou de fazer todo mundo anotá-lo em vez de falar.

Aqui está uma abordagem alternativa: em vez de usar essas técnicas de 'pesquisa' em que você solicita a cada desenvolvedor seu status, use uma técnica de 'envio'. Se o desenvolvedor não tem muito a relatar, eles não devem, devem relatar todo e qualquer problema e progresso à medida que ocorrem. Portanto, quando concluírem um módulo, devem enviar por e-mail para toda a equipe que terminou, que está no SCM, onde a documentação pode ser encontrada e um breve resumo do que é, como funciona e / ou como usar isto. Se tiverem algum problema, devem enviar um email à equipe pedindo conselhos, ajuda ou qualquer dica. (sim, assim como nos velhos tempos em que as equipes se comunicavam bem sem a microgerenciamento que sofremos hoje)

você verá que isso é muito mais produtivo e construtivo. Você não receberá relatórios sem sentido por causa deles e terá uma equipe mais motivada, pois todo mundo gosta de informar seus colegas sobre seu trabalho.

Também concordo que é uma má idéia substituir as stand-ups diárias por um relatório. Um stand-up diário é um ótimo lugar para vocalizar idéias e problemas. Essa é uma das razões pelas quais eu gosto do bom e velho quadro branco (que usamos ao lado de Jira + Greenhopper). O quadro branco é um lugar onde o grupo 'se agrupa' e compartilha informações, tudo está lá, tudo é visível, todo mundo se move e muda os adesivos nos quais eles trabalharam, também é muito divertido.

Você não consegue extrair essas informações de suas outras ferramentas?

• No que você está trabalhando atualmente? Os tickets que eu designei.
• Qual é o seu progresso? Para tickets com mais de 1 dia, consulte os comentários no ticket ou envie mensagens da filial. Bilhetes que tenho mais curtos: provavelmente já estão prontos amanhã (você não faz grandes bilhetes para mais de 5 dias, não é?)
• Qual é o progresso geral? consulte relação de tickets abertos / fechados
• O que precisa ser organizado? os tíquetes que você recebe de volta, com o feedback de status necessário e tudo o que é discutido no IRC da sua equipe, na Sala da Fogueira, o que seja.

Quando você tem perguntas mais específicas a serem respondidas, eu consideraria a necessidade de relatórios específicos, mas sem isso os seus relatórios parecem um pouco em si mesmos.