Fernanda: Fiquei ouvindo você falando aí, realmente, o Developer Velocity cria uma objetividade, em um indicador. Tem gente que fala assim: “Beleza. Esses indicadores, esse tanto de coisa de lead aqui, se você investir nisso, nisso, aquilo, estou te contando que você vai melhorar sua performance.
Diulia: E aí, pessoal, joia? Então esse é mais um episódio de Os Agilistas, o podcast que tem uma comunidade de pessoas que acreditam e vivem o agilismo. A gente está aqui, mais uma vez, eu e o Pedro. Não é, Pedro?
Pedro: É isso aí. Tudo bem, Diulia?
Diulia: Tudo bem.
Pedro: De volta.
Diulia: Pois é. E aqui, hoje, a gente está com uns convidados, são figurinhas super repetidas, na verdade não é nem convidado é até…
Pedro: Mais um dia só de hosts.
Diulia: É. A gente está aqui com o Vinição.
Vinícius: E aí, pessoal. Tudo bem? Vamos lá.
Diulia: E com a Fernandinha, que é host do Entre Chaves.
Fernanda: E aí, galera. Então, pois é, o Entre Chaves, o nosso podcast aqui de desenvolvimento de software também, da dti, e muito do que a gente vai falar hoje tem bastante intersecção, na verdade, com o Entre Chaves, então, bora lá.
Diulia: Bora lá.
Pedro: Hoje a gente vai fazer uma conversa sobre um material que a gente tem discutido bastante, aqui, na DTI. Na verdade, o foco não é nem o material em si, mas o material está sendo um benchmark para a gente, para a gente discutir drives que influenciam o desempenho dos times, desempenho organizacional, então muito do nosso papo aqui hoje vai ser em volta de um artigo, feito pela McKinsey & Company, que é uma consultoria estratégica, americana, super famosa, renomada, e o artigo que é chamado “Developer Velocity”, e o subtítulo é “Como a excelência em software potencializa o desempenho dos negócios.” Então a nossa motivação aqui é realmente vertificar esse benchmark, esse e outros, de repente, o que é legal a gente falar aí quando a gente fala do desempenho dos times, e ver se faz sentido para os mecanismos que a gente está utilizando até aqui mesmo na dti, que é um assunto muito quente, esse é um ano de eficiência, não que os outros não tenham sido, mas esse é um ano de mais eficiência, então falar dos drivers é muito importante.
Diulia: E é interessante porque a gente tem feito episódios a respeito de metodologia, a gente tem conversado também sobre seguir materiais no modelo book, assim, de ir muito à risca, e hoje é um exercício de a gente fazer uma reflexão mais na prática, um exercício de pegar um material e ir refletindo sobre o que realmente faz sentido para a gente poder acompanhar.
Pedro: Isso. E a gente está sempre criando muita coisa nossa, aqui na dti.
Diulia: Sim.
Pedro: A nossa própria metodologia, o nosso próprio jeito de fazer as coisas, os nossos flows, e é legal falar dos benchmarks também, porque todo mundo aqui estuda, vê e escuta bastante coisa, e é legal ver o que está rolando no mercado também. Para começar esse papo acho que seria legal primeiro a gente nivelar o que o artigo diz, o que são os principais insights que estão girando em torno desse conceito, que eles chamaram de Developer Velocity. Bom, acho que o artigo já começa dizendo que as empresas que estão obtendo maior desempenho organizacional têm esse fato relacionado com um conjunto de 46 drivers, que formam o que eles chamaram de Developer Velocity Index. Então foi uma pesquisa intensa que eles fizeram, com executivos sêniores de mais de 400 empresas. A pesquisa é de 2019, mas a gente entende que tem algumas coisas ainda bem relevantes. Enfim, aí para entender melhor os fatores que permitem as organizações alcançarem esse chamado Developer Velocity, foi que eles realizaram essa pesquisa, e com o resultado eles apontam fatores críticos relacionados à tecnologia, práticas, práticas de trabalho, capacitação organizacional, para alcançar essa velocidade do desenvolvedor. Então são, ao todo, 13 áreas de capacidade, que eles levantaram no artigo, e eles colocam essa correlação no cerne da pesquisa, de que os top 25% score, as empresas que ficaram no top 25% score do DVI, o índice, correlacionam com o crescimento de receita quatro a cinco vezes maior do que os 25% piores. E aí entra em uma análise um pouco mais profunda dentro de cada área de capacidade, e falam da pontuação, satisfação do cliente, percepção de marca, gestão de talentos, etc.
Diulia: É interessante mencionar que a forma como o artigo correlaciona os itens é bem global, assim, do ponto de vista de desenvolvimento, não vai tratar especificamente de questões técnicas ali, apenas de ferramenta, então vai tratar também de aspecto de gestão de produto, vai tratar de aspectos da organização como um todo, para dar condições para que o trabalho seja executado, até porque 46 fatores, são muito fatores, e eu acho que seria interessante até a gente correlacionar já, Fernandinha, até com um pouco do que a gente tem, hoje, de visão, aqui na dti também, o que a gente acompanha, o que traz lá no artigo.
Fernanda: Bom, queria dar um passinho atrás, que eu acho que vale a pena dar uma explicitada um pouco maior nesse conceito do Developer Velocity, porque o artigo vem muito falando, assim: “Tecnologia vem drivando os nossos negócios já tem um tempo”, ele fala assim que melhorias de performance não foram vistas com a mesma velocidade, de que empresas estão cada vez mais investindo em tecnologia, mas não necessariamente melhorando a sua performance, de fato, e eu acho que esse é o grande mote, para que ele comece a falar sobre esse Developer Velocity, que ele fala assim: “Beleza. Então agora, para melhorar, a minha performance realmente de entrega na minha empresa, uma das coisas que eu tenho que fazer é aumentar a minha velocidade de desenvolvimento, do desenvolvedor ou da desenvolvedora, vamos falar assim, e aí ele começa falando desses outros fatores, como você falou, e tudo mais, mas acho que é legal falar que isso veio como uma resposta de: não conseguimos colocar código em produção rápido, não conseguimos lançar produtos rápido, não conseguimos saber o custo do meu time, então vamos criar esse indicador para ver o que drivar as nossas ações, então vem aí o Developer Velocity. E aqui na dti, eu acho que muito do que ele fala como Developer Velocity, ele fala sobre quatro grandes fatores, que são os mais importantes, assim, na visão dele, na visão desse artigo e dessa pesquisa, que são as ferramentas de desenvolvimento devOps, colaboração planning, também a cultura, a parte de segurança psicológica ali. Ele fala também sobre gestão de produto, como falou, Diu, e ele fala sobre gestão de talentos. E eu acho que, desses vários, a gente pode falar muito aqui, mas, assim, a gente acompanha coisas aqui bem relacionados à saúde dos times, a gente tem os nossos checks, enfim, a gente tem o produto certo, certo produto, que eu tenho certeza que aqui a gente já falou, no Os Agilistas, várias vezes sobre, que é nossa ferramenta de medir efetividade, tanto de produto, quanto de engenharia, de operações e design, então essas ferramentas com certeza nos ajudam a dar visibilidade e acompanhar a saúde dos nossos times. Então é uma das coisas, vamos falar assim, que é a pontinha do iceberg do que a gente faz, que tem a ver com o artigo, de repente acompanhar esses indicadores e tudo mais, dar transparência e tomar ações, ter uma cultura de melhoria contínua, conseguir tomar ações em relação a isso.
Pedro: Em um primeiro momento, o artigo chama muito atenção, né? Porque essas coisas que ele coloca como top 4 coisas importantes, são coisas que a gente considera importante também aqui, não é?
Fernanda: Sim.
Pedro: Nos artefatos que a gente produz para acompanhamento do desempenho dos times.
Vinícius: Assim, vou colocar minha visão aqui, todo mundo já conceituou o início, assim, eu acho a existência do artigo interessante, porque quando você pega uma consultoria tipo a McKinsey, preocupando com isso aí, que é uma consultoria que normalmente está mais vinculada à questão estratégica, de negócio, e ela coloca esse tipo de assunto em pauta, vamos falar assim, ela normalmente consegue traduzir de um jeito bom para executivos, tanto é que não é à toa que ela tenta colocar o tal do DVI, o Developer Velocity Index, que seria uma nota, assim, eu não sei nem se é um jeito tão adequado assim de querer fazer uma comparação, porque eu não sei se tudo é redutível a um índice único, entendeu? Mas, querendo ou não, é um jeito bom para ser, o pessoal executivo gosta de coisas que são fáceis de analisar, e tal, então, querendo ou não, isso é fácil. Eu acho que a existência de um artigo desse tipo é interessante, a gente já vinha usando muito aqui, na dti, como inspiração para os métodos internos, igual a Fernandinha citou aqui, do produto certo, certo produto, muito inspirado no DORA, que nasceu um pouco mais na comunidade técnica, e eu acho que esse da McKinsey complementa e traz uma visão, talvez, um pouco mais executiva, então acho importante, nesse sentido, e acho muito importante analisar as variáveis que eles trazem lá. Eu não sei, a Fernandinha leu três vezes, fez um resumo, então talvez ela pode citar melhor aí. Então, assim, eu acho bem interessante avaliar essas dimensões que eles avaliaram, tanto dimensões de metodologia, algumas dimensões mais técnicas, arquiteturais, de DevOps, algumas coisas do tipo, algumas pessoas culturais. Igual a Fernandinha falou, são coisas que a gente avalia internamente também, e fazem total sentido. Apesar disso, apesar disso tudo, uma crítica que eu faço, que a gente comentou até em off aqui nos bastidores, é que eu acho que tem um problema muito, eu acho que é provável, então não vou ser tão firme assim, não, mas me parece que não daria para fazer uma análise de causalidade ali. Igual o Pedro falou no início, se você olhar a correlação, sim, mas causalidade, tipo assim, que você ter aqueles fatores naquele jeito que foi colocado no artigo bem, isso implicaria em um desempenho financeiro. Ele coloca, no início lá, que eles avaliaram o desempenho financeiro, mas não só financeiro, eles começaram a colocar algumas outras dimensões, algumas dimensões de pessoas, de bem-estar. Então, tipo assim, ser top performance é não significa apenas o resultado financeiro, isso eu entendi bem no artigo, significa ter um bom resultado financeiro, mas também ter outras variáveis que definiriam um negócio saudável. Me parece que não daria para estabelecer uma causalidade, inclusive, algumas causalidades ali me parecem que poderiam eventualmente ser até o contrário. Por exemplo, quando uma das quatro dimensões que a Fernandinha colocou aqui, que eles definem que foram as que chamaram mais atenção, eles colocaram como se fosse assim, se eu tenho as empresas que utilizam um nível mais sofisticado, de forma assertiva, em termos de ferramentas, tem um resultado melhor, só que dá para muito bem ser o contrário, dá para, tipo assim, empresas que foram muito bem-sucedidas e tiveram condições financeiras para comprar as melhores ferramentas, elas conseguiram comprar as melhores ferramentas exatamente porque tiveram resultado financeiro melhor. Então uma crítica que eu faço é esse estabelecimento de causalidade, mas isso não significa que o artigo não seja bom, e não seja bom para reflexão, e não seja bom, inclusive, para sensibilizar o público dos nossos clientes, que é mais executivo, da importância que existe em relação a você ter um ecossistema bom, do ponto de vista de produtos digitais, que é muito provável que influencie em um bom resultado na empresa.
Pedro: Eu tendo a concordar, assim. Eu acho até que a gente tem mesmo que questionar a metodologia da pesquisa, dos benchmarks que a gente faz, porém, eu acho que o conceito que ele traz é um negócio que a gente gosta de ouvir também. Assim, eu não gosto muito quando as referências trazem um hall two e ele faz exatamente isso no final, não é? “Como atingir um DVI mais alto”, então traz o negócio como se fosse uma receita, assim, e eu acho que as coisas não são tão simples, eu gostaria até de ver uma atualização desse artigo pós-pandemia, porque ele foi em 2019.
Fernanda: É, total.
Pedro: E eu fico imaginando que alguns desses drivers já tenham se acentuado muito mais que outros, outros podem ter caído.
Fernanda: Eu fiquei pensando justamente nisso, e assim, eu acredito que o driver lá que ele fala sobre arquitetura de dados, por exemplo, é um negócio que deve ter mudado, a parte de segurança parece também que deve ter mudado, que apesar de que ele fala lá, quando você olha para essa parte de tecnologia, segurança não foi ali elencada dentro dos quatro grandes fatores, as ferramentas estão muito mais, mas você vê que segurança está ali, assim, bem relevante, e eu acredito que isso deve ter crescido nos últimos anos, eu acredito que esse deve ser um ponto que foi diferente, dessa última.
Pedro: Eu ainda gosto particularmente do ponto que ele fala também sobre criar, estou tentando traduzir na minha cabeça aqui, criar uma função de gestão de produtos compreensível.
Diulia: Sim.
Pedro: Que eu acho que é um desafio que a gente tem direto, em trazer compreensão para essa abordagem de gestão de produto, não é?
Diulia: Pois é, isso é até uma coisa que eu ia comentar, assim, a forma como eles colocam a questão de gestão de produto é muito pouco engessado, no sentido de: “Tem que ter uma pessoa representante, que vai ocupar um cargo específico, que vai se chamar X, e aí vai fazer essas atividades aqui”.
Pedro: Super prescritivo.
Diulia: É. Não é nem um pouco prescritivo, e muito pelo contrário, assim, traz um direcionamento sobre a necessidade da gestão de produto, então eu acho que isso foi uma abordagem feliz, assim, no artigo, porque naturalmente é mutável, e mais do que mutável com relação ao tempo, é naturalmente mutável também de acordo com o cenário que a gente está falando, pode ter cenários que vai exigir pessoas dedicadas, e aí não é nem no singular, é no plural, pessoas dedicadas para poder garantir a saúde do produto, focadas na gestão de produto, em outros cenários, pode ser que o próprio time consiga se organizar de uma maneira a garantir a gestão de produto, mas sem ter um representante único ali, naquele papel.
Pedro: Sim.
Fernanda: Eu ali um artigo, que é da própria McKinsey, de 2021. Essa pesquisa saiu em 2020, não é? Eles fizeram uma pequena atualização mesmo, assim, eu li rapidamente, infelizmente não vou conseguir falar muita coisa sobre.
Pedro: Vou precisar me atualizar.
Fernanda: Mas depois dá uma olhada, eu acho que vale a pena. Mas eles falaram, um pouco, sobre essa parte da gestão de produtos, pelo que eu li rapidamente, e eles falam que realmente é a maior das dificuldades, assim, que é de criar boa gestão de produtos, dessa forma aí, saudável, e realmente que seja, enfim, que não seja uma pessoa, que seja realmente todo time tendo responsabilidade sobre, conhecendo roadmap, conhecendo o valor gerado, sabe? Talvez essa seja uma das coisas mais complexas mesmo, assim, para se melhorar a velocidade, a Developer Velocity.
Vinícius: No artigo, estou me lembrando aqui, nessa parte de produto, que ele coloca em uma macro categoria organizacional, e que também eu acho, uma crítica que eu faço aqui, eu acho que aquilo ali deveria estar separado, inclusive aqui na dti isso é separado, porque aquilo ali é uma competência igual existe a competência técnica de arquitetura de software, tal.
Pedro: É verdade.
Vinícius: Eu acho, outra coisa também, ele não coloca muito claramente a parte de design. Quase não cita, não é?
Diulia: Uma lágrima desceu, fiquei lá procurando, design, design, design, falei: “Gente, o que é isso? Não é possível”, não aparece.
Vinícius: E o que ele coloca, a conclusão dele, é de que não existe uma correlação. Lembrando, sempre quando ele fala correlação, ou até causa, na minha visão, apesar de ele não colocar, talvez, muitas vezes, a palavra causalidade, ele está claramente tentando estabelecer essa causalidade ao longo dos comentários no artigo.
Pedro: Isso. Totalmente.
Vinícius: Mas ele coloca que não existe uma causalidade específica de alguma dimensão de produto, mas existe uma no geral, tipo assim, no geral, se você tem boas práticas de produto você acaba tendo um resultado melhor. Uma reflexão que eu acho que é interessante, independente do artigo, igual o Pedro falou no início, que eu acho bem importante que exista, assim, até antes, uma reflexão: “Por que alguém usaria isso? Por que e como, assim, que uma empresa usaria isso?”. Um motivo básico é, assim, na minha visão, você quer, de algum jeito, saber se você, com as suas iniciativas digitais, está no momento presente com potencial de gerar mais valor, mas principalmente observando se a sua estrutura está ficando melhor, para que no futuro você consiga se sustentar gerando valor, e também sendo criativo suficiente para ter condições e musculatura, para no futuro continuar tendo essas competências. Então daria para falar que, tipo assim, que é como se fosse o seguinte, no fundo você está querendo acompanhar se você está gerando valor no presente, se você está caminhando pra ter condições de gerar valor no futuro. E aí então, assim, o que refletiria isso aí seria o próprio valor, que é o resultado das empresas que estão colocando, mas um proxy para isso seria o índice, que ele coloca lá o DVI, tipo assim, se eu tenho um DVI alto, eu provavelmente vou conseguir gerar muito valor, e vou, no futuro também, estar bem-preparado para o futuro. E aí é como se fosse o seguinte, beleza, mas se eu vou acompanhar só isso aqui, é um negócio muito abstrato, assim, então eu preciso quebrar isso em outras dimensões, ele quebra nessas 46 dimensões. Fazendo um paralelo com o DORA. eu acho interessante o DORA, porque o DORA coloca como se fosse uma camada intermediária, que seria alguns indicadores que normalmente eles são consequência de fatores menores, de competências menores, mas eles chegam em quatro indicadores, que tem a ver com lead time, com tempo de reparo, se você consegue reparar as coisas rapidamente, se você consegue identificar problemas rapidamente, então eu acho bem, um pouco mais, vamos dizer assim, um método melhor. E aí, principalmente, já que você está querendo acompanhar isso para você sentir que a sua organização está se transformando, ou se está mantendo as competências digitais, é muito importante que você acompanhe essas coisas no tempo, e que você estabeleça alguns forecast baseado nas ações que você pretende fazer, do que você espera estar daqui a pouco. Por exemplo, se a pessoa que leu lá acredita que realmente, por exemplo, que faz muita diferença ter as melhores ferramentas do mundo, igual o artigo que tende a te fazer pensar que seja uma condição, você precisa pensar como você vai fazer isso, você precisa de projetar daqui três meses, por exemplo, é como se você definisse objetivos organizacionais que tem a ver com isso, e aí você vai avaliar onde que você vai colocar essa ferramenta, você não pode colocar em qualquer lugar, você tem que avaliar. Tipo assim, vai ser ferramenta de DevOps? Vai ser uma ferramenta de planejamento? Um JIRA da vida? Um Azure DevOps? Alguma coisa do tipo? Então esse para mim é o ponto mais importante, disciplina, e é o que a gente tenta fazer, aqui na dti, com o produto certo, certo produto, acompanhando o passado, presente e o futuro, sendo o futuro forecast que a gente estabelece. Para eu ter essa disciplina, é uma das coisas mais importantes que influenciam, inclusive, no resultado que você vai conseguir utilizando alguma metodologia desse tipo.
Fernanda: Justamente, assim. Eu fiquei ouvindo você falando aí, realmente, o Developer Velocity cria uma objetividade, em um indicador. A gente fala assim: “Beleza. Esses indicadores aqui, esse tanto de coisa de lead aqui, se você investir nisso, nisso e aquilo, estou te contando que você vai melhorar sua performance, mas, de fato, ele não te dá um indicador mais geral, que você pode realmente confirmar se as suas ações estão sendo efetivas, diferente do DORA né? Que é o contrário, ele dá os indicadores leg, que são esses indicadores mais difíceis de mudar, mas ele não te dá os indicadores de lead. Na verdade, assim, ele fala sobre as capabilities, o DORA fala sobre como mudar esses indicadores de lag que o Vinição mencionou, que são lead time de entrega, frequência de deploy, percentual de falha e tempo de rou back, esses quatro indicadores ele dá, falando que: “Esses indicadores aqui, se você fizer essas outras coisas certas aqui, esses indicadores vão ser sensibilizados”. Mas então, assim, parece que eles são meio que complementares mesmo, assim, não é? Um te fala objetivamente o que mudar e como medir, e o outro te fala assim: “Não, espera aí, eu te dou um tanto de jeito para mudar, e aí você mede do seu jeito. Mas olha só, se você conseguir sensibilizar isso aqui provavelmente você está mudando a sua performance de entrega”, então talvez eles são meio complementares mesmo, e de fato, eles têm muita intersecção, eles falam sobre cultura, os dois falam sobre a importância da cultura na hora que você está falando sobre performance de uma organização, os dois falam sobre a importância da tecnologia. O Developer Velocity foca mais nas ferramentas, como o Vinição já falou, o DORA foca mais amplo, ele fala sobre teste, ele fala sobre CICD, que são mais óbvios ali.
Pedro: Fala de tudo. Pessoas, processos, ferramentas.
Fernanda: É, exatamente. E aí eu fico pensando quando você falou, Vinição, sobre causalidade, que de fato o Developer Velocity parece que ele fica falando muito sobre causalidade, no DORA é o contrário mesmo. No site do DORA tem até um grafo, aqueles gráficos, grafos mesmo, que eles relacionam todas essas dimensões de forma bem não linear mesmo, uma que vai influenciando a outra, que vai influenciando a outra, e não sei o que, não sei o que, então é total grafo que você consegue ver, e consegue meio que ver que o negócio é uma nuvem, assim, ele, de fato, não tem uma causalidade muito clara. Eu acho que isso é legal, do DORA, realmente.
Diulia: A gente já tem mencionado muito o DORA.
Pedro: Sim.
Diulia: Acho que até em outros episódios, a gente sempre fala sobre ele, não tem como não falar, porque é super relevante, mas só para poder não deixar o pessoal perdido.
Pedro: Ia falar isso agora.
Diulia: Que a gente falou, a gente falou da historinha do Developer Velocity, de ser da McKinsey, e tal, de onde saiu o DORA?
Fernanda: O DORA é uma pesquisa também, com muitas, mais de 32 mil pessoas.
Pedro: A base estatística é maior, Vinição.
Fernanda: A base é grande, a base é bem grande de pessoas.
Vinícius: Eu acho muito mais consistente.
Pedro: É.
Fernanda: Foi uma pesquisa que nasceu de um grupo, mas que foi depois esse grupo, esse grupo foi, agora é um grupo que está dentro da Google Cloud, enfim, nessa pesquisa eles pesquisaram sobre diversos fatores, que influenciam também a performance de delivery. E esses fatores, eles conseguiram condensar isso nessas quatro grandes variáveis que eu já mencionei, que falam que, assim, se você fizer ações para melhorar essas variáveis, você está indo em um caminho de eficiência da sua performance organizacional, e aí eles dão uma série de capabilities, que são esses como melhorar, porque, assim, eles te dão lá: “Beleza, mede isso aqui, mas para você melhorar essas coisas aqui, essas são as capabilities”. E aí ele não fala justamente assim: “Se você melhorar essa capabilities você vai incidir diretamente na velocidade, por exemplo, no lead time”, porque é um tanto de coisa que incide em um tanto de coisa, entendeu? Então por isso que eu falei desse negócio do grafo, mas os dois, tanto o Developer Velocity, quanto o DORA, eles têm um forms lá, um jeito de você medir, de você responder para a sua empresa.
Pedro: Sim. O DORA tem até o Quick Ckeck online, não é? Você pode ir lá e responder.
Fernanda: Exato. O DORA tem o Quick Check, que são essas quatro variáveis, você responde, ele te fala assim: “O seu nível de performance é baixo, deixa eu te ajudar a priorizar às suas ações?”, e aí se você pede ajuda, aí ele te abre todas essas capabilities que eu estou te falando, e você responde, ele te fala assim: “Olha, de acordo com as suas respostas, me parece que o melhor que você deveria investir agora é em melhorar sua qualidade de código”, porque, de acordo com a pesquisa dele, faz todo sentido isso, é como se fosse uma maturidade de times mesmo. Se eu tenho problema na minha qualidade de código, não quero melhorar o meu monitoramento, que eu preciso melhorar minha qualidade de código. É tipo isso.
Pedro: E ele considera até o segmento que você está inserido, não é?
Fernanda: Isso. Exatamente.
Pedro: Se é indústria, se já é uma fintech, se já é um mercado mais maduro ou não.
Fernanda: Exatamente. E o Developer Velocity faz um negócio semelhante, ele abre essas 46 coisas, atributos aí, e te pede para você ir respondendo e te dá o seu score. Então ambos têm isso aí.
Pedro: Legal contar também sobre o processo do DORA. DORA é o grupo, não é? Mas o relatório que eles produzem já é produzido anualmente há oito anos, não é?
Fernanda: Sim.
Pedro: Que é o Ox Acceleretor, então os caras estão refinando isso há bastante tempo, e a desse ano eles trouxeram coisa nova aí sobre confiabilidade, enfim, algumas coisas legais lá, e interessante que na base da pesquisa deles ninguém ficou no grupo de elite, não é? Em 2022. Eles acham que eles até tentam explorar um pouco, pode ter sido o cenário pós-pandemia, e tal, eles não aprofundam muito nisso, mas faz a gente refletir um pouco também. Parece que a régua subiu, ou todo mundo caiu um pouquinho, não sei o que aconteceu, mas é bem interessante que eles fazem uma análise muito mais completa, o relatório é até muito maior, uma leitura um pouco mais complexa, assim, mas é bem interessante.
Diulia: Pois é. De tudo que a gente vem conversando aqui sobre o que a gente viu, que a gente tem experimentado, como é que tem sido, o que é a conclusão que vocês tiram sobre o DORA, com o Developer Velocity, com outras referências também que a gente acaba tendo contato, sendo mais ou menos técnicas, mais de negócio, enfim, como é que vocês acreditam que esses materiais podem influenciar, de uma maneira saudável, nas organizações, do ponto de vista de contribuir para evolução contínua de como a gente se organiza?
Vinícius: Bom, a forma que eu acho que é uma boa influência, é um bom uso, acho que é um pouco parecido com o que eu falei antes, aí eu vou falar, talvez, mais direcionado para a pergunta aqui, mas vou tentar ser mais sucinto. Mas, assim, o mais importante, na minha visão, é você ter como avaliar a sua jornada digital. Eu vou até falar jornada, porque, igual a gente está vendo aqui, na dti, atualmente, antes a gente falava, às vezes a gente ainda fala, a transformação digital, mas, no fundo, a maior parte dos clientes já estão transformados, de alguma forma, entendeu? O que não significa que foi uma boa transformação. Mas, no fundo, não adianta só estar transformado, você pode ter ou estar com a sensação de ter sido transformado, porque o cenário das empresas, da sociedade, a gente está vendo aí com o ChatGPT, agora, a gente não sabe nem o que ai acontecer com a humanidade, se vai acabar a humanidade por causa disso, mas a todo momento a gente tem novidades digitais, e assim que o artigo começa, mostrando que hoje em dia praticamente tudo é influenciado por tecnologia, então não tem como você escapar disso. Então é importante que você tenha algum tipo de mecanismo, como se fosse sensores vinculados ali na sua estrutura organizacional, que são capazes de te mostrar algum tipo de informação relevante para você navegar e se orientar para frente, e aí não usar uma ferramenta dessa, ou você pode inventar uma em casa, igual aqui na dti a gente tem, mas a gente não inventou ela do nada, a gente foi mais ou menos se inspirando nessas ferramentas, eu costumo falar que, aqui nas reuniões de tribo, que é um certo até amadorismo, entendeu? Você está ali meio que trabalhando com uma gestão eventual, ou seja, tipo assim, um dia você tem em um squad, ou em uma tribo, você tem um bom líder e está indo bem, mas no outro a pessoa não é tão boa assim, não está lembrando das coisas, então, tipo assim, é muito amador, não é? Então é importante que você se oriente por algo. Esse algo, igual eu falei, você pode inventar ele, ou você pode copiar algum outra lugar, ou você pode se inspirar, e esse algo é importante que ele tenha as variáveis ali, algum tipo de variável, algum tipo de desdobramento, que tenha coerência com o mundo digital. Então, por exemplo, aqui na dti a gente divide em quatro coisas, na verdade são quatro, mais outras. As quatro são as cór, que a gente fala do produto, design, engenharia e operações, mas também tem a parte pessoas e a parte financeira, no mínimo, podendo ter outras também. Então você tem que ter sensores organizacionais que medem essas coisas, e que te mostrem se determinadas coisas estão indo para um caminho que você desejava, e normalmente isso tem que estar vinculado, nesse ponto aí eu acho que a análise do artigo é muito boa, ou pelo menos a intenção é muito boa, em relação a colocar o que você está buscando. No caso lá, ele está buscando o que? Resultado financeiro e alguns outros fatores, porque você pode ter um resultado financeiro e ser uma empresa que é péssima, que faz todo mundo ficar doente, então, tipo assim, não necessariamente é uma boa empresa, não é? Então, para mim, o objetivo, o que essas, tanto DORA, quanto esse da McKinsey, o nosso, da dti, o que ele se propõe é te dar um formato de ter sensores e te ajudar a guiar uma jornada digital.
Pedro: Eu acho até, talvez ajude a responder um pouco da sua pergunta também, Diulia, a gente, no contexto que eu estou inserido, porque hoje são três tribos, a gente está com o mecanismo de produto certo, certo produto, rodando, mais ou menos, desde setembro do ano passado, a versão que a gente tem agora, por exemplo. E a gente fez aí umas cinco, seis rodadas de medição, em algum momento no meio do caminho eu li o artigo da McKinsey e eu fiz essa comparação, sabe? Eu bati os índices que a gente estava usando, com os drivers que o artigo levantou, e eu percebi uma certa intersecção, e isso inspirou a incluir coisas, excluir outras, assim como o DORA também, fiz a mesma coisa, rodei o Quick Check lá, em todos os times, para a gente poder comparar um pouco do resultado, o que cada um estava me dizendo de maturidade dos meus times, e isso com certeza me inspirou para um segundo ciclo, mas mais ainda do que isso, o resultado do primeiro ciclo, esses sensores que o Vinição falou, me apontaram, por exemplo, para duas ou três dimensões lá, de produto, que a gente viu que está sendo o ponto fraco ainda dos times. Por exemplo, era uso de métricas para orientar, roadmap, visão de produto, o que é até um negócio um pouco característico desses ambientes de indústria, um pouco mais convencional, que é o caso do meu cliente. E agora eu vou buscar outras referências que me ajudem a navegar um pouco mais nesse desafio, já que os meus sensores revelaram isso, entendeu? Então acho que essa é a forma de usar.
Fernanda: É, exatamente assim. Vejo bem isso aí, de dar transparência para esses indicadores. O Vinição falou um negócio há algum tempo já, em relação forecast, que eu acho que isso é bem importante também, a gente saber o que a gente deve melhorar. Como eu falei até agorinha mesmo também, em relação a priorizar, saber priorizar, não adianta eu priorizar um negócio que eu não tenho maturidade para executar ainda.
Pedro: Exato.
Fernanda: E isso é bem importante, eu acho que essas ferramentas nos ajudam nisso também. E o nosso PCCP, o produto certo, certo produto, ele também indo nesse caminho, e com ajuda das pessoas mais seniores ali, estando em contato com os times, também ajuda esses times, que às vezes têm senioridades mais baixas, a priorizar as melhores ações e acompanhar o forecast, porque realmente essa mentalidade e melhoria contínua que eu acho que é o mais importante também, de a gente realmente dar visibilidade, é a mesma coisa dos princípios do Scrum mesmo, de dar visibilidade, dar transparência, para que a gente consiga se adaptar e melhorar a cada ciclo.
Pedro: É isso aí. Não é só ter o sensor, não é?
Fernanda: É, não.
Pedro: Tem que retroalimentar. O Vinição que fala isso aí direto. Legal.
Diulia: Bom, pessoal, acho que tivemos um episódio bem repleto de reflexões, e a gente gostaria também de ter a visão de vocês, então leiam o material, se inspirem.
Pedro: É, se eu puder deixar a reflexão, é essa, assim, leiam, estudem as referências, vejam com olhar crítico e adapte para o seu contexto, para o que é importante para você. Acho que é isso. E não deixem de olhar o forecast, fazer forecast, não só medir o forecast, como a Fernandinha comentou.
Diulia: Conte para a gente também, nas nossas redes sociais, assinem a Newsletter, que vocês podem tanto acessar pelo LinkedIn, como também receber por e-mail, acessem o nosso site, a gente está com vários materiais ricos e interessantes para poder serem consumidos, e vamos trocando figurinha, vamos conversando por aí.
Pedro: Isso aí. E sigam também, no Instagram, @osagilistas.
Fernanda: e @entre.chaves.
Pedro: Isso aí.
Fernanda: Isso aí.
Pedro: Bacana. Valeu.
Fernanda: Valeu, gente.
Vinícius: Legal, pessoal. Obrigado.
Fernanda: Até a próxima. Tchau, tchau.
