: :
os agilistas

Seu produto precisa gerar valor no presente e no futuro

Seu produto precisa gerar valor no presente e no futuro

os agilistas
: :

Vinícius: No artigo – estou me lembrando aqui – nessa parte de produto, que ele coloca uma macrocategoria organizacional, e que também – uma crítica que eu faço – 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. Então, acho que outra coisa também: ele não coloca muito claramente a parte de design.

Pedro: Quase não cita.

Diulia: A minha lágrima desceu. Fiquei lá procurando design, falei: “que é isso? Não é possível”. Não aparece.

Vinícius: 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é, na minha visão, apesar de ele não colocar, muitas vezes, a palavra causalidade, ele está claramente tentando estabelecer essa causalidade ao longo dos comentários no artigo. Mas ele coloca que não existe uma causalidade específica de alguma dimensão de produto, mas existe uma no geral. 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… até antes, uma reflexão: por que alguém usaria isso? Por que e como uma empresa usaria isso? O motivo básico é, na minha visão: você quer, de algum jeito, saber se você, com as suas iniciativas digitais, está no momento presente com um 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 o suficiente para ter condições e musculatura para, no futuro, continuar tendo essas competências. Então, daria para falar que é como se fosse o seguinte: no fundo, você está querendo acompanhar se você está gerando valor no presente e se você está caminhando para ter condições de gerar valor no futuro. Então, o que refletiria isso seria o próprio valor, o resultado das empresas que ele está colocando; mas um proxy para isso seria o índice, que ele coloca o DVI. 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 acompanhar só isso aqui, é um negócio muito abstrato. Preciso quebrar isso em outras dimensões, e aí ele quebra nessas 46 dimensões. Fazendo um paralelo com o Dora, eu acho interessante o Dora porque ele coloca como se fosse uma camada intermediária, que seria alguns indicadores que, normalmente, são consequência de fatores menores, de competências menores, eles chegam em quatro indicadores que têm a ver com leading time, tempo de reparo – se você consegue reparar as coisas rapidamente, se você consegue identificar problemas rapidamente. Então, eu acho um pouco mais… um método melhor. E aí, principalmente, já que você está querendo acompanhar isso e sentir que a sua organização está se transformando ou está mantendo as competências digitais, é muito importante que você acompanhe essas coisas no tempo e que você estabeleça alguns forecasts baseados 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 faz muita diferença ter as melhores ferramentas do mundo – igual o artigo tende a te fazer pensar que seja uma condição – você precisa pensar em como vai fazer isso, você precisa projetar, daqui a três meses, por exemplo… é como se você definisse objetivos organizacionais que têm a ver com isso. E aí você vai avaliar onde que você vai colocar essas ferramentas – você não pode colocar em qualquer lugar. Você tem que avaliar: vai ser uma ferramenta de DevOps, vai ser uma ferramenta de planejamento, um Jira da vida, um Azure DevOps, alguma dois do tipo? Então, esse, para mim, é o ponto mais importante de disciplina e é o que a gente tenta fazer aqui na dti com um certo produto, acompanhando passado, presente e futuro – sendo o futuro, o forecast que a gente estabelece. Para mim, ter essa disciplina é uma das coisas mais importantes que influenciam, inclusive, no resultado que você vai conseguir, utilizando alguma metodologia nesse sentido.

Fernanda: Justamente. Fiquei ouvindo você falando e, realmente, o developer velocity cria uma objetividade, um indicador de te falar: “esse tanto de coisas de lead, que se você investir nisso, nisso e aquilo, estou te apontando que você vai melhorar a sua performance”. 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, que é o contrário: dar os indicadores de leg, que são esses indicadores mais difíceis de mudar; mas ele não te dá os indicadores de lead. Na verdade, ele fala sobre as capabilities, o Dora fala sobre como dar esses indicadores de leg que o Vinição mencionou, que são leadtime de entrega, frequência de deploy, percentual de falha e tempo de rollback – esses quatro indicadores, ele dá, falando que: “esses indicadores, se você fizer essas outras coisas certo, vão ser sensibilizados”. Mas então parece que eles são meio que complementares mesmo: um te fala, objetivamente, o que mudar e como medir; e outro te fala: “não, 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 sejam meio que 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, e o Dora foca mais amplo, ele fala sobre testes, 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 fica falando muito sobre causalidade. No Dora, é o contrário mesmo. No site do Dora, tem até um grafo – aqueles gráficos que são grafos mesmo – que relaciona todas essas dimensões de forma não-linear mesmo. Uma vai influenciando a outra, que vai influenciando a outra. Então, é total um grafo que você consegue ver que o negócio é uma nuvem. Ele, de fato, não tem uma causalidade muito clara. Eu acho que isso é legal do Dora, realmente.

