(Time-To-Market).
Mesmo nos fins de semana, ele pensava sobre as métricas: "E daí que eu medi o tempo? O que isso me traz?"
De fato, o que traz o conhecimento do tempo? Suponha que a entrega leve 5 dias. E agora? É bom ou ruim? Mesmo que seja ruim, de alguma forma é necessário reduzir esse tempo. Mas como?
Esses pensamentos não o deixavam em paz, mas a solução não chegava.
Ivan entendia que tinha chegado à essência da questão. Os inúmeros gráficos de métricas que ele havia visto antes o convenceram há muito tempo de que a abordagem padrão não funcionaria, e que simplesmente construir um gráfico () não teria valor.
O que fazer?…
Uma métrica é como uma régua comum de madeira. As medições feitas com ela não explicam a razão pela qual por que o objeto medido tem exatamente o tamanho que ela mostrou. A régua apenas mostrará seu tamanho e nada mais. Não é uma pedra filosofal, apenas uma tábua de madeira para medir.
"A Rato de Aço" do seu escritor favorito, Harry Harrison, sempre dizia: a ideia deve atingir o fundo do cérebro e lá repousar, por isso, depois de dias de tentativas sem resultados, Ivan decidiu abordar outra tarefa…
Depois de alguns dias, enquanto lia um artigo sobre lojas online, Ivan de repente percebeu que o valor do dinheiro que a loja online recebe depende do comportamento dos visitantes do site. São eles, os visitantes/clientes, que entregam seu dinheiro à loja e são sua fonte. O comportamento dos clientes influencia diretamente o valor final de dinheiro que a loja recebe, e não há outra coisa.
Assim, para alterar a quantidade medida, era necessário influenciar aqueles que formam esse valor, ou seja, para mudar a quantia de dinheiro de uma loja online, era necessário influenciar o comportamento dos clientes dessa loja, e para alterar o tempo de entrega em DevOps, era preciso influenciar as equipes que "criam" esse tempo, ou seja, usam DevOps em seu trabalho.
Ivan percebeu que as métricas de DevOps não deveriam ser apenas gráficos. Eles deveriam ser uma ferramenta de busca "excepcionais" equipes que moldam o tempo de entrega final.
Nenhuma métrica jamais mostrará a razão pela qual determinada equipe levou muito tempo para fornecer uma distribuição, pensou Ivan, pois na realidade pode haver milhões de razões, e elas podem não ser tecnológicas, mas organizacionais. Ou seja, o máximo que se pode esperar das métricas é ter uma visão das equipes e de seus resultados, e depois, ainda assim, será necessário ir até essas equipes e descobrir o que ocorreu.
Por outro lado, na empresa de Ivan havia um padrão que obrigava todas as equipes a testarem as compilações em várias práticas. A equipe não podia passar para a próxima prática até que a anterior fosse concluída. Isso significava que, se considerássemos o processo DevOps como uma sequência de práticas, as métricas poderiam mostrar o tempo que as equipes gastaram nessas práticas. Sabendo a prática e o tempo da equipe, poderia-se falar de forma mais concreta com ela sobre as causas.
Sem pensar muito, Ivan pegou o telefone e discou o número de uma pessoa que entendia bastante sobre as entranhas do DevOps:
— Denis, você pode me dizer se há uma maneira de entender se uma equipe passou por determinada prática?
— Claro. Nosso Jenkins acende uma flag se a compilação foi bem-sucedida (passou no teste) na prática.
— Ótimo. E o que é essa flag?
— É um simples arquivo de texto tipo "prática_OK" ou "prática_FAIL", que indica se a compilação passou ou não pela prática. Entendeu?
— Basicamente, sim. Ele é gravado na mesma pasta de armazenamento onde está a compilação?
— Sim.
— E o que acontece se a compilação não passar pela prática? Será necessário fazer uma nova compilação?
— Aham.
— Ok, obrigado. E mais uma pergunta: entendi corretamente que posso usar a data em que a flag foi criada como data de passagem pela prática?
— Absolutamente!
— Ótimo!
Eufórico, Ivan desligou o telefone e percebeu que tudo se encaixava. Sabendo a data de criação do arquivo de compilação e das flags, poderia calcular com precisão até o segundo quanto tempo as equipes passavam em cada prática e entender onde estavam gastando mais tempo.
"Entendendo onde está sendo gasto mais tempo, podemos identificar precisamente as equipes, ir até elas e escavar o problema." Ivan sorriu.
Para o dia seguinte, ele se propôs a esboçar a arquitetura do sistema em desenvolvimento.
Continua…
Fonte: habr.com
