Criar indicador para medida de ganho de eficiência com trabalho remoto e comunicação assíncrona

[gabrielbdornas]

Um dos pilares da metodologia estamos construindo são: trabalho remoto; e comunicação assíncrona.Como medir, ao longo do tempo, ganho de eficiência de uma equipe que resolva utilizar essa metodologia?

Penso que podemos criar um cálculo simples que medirá o número de dias que um issue ficou aberto. Minha expectativa é que o este número de dias tenderá a diminuir à medida que a equipe utilize as ferramentas que vamos propor, o que poderá ser um dos indicativos para ganho de eficiência.

Outra idéia é medirmos o aumento (ou não) do número de issues abertos ao longo do tempo. "Quando tudo está sob controle, é sinal de que não estamos indo suficientemente rápido."[^1]. Neste sentido, outro pilar de nossa metodologia será o registro de problemas e novas idéias em issues. Se a criação de issues aumenta ao longo do tempo, temos uma demonstração de que não estamos sob controle, ou ao contrário estamos ganhando eficiência.

A pergunta fundamental para esta discussão será: Um maior número de issues abertos, sendo estes fechados mais rápidamente, são análises que contribuirão para demonstrar ganho de eficiência no trabalho?

[^1]: Mario Andretti

[gabrielbdornas]

Relacinado com #13.

[fjuniorr]

Penso que podemos criar um cálculo simples que medirá o número de dias que um issue ficou aberto.

Falei isso no #13 mas acho que é importante considerar que o issue pode estar aberto mas ninguém está ativamente trabalhando nele. Então o cálculo teria que "expurgar" os dias em que o issue não estava atribuído a ninguém.

Minha expectativa é que o este número de dias tenderá a diminuir à medida que a equipe utilize as ferramentas que vamos propor, o que poderá ser um dos indicativos para ganho de eficiência.

Eu não tenho acesso mais ao trello da DTA, mas acho que tem algum card lá que faz uma reflexão bacana sobre as dificuldades de medir "velocidade" de um time. Se ele existir mesmo faz sentido trazer a discussão pra cá.

Outra idéia é medirmos o aumento (ou não) do número de issues abertos ao longo do tempo.

Eu acho que no geral é bom que o número de issues abertos aumente, mas tendo a achar que medir isso é focar nos aspectos errados, porque diferentemente do prazo para encerrar um issue, essa métrica não tem interessados externos.

"Quando tudo está sob controle, é sinal de que não estamos indo suficientemente rápido."

Essa frase pra mim é muito move fast and break things, cada dia mais eu vou pra vibe move slow and fix things. 🙃

[gabrielbdornas]

Eu não tenho acesso mais ao trello da DTA, mas acho que tem algum card lá que faz uma reflexão bacana sobre as dificuldades de medir "velocidade" de um time. Se ele existir mesmo faz sentido trazer a discussão pra cá.

@fjuniorr, tentei encontrar este card, inclusive perguntando todos da equipe, mas por enquanto não encontrei. Vou pedir auxílio para @andrelamor.

Sobre os outros pontos, fico em dúvida sobre a vibe move slow and fix things, penso mais em algo como move constantly without breacking things.

[fjuniorr]

A pergunta fundamental para esta discussão será: Um maior número de issues abertos, sendo estes fechados mais rápidamente, são análises que contribuirão para demonstrar ganho de eficiência no trabalho?

Na última edição do Technology Radar Volume 29 da thoughtworks um dos temas foi "Quão produtivo é medir produtividade?". Esse trecho da introdução é relevante pra essa discussão:

Software development can sometimes seem like magic to non-technologists, which leads managers to strive to measure just how productive developers are at their mysterious tasks. Our chief scientist, Martin Fowler, wrote about this topic as long ago as 2003, but it hasn't gone away. We discussed many modern tools and techniques for this Radar that take more nuanced approaches to measuring the creative process of building software yet still remain inadequate. Fortunately, the industry has moved away from using lines of code as a measure of output. However, alternative ways to measure the A ("Activity") of the SPACE framework, such as number of pull requests or issues resolved, are still poor indicators of productivity.