Um anel para governá-los todos
Jrtolkien
"Você só pode controlar o que pode ser medido"
P. DruckerQuando se trata de métricas, dezenas, se não centenas, de opções diferentes vêm à mente.
Que medidas não foram inventadas!
Mas o problema é que, quando você olha para essas belas imagens, geralmente é completamente incompreensível o que elas significam.
E, em geral, não está totalmente claro se essas métricas foram escolhidas corretamente ou se valeria a pena analisar métricas completamente diferentes.
Eu quero algum tipo de métrica, tal que parecesse, e tudo ficou imediatamente claro.
Mas existe? Ou não há mágica?
Vamos dar uma olhada e ver um exemplo específico ...
Freqüentemente, tudo o que temos é apenas um determinado conjunto de dados de entrada com os quais não está muito claro o que fazer.
Jira e suas tarefas
Imagine que sua empresa usa o rastreador de tarefas Jira e todos os desenvolvedores são obrigados a marcar eventos de execução de tarefas para trabalhar e suas soluções.
Você pode obter uma descarga para as tarefas do Jira, mas o que fazer a seguir?
Uma boa idéia nessa situação é pensar exatamente sobre o que você deseja gerenciar e o resultado que deseja alcançar.
Leia, por exemplo, o artigo "
Visão sobre métricas: como eu entendo, o que são métricas e qual é o seu principal charme "
E se adicionarmos aqui também os livros “Lean Analytics”, “Running Lean” e Tao Toyota, fica claro que, no caso de Jira, é mais correto gerenciar e medir o tempo de entrega da funcionalidade desenvolvida para o baile.
Portanto, o objetivo é escolhido - queremos medir o tempo de entrega do software, mas você pode fazer isso de centenas de maneiras diferentes. Por exemplo, você pode medir a duração de cada uma das etapas de desenvolvimento e também adicionar a essa medida a perda de tempo de espera, correção de defeitos, redescoberta etc. Até o vskidku pode ser chamado de 50 a 70 métricas diferentes relacionadas ao desenvolvimento de software.
Como ser Existe aquela Métrica Única pela qual um olhar pode entender tudo?
Se você viu com seus próprios olhos aquelas dezenas de métricas discutidas acima, então eu sei sua resposta com antecedência - você dirá: Não! E então eu quero ...
Eu gostaria de ter essa métrica, uma olhada na qual se possa entender com que sucesso o desenvolvimento está se movendo e se é necessário fazer algo adicional com ele.
Surpreendentemente, parece que existe uma métrica digna que pode reivindicar com segurança o título de
Um e Único .
Vamos dar uma olhada mais de perto.
Existe um relatório em Jira como o "Diagrama de fluxo total" ...
"Pare, pare, pare ... Todo mundo o conhece, - você diz, não vou encontrar nada de novo aqui"
Em geral, sim, o relatório é bem conhecido por todos, mas ainda vamos dar uma olhada em mais detalhes. Garanto-lhe que encontrará várias surpresas "agradáveis".
Aqui está como costuma aparecer:
Algumas listras. Por que eles são? Porque O que eles significam? E aqui está o que ...
Barra vermelha escura - o número de tarefas concluídas de acordo com o
regime de competência . Azul é o número de tarefas no trabalho e amarelo são as novas tarefas registradas na lista de pendências.
O total acumulado é quando as tarefas executadas são sempre adicionadas ao número de tarefas executadas anteriormente.
Por exemplo, imagine que você fez duas tarefas anteontem. No gráfico de anteontem, constará: 2.
Ontem você fez mais 3 tarefas. O próximo ponto no gráfico será 2 (ontem) +3 (ontem) = 5.
E hoje você fez mais uma tarefa. O ponto de hoje no gráfico será igual a 2 (ontem) +3 (ontem) +1 (hoje) = 6
I.e. a programação aumentará o tempo todo.
E assim, se você colocar no gráfico o número de tarefas executadas, o número de tarefas no trabalho e as novas tarefas, poderá extrair a Métrica Única e Única.
Vamos considerar um exemplo real (descarregando do Kibana e Elasticsearch):
Está vendo?
De fato, podemos calcular a velocidade (ou produtividade) do desenvolvimento. 200 novas tarefas concluídas em 17 dias. A partir daqui, obtemos que a velocidade atual de desenvolvimento é de 11,76 tarefas / dia, ou seja,
0,085 dias por
tarefa .
Eles são julgados pelo cronograma, o número de tarefas no trabalho, a área azul, não muda (a largura da faixa é quase a mesma em todos os lugares), ou seja, podemos assumir que a velocidade de desenvolvimento é constante, em contraste com o número de novas tarefas.
Na velocidade atual de desenvolvimento, 800 novas tarefas criadas em 17/06/2018 serão concluídas somente após 68,03 dias.
Ok Na minha opinião, não realmente.
Falando? Definitivamente!
Aqui está outro exemplo do mundo real (relatório Jira). Este é o cronograma de execução do ticket pelo suporte técnico:
Da mesma forma, calculamos a produtividade do serviço de suporte - 2,7 tarefas / dia.
Há algo pelo qual lutar
Não basta saber a velocidade atual. Você também deve entender o valor desejado, ou seja, veja o que lutar.
Entendendo a velocidade de uma pessoa, você pode calcular quantas pessoas o serviço de suporte precisará para realizar o número alvo de tarefas ou aumentar a produtividade atual.
O serviço de suporte emprega 15 pessoas. Acontece que existem 0,18 tarefas / dia por pessoa.
Suponha que você queira aumentar a velocidade de execução e tornar o serviço capaz de executar não 2,7 tarefas por dia, mas 10 (valor-alvo).
Uma pessoa realiza 0,18 tarefas por dia, o que significa que 56 pessoas farão 10 tarefas.
Bem, ou como opção, você pode aumentar a velocidade de uma pessoa.
A uma velocidade de 1 tarefa por dia, para 10 tarefas, você não precisará mais de 56 pessoas, mas apenas 10.
Gerenciamos o tempo de entrega
Acontece que a métrica permite, de fato, afetar o tempo de entrega.
Comparando o desempenho atual com o valor-alvo, você pode entender quantas vezes precisa para acelerar o processo.
Variando os parâmetros que compõem a produtividade (o número de pessoas e a velocidade do trabalho), você pode controlar o tempo total de entrega.
Onde mais isso é aplicável?
De fato, análogos da métrica podem ser vistos em muitas áreas.
Veja o DevOps, por exemplo. O DevOps é usado para reduzir o intervalo de tempo entre a criação de um kit de distribuição e a implantação em um baile, ou seja, aqui, como nos exemplos acima, você precisa controlar o tempo de entrega.
Obviamente, a métrica também é ideal para DevOps. Apenas conte quantas distribuições (montagens) chegaram ao baile em um determinado período de tempo e obtenha o desempenho atual do seu pipeline.
Em princípio, a mesma métrica pode ser usada em áreas relacionadas ao dinheiro.
Por exemplo, para uma loja online, é possível calcular da mesma forma o número de pedidos por um determinado período. A questão é: as lojas realmente precisam disso?
Conclusão
Como você pode ver, o One Only Universal Metric ainda tem direito à vida, pelo menos no campo do desenvolvimento de software e nas divisões de serviço (serviço de suporte técnico).
É fácil de calcular, contém significado e pode ser usado para comparar com o valor alvo.
Obviamente, não pode ser usado sem pensar. Antes de iniciar a implementação, pense sobre isso, mas você realmente precisa.
O que você acha da métrica universal?
Que métrica você usa como universal?