: :
os agilistas

O poder das métricas para a evolução do time

O poder das métricas para a evolução do time

os agilistas
: :

VINÍCIUS PAIVA: Uma ponderação que eu queria fazer aqui, é uma pergunta na verdade, para vocês que estão mais próximos das aplicações e medições. O Schuster até comentou sobre tipo aquele comentário, igual ele falou do waterfall. Falou assim: “Mas, como assim eu planejei lá está ok”. Eu queria explorar um outro lado de uma certa diferença de entendimento ou até ceticismo, se e a turma no dia a dia eles também não ficam, os times ficam: “Como assim?”. Mesmo que a galera tenha uma mentalidade ágil, mas a gente vai trabalhando no dia a dia aqui por que precisa dessas medições adicionais. Eu já fui desenvolvedor durante um bom tempo também do … A gente tende a ser um pouco mais cético com relação a alguns desse tipo de coisa. Como é que a gente está encarando isso com os times para que eles também considerem de fato que é bom fazer esse tipo de acompanhamento e usar esse tipo de ferramenta? 

Felipe: Eu posso comentar um pouco aqui, porque justamente foi um dos desafios que a gente enfrentou aqui em uma das nossas alianças. Eu concordo plenamente com você que isso pode causar uma certa aversão do desenvolvedor em relação a: “Eu tenho só o que fazer certo produto, é fazer. Por que eu vou fazer medições?”. Eu acho que uma das coisas que, pelo menos eu me preocupei bastante e  eu acho que faz parte do nosso DNA também, é não simplesmente definir um conjunto de métricas que aquele squad que vai atender aquele cliente ou aquele conjunto de squad que está atendendo aquele cliente deveria medir e buscar uma melhoria, mas sim participar de um entendimento conjunto com esses squads sobre o que eles mesmos acreditam que eles deveriam buscar como melhoria e tentar construir essas métricas em conjunto com os squads. Acho que dessa forma como o produto da medição parte da própria percepção do squad, a gente tem mais engajamento. Então não é mais o Felipão enquanto, vamos dizer assim, a operação centralizada do dti ou a Fernandinha ou o Becatini, o Malaguth, como engenharia da dti, dizendo: “Meça isso aquilo ou aquilo outro”. É assim, o squad tentando fazer uma autorreflexão de o que a gente acredita que precisa melhorar e tentar traduzir esse o que em métricas que nos permitam priorizar ações concretas para essa melhoria. Então se partiu de dentro para fora, eu acho que é mais fácil do desenvolvedor médio não sentir isso que você está.  

Szuster: Não, Felipão, sem falar, não é fácil igual o Vinição disse, mas não é fácil. Toda teoria nossa é de times auto-organizados, mas você tem que ter os elementos de auto-organização. Se não houvesse, é até um jeito de responder aquela pergunta anterior de porque tem que ficar fazendo esse esforço, se um time não mede esse tipo de coisa, ele nem se auto-organiza em torno disso. E aí, a pressão do negócio só por features e para entregar software rápido de qualquer jeito seria terrível e o time refletiria isso, o time vai refletir o ambiente dele. Fala aí, Fernandinha.   

Fernanda: Acho que a retro é um excelente mecanismo. Claro, para os times, um mecanismo que está ali nos princípios das metodologias ágeis. A retro é um excelente mecanismo para os times refletirem sobre o que eles precisam melhorar. Mas em alguns momentos até pelas nossas maturidades e tudo mais, pelos times estarem em diferenças de maturidades também, a gente precisa criar algumas outras restrições até para o time, conseguir discutir sobre isso até para o time falar assim: “Nossa, não, espera aí, eu tenho que abrir um pouquinho mais a minha mente, porque tem esse, esse e esse aspecto que eu nem tinha pensado aqui no meu contexto”. Então eu acho que isso é bem importante de a gente falar que isso é um dos motivos pelos quais a gente mede também, pelo qual a gente tem esse tipo de mecanismo que é dar mais insumo para os times refletirem sobre a sua operação. Isso que o Felipão falou sobre flexibilidade, essas nossas formas de lidar com um certo produto, ele tem essa flexibilidade como vantagem. Eu acredito bastante nisso também, que é um jeito do time olhar contextualizado para aquelas métricas falar assim: “Não, isso aqui faz sentido para mim, isso aqui não faz isso aqui não faz”. E com isso, a gente produziu uma gestão à vista super simples de coisas assim que eu consigo bater o olho e falar: “Poxa, isso aqui é o que eu tenho que priorizar no meu próximo ciclo”. Então eu até falei do início, que é uma das vantagens também do negócio de a gente estar sempre olhando para que a gente quer priorizar, executando e prevendo o que a gente gostaria de executar no próximo ciclo. Eu acho que são coisas que são bastante vantajosas desse olhar do certo produto. E claro, de novo, o apoio do cliente para a a gente conseguir fechar a malha e fazer as coisas acontecerem. 

