Marcelo Szuster: Bom dia, boa tarde, boa noite. Vamos começar mais um episódio de Os Agilistas, mais uma vez aqui com o Vinição. E aí, Vinição, tudo bom?
Vinicius: E aí pessoal, tudo bom? Vamos lá.
Marcelo Szuster: Quem está ouvindo não está sabendo disso, mas o Vinição está ali no estúdio, todo confortável, preponderante, a gente aqui de longe.
Vinicius: Estou tranquilão aqui.
Marcelo Szuster: No foco.
Vinicius: Sentindo várias cadeiras vazias.
Marcelo Szuster: Então, gente, hoje nós vamos trazer um tema aqui que eu acho que é bem pouco explorado, então vai ser interessantíssimo aqui, que é o seguinte: quando a gente fala aí de produtos digitais a gente sabe que todo time que está desenvolvendo um produto digital ele faz lá reviews ou análises críticas, o nome que se quiser dar, para poder discutir assuntos relevantes, as vezes os assuntos vão desde se o time está gerando valor, se o time está unido, etc., até um assunto extremamente importante que é: se o processo que aquele time segue está sendo bem executado. E uma coisa que a gente observa que é muito comum os times discutirem esse processo à luz de engenharia, a luz da produção do software, dos famosos indicadores que a gente cita muito aqui, nós vamos falar daqui a pouco de como saber se um software está sendo feito com um desempenho correto, se você está fazendo releases suficientes e vários outros indicadores que controlam o processo de desenvolvimento. Só que é curioso dizer o seguinte, o sucesso de um produto, como a gente vem falando muito aqui, consiste muito em fazer o produto certo, saber se está fazendo o produto certo. A gente sempre fala: tem que fazer certo o produto e fazer o produto certo. E fazer o produto certo não é uma arte, é uma técnica que segue um processo, e esse processo, a gente quis trazer esse tema aqui, a gente começou a perceber que esse processo, claro, tudo é um processo, mas essa parte do processo que foca mais em fazer o produto certo é uma parte do processo que muitas vezes não é submetida tão criteriosamente a uma análise crítica para poder evoluir também. Porque, obviamente, um time não pode ficar só melhorando na outra parte, é como se ele tivesse só fazendo certo o produto e não evoluir o processo de fazer o produto certo. É esse tema que vamos explorar aqui hoje. Nós temos dois convidados que vão se apresentar agora, primeiro a Flávia. Tudo bem, Flávia.
Flávia: Tudo bom, Szuster. Bom dia, boa tarde e boa noite. Muito bom estar aqui com vocês. A primeira vez que eu estou participando aqui do podcast, sou ouvinte. E é muito legal participar desse bate-papo de um assunto que eu acho bem relevante que, como o Szuster falou, não á tão falado, então eu acho bom a gente ter essa discussão aqui para agregar isso aí para todo mundo que está ouvindo a gente.
Marcelo Szuster: Só fala um pouquinho sobre você rapidinho assim, só para o ouvinte te conhecer.
Flávia: Isso, eu ia falar sim porque é que eu estou aqui. Eu estou na DTI vai fazer uns dois anos agora em dezembro, estou atuando como product ower. Na verdade, eu entrei como scrum master, eu acho que por isso que aí já fiz um link aí com essa questão das métricas, então acho que esse período de transição trouxe um pouco dessa necessidade de análise desse tipo de métrica também agora aqui atuando na área de produto.
Marcelo Szuster: Muito bacana. Temos aqui também o Rafael Salvio. Chamarei você de Rafael ou de Salvio.
Vinicius: Bom dia, Rafa.
Rafael Salvio: Tudo bom, Szuster. Tudo bom, pessoal. Pode ser de Salvio mesmo. Eu costumo brincar que Rafael é um nome muito comum, todo canto que a gente vai sempre tem pelo menos um, então o apelido ficou o sobrenome mesmo.
Marcelo Szuster: Igual eu com Szuster, ninguém me chama de Marcelo não.
Rafael Salvio: Pois é, fica mais pessoal.
Marcelo Szuster: Mas então se apresente aí, Salvio.
Rafael Salvio: Tudo bom, pessoal? Bom, eu sou Rafael Salvio, estou aqui na DTI acerca de dois anos também, um período bem próximo aí da Flávia. Hoje eu venho aqui com uma perspectiva de (inint) [00:03:29] de SM, atualmente estou numa transição de carreira aqui dentro da DTI, fazendo uma transição aí para um novo desafio como TM, mas ainda atuando um pouquinho ali na ponta da operação como scrum master.
Marcelo Szuster: Muito bacana. Então eu queria que começasse assim, nós estamos falando aqui de que existe todo um processo de desenvolvimento integrado, mas que parte desse processo tem muito foco em fazer o produto certo, é a parte que a gente costuma chamar de discovery contínuo, não é? A gente já fez episódios aí especificamente sobre isso, mas eu acho que a Flávia podia explicar o que é esse discovery contínuo. É porque nós vamos falar sobre métricas de um processo, então quem está ouvindo saber de que processo estamos falando.
Flávia: Boa. Você roubou a parte da minha introdução viu, Szuster. Eu ia justamente fazer esse link do fazer o produto certo. É um movimento que está rolando aqui na DTI e, assim, está tendo alguns episódios aqui no Os Agilistas também, e assim é desafiador realmente, e aí tem um episódio específico falando sobre os pilares para criar soluções que geram valor. E aí quando a gente fala do discovery ainda é uma palavra que amedronta algumas pessoas de produto, porque é um processo complexo, e a gente ter uma orientação nesse sentido é muito bom. Então, assim, quando a gente fala sobre o discovery eu acho que tem que estar claro para todo mundo que a ideia principal de discovery é para mitigar riscos. Então, assim, se a gente ter isso em mente assim as vezes fica até um pouco mais fácil lidar com esse processo no dia a dia. E aí quando a gente fala de discovery contínuo, a ideia do discovery contínuo para pessoas de produto, que conseguem, que podem rodar, que conseguem inserir no fluxo de rotinas delas, terem o discovery contínuo, é que essas pessoas elas têm contato constante com os usuários. Pessoas de produto elas tomam decisões diariamente, então se elas têm contatos diários com os usuários, conseguem ter essa rotina elas conseguem trazer esses insights desses contatos diários com os usuários e trazer isso para as suas decisões diárias. E aí, assim, é bom a gente só… isso já foi falado também em alguns episódios aqui, mas só para a gente enfatizar um pouquinho sobre o que é que seriam esses riscos, e que até faz um link um pouco sobre as métricas que a gente… que é interessante a gente levantar quando a gente está falando do processo de discovery. Que a gente tem quatro riscos assim principais que a gente sempre tenta avaliar quando a gente está rodando esse processo: o risco de valor, o risco de usabilidade, o risco de viabilidade ou o risco de negócio, e o que eu queria assim dar uma enfatizada maior é no risco de execução, que também a gente chama de risco técnico. Nesse risco o que é que a gente está querendo mitigar? A gente quer realmente entender se a equipe, o time de desenvolvimento ele tem capacidade de executar essa solução que a gente está propondo. Existem riscos que podem comprometer no desenvolvimento dessa solução? Então esse é um risco que a gente tenta mitigar durante esse processo e que envolve a equipe de desenvolvimento. Eu não queria falar muito sobre time de desenvolvimento, time de produto, que eu sei que isso aí e meio polêmico a gente fazer essa separação, mas eu queria só, assim, que é claro para todo mundo que existem essas diferentes fases, que a gente sabe que o time de produto, o time de design, as pessoas de produto e as pessoas de design elas estão ali atuando nesse processo de discovery, que antecipam as entregas das pessoas ali de desenvolvimento. E a gente ter esse fluxo, esse fluxo de discovery bem definido facilita com que a gente consiga envolver essas pessoas, ou seja, essas pessoas do desenvolvimento, que existem conexões em algumas das etapas nesse fluxo de discovery, elas têm uma capacidade de poder ajudar a gente nesse processo. Então por isso que eu acho que é muito importante a gente ter esse fluxo, assim como o fluxo de delivery bem definido, mas o fluxo de discovery também bem definido para a gente fazer essas conexões nos momentos certos.
Marcelo Szuster: Não, perfeito. Eu gosto assim, acho interessante quando fala discovery e contínuo. Porque, assim, o discovery já parte de uma posição de humildade, eu tenho que descobrir o que fazer para poder eliminar os riscos. E não só tenho que descobrir, tenho que descobrir isso continuamente assim. Porque, assim, é bom repetir essas coisas, porque isso está no cerne lá do agilismo, partir dessa posição de aprendizado. E aí então, Salvio, eu queria te botar na conversa. Nós vamos falar então, olha, dessa… como a Flávia tentou salientar, existe um time que tem uma missão única ali, mas nesse time tem papéis que focam mais em uma coisa ou outra. E aí quando a gente olha para o desenvolvimento a gente já tem um conjunto de métricas que são mais solidamente utilizadas, e quando a gente olha para essa parte de discovery, para poder controlar o processo, a gente já não tem isso tão claro. É disso que vamos falar. Aí eu pergunto para o Salvio, para a gente poder ir fazendo os contrastes: Que métricas são essas do desenvolvimento que a gente normalmente usa? Para a gente depois poder fazer o paralelo com as métricas do discovery.
Rafael Salvio: Não, bacana. Hoje, na gestão de projetos, quando a gente olha assim da perspectiva do fluxo de desenvolvimento é muito comum a gente ouvir sobre várias métricas que são utilizadas, óbvio que contexto diferentes vão empregar também métricas diferentes, mas no geral o que é que a gente sempre presente com isso: é garantia da nossa saúde do nosso progresso, a gente ter um progresso consistente. Então quando a gente fala, por exemplo, em métricas que vão ditar ali o ritmo de entrega do time, se a gente quer um acompanhamento, a gente faz um (inint) [00:08:42] down; a gente tem um (TropOut) [00:08:43] out, dependendo se a gente usa no Scrum; se a gente está seguindo o Kanbam; a qualidade de entrega, que também é uma das métricas que hoje a gente tem atuado muito forte aqui na DTI. Então qual que é a nossa frequência de implantação, qual que é o nosso tempo de implantação, a nossa taxa de falhas, em casos quando a coisa dá errado, o tempo para restauração daquele serviço. Então tudo isso são conjuntos de métricas que a gente observa sempre com o objetivo de dar visibilidade as pessoas interessadas daquelas informações que elas precisam, isso vai auxiliar a identificação de pontos de atenção, isso vai facilitar o entendimento do que está dando certo ou do que não está dando certo. E da perspectiva de desenvolvimento a gente faz isso com muito mais naturalidade (inint) [00:09:28] daquela perspectiva do discovery, naquele fluxo do upstream. Isso também é necessário. A gente precisa entender e ter essa capacidade de se adaptar com as coisas que estão dando certo ou não, e aí nesse ponto tem ainda uma infinidade de possibilidades para explorar.
Marcelo Szuster: Vocês usaram o tema aí upstream e downstream, podia clarear isso para o nosso ouvinte?
Flávia: Claro. Aí até antes de falar sobre essa nomenclatura muito utilizada no método Kanbam, até para fazer um link sobre a… o porquê de analisar métrica discovery e que eu cheguei já querendo fazer isso. É como eu fiz essa transição para SM, eu cheguei aqui e eu fiquei um pouco incomodada que eu não conseguia visualizar muito essa gestão das atividades de produto e design, e eu falei: “Não, a gente… assim, a gente precisa ver como que isso está funcionando, alguns gargalos que estão acontecendo nesse fluxo”. E na minha atuação como SM eu confesso que eu realmente foquei muito na operação de desenvolvimento, eu não olhava tanto para essas atividades que estavam rodando no upstream. Então quando a gente fala de upstream a gente está falando ali das incertezas, de onde nascem as ideias e onde está realmente o fluxo de discovery. E aí quando a gente fala de downstream a gente está falando da execução em si, onde ali a gente gerencia o fluxo das demandas, é onde a gente está focando realmente nas entregas que precisam ser feitas.
Marcelo Szuster: E é interessante, porque quando você fala em upstream e downstream, não é, do jeito que você colocou “Ali tem mais risco, aqui…”, realmente essa visão do scrum master, que é gerir uma equipe, é como se houvesse jeito de gerir mesmo a parte do desenvolvimento, o resto você alocou e é isso aí, não é?
Flávia: (Inint) [00:11:04].
Marcelo Szuster: As vezes não tem nem o básico, antes de medir não tem nem um planejamento básico, assim, é como se a equipe que está fazendo essas atividades de upstream ela, de alguma forma, se você alocou, o que tiver que fazer ela dá conta de fazer, você presume que dá conta, presume que está fazendo com a produtividade certe, presume que… assim, é tudo uma… É curioso isso, como que a gente é meio… Qual será a origem filosófica disso? Talvez é porque fica essa associação de que a parte mais técnica é onde você efetivamente tem mais controle e gasta mais ali, porque é um time maior, e talvez que a outra parte… Eu não sei. O que é que vocês acham?
Flávia: E aí, assim, até contando um pouquinho do contexto aqui da nossa tribo, eu acho que o Salvio chegou um pouquinho depois dessa definição. A gente realmente sentiu a necessidade de definir melhor esse fluxo do upstream, inclusive tem um nome isso, chama Cangurus Upstream Flow. A gente reuniu inclusive presencial, a gente foi na DTI, a gente conversou sobre esse fluxo do upstream, a gente já tinha identificado alguns gargalos antes mesmo de a gente medir, realmente medir e olhar para essas métricas, e a gente definiu em fases, que até depois eu posso até comentar, a gente definiu em algumas fases e principalmente a gente fez a relação das pessoas envolvidas em cada uma dessas fases. E aí assim, beleza, a gente tem agora esse fluxo de certa forma bem definido e visível para todos, não é? Então, assim, para também fomentar o entendimento desse fluxo também, que não é tão conversado. Então, assim, as pessoas já estão ali esperando a feature para ser desenvolvido, mas tem muita coisa que é feita antes disso.
Vinicius: Só um ponto. Assim, você falou no início do episódio que, vamos dizer assim, o objetivo dessa parte que está mais orientada a produto, que a gente está chamando aqui de upstream, é a redução dos riscos que você citou. Mas, assim, essa métricas que você está mencionando estou entendendo que o objetivo delas é mais produtividade nessa fase, dentro dessa fase, é isso mesmo ou não? Também está com o objetivo de redução de risco?
Flávia: Não, é mais para gente… Assim, a gente até chegou a conversar um pouquinho sobre isso. A ideia principal era entender como a gente estava rodando esse fluxo, como estava funcionando esse fluxo considerando as pessoas que estavam envolvidas ali, entrou muitas pessoas novas na época, quando a gente fez essa estruturação do fluxo, a gente estava tendo alguns gargalos que o time de desenvolvimento não conseguia apoiar a gente nesses momentos, nessas etapas para mitigar os riscos técnicos. Então a ideia principal é: vamos olhar o nosso fluxo e entender o que precisa ser melhorando, tanto oportunidades de melhoria, como alguns gargalos, mas não focando, por exemplo: “Estamos mitigando riscos de valor?”, não. A ideia é assim: vamos olhar o fluxo, a gente quebra o fluxo e entende como que está o andamento dessas atividades e que possíveis melhorias a gente pode fazer para que esse fluxo funcione melhor. Seria mais nesse sentido.
Marcelo Szuster: Então só para ficar claro para quem está ouvindo aqui. O primeiro passo para poder, digamos assim, profissionalizar isso aí, foi assim: vamos dar visibilidade.
Flávia: Vamos dar visibilidade.
Marcelo Szuster: Quem é uma coisa bem de Kanbam, não é? Tem todo um livro que eu li uma vez, ele chama acho que chama Make (inint) [00:14:03], sei lá, alguma coisa assim, que é assim: primeiro, você tem que tornar visível para a organização que isso está acontecendo.
Flávio: Exatamente.
Marcelo Szuster: Eu vi que o Salvio quer falar alguma coisa não é, Salvio? Eu acho que eu…
Rafael Salvio: Não, exatamente. Nesse sentido é importante a gente, primeiro, dar visibilidade, até pelo momento de estruturação que a gente ainda se encontra, a gente quer organizar esse fluxo para… É meio que assim, a gente tem… no fluxo de upstream a gente tem uma orientação muito mais a ideias, então a gente tem muita liberdade de explorar. E como que a gente se organiza para gerenciar ideias, que as vezes não tem um início, um meio e um fim tão bem definido quanto um plano de desenvolvimento, que as vezes já é um algo mais consolidado, um pouco mais definido. Óbvio que tem também as suas peculiaridades, tem as suas surpresas, mas a ideia é essa organização para que a gente consiga melhorar a eficiência desses dois fluxos e num segundo momento a gente conseguir colher benefícios no final da conta, a gente garantir que aquele fluxo como um todo tenha também as suas evoluções e as suas melhorias.
Marcelo Szuster: Mas aí eu pergunto… Eu acho que a gente então exauriu bem essa parte aí do upstream, downstream e da necessidade de medir o upstream também. Vocês conseguem dar uma visão geral do que é esse fluxo e dar uns exemplos do que a gente poderia medir? Para ficar mais tangível aí para o nosso ouvinte.
Flávia: Eu acho que eu comentei já, mas vou até falar de novo, que eu fiquei incomodada, que eu não conseguia ver a gestão a vista das atividades de produto e design. E aí logo que eu cheguei, eu estava ainda num período de transição, e eu gosto bastante de dashboard, eu montei um dashboard explorando assim alguns gráficos, algumas ferramentas da ferramenta que a gente utiliza de gestão de backlog, enfim. E aí eu montei esse dashboard, confesso que eu fiz uma mistura de upstream e downstream, utilizei algumas métricas que são mais utilizadas no downstream, mas a ideia era realmente testar, avaliar o que é que fazia sentido, o que é que traria insights para a gente para poder melhorar esse processo. Quando a gente fala de upstream, assim, a principal métrica, a métrica mais utilizada e mais falada no mercado para acompanhamento desse fluxo é o lead time, que também é acompanhado também no fluxo de downstream, mas essa também é uma das métricas mais utilizadas. Então quando a gente fala de lead time é: beleza, eu quero identificar quanto tempo que durou da identificação da oportunidade até essa solução chegar ali no delivery. Então qual é esse tempo? Então essa é uma das métricas mais utilizadas. Mas aí só para, assim, até deixar mais claro para o pessoal que está escutando a gente. Como que eu consegui medir fazendo essa miscelânia de gráficos e tudo mais, mas o que é que foi muito importante: a gente ter estabelecido essas diferentes fases dentro desse fluxo. Aí eu vou comentar quais são etapas, lógico que essas etapas também são utilizadas por outros contextos, mas para vocês verem assim: “Ah, entendi. Então você utilizou tal métrica, talvez porque ali podia ter um gargalo. Beleza, se tem um gargalo ali naquela etapa pode ser tal, tal coisa”. E aí como que a gente quebrou esse fluxo do upstream? A gente colocou, primeiro, uma fase, que é o entendimento do problema, então ali a gente vai identificar as dores, a gente vai identificar as identidades dos usuários, as oportunidades. Então, beleza, a gente tem essa primeira etapa. Depois a gente passa a definição da hipótese em si. A gente já sabe as personas que a gente está tentando validar, qual que é o problema, tem essas dores mapeadas e então a gente faz essa definição da hipótese que a gente propõe validar nesse fluxo de discovery. Passando por essa validação da hipótese a gente já traz a etapa da solução. Então nessa etapa a gente já faz ali um desenho mínimo para apresentar isso já para as pessoas de desenvolvimento para a gente já começar a avaliar se essa solução que a gente está propondo faz sentido. E aí vem uma etapa, que é uma etapa bem importante, até fazendo um link do que eu comentei sobre a mitigação dos riscos técnicos, que é a etapa de avaliação da engenharia. Nessa etapa a ideia é a gente reunir, em conjunto, tanto pessoas de produto e design quanto pessoas de desenvolvimento, para validar e fazer a ideação em conjunto dessa solução que está sendo proposta. Então essa é uma etapa que, por exemplo, poderia estar mitigando riscos técnicos que poderiam chegar lá no delivery e a gente não ter mapeado isso antes. Depois disso vem a etapa de testes. Caso seja uma solução que seja interessante a gente realmente validar testes, testes até com os próprios usuários, a gente tem essa etapa também. E a última coluna é pronta para delivery. E aí já comentando, um dos grafos que eu utilizei, que eu queria tentar realmente fazer algo bem visual, foi utilizar o gráfico (CFD) [00:18:33], que é o Cumulativo Flow Diagrama, que é muito utilizado para a etapa de downstream, para delivery. Mas como a gente tinha essas etapas bem definidas, eu falei: “Eu vou tentar adaptar, incluir nas atividade, que no caso são as hipóteses”. Então a gente pegava os work itens, que são de hipóteses, e avaliava como que estava o fluxo dessas demandas em cada uma dessas etapas. Então a partir desse gráfico a gente poderia conseguir avaliar alguns gargalos que estavam tendo em algumas dessas etapas ou também oportunidades de melhorias, porque a ideia é a gente olhar para isso e tentar tirar insights com base como que está funcionando esse fluxo. Para isso eu incluí também uma… uma sinalização de work in progress. Então eu acho que, assim, existem algumas práticas que são muito faladas na execução, no desenvolvimento em si do software, mas que podem ser também utilizadas para melhorar a rotina de trabalho das pessoas de produto e design. E aí eu coloquei, calculei quantas pessoas de produto e design que estavam atuando ali naquele fluxo de discovery e limitei o trabalho em progresso, então quando a gente passada das atividades ficava vermelho. Claro que, assim, é uma característica de trabalho diferente quando a gente compara isso com o fluxo de desenvolvimento, mas a ideia é a gente tentar realmente melhorar esse processo e ver o que é que a gente poderia melhorar nesse fluxo. Não sei se ficou claro.
Vinicius: Eu acho que até ficou claro assim, só que eu acho que seria legal, igual o Szuster comentou antes, do ponto de vista do ouvinte, você desse alguns exemplos e fosse ilustrando mais ou menos como é que isso afetaria as métricas. E se vocês conseguirem pensar em algum exemplo que tem uma validação técnica mais densa, não é, serial legal também. E uma coisa que eu também tenho curiosidade é sobre essa fase de testes dentro da etapa do upstream, porque eu sempre fico achando que o pessoal negligencia muito isso, eles já meio que dão hipótese meio que como validada, tipo assim, eles tratam muitas vezes como requisito, não como hipótese, entendeu? Tipo assim, eles já, uma vez que já está mais ou menos definida a solução ali, aquele negócio já vai para ser construído num fluxo de delivery, sendo que muitas vezes, se você fizesse uma parte de teste ali talvez você até descartaria a hipótese como solução.
Flávia: Bom, eu vou tentar fazer um link com uma parte desse fluxo que trouxe alguns insights já para a gente olhando para esse processo de desenvolvimento e olhando algumas métricas. Um eu comentei, por exemplo, a gente não estava conseguindo um apoio da engenharia para a gente conseguir validar e mitigar os riscos técnicos, então esse é um possível gargalo que a gente pode ver olhando para essas métricas. E um outro ponto é que o fluxo em si, como você comentou, a parte de testes, a gente está num contexto completo, a gente está evoluindo uma plataforma, a gente tem uma orientação com base no que a gente espera dessa plataforma que a gente está construindo. Então essa etapa de testes é muito importante, e até por isso que a gente realmente incluiu isso no nosso fluxo. Então, assim, beleza, a gente faz aquele desenho ali, que é aquela parte de solução, depois a gente faz essa avaliação com a engenharia. Aquela parte da solução a gente não faz um protótipo de média ou de alta fidelidade não, porque a ideia é a gente validar isso com a equipe de engenharia primeiro para depois realmente fazer um protótipo, pode ser aí um protótipo de alta fidelidade para a gente poder validar junto com os usuários. Então, assim, a gente precisa realmente fazer isso, porque as soluções que a gente está propondo são soluções que contemplam, podem contemplar mais de um produto que a gente está trazendo ali dentro daquela plataforma. Então é extremamente importante a gente conseguir validar isso antes que a gente realmente leve isso para a (inint) [00:22:07] de discovery.
Vinicius: Nesse exemplo da plataforma que você deu aí sem… eu sei que envolve questões de confidencialidade e que a gente não entraria em detalhes, mas, por exemplo, que tipo de coisas que vocês passaram para a engenharia? Que tipo de ferramental que eles usam? Como é que você vai prever? Tipo, assim, eles vão fazer igual no caso do delivery, de tentar estimar em pontos, alguma coisa ali? Tem atividade que é mais identificativa? Como que você vai fazer o… Que eu estou entendendo que essas métricas tem o sentido de… tem um certo controle de tentar até ter um certo nível de previsibilidade de uma “produção”, mas são atividades mais investigativas. Se pudesse explorar um pouco mais algum exemplo de funcionalidade que vocês passaram, como é que foi esse controle das métricas em cima disso.
Flávia: Você fala mais a nível do risco técnico mesmo? Tipo, dentro dessas etapas o risco técnico por exemplo, um exemplo.
Vinicius: É, do risco técnico e eu também tenho a curiosidade do outro que eu falei, que seira a alimentação do teste, que seria o teste de… algum tipo de teste de valor, igual você falou que, tipo assim, antes de fazer o teste já com a coisa toda construída, que aí seria mais lá no delivery, no downstream.
Flávia: A gente tem um… Fora esse fluxo do upstream, eu acho que até tinha comentado com o Salvio mais cedo, que eu acho que é legal a gente dar visibilidade também disso, a gente também tem um fluxo assim, assim que a solução… a gente define essa solução, a gente também tenta passar por um fluxo antes de isso entrar para o delivery, e que envolve uma nova avaliação da engenharia para depois a gente passar para uma estimativa, que a gente também faz uma estimativa do tamanho de camisa. E aí, assim, eu acho que essas etapas fazem com que a gente vai mitigando os riscos do time não ver, por exemplo, um risco quando já está ali no delivery e aí eles não conseguirem mais atuar ou então isso até impactar nas métricas do fluxo de desenvolvimento em si. Acho que a gente até ia comentar um pouco disso não é, Salvio? Se você quiser fazer um link.
Rafael Salvio: Estou pensando aqui em algum caso que a gente possa trazer, mas me veio um aqui em mente que talvez até se aplique. A gente tem uma solução em que a gente tinha uma tarefa talvez um pouco manual, por exemplo, de validação de aderência de uso de uma das nossas aplicações. E a gente tinha uma ideia de, por exemplo, conseguir automatizar isso dentro da aplicação para a gente poder reduzir um pouquinho desse esforço manual e repetitivo. Então a ideia a gente conseguiu chegar, a gente começa a pensar nas possibilidades ali de solução, mas a gente ainda tem um caminho muito grande até que isso de fato entre ai no fluxo do downstream, que a gente tenha mais segurança em como resolver aqui. Então imagina aquele cenário em que a gente pensa numa solução, a gente encaminha para um time técnico e aí em algum momento, quando ele já passou um tempo, ele pega aquilo para analisar e percebe: “Poxa, acho que isso não é tão viável”. A gente volta naquele fluxo, volta para o discovery para a gente pensar em novas soluções. Então porque não a gente encurtar esse meio do caminho e a gente já trazer o time técnico para ter essa análise antecipada, fazer parte ali dos momentos em que é necessário e com isso a gente ter as vezes até uma maior previsibilidade mesmo de backlog, acho que esse é um dos grandes resultados que a gente consegue ter. E aí nesse caso especifico por exemplo a gente traz o time técnico, a gente vê uma oportunidade de, as vezes, com uma pequena spike, um pequeno estudo, com um esforço ali que a gente traz para dentro de uma sprint, a gente consegue sair, por exemplo, do processo de discovery com muito mais confiança para aquela solução entrar no nosso fluxo do downstream a gente não ter uma surpresa posterior. Então essa é uma das maneiras em que a gente, olhando para essas métricas, pensando em como reduzir o lead time, por exemplo, do nosso processo de discovery a gente tem ganhos depois inclusive no lead time geral, desde que a ideia nasceu até que ela foi de fato entregue. Não sei se eu consegui explicar muito bem (inint) [00:25:52].
Marcelo Szuster: Sim. Não, então tentando só fazer uma sumarizada aqui, até porque estamos já no avançado aqui da… Eu acho interessante, até para tentar clarear bem para quem está ouvindo. Assim, quando você tem soluções mais complexas você acaba tendo times que ficam explorando o que fazer, enquanto tem times já meio que atacando um backlog que já está mais maduro, que é o downstream e upstream. Você tem que tomar cuidado para que isso não fique desconectado e vire quase que dois mundos diferentes que não tem o menor sentido, justamente porque é um time todo uma missão única. Então o que vocês estão promovendo ao gerir tudo junto é fazer com esses times fiquem mais integrados, não é? Você tem que fazer uma medição que vá desde o upstream, justamente porque se você quer realmente melhorar o processo e melhorar a percepção mesmo de melhora, você tem que medir o lead time desde o upstream. Porque não adianta um time filhar ali olhando para o backlog que já chegou de algum jeito ali mais definidinho e ficar pensando: “Poxa, mas nós somos tão rápidos”, e na verdade você tem um processo anterior ali, upstream, que demorou para caramba e o resultado final para a área de negócios é que as coisas demoram muito. Então assim, eu entendo que o que nós estamos falando aqui é isso, é tanto a importância de medir tudo para poder justamente saber onde estão os gargalos a atacar, e vocês deram exemplos. Muitas vezes você ataca um gargalo do discovery aproximando do time técnico e já eliminando um problema ali rapidamente, o que vai se traduzir na frente em eliminar um gargalo também. E você limita o work in progress do próprio time de discovery, justamente porque o work in progress é a Lei de Little, se não me engano, que se você aumentou o work in progress você… é igual eu lendo os meus livros, lê 20 livros ao mesmo tempo não acaba, vai demorando para acabar cada livro. Eu acho que a gente cobriu bem, sabe? Só uma coisa que eu tenho medo de alguém sair daqui pensando isso, eu queria que vocês falassem sobre isso. Muita gente pode ficar achando que você estão defendendo um pouco de um waterfall aqui de uma certa forma. Eu sei que não, porque assim… eu sei que as discovery são curtas, eu sei que são pequenas. Mas o que vocês falam, entende, uma pessoa que escuta fala: “Ah, entendi. Então eu tenho um processo que… Poxa, mas isso era waterfall, isso era o…”. O que é que vocês dizem a respeito disso? Porque é fácil alguém ouvir e sair, a partir de uma certa descrição, pensando: “Poxa, é tudo muito simples. Eu faço um bom discovery, aí eu testo bem, aí eu faço isso, aí eu faço aquilo”, daqui a pouco “Por que é que eu não faço waterfall, não volto lá para as origens lá atrás? Por que é que eu estou com essa confusão de fazer o ágil?”.
Rafael Salvio: É engraçado que até numa das nossas conversas de alinhamento eu até sinalizei isso para a Flávia. De maneira nenhuma a ideia é a gente perder o nosso poder de adaptação, não é essa. A gente quer sempre se precaver de riscos que, seriam possíveis dentro do nosso processo a gente ter enxergado, por conta de comunicação, e essa comunicação passa não somente ali de boca-a-boca da interação entre os colaboradores, mas também das métricas e das boas práticas que a gente consegue trazer do modelo já bem definido. Por exemplo, do downstream a gente que a gente ter os tempos de lead time, por exemplo curtos, vão ter benefícios, a gente aplica as mesmas ideias também no fluxo de upstream para a gente poder ter um processo como um tudo mais eficiente, mas nunca abrindo mão do nosso poder de adaptação que, assim, não é o propósito. A gente tenta antecipar os riscos. A gente tenta, dentro do período oportuno a gente conseguir levantar o máximo de informações para que, no final, a nossa entrega sempre tenha qualidade e prazos curtos, mas de forma alguma a ideia é a gente defender o waterfall.
Flávia: E aí assim, só para… até para mostrar um pouquinho das conclusões que a gente teve quando a gente começou a olhar essas métricas, porque realmente era para a gente tentar identificar melhorias nesse processo e não porque isso precisava ser engessado, pelo contrário. A gente estava vendo que a gente estava tendo dificuldade de rodar esse processo de uma forma bem (inint) [00:29:47] mesmo, de a gente conseguir identificar uma oportunidade, conseguir avaliar essa solução, propor essa solução e num processo que fazia sentido ali com base no fluxo das demandas que a gente precisava atuar. E aí, assim, o que a gente identificou: que o nosso processo o lead time estava alto. Por que ele estava alto? Porque a gente estava começando as atividades e essas atividades estava ficam muito tempo paradas, e aí um dos insights que a gente pegou nesse processo é que, atualmente, a gente atua tanto no delivery quanto no discovery, é que o delivery estava consumido muito a gente, então a gente não estava conseguindo dar vazão nas atividades de discovery que a gente estava planejando. Então esse foi um primeiro insight que a gente teve, mas pode ser outro também, por exemplo: a gente utiliza algumas técnicas e ferramentas para rodar esse processo de discovery, pode ser que a gente precisa melhorar ou então alterar a ferramenta que a gente está utilizando com base no contexto. Eu não esqueço um dia que a gente… eu estava fazendo uma adequagem de uma entrevista, eu fiz uma série de entrevista para validar um discovery, uma hipótese que a gente estava testado, e eu cheguei e comentei com a design que eu estava demorando muito tempo para fazer aquilo, que não fazia sentido, e ela falou assim: “Flávia, foca no problema. Não é para você registrar tudo. Tenta ser… realmente fala: “O problema é esse. Então o que eu preciso realmente registrar para depois eu conseguir ter insights dessa documentação que eu estou fazendo que vai conseguir me trazer a resposta para validar realmente essa hipótese”.”. Então, assim, pode estar também nas técnicas e ferramentas de discovery que estão sendo utilizados pelas pessoas de produto. A gente também viu que a gente precisava acompanhar melhor essa parte do delivery em si, porque as pessoas de produto estão precisando atuar tão próximas ali. Claro que isso aí já é um comum, essa pessoas estão juntas, mas o apoio constante ali estava sobrecarregando as pessoas de produto, aí poderia ser por testes, poderia ser talvez as histórias não estavam bem escritas, os critérios de aceite não estavam bem escritos, então a gente precisava identificar que tipo de gargalho está tendo que as pessoas de produto não estão conseguindo desprender do delivery para também focar nas atividades de discovery, porque nós atuamos com o discovery contínuo.
Marcelo Szuster: Excelente. A gente está chegando aqui ao final. Eu acho que foi excelente, eu acho que fica claro que, na medida em que você lida com um cenário mais complexo, você começa necessariamente a ter um time que se divide mais em upstream e downstream, isso vai ficando cada vez mais visível e aí você tem garantia que o fluxo flua mesmo entre esses times, que ele continue sendo (inint) [00:32:21], e você, para poder fazer de uma forma objetiva, você tem que ter visibilidade disso e tem que ter métrica, que é o que vocês defenderam aqui. Eu acho super interessante porque a gente sabe que está num momento onde produtividade é mais importante do que nunca devido ao cenário recessivo, e é curioso, porque a gente… é comum nas reuniões executivas que a gente participa o cliente sempre… muitas vezes o CTO ou o CIO, representando a TI ali, sempre repassaram uma cobrança do negócio muito grande, de que a produtividade de alguma forma não é boa. E a produtividade de alguma forma não é boa significa que esse lead time é alto na verdade, como se a empresa visse um investimento grande acontecendo e visse pouca coisa sendo colocada em produção e etc. E é curioso, porque a tendência é ficar espremendo o time de desenvolvimento, espremendo o downstream, sabe? Como se você tem que ficar indo lá no downstream e falando: “Pô, mas com é que está a velocidade aí?”, sabe? Fica tentando achar ali no downstream. E aí quando faz uma análise igual a Flávia comentou ali do fluxo lá desde o upstream você começa a ver: poxa, na verdade, paradoxalmente aos olhos do cliente, se eu botar, por exemplo, mais um PO aqui que permita que eu tenha mais dedicação no upstream por exemplo, eu vou fazer o lead time melhorar absurdamente e a produtividade vai melhorar para caramba. Então por isso que é interessante fazer essa análise integrada mesmo. Eu acho que o tema já é relevante sempre, é mais relevante ainda agora, sabe, nesse momento de quantidade, porque eu insisto nisso. A gente sempre vai para a zona de conforto, sabe? Eu falo assim o ser humano, e o lugar mais óbvio de procurar a grande produtividade é meio que pressionando o time de desenvolvimento como se ele tivesse devagar, até porque a gente sabe, é até um tema, estimativa em software é sempre difícil, difícil de medir produtividade, difícil de comprar time. Então alguém pensa: “Eu não sei… Eu só sei o seguinte: (inint) [00:34:10]”, tipo assim, alguém fica com essa sensação e, na verdade, as vezes, o problema está lá no upstream. Eu acho que se isso já botar uma pulga atrás da orelha de um tanto de gente, de que o problema as vezes está lá no upstream e que você está fazendo um investimento enorme no downstream, e as vezes está economizando de melhorar um pouquinho ali no upstream, e decidir mudar o jogo, você vai ganhar uma ótima reflexão. Pessoal, muito obrigado. Eu acho que foi bem bacana. Eu espero que vocês voltem outras vezes aí para participar de mais episódios.
Flávia: Pode deixar.
Rafael Salvio: Valeu, pessoal.
Flávia: Obrigado, pessoal.
Vinicius: Obrigado, pessoal.