Vinícius: No artigo – estou me lembrando aqui – nessa parte de produto, que ele coloca uma macrocategoria organizacional, e que também – uma crítica que eu faço – 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. Então, acho que outra coisa também: ele não coloca muito claramente a parte de design. Pedro: Quase não cita. Diulia: A minha lágrima desceu. Fiquei lá procurando design, falei: “que é isso? Não é possível”. Não aparece. Vinícius: 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é, na minha visão, apesar de ele não colocar, muitas vezes, a palavra causalidade, ele está claramente tentando estabelecer essa causalidade ao longo dos comentários no artigo. Mas ele coloca que não existe uma causalidade específica de alguma dimensão de produto, mas existe uma no geral. 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… até antes, uma reflexão: por que alguém usaria isso? Por que e como uma empresa usaria isso? O motivo básico é, na minha visão: você quer, de algum jeito, saber se você, com as suas iniciativas digitais, está no momento presente com um 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 o suficiente para ter condições e musculatura para, no futuro, continuar tendo essas competências. Então, daria para falar que é como se fosse o seguinte: no fundo, você está querendo acompanhar se você está gerando valor no presente e se você está caminhando para ter condições de gerar valor no futuro. Então, o que refletiria isso seria o próprio valor, o resultado das empresas que ele está colocando; mas um proxy para isso seria o índice, que ele coloca o DVI. 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 acompanhar só isso aqui, é um negócio muito abstrato. Preciso quebrar isso em outras dimensões, e aí ele quebra nessas 46 dimensões. Fazendo um paralelo com o Dora, eu acho interessante o Dora porque ele coloca como se fosse uma camada intermediária, que seria alguns indicadores que, normalmente, são consequência de fatores menores, de competências menores, eles chegam em quatro indicadores que têm a ver com leading time, tempo de reparo – se você consegue reparar as coisas rapidamente, se você consegue identificar problemas rapidamente. Então, eu acho um pouco mais… um método melhor. E aí, principalmente, já que você está querendo acompanhar isso e sentir que a sua organização está se transformando ou está mantendo as competências digitais, é muito importante que você acompanhe essas coisas no tempo e que você estabeleça alguns forecasts baseados 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 faz muita diferença ter as melhores ferramentas do mundo – igual o artigo tende a te fazer pensar que seja uma condição – você precisa pensar em como vai fazer isso, você precisa projetar, daqui a três meses, por exemplo… é como se você definisse objetivos organizacionais que têm a ver com isso. E aí você vai avaliar onde que você vai colocar essas ferramentas – você não pode colocar em qualquer lugar. Você tem que avaliar: vai ser uma ferramenta de DevOps, vai ser uma ferramenta de planejamento, um Jira da vida, um Azure DevOps, alguma dois do tipo? Então, esse, para mim, é o ponto mais importante de disciplina e é o que a gente tenta fazer aqui na dti com um certo produto, acompanhando passado, presente e futuro – sendo o futuro, o forecast que a gente estabelece. Para mim, ter essa disciplina é uma das coisas mais importantes que influenciam, inclusive, no resultado que você vai conseguir, utilizando alguma metodologia nesse sentido. Fernanda: Justamente. Fiquei ouvindo você falando e, realmente, o developer velocity cria uma objetividade, um indicador de te falar: “esse tanto de coisas de lead, que se você investir nisso, nisso e aquilo, estou te apontando que você vai melhorar a sua performance”. 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, que é o contrário: dar os indicadores de leg, que são esses indicadores mais difíceis de mudar; mas ele não te dá os indicadores de lead. Na verdade, ele fala sobre as capabilities, o Dora fala sobre como dar esses indicadores de leg que o Vinição mencionou, que são leadtime de entrega, frequência de deploy, percentual de falha e tempo de rollback – esses quatro indicadores, ele dá, falando que: “esses indicadores, se você fizer essas outras coisas certo, vão ser sensibilizados”. Mas então parece que eles são meio que complementares mesmo: um te fala, objetivamente, o que mudar e como medir; e outro te fala: “não, 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 sejam meio que 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, e o Dora foca mais amplo, ele fala sobre testes, 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 fica falando muito sobre causalidade. No Dora, é o contrário mesmo. No site do Dora, tem até um grafo – aqueles gráficos que são grafos mesmo – que relaciona todas essas dimensões de forma não-linear mesmo. Uma vai influenciando a outra, que vai influenciando a outra. Então, é total um grafo que você consegue ver que o negócio é uma nuvem. Ele, de fato, não tem uma causalidade muito clara. Eu acho que isso é legal do Dora, realmente.

Descrição

Este conteúdo é um corte do nosso episódio: “#237 - Eficiência digital: excelência de software e performance nos negócios”.   

Neste corte, Vinicius Paiva COO e Fernanda Vieira Head de engenharia da dti digital, compartilham insights valiosos sobre produto usando o artigo Developer Velocity, da Mckinsey & Company como base. Além disso, também fazem uma comparação com os resultados da pesquisa DORA Metrics.  

Bateu a curiosidade? 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.