MATHEUS: É uma forma legal. A gente estava falando do engajamento do time com as métricas e com essa disciplina de desenvolvimento, a gente ter um modelo para ir o tempo todo adaptando o que a gente está medindo, o que a gente está buscando de melhorar, faz muita diferença no sentido assim: é muito comum a gente pensar no todo, definir métricas que a gente quer acompanhar e trabalhar para atingir elas. Talvez isso seja até o mais natural se a gente for pensar de uma forma lógica. Porém, uma forma de trazer mais esse engajamento é a gente começar do micro para descobrir o todo. A gente junto com o time técnico durante a implementação a todo momento vai se baseando nessa estrutura meio que direcional, vamos chamar assim, para ir pensando refletindo: “Beleza, eu tenho que medir isso daqui. É o momento? Vou começar a me preocupar com isso e vou trabalhar para atingir isso”. Em um outro momento ele vai entender e falar: “Isso daqui agora já está consolidado. Eu posso partir para um outro”. E dessa forma, os times tendem a querer de fato se envolver mais com essa garantia de que o produto está sendo construído corretamente. Eu tento trazer muito aqui para os times isso. “Galera, não preocupa muito com o todo agora. Vamos construindo juntos, que aos poucos vocês vão identificando pontos de qualidade, pontos de fraqueza que devem atuar, enfim”. Tende a dar certo. Obviamente, nem tudo na vida é 100% garantido. 

VINÍCIUS PAIVA: Uma ponderação que eu queria fazer aqui, é uma pergunta na verdade, para vocês que estão mais próximos das aplicações e medições. O Schuster até comentou sobre tipo aquele comentário, igual ele falou do waterfall. Falou assim: “Mas, como assim eu planejei lá está ok”. Eu queria explorar um outro lado de uma certa diferença de entendimento ou até ceticismo, se e a turma no dia a dia eles também não ficam, os times ficam: “Como assim?”. Mesmo que a galera tenha uma mentalidade ágil, mas a gente vai trabalhando no dia a dia aqui por que precisa dessas medições adicionais. Eu já fui desenvolvedor durante um bom tempo também do … A gente tende a ser um pouco mais cético com relação a alguns desse tipo de coisa. Como é que a gente está encarando isso com os times para que eles também considerem de fato que é bom fazer esse tipo de acompanhamento e usar esse tipo de ferramenta?  Felipe: Eu posso comentar um pouco aqui, porque justamente foi um dos desafios que a gente enfrentou aqui em uma das nossas alianças. Eu concordo plenamente com você que isso pode causar uma certa aversão do desenvolvedor em relação a: “Eu tenho só o que fazer certo produto, é fazer. Por que eu vou fazer medições?”. Eu acho que uma das coisas que, pelo menos eu me preocupei bastante e  eu acho que faz parte do nosso DNA também, é não simplesmente definir um conjunto de métricas que aquele squad que vai atender aquele cliente ou aquele conjunto de squad que está atendendo aquele cliente deveria medir e buscar uma melhoria, mas sim participar de um entendimento conjunto com esses squads sobre o que eles mesmos acreditam que eles deveriam buscar como melhoria e tentar construir essas métricas em conjunto com os squads. Acho que dessa forma como o produto da medição parte da própria percepção do squad, a gente tem mais engajamento. Então não é mais o Felipão enquanto, vamos dizer assim, a operação centralizada do dti ou a Fernandinha ou o Becatini, o Malaguth, como engenharia da dti, dizendo: “Meça isso aquilo ou aquilo outro”. É assim, o squad tentando fazer uma autorreflexão de o que a gente acredita que precisa melhorar e tentar traduzir esse o que em métricas que nos permitam priorizar ações concretas para essa melhoria. Então se partiu de dentro para fora, eu acho que é mais fácil do desenvolvedor médio não sentir isso que você está.   Szuster: Não, Felipão, sem falar, não é fácil igual o Vinição disse, mas não é fácil. Toda teoria nossa é de times auto-organizados, mas você tem que ter os elementos de auto-organização. Se não houvesse, é até um jeito de responder aquela pergunta anterior de porque tem que ficar fazendo esse esforço, se um time não mede esse tipo de coisa, ele nem se auto-organiza em torno disso. E aí, a pressão do negócio só por features e para entregar software rápido de qualquer jeito seria terrível e o time refletiria isso, o time vai refletir o ambiente dele. Fala aí, Fernandinha.    Fernanda: Acho que a retro é um excelente mecanismo. Claro, para os times, um mecanismo que está ali nos princípios das metodologias ágeis. A retro é um excelente mecanismo para os times refletirem sobre o que eles precisam melhorar. Mas em alguns momentos até pelas nossas maturidades e tudo mais, pelos times estarem em diferenças de maturidades também, a gente precisa criar algumas outras restrições até para o time, conseguir discutir sobre isso até para o time falar assim: “Nossa, não, espera aí, eu tenho que abrir um pouquinho mais a minha mente, porque tem esse, esse e esse aspecto que eu nem tinha pensado aqui no meu contexto”. Então eu acho que isso é bem importante de a gente falar que isso é um dos motivos pelos quais a gente mede também, pelo qual a gente tem esse tipo de mecanismo que é dar mais insumo para os times refletirem sobre a sua operação. Isso que o Felipão falou sobre flexibilidade, essas nossas formas de lidar com um certo produto, ele tem essa flexibilidade como vantagem. Eu acredito bastante nisso também, que é um jeito do time olhar contextualizado para aquelas métricas falar assim: “Não, isso aqui faz sentido para mim, isso aqui não faz isso aqui não faz”. E com isso, a gente produziu uma gestão à vista super simples de coisas assim que eu consigo bater o olho e falar: “Poxa, isso aqui é o que eu tenho que priorizar no meu próximo ciclo”. Então eu até falei do início, que é uma das vantagens também do negócio de a gente estar sempre olhando para que a gente quer priorizar, executando e prevendo o que a gente gostaria de executar no próximo ciclo. Eu acho que são coisas que são bastante vantajosas desse olhar do certo produto. E claro, de novo, o apoio do cliente para a a gente conseguir fechar a malha e fazer as coisas acontecerem.  MATHEUS: É uma forma legal. A gente estava falando do engajamento do time com as métricas e com essa disciplina de desenvolvimento, a gente ter um modelo para ir o tempo todo adaptando o que a gente está medindo, o que a gente está buscando de melhorar, faz muita diferença no sentido assim: é muito comum a gente pensar no todo, definir métricas que a gente quer acompanhar e trabalhar para atingir elas. Talvez isso seja até o mais natural se a gente for pensar de uma forma lógica. Porém, uma forma de trazer mais esse engajamento é a gente começar do micro para descobrir o todo. A gente junto com o time técnico durante a implementação a todo momento vai se baseando nessa estrutura meio que direcional, vamos chamar assim, para ir pensando refletindo: “Beleza, eu tenho que medir isso daqui. É o momento? Vou começar a me preocupar com isso e vou trabalhar para atingir isso”. Em um outro momento ele vai entender e falar: “Isso daqui agora já está consolidado. Eu posso partir para um outro”. E dessa forma, os times tendem a querer de fato se envolver mais com essa garantia de que o produto está sendo construído corretamente. Eu tento trazer muito aqui para os times isso. “Galera, não preocupa muito com o todo agora. Vamos construindo juntos, que aos poucos vocês vão identificando pontos de qualidade, pontos de fraqueza que devem atuar, enfim”. Tende a dar certo. Obviamente, nem tudo na vida é 100% garantido. 

Descrição

Este conteúdo é um corte do nosso episódio: “#199 – Construir certo o produto: desenvolvendo a solução na prática”. 

Nele, Fernanda Vieira, Matheus Becatini, Francisco Malaguth e Felipe Silveira, todos da dti digital, compartilham dicas para melhorar a performance dos times ágeis usando a metrificação de ações como impulsionadora da evolução. Ficou curioso? Então, dá o play! 

Quer conversar com Os Agilistas? É só mandar sua dúvida/sugestão para @osagilistas no Instagram ou pelo e-mail osagilistas@dtidigital.com.br que nós responderemos em um de nossos conteúdos! 

Nos acompanhe pelas redes sociais e assine a nossa newsletter que chega todo mês com os assuntos quentes do agilismo através do site

See omnystudio.com/listener for privacy information.