M1: Bom dia, boa tarde, boa noite. Vamos começar mais um episódio de Os Agilistas. Mais uma vez com Vinição. E aí, Vinição, beleza?
M2: Beleza. Você não me aguenta mais, Schuster. Vamos lá.
M1: O Vinição é figurinha presente aqui no Os Agilistas. É figurinha presente em todos os lugares. Tudo que acontece tem o Vinição lá. Ninguém se livra do Vinição. Hoje eu já vou apresentar um convidado. Nós vamos falar de um tema super interessante. Normalmente, quando eu apresento a DTI, que eu sempre falo que a gente usa muito o agilismo como, a gente sempre fala que a gente tem dois pilares: agilismo e design thinking e coloca sempre o agilismo como forma de gerar valor continuamente, de gerar valor no curto prazo, de gerar aprendizado, e o design thinking como aquilo que vai orientar para onde a gente canaliza a nossa energia, como é que a gente sabe que a gente está aprendendo na direção certa, se nós estamos canalizando todo o esforço de entrega em curto prazo, para a direção certa, se estamos empatizando bem com os usuários finais, se nós estamos definindo hipóteses. E a gente pode pensar de forma mais ampla o design thinking como fazendo parte da disciplina de gestão de produtos. Hoje isso tem sido cada vez mais relevante. Na medida em que as empresas passam não mais a se orientarem a projetos, mas sim a se orientarem a produtos, a (inint) contínuas de geração de valor, obviamente fica fundamental saber fazer uma boa gestão dessas frentes. É uma coisa que a gente sempre fala aqui. O orçamento das empresas que vão ficando digitais vai aumentando. Isso é inevitável. E o que a empresa, então, tem que fazer é usar muito bem esse dinheiro. A verdade é essa: gerar valor muito bem. Isso reforça ainda mais a importância de saber fazer uma boa gestão de produto. Com isso nós estamos trazendo uma pessoa que é especialista no tema e vai se apresentar aqui e agora. Eu sempre prefiro que os convidados se apresentem. E aí, Onofre. Tudo bom?
M3: Oi, gente. Tudo bem? Tudo ótimo aqui.
M1: Se apresente por favor, Onofre, rapidinho. Fala um pouquinho sobre seu backgroud, o que você faz aqui na DTI, para o pessoal te conhecer.
M3: Tudo bem, pessoal? Onofre aqui. Hoje atuo como PEO e ADM em um dos nossos squads aqui dentro de uma das alianças e também contribuo com os nossos (inint) de produto nessa disciplina que tem crescido cada vez mais, ajudando principalmente com algumas práticas e (inint) algumas (inint). Lembra que cloud é um pouco mais técnico. Fui desenvolvedor bastante tempo e aí eu sempre me interessei nessa parte de entender muito o porquê de a gente estar construindo software e porquê que a gente está resolvendo essas dores, quais dores (inint). Aí eu fui direcionando a carreira para a parte de produto. Comecei a atuar como PEO lá atrás, entendendo mesmo as necessidades. Nem era PEO, era um pouco de analista de requisitos, e aí a gente foi direcionando, aprendendo ágil, implantando o ágil nos times. Também tive algumas passagens pela (inint) master, com os times, e hoje estou contribuindo para essa parte de disciplina, especialmente na parte de produto e estou aqui, atendendo nossos clientes. Mais um convertido pelos produtos. É super interessante isso, de ter um background técnico. Eu acho isso interessante. Eu lembro de eu participar de reuniões com você, você como BL, não era? Você aqui dentro dando solução e depois como PEO. Acho interessante, tanto essa questão das trajetórias, a gente sempre fala que é legal a pessoa poder mudar de trajetória, mas eu até queria começar, primeiro, fazendo uma pergunta antes de entrar nas questões realmente do podcast: o que foi te despertando esse interesse e como é que foi essa transição? Você não sente falta também? Porque muita gente técnica pensa: você não está sentindo falta de desenvolver? Como é que está sendo essa vida?
M3: Essa transição que aconteceu. Eu lembro que certa época, 2010, coisa assim, eu fui na feira do empreendedor do SEBRAE. Eu fui aprender o que era empreender, ter o negócio. Eu comecei a me interessar muito pela área de startups, eu tive passagem em duas startups e (inint) também nesse processo até aqui. Na (inint) quando a gente ficou lá incubado, certa vez, a gente começou a ver muita (inint) de produto, disciplina de desenvolvimento de mercado, e para mim aquilo começou a: isso aqui é o que faz sentido, é para isso que a gente faz software, o produto resolve dores do mercado, o produto resolve dores dos usuários. Eu fui entendendo um pouco nessa parte e soltando um pouquinho os estudos que estavam direcionando para produto. Hoje eu sinto falta. Eu gosto muito de programar, gosto muito de código, mas eu olho ele com carinho, então eu olho para ele, gosto muito, gosto como funciona a lógica de tudo, porém hoje eu acredito que eu consigo agregar mais nessa parte de direção, gestão, de direcionamento do (inint) dos problemas, mas eu dou umas palhinhas, de vez em quando, converso com os desenvolvedores, com (inint) também. Consigo me comunicar muito claramente com eles por causa disso, entender essa parte mais técnica. Isso me ajuda bastante nesse processo.
M2: Acaba que é bastante comum pessoal de produto normalmente começa por alguma outra disciplina. Às vezes é programação, às vezes é design também. Isso é legal, porque normalmente quem está trabalhando com produto tem propriedade, pelo menos, em algum tema bastante relevante ali de como as coisas vão ser construídas, das dificuldades que existem, dos impedimentos que existem. Isso ganha até uma certa credibilidade maior e uma liderança automaticamente por referência, no mínimo, porque pode ter outros tipos de liderança, mas fica mais fácil de fazer com que o time fique mais unido.
M1: E é interessante, porque no ágil, como você já traz o time todo mais para o jogo, acho que você até começa a despertar esse interesse mais multidisciplinar das pessoas. Não que não vai ter gente que vai, claro, adorar ser desenvolvedor e vai ficar a vida inteira progredindo no desenvolvimento, e é ótimo, mas é porque o time ágil, em teoria, pelo menos, deve ser mais interessado pelo resultado ali, todo mundo junto. Isso abre mais contato. Aí eu já queria começar fazendo uma pergunta, Onofre, que é a seguinte. A gente começou falando isso: poxa, eu posso ter um time ágil, mas se não estiver fazendo uma gestão de produtos bem feita, esse time pode estar canalizando energia errado ou pode estar não gerando valores. Tem que ser um time ágil, digamos assim, atuando corretamente. Mas você volta lá no manifesto, lá atrás, desde sempre o cara fala assim: você vai ter o PEO ali, vai ter o usuário, que é quase o cliente dentro do time, aquela história que o XP prega lá atrás. A pergunta que eu queria fazer, para ser mais objetivo, é assim: o ágil começou talvez com a interpretação de que você tem um cliente dentro do time para aproximar a área de negócio do DTI e isso já seria a garantia, digamos assim, de que você está alinhado com o negócio, gerando valor. Mas me parece que a transformação digital foi fazendo o estudo ficar tão estratégico que você foi sofisticando muito mais esse tipo de prática, está realmente garantindo que o time gere valor. Não é uma questão tão simples, só de botar um cara ali de negócio e pronto, acabou, porque aquele cara ali também pode estar fingindo coisa que não gera valor, pode estar enxergando coisas. É isso mesmo que você quer dizer quando fala sobre ter essa disciplina de toda a gestão de produto?
M3: É por aí mesmo. Acho que com a especialização das pessoas, e aí essas pessoas vieram conhecendo cada vez mais e expandindo as disciplinas, não só o PEO, mas design. Lá atrás era web master e hoje a gente tem várias especializações de design. Então de produto é semelhante e essa pessoa de produto começa a se preocupar ainda mais para ser mais eficaz nas entregas, porque, na minha cabeça, eu tenho o ágil como a forma de entregar em ciclos curtos. A gente sempre fala aqui em entregar em ciclos curtos, reduzindo riscos e aumentando um (inint) marketing, aumentando a eficiência para caminhar. Porém, ele não está ligado necessariamente para a eficácia, para a (inint) entregar o produto certo. Então eu posso estar tendo um time muito especialista em ágil, fazendo bem feito, excelente arquitetura, porém não está na direção mais acertada. Você pode estar caminhando para um lado mais (inint), mas para ser mais eficaz as práticas de gestão de produto te ajudam nisso e com isso você tem mais sucesso de, de fato, entregar valor. Não é só mais software, não é só mais (inint). A gente pode entregar telas rápidas. A gente pode fazer um time que entrega telas como nenhum outro time online. Está entregando telas? Está entregando fundos de (inint)? Mas como o nosso cliente está melhor depois da nossa entrega? De que forma que eu sei que o cliente está no patamar antes, e aí nosso sistema veio, nosso software (inint) veio e agora ele está melhor, e agora ele tem menos dores, agora ele tem menos problemas no seu dia a dia? A gestão de produto vem nesse ponto, nesse aspecto. As práticas de gestão de produto, e aqui eu entro métricas, (inint) indicadores, um discovery bem feito, uma (inint) muito bem feita com design para a gente trabalhar junto, descobrir qual é o (inint) certo. Muita experimentação. Hipóteses, (inint), o uso correto do MVP. Tem uma série de práticas que vêm dessa disciplina de produto, que ajuda a gente caminhar na direção certa e não somente de forma ágil.
M1: Isso é interessante, porque eu lembro lá dos anos 2000, quando comecei a trabalhar com o ágil, eu diria que a intenção sempre foi aproximar do negócio e gerar valor para o negócio, sim. O ágil surgiu nesse contexto, mas que é fácil cair em uma armadilha de você estar entregando (inint), que é o princípio, mas você está entregando work software que não necessariamente gera valor, justamente por se subestimar, talvez, o esforço que existe até para mudar a organização, para a organização conseguir. Eu tenho um pensamento bem meu. Por exemplo, eu adoro o ágil. Não tenho dúvida disso. Eu sempre brinco, clientes nossos não podem acusar a gente de não gostar do ágil, mas existe uma visão às vezes ingênua, me parece, do ágil, no sentido assim: organizações têm política, têm estruturas de poder, então eu tenho às vezes uma visão muito ingênua de: se eu estiver tendo progresso com o work in software, eu vou mudando tudo. E não vai. A gente está cansado de ver que tem um tanto de lugar que você tem que fazer várias comunicações formais, você tem que ter alguns comitês, você tem que fazer uma gestão de risco, tem que fazer isso, tem que fazer aquilo, coisa que talvez aos olhos de um ágil puro e todo mundo no jogo fosse se perder, como se fosse: você está desperdiçando, não precisa. Está todo mundo no jogo, para que você comunica tanto a equipe? Talvez, na gestão de produto, quando a gente fala como uma disciplina nova, eu estou fazendo isso por quê? Talvez um agilista raiz vai falar assim: não, cara, você está enganado. O ágil já é feito para gerar valor, sim, só que a questão é, e é isso que eu queria que a gente explorasse aqui: não é tão fácil descobrir como é que você gera valor. Tem que ter alguém que pensa ativamente nisso mesmo. Tem que ter técnica para isso. Acho que a grande lição aqui é a seguinte: não é só porque eu faço software bem feito e consigo cumprir o que me pedem em curto prazo que eu estou gerando valor ou que o caminho vai acabar sendo descoberto. Eu posso acabar (inint) errado.
M3: Eu vou dar um exemplo até nesse modelo, trazendo um exemplo prático. É comum que a gente tenha times funcionando bem no ágil, entregando valor, com sprints muito bem (inint), mas quando eu vou fazer mentoria, em alguns casos aqui, e aqui dentro da DTI, eu chego para algumas pessoas e falo assim: legal, vocês estão fazendo (inint), isso está andando. Qual é o critério de (inint) do seu produto? Qual é a métrica que está te dizendo isso? Não sei. Opa, então tem algo aqui que a gente precisa melhorar. Legal que você faça o ágil bem feito, mas se você não está medindo, por exemplo, uma das técnicas, métricas. Se você não está medindo algo de produto, se você não está medindo algum indicador de negócio e o seu cliente está melhorando após as suas entregas, a cada sprint que você entregar, a cada ciclo que você está circulando, se você não mede algo, como que você sabe que você está melhorando? Como que você sabe que o seu cliente está melhor? Como você sabe que você está eficaz? Em alguns casos a gente não tem aqui uma métrica muito clara, um critério de sucesso do produto muito bem descrito. Qual é a minha proposta de valor? Qual é a proposta de valor desse produto para esses usuários? A proposta de valor é essa. Qual é a proposta de captura de valor? O que o cliente recebe em troca da entrega desse produto? O cliente está investindo aqui, em squads, o cliente está investindo em transformação. Muito boa essa (inint). E o que ele tem em troca de indicador profissional? Como a empresa dele está melhor? O produto, estrategicamente, entra nessa parte, porque o produto está ajudando esses números a melhorarem. Quando você faz um ágil, por mais que seja bem feito, e aí o ágil é feito para agregar valor, ele é, mas ele é feito para entregar valor, você está fazendo ele bem feito e você não tem esses indicadores, (inint) métricas. Se você não tem (inint), aí você já tem ponto de melhoria aí, já dá para melhorar, já dá para (inint) design para pensar em métricas. Isso é um exemplo.
M2: Onofre, aqui na DTI a gente costuma falar muito em maturidade, em tentar desenvolver maturidade de produto. Eu sei que é óbvio que cada caso é um caso, cada contexto é diferente, cada contexto é um desafio, uma sequência talvez diferente que deveria seguir, mas o que seria dos cenários típicos que você encontra, que você enxerga, e quais seriam os primeiros passos típicos que você indica?
M3: (inint) várias respostas certas. Uma coisa prática, que eu vejo, para o cenário que eu trabalho hoje, simplificando um pouco, de novo, tem várias respostas certas, mas tem alguns tópicos que eu acho que são fundamentais para a gente caminhar, nesse sentido, nessa gestão de produto e começar a caminhar na direção correta. Um dos exemplos aqui: qual é minha proposta de valor? Isso vem lá do modelo até de startup mesmo. As empresas de startup que (inint) de produto, e geral, têm um (inint), por exemplo, que lá tem proposta de valor, captura de valor, uma série de coisas. Aqui a gente (inint) um pouco disso e aí eu penso: proposta de valor, o que eu estou entregando (inint)? Qual é a captura de valor? O que o meu cliente está recebendo em troca? O que vai me dizer se eu estou no caminho certo? A gente tenta algumas ferramentas, alguns campos, alguns (inint) que a gente preenche e estimula o time a trazer informações, em trazer essas respostas para essas (inint), para esses quadros, para a gente pensar junto. A partir dali a gente tem algumas respostas. A partir dali a gente começa a ter insights de (inint) e caminhar. Não pode também ser frases, não pode ser descrições muito genéricas, que são bonitas no papel, mas que não querem dizer nada. Quero melhorar minha eficiência operacional, então minha proposta de valor, minha captura de valor é melhorar minha eficiência operacional. Legal, mas o que isso quer dizer para o seu produto? O que é eficiência profissional para o seu produto? É em horas? É em grana? Menos desperdício de algum recurso? O que é? Eu preciso medir isso. Eu preciso ter isso em mente para dar (inint). Eu definir melhor os OKRs, os direcionadores a longo prazo. Tem alguns artefatos de produto que aqui a gente precisa ir construindo junto e comunicar contínuo. Um outro passo, uma outra vertente importante: roadmap. Roadmap é uma forma de apontar o caminho do time e comunicar. O roadmap, na minha visão, é uma ferramenta de comunicação. Na minha visão, não de metas. Se (inint) um roadmap de seis meses ou uma no e que (inint) metas comparativas ali, eu já começo a ter uma série de distúrbios, mas se eu usar o roadmap como uma ferramenta de comunicação, que ele vai evoluir com o tempo, isso me ajuda a dar a visão para o time e para pessoas interessadas ao redor desse projeto e desse produto. As pessoas vão olhar para mim e vão acreditar em mim, vão se sentir representadas nesse roadmap, vão sentir: “opa, o que eu quero nesse produto está ali”. Não está agora, nos próximos três meses, mas está dali seis. Aí ao tempo em que esse roadmap for se evoluindo e for sendo neutralizado e colocado para as pessoas, então é uma ferramenta de comunicação. E os indicadores, porque quando eu tenho frases claras e (inint) claros do meu produto, que ele está aqui, isso me facilita de criar esses melhores indicadores, priorizar, principalmente, o backlog saudável para que seja construído. Eu não tenho que ficar escolhendo histórias aleatoriamente, que elas estão prontas e refinadas para colocar no sprint e (inint). Não. Eu vou escolher baseado no objetivo. O objetivo está na sprint. O objetivo do meu ciclo. O meu ciclo agora está atacando esta dor, então eu vou priorizar esse backlog, escolher histórias já priorizadas para atacar esse indicador, para melhorar esse (inint). O time se sente mais engajado quando tem um objetivo em comum, quando tem um objetivo claro. A gente está indo para lá (inint). E existem problemas que são problemas para o seu time do futuro. Esse problema, eu vou atacar agora ou não? Ele é daqui seis meses. Depois eu preciso aprender sobre esse problema ainda, aprender sobre essa dor? A gente fica lá. Aí você já tranquiliza o seu time, diminui a ansiedade, para que eles não lidem com tantos assuntos e tantos problemas ao mesmo tempo, e sim nos principais, nos de agora. Uma série de práticas que a gente consegue começar a ter de boas práticas começando no básico, para a gente sair em uma direção melhor.
M1: Onofre, interessante, porque você fala assim. Eu quero até explorar mais o roadmap, porque é um tema super polêmico. Vou explicar porquê. Eu só queria antes fazer uma pergunta, que é o seguinte. Você está falando assim: cara, eu preciso partir de uma proposição de valor, eu preciso ter um roadmap que seja uma ferramenta de comunicação, que dê uma certa tranquilidade para todos: nós iremos fazer mais ou menos isso nos próximos meses. Não fica só os times ágeis e os gestores de produto falando para todo mundo assim: a garantia soy yo, fica tranquilo que nós vamos gerar valor. Eu diria que o roadmap acaba fazendo esse papel. Claro, eu começo a mensurar também o que está acontecendo e assim vou fechando esse ciclo de confiança. O que eu queria falar mais sobre o roadmap? Por quê? Eu queria ver a sua visão. O roadmap, muitas vezes, vira um instrumento que tem uma boa intenção, mas acaba sendo maléfico, porque ele acaba virando uma forma de se voltar para uma (inint) fall. O cara vira e fala assim: eu sou ágil. Até faz um mission (inint), o ritual que o cara quiser fazer para falar: esse produto tem a visão tal, tal e tal. Mas aí, no minuto seguinte, pela necessidade de controle, pela ansiedade, o cara vira e fala: agora me dá uma estimativa de tudo, me fala quais são os modos, me fala quais são as funcionalidades, chama de roadmap e agora nós temos um produto…
M3: Mais um projetinho, o gráfico de Gate traçado.
M1: Essa armadilha aí. Esse negócio, se bobear, esse episódio deve chamar armadilha de roadmap. Que roadmap é esse que vai ser útil? É um roadmap de resultados? É um roadmap de marcos mais flexíveis? Como é que a gente não cai na armadilha? Porque eu acho que esse tema é super relevante. Você vê times que têm a intenção de entregar valor, você tem empresa que obviamente tem a intenção de gerar valor, aí acontece alguma coisa que, você vai ver, tem um time de novo focado em (inint), doido para entregar o roadmap, está na meta de todo mundo, passa não sei quantos meses, ninguém sabe o que está fazendo nas coisas. Isso acontece com uma frequência grande. O que você diria sobre o roadmap? Como você vê essa situação?
M3: Eu vejo assim. Falando o que eu penso e eu falo que eu tive alguns times muito eficientes no mercado trabalhando. Se você não sabe lidar com roadmap como meio de comunicação e como uma ferramenta flexível, você vai nessa armadilha e eu preferiria nem (inint) o roadmap, nesse sentido, mas o que eu vejo como uma (inint) de roadmap, e tem alguns princípios aqui. É sabido que quando a gente constrói algum sprint, isso é uma boa prática também de (inint) de produto, é construir algo, construir uma feature nova para produto. Coloquei em produção. Depois de um tempinho, aí você vai definir qual tempo é esse, pode ser uma semana, um mês, vai depender, você tem que avaliar se ela está gerando algum retorno, se ela está tendo o resultado esperado daquela feature. Você tem uma hipótese sobre o problema. Você resolveu isso como funcionalidade no seu sistema. Você entregou para os seus usuários. Eles estão usando. Você tem que medir para saber se eles chegaram no sucesso esperado daquela funcionalidade. Aquilo atendeu o que eu queria? A resposta: não atendeu? Ela é (inint). Talvez não atendeu. Algo que você entregou não atendeu suas expectativas, sua hipótese era falha. Tudo bem. Você elimina aquilo e tenta outra coisa. Você percebe, então, que é um caminho desconhecido? Quando a gente fala de produto e projeto, uma das coisas principais era isso: se eu tenho um projeto, eu já sei isso, eu sei mudar a data quando termina e eu sei exatamente o que vai ter no percurso. É por isso que eu tendo a ter um planejamento um pouco mais fixo, com menos incertezas. Menos, não quer dizer que não tem. No (inint) produto, que aí você tem um problema, você tem hipóteses para resolver, as dúvidas são demais. Você tem várias dúvidas que você tem que ir respondendo ao longo do tempo, que você tem que aprender a medida em que você entrega. Você entrega, aprende. Muda a ordem. Então, se eu chego no roadmap e coloca todos os (inint) do meu ano nesse roadmap como algo fixo, que eu não tenho a oportunidade de mudar e ser flexível, então eu estou ferindo esse princípio, porque no meio do percurso eu posso estudar. Vamos pegar o ano, para simplificar. Lá em abril eu posso descobrir que algo que eu planejei para novembro não faz mais sentido e eu tenho que tirar ele de lá. Não faz mais sentido, porque eu aprendi novas coisas. Eu tive acesso a novas informações, eu fiz testes, eu fiz (inint) e eu aprendi que aquilo não é muito mais um problema, então eu posso tirar aquilo (inint). Se eu não tenho esse mindset de que o meu roadmap é uma ferramenta de comunicação para o time e para todos os interessados, de que time eu estou falando aqui? Não é só time de desenvolvimento. Às vezes você tem time de marketing também trabalhando com (inint) de produto, time comercial, para saber para onde o produto está indo. Esses times vão usar esse roadmap para poder comunicar com os clientes uma jornada, para poder fazer planos de vendas, estratégias de marcas, estratégia de venda, estratégia de grow, porém, se esses times amarrarem esse roadmap em uma coisa muito fixa, que não pode mudar, isso é um problema. Por isso tem que ser uma ferramenta de comunicação de: olha, isso é o destino, é a rota do meu GPS. O meu (inint) está ligado, apontando para lá. Mas, no meio do caminho, pode aparecer algum congestionamento e o (inint) me direciona para um caminho um pouco diferente. Se todo time tem que estar alinhado com isso e tem que ágil e flexível para lidar com isso. Se tiverem pessoas (inint).
M1: Só para tentar deixar mais concreto, porque eu acho esse tema super relevante. Eu falo assim, essa palavra roadmap, eu falo muito aqui no podcast de um pensamento ágil. Isso que você falou não é tão facilmente aceitável, que eu não sei o caminho direito, que eu tenho que coagir rota. Mais uma vez, o roadmap vira o…
M2: Vira o que vai ser a rota.
M1: É. Eu estou rindo, mas é porque é assim: nós vamos ser ágeis, eu entendo, nós temos que gerar valor, eu entendo que é desconhecido, me dá o roadmap aí. Aí o roadmap vira o plano. Tanto que aí uma reação que dá vontade de ter é assim: não faz roadmap. Dentro dessa reação é justamente isso: o fato de você saber que tem certeza não quer dizer que você não possa declarar certas coisas que você já enxerga, ter certas referências que permitam comunicar isso para a organização e ficar continuamente revisando aquilo. É muito fácil também para a gente que acredita no método ágil falar assim: fica tranquilo, nós vamos fazendo e você vai ver que é bom. Fica esperando aí que você vai ver que é bom. É quase que uma resposta assim. O que seria? Você consegue trazer exemplos? O que tem em um roadmap desse que você gosta para a gente até explorar depois como é que vira o bom ou ruim? O que teria no roadmap? É (inint) mesmo? Tem prazo ali? Tem marco? O que tem nesse roadmap?
M3: Tem fases. Vou falar de um modelo que hoje a gente tem visto como um modelo muito bom, que tem funcionado: o modelo de três colunas, now, late, later – agora, próximo, mais tarde. Ali são só três colunas. Só para (inint) comunicação, o que está agora? Qual é a prioridade do time no primeiro ciclo? São esses itens aqui. A gente já vai entrar no detalhe desses itens, mas são esses itens aqui. O que está previsto no próximo ciclo?
M1: Mas é a funcionalidade isso? É modo? É funcionalidade? É meta de negócio? O que são esses itens?
M3: Vai depender do time. Não tem meta, não tem data ali, não tem (inint), não tem (inint). Não é legal que a gente coloque tela ali. A tela de tal coisa, a integração de tal coisa. Por quê? De novo, pode ser que em algum momento eu descubra que eu não preciso daquela integração com SAP. Eu resolvi de outra maneira. Então ali a gente pode colocar resultado de negócio, (inint). A gente tem essa palavrinha, resultados esperados. O que eu espero do meu produto nesses três meses ou nesse primeiro mês? Nesse primeiro mês, qual é a (inint) que eu estou (inint)? Eu posso orientar (inint). Quais as dores que eu estou atacando agora? As principais dores. Aí escrevo ali de acordo com a sessão de design. Eu posso entrar um pouquinho no detalhe ali de como eu estou controlando essa dor, de como estou atacando essa dor e as funcionalidades do meu (inint). Porém aqui tem um limiar: se eu pôr funcionalidade ali, eu tenho que tomar cuidado, porque isso pode virar uma meta e eu tenho que entregar aquela coisa e todo mundo espera pela funcionalidade, mas pode ser mesmo que (inint) de outra maneira. Então é delicado, sim, mas tem alguns modelos que a gente usa que a gente coloca dor como um breefing de uma solução dessa dor, de como eu estou atacando essa dor, uma área de negócio que me pertence, porque às vezes estou atacando áreas diferentes e essas áreas estão vendo esse roadmap. Elas querem se sentir representadas ali em (inint) expectativas. Então, beleza, está atendendo essa persona. É um pouco de médio e alto nível. Se chegar muito no detalhe ali, aquele roadmap depois pode ficar desatualizado, as pessoas perdem confiança e aí fica só mais um artefato que não serve muito para muita coisa. Esse é o nível que tem que ser atualizado. Não sei se cheguei exatamente na resposta, mas dependendo da maturidade do seu time você pode pôr (inint), seu time vai saber lidar com mudanças, seus stakeholders vão (inint) com essa mudança. Dependendo, se não estiver muito maduro, você põe menos detalhes, só para comunicar. É um pouco sentir mesmo como está o terreno, se a equipe está fazendo bem, se o roadmap está fazendo bem e seguir com ele.
M2: Bem legal do jeito que você colocou, porque é sempre assim, na verdade. No fundo, é o nível de restrição ou de estruturação ou de prescrição que você vai colocar. Em determinados contextos você aplica mais ou menos. Desse jeito que você colocou, me parece bem interessante mesmo, porque você cria alguma restrição mínima. Não estou deixando de falar o que eu vou entregar, mesmo que esse o que eu vou entregar seja mais negócio, igual você colocou aí, de (inint). Ainda sem colocar meio (inint) prazo, mas dando, colocando uma estruturação mínima. Realmente parece que esse tipo de coisa pode ser útil em vários contextos, mas você pode encarar, talvez, alguns cenários onde isso aí não seja satisfatório. O pessoal fala: mas eu preciso de mais que isso. O que eu entendo é que realmente depende muito de onde você está. Eu gostei muito desse jeito que você colocou, que é uma ferramenta de comunicação. Se você tem uma cultura adequada para isso, o pessoal já é aceitável você fazer muito mais como se fosse um (inint) ao invés de ser uma meta, isso aqui o time entende que é possível e, além de ser possível, é uma visão estabelecida de que a gente vai chegar em algum lugar. Porém, em outros lugares, em que talvez isso não seja aceitável, você tem que ir aumentando um pouco a restrição, ir aumentando, fazendo uns (inint) ali, tipo um episódio que a gente gravou no passado, do Alimentando os Tigres. Agora, uma coisa que me parece que sempre ajuda é você começar a entregar as coisas com cadência, já em um modelo orientado à hipótese, que você vai ganhando confiança até para que você vá convencendo as pessoas de tirar algumas restrições. Por exemplo, o que seria uma restrição? Ficar querendo amarrar tudo com uma data. Eu acho que depende muito do contexto em que você está.
M3: São passos. Às vezes eu gosto de falar do (inint). O modelo que eu falei, que é um modelo (inint), mas existem passos intermediários. Um passo intermediário, bem genérico, (inint), fica muito (inint), de repente, ao invés de trabalhar com datas e meses fechados, que aí é um modelo já um pouco mais amarrado, você traz para quarters, para períodos do ano, então quatro períodos do ano. Aí já é um passo intermediário, que é: eu tenho datas, são quarters que são separados ali. Tudo bem, não está amarradinho trinta de junho ou cinco de julho e por aí vai. Então foi um passo intermediário. A partir do momento que você faz essa entrega em cadência, como você citou, e os usuários ganham confiança de que está saindo, está vindo, religiosamente a cada sprint está entregando, aquela confiança ali começa a ser construída e aquilo ali começa a ser executado. Tem partes intermediárias nesse processo.
M1: Eu acredito profundamente nisso. Eu acho assim, existe um histórico de não confiança na TI com os métodos tradicionais, porque, justamente, ninguém estava acostumado a receber com cadência as coisas. E aí eu quero dizer assim, é tão caixa preta para quem está recebendo que o cara não tem ideia do que ele vai receber. Ele fica pedindo data. Imagina o cenário antigo: o cara pede datas, essas datas nunca são cumpridas, aí o cara pede para mudar uma coisa, aí muda as datas todas, atrasa tudo. Eu acho que essa desconfiança é super justificada pelo (inint) histórico. Quando você tem um relacionamento que se aproxima os times e o cara começa a sentir o que ele consegue receber de um time de duas em duas semanas, por exemplo, ele começa a ter os (inint) dele naturalmente. É isso que eu acho curioso, que eu acho que o pessoal, às vezes, tem dificuldade de perceber: ninguém fica planejando o ano inteiro na empresa toda para tudo, nesse sentido, de todas as entregas, mas da TI se exige isso. Por quê? Porque ainda se você como um investimento único, que eu vou gastar aquele dinheiro, não como um time que está mobilizado junto com os outros, gerando valor comigo. O cara não pega o time dele no começo do ano e fala: me fala todas as entregas que você vai fazer até o final do ano e as datas. Mas do time de TI enxerga isso, justamente por quê? Porque o cara tem que pegar uma verba, tem que gastar um dinheiro. Por isso que eu falo que o problema é profundo.
M2: Schuster, um jeito de analisar isso aí, é até meio chavão, mas é verdade: um dos problemas, a raiz dos problemas talvez seja porque é difícil de estabelecer confiança nesse tipo de modelo. Por exemplo, se você não faz entregas, você nunca consegue estabelecer confiança. Como você não consegue estabelecer confiança, você vai querer controlar. Quando (inint), você quer controlar mais ainda. E é um ciclo vicioso de você cada vez ter menos confiança. Agora, se você consegue ir estabelecendo algumas práticas que viabilizam que você consiga entregar pequenas coisas, é engraçado, porque mesmo sem ter todo o arcabouço de ser um modelo ideal de trabalhar com agilismo e com produtos, você começa a estabelecer confiança, porque você começa a estar entregando o tempo todo. Você começa a falar: estou entregando alguma coisa o tempo todo. Então, à medida em que você vai ganhando essa confiança entre os times, vai sendo mais aceitável usar modelos que têm um nível de restrição menor, tipo esse modelo de que o Onofre falou, que realmente parece um modelo bem legal para estabelecer algum nível de restrição sem ser uma restrição muito forte, que acaba sendo não habilitadora das coisas.
M3: Esse modelo tem até um nome e dá, para quem estiver interessado, pesquisar: lean roadmap, lean (inint) roadmap. Você via encontrar vários (inint), algumas empresas que já utilizam, exemplos de como chegar nele, esses modelos intermediários. Certa vez a gente estava vendo isso, para chegar nisso tem passos no meio do caminho para estabelecer essa confiança.
M1: Eu gostei muito do jeito que você coloca, de ser uma ferramenta de comunicação, ou do jeito que o Vinição fala: é um (inint) que o time está fazendo. Isso captura bem a essência do ágil. Eu não sei, mas é claro que eu posso declarar o que nós acreditamos e do que nós vamos correr atrás, para todo mundo ficar alinhado, todo mundo estar entendendo e todo mundo, inclusive, questionar e mudar isso no futuro. É completamente diferente de instrumento de gestão, de você falar: o plano é esse e não muda mais e eu vou morrer para entregar isso, e mesmo que a gente aprenda eu não mudo mais. É muito interessante isso.
M2: Parece até meio estúpido.
M1: É, mas essas sutilezas, é isso que é engraçado. Eu falo que o modelo mecanicista das organizações está por trás de tudo, sem perceber. Essa sutileza, por exemplo, você pega no (inint), aquele movimento do (inint) budget, o cara fala justamente isso. Quando você mistura forcast com meta, você avacalhou tudo, porque uma coisa é você chegar todo mundo junto e falar o seguinte: eu acho que a gente até consegue esse (inint), igual você disse, em três meses, por exemplo. Eu acho. É desafiador para caramba, mas acho que dá, sim. Agora, outra coisa é a seguinte: a sua reputação, o seu bônus, a sua carreira, o seu emprego, o que você consegue em três meses? O que você acha que o cara responde? Ele responde um décimo disso para garantir carreira, emprego, reputação.
M2: É a mesma pergunta, só que em uma tem uma arma na sua cabeça.
M3: Aconteceu comigo, certa vez. A gente em novembro fez um planejamento de metas e roadmap do nosso produto para o ano que vem, para o próximo ano. Lá em novembro do ano seguinte tinha um relatório no sistema, uma ficha de um relatório. A gente foi caminhando o ano. Entrou janeiro, fevereiro, foi caminhando. No meio do ano, aquele relatório não fazia mais sentido, o (inint) da empresa mudou e aquele relatório não fazia mais sentido. Não precisava, não iria ser acessado por ninguém. Porém estava cravado como uma meta fixa até de remuneração variável, por aí vai. Então nosso time teve que construir, de fato, em sprint, o relatório daquela tela e colocou no sistema como evidência. Tirou print, a evidência (inint). Ninguém nunca acessou (inint) sprint com aquilo. Tem várias armadilhas que a gente entra nesse ponto de colocar no (inint) de meta, como travado. Para estabelecer essa confiança, nas primeiras entregas a gente sempre viu o resultado esperado, as dores, se você faz um produto certo, com as boas práticas, boas técnicas e começa a mostrar resultado e negócio, (inint), na veia mesmo, esse produto de fato está reduzindo esse indicador, está melhorando esse indicador, está reduzindo aquele outro indicador, a confiança vai ser reestabelecida no (inint) do produto, o PEO do time. Eles vão voltar a confiar: nossa, vocês previram que vocês iam atacar essa dor e, de fato, vocês vieram aqui depois de um período e me mostraram esse número, que está menor, que está melhor. Está melhor esse indicador e o produto contribuiu nisso, que vai passando de contribuição nesse produto, nesse indicador. Às vezes tem várias áreas atuando. Minha parcela é essa aqui. Eu contribuí e, como eu previ, planejei, gera mais confiança, engajamento, e aí se consegue se flexibilizar um pouquinho esses planejamentos, em que a confiança passa a ser na entrega, não necessariamente no seu (inint).
M1: Eu queria só falar mais um pouquinho sobre outras ferramentas. Só queria fazer uma última ainda reflexão sobre isso, porque eu acho legal a gente reafirmar certas coisas aqui. A gente fala muito aqui, eu também acredito muito nisso, que muitas das coisas que acontecem nas organizações você pode resumir a teoria X versus teoria Y. A teoria X é que você não confia nas pessoas e aí você tem punição, ou, então, recompensa, e aí você acredita no engajamento. Isso aqui é muito a cara disso. Quando você obriga o cara a ter um roadmap fixo, um plano fixo ou o que seja, é quase você acreditando que esse cara só vai se motivar se ele for punido caso ele não entregue ou for recompensado por ter entregue. Quando você acredita nas pessoas e pega a melhor estimativa que elas têm, eu falo assim, quando você confia que as pessoas são engajadas, você confia que elas vão falar o seguinte: eu acho que eu consigo fazer isso em três meses e que o aprendizado em curto prazo e a vontade de entregar que vai mover muito mais do que a recompensa ou a punição no final. Eu gosto sempre de trazer isso. É muito difícil para a gestão tradicional, às vezes, perceber isso. O tanto que um time que quer perseguir um resultado incrível, com que ele se deparou nesse roadmap, vai simplesmente perseguir esse resultado incrível só porque ele quer mesmo, porque é legal, porque é humano. Não é porque alguém vai punir ele ou porque alguém vai recompensar ele. Acho impressionante. Acho sempre bom trazer isso à tona, porque aí a empresa vai, adota um milhão de ferramentas, mas continua no final com a crença de que “mas se esse cara não tiver uma ameaça, ele não vai entregar isso”. Isso muda tudo. É o que eu falo, é acreditar no ser humano. É acreditar que aquele time entrega porque quer. É o que a gente fala até no nosso manifesto, a gente entrega por uma questão de honra, porque está a fim de entregar. Onofre, queria só voltar, a gente até avançou bastante no tempo, mas eu queria, a gente falou muito do roadmap. Você chegou a falar de uns Canvas. Roadmap é uma ferramenta de comunicação de uma vez que você tenha a proporção de valor, tenha as dores. Você comunica para a organização onde é seu foco no presente, onde é seu foco amanhã, onde é seu foco no futuro, e mais ou menos algumas hipóteses que você tem, então fica por dentro do assunto ali. Você chegou a mencionar algum outro Canvas aí, não chegou? Dá uma passada geral por alguns desses produtos que você considera, desses artefatos, que você considera que são importantes e qual mais ou menos a função de cada um.
M3: Tem um que está sendo usado bastante nos times também, no (inint) a gente está usado bastante (inint), que é o Value Proposition Canvas. É um Canvas de proposta de valor. Visualmente, para quem está ouvindo, algumas pessoas já devem ter visto. Do lado esquerdo tem um quadrado e do lado direito tem um círculo. No lado direito, no círculo, tem o usuário, tem os jobs to be done que esse usuário precisa cumprir ao longo da sua jornada, e aí falo um pouco aqui que isso é muito importante. O usuário não acorda de manhã pensando assim: vou usar aquele sistema, acordei para usar aquilo. Ele não acorda falando isso. Ele tem uma jornada durante o dia dele, que ele precisa cumprir mais tarefas. Ele trabalha e o seu produto vai impactar ele, de alguma maneira, e tem que ser positiva. Você busca que seja positiva. Nesse Canvas você aprende quais são essas tarefas desse usuário e aí você coloca alguns ganhos que ele pode ter no dia a dia e as dores que ele tem ao executar essa tarefa, o job to be done. Do lado esquerdo, aí vem o seu produto no quadrado, então tem algumas áreas nesse Canvas que você preenche. É uma ferramenta de design, que a gente faz bastante nos discovery, contínuos, inclusive. A gente vai explorando novas features, novas dores e atualizando esse Canvas, e do lado esquerdo você coloca analgésicos, que a gente chama de analgésicos, porque se o cara tem uma dor, o seu produto pode trazer analgésicos. É lúdico, mas é simples de entender para todo mundo engajar e participar das sessões de design. Do lado direito tem dores, do lado esquerdo tem analgésicos. Mas que analgésicos o produto está trazendo? Ali a gente preenche esses (inint) design, dizendo quais são. A partir do momento em que eu tenho esse Canvas…
M1: Tem uns alucinógenos também nesse Canvas, não só analgésicos mesmo…
M3: A gente pode ter. Tem um outro item, que é vitaminas. São vitaminas. Eu posso ter uma dor e aí eu tenho uma analgésico, algo que resolve e ataca muito essa dor. Eu tenho alguns termos lúdicos. Ou doces. Candies. É nice to have. Seria legal se tivesse o produto e isso é uma coisa que vai atacar uma dor diretamente.
M1: Eu estou brincando com o alucinógeno. A gente pode chamar de alucinógenas as ilusões que os caras criam ali para resolver o problema.
M3: São essas ilusões que às vezes não querem dizer nada. Eles colocam uma frase muito bonita escrita lá, mas como que eu vou chegar nisso aí se eu preciso botar isso na prática? E o papel do produto, às vezes, é balizar isso aí.
M1: Agora, esses analgésicos e vitaminas são funcionais ou são hipóteses? São hipóteses ainda, mas alto nível, não é? Ou já são hipóteses solução?
M3: Às vezes na própria (inint) de design a gente percebe que está muito incipiente, as pessoas acreditam que aquilo resolveria o problema, mas tem que testar ainda, então tem dos dois tipos. O nível de certeza que pode variar de acordo com a hipótese, e a gente precisa validar mais ou menos de acordo.
M1: Está bom. Então existe o Canvas de valor, que vai declarar para o time qual é o valor, no final das contas, e quais são possíveis caminhos. Existe o roadmap para dar uma organizada nisso e mostrar o que foi priorizado no presente. Acho que só para a gente poder fechar, talvez falte aí alguma coisa que tem a ver com as medições. O que vocês usam, normalmente, para poder concentrar essas medições e poder acompanhar? Porque tudo isso ainda são intenções, tanto o Canvas de proposição quanto os roadmaps são proposições, não é? Mas a realidade tem que aparecer em algum lugar. Qual artefato você usa e que a realidade aparece?
M3: Perfeito. Agora você tocou em um ponto que é: quando eu sei que o meu produto é o certo? Eu estou construindo um produto certo, eu estou fazendo um (inint) com uma arquitetura habilitadora, mas como eu sei que, de fato, eu estou atingindo o meu resultado de forma mais eficaz? A principal coisa que eu vejo é medir métricas. Não é simples. Quando a gente fala de métricas poderia ser, sei lá, um episódio somente disso, porém tem alguns passos para chegar em uma métrica ideal. Eu consigo falar, pelo menos, alguns de que eu gosto. De novo, tem várias respostas certas. Eu gosto dessa linha, que é: a partir do momento em que eu tenho uma proposta de valor e tenho teses de sucesso nesse produto. O que é sucesso para o meu produto? O sucesso do meu produto tem que estar descrito. É isso aqui. Se os usuários conseguirem fazer isso ao final do dia, se a empresa conseguir esse indicador ao final do mês, ao final do período, o meu produto está tendo sucesso. A partir daí eu já começo a ter insights do que eu poderia medir e aí tem uma outra palavrinha, que é fator de sucesso. O que os usuários precisam fazer no meu produto? De que forma o meu produto precisa atuar para que esse sucesso aconteça? O usuário precisa logar o meu produto toda semana? Ele precisa logar todo dia de manhã? Meu produto é um produto de planejamento, por exemplo, e eu já mapeei a jornada e consegui fazer esse planejamento de manhã. O usuário tem que entrar todo dia de manhã? Todos os meus usuários têm que entrar todo dia de manhã? Vou medir se eles estão entrando todo dia de manhã. Uma vez na semana, somente, que ele entrar já faz sentido para ele? Tudo bem. Eu meço. Se ele entrar uma vez na semana, eu já estou com um (inint) legal. Eu tenho que tirar dessas frases bonitinhas que a gente escreve nos critérios de sucesso o que dali é um fator de sucesso. Eu tenho que saber. Às vezes seu produto é de transação. O usuário entra, faz algo, cadastra algo, cria alguma coisa dentro do sistema e sai. Isso é fator de sucesso para o sucesso? Vou medir quantas vezes isso está sendo cadastrado no dia, quantas vezes na semana. Porque para criar um número e medir ali na frente, eu faço como? Aí você vai em alguma ferramenta, vai ser uma (inint) de dados, alguém vai (inint) ou uma ferramenta mais inédita. Google Analitics. Ali é parte de operacionalização, mas o método é o passo importante. O que é importante medir? Aí esses critérios de sucesso, esses fatores de sucesso vão ajudar. Definir isso, escrever junto com o time, junto com os stakeholders, escrever e a partir dali você extrair. Então é logar no sistema. O cara tem que logar no meu sistema todo dia para ter sucesso. Depois eu vou para a ferramenta.
M1: Isso é legal, porque isso é bem pragmático. Eu falo, isso é lead de (inint) mesmo, porque é claro, é igual você disse, o cara pode fazer um software de planejamento e declarar que o sucesso é o (inint) mais o planejamento, vamos supor. Você até tem como medir isso, só que como é que se traduz o que você faz no software, no final das contas, para chegar a esse objetivo se você não detalha indicadores que levam esse sucesso, que é o que você está chamando desses fatores de sucesso? Para o cara ter um planejamento bom, ele tem que conseguir (inint), ver todas as informações. Ele tem que conseguir, então vou medir se ele está conseguindo. Ele tem que conseguir, a partir disso, cadastrar muito rápido um plano novo, porque, se não for muito rápido, ele tem que fazer mais um milhão de coisas e ele não faz. Estão conseguindo cadastrar, em média, em quanto tempo? Por isso que eu falo que acho volta ao começo do episódio, por que tem que ter toda uma disciplina que tem que cuidar disso? Porque dá trabalho para caramba, é difícil. É um problemão. Você tem que pensar o seguinte: eu quero planejar melhor e para planejar melhor as condições são essas, essas e essas, então ao medir isso eu tenho que pensar nisso, pensar naquilo. Por isso que eu acho que isso dá um desânimo e todo mundo volta muito fácil a (inint). O time não tem estrutura para isso, o time não tem tempo para isso, o time não tem espaço.
M2: Uma reflexão legal disso que você acabou de falar, Schuster, é que parece que a discussão é sempre binária. A gente cai nessas armadilhas de: ou eu tenho um modelo ideal, dos OKRs, ou então se eu não consigo ver isso funcionando, eu já vou querer controlar. O que eu vou querer controlar? Normalmente você vai querer controlar output, vai querer controlar quantidades que estão sendo feitas. Com isso que o Onofre está falando, eu achei muito interessante, porque você consegue fazer a discussão ficar mais rica de que tem outras fontes para você controlar. Você pode controlar um desdobramento do que são os seus indicadores, que é essa discussão do lead versus (inint) indicators. É claro que você sempre tem que tomar cuidado ali, porque às vezes você está medindo uma coisa que é um lead de (inint) e que não necessariamente tem uma relação cravada causal ali, mas é muito melhor você ir para um caminho desse do que ficar tentando controlar a produtividade. Eu achei bem legal a discussão desse jeito aí.
M3: Aqui vai para outros lados, métricas próximas, métricas norte. Aí especialista nessa parte de métricas dá para tirar do produto, porém (inint) por aí, medir para seguir o caminho certo.
M1: Muito bom, viu, Onofre? Acho que a gente já está chegando ao final. Igual você mesmo sugeriu, a gente pode gravar um episódio só sobre métrica. Aliás, acho que mereceria, porque para fechar o episódio com o que a gente falou no começo, é isso que eu acho legal, porque é tão claro. Você vê o seguinte: o time pode se declarar como ágil e pode entregar em curto prazo e pode ter um (inint) de adaptação incrível, mas ele pode estar canalizando pouquíssima energia para tudo isso que você disse. Mas aonde eu quero chegar? Como que eu meço que eu estou chegando lá? Como é que mesmo eu sabendo onde eu quero chegar, o que me diz se, de fato, eu estou caminhando para conseguir ter condições de chegar lá – que são esses fatores de sucesso que você disse? Se eu não consigo medir tal coisa, eu consigo substituir por uma outra coisa que me indica se eu estou chegando lá? Existe todo um outro problema aí que é completamente subestimado e que faz o time, de novo, voltar a entregar software baseado na cabeça de um cara que acha que sabe. É nesse sentido que eu acho que poderia ser a grande reflexão do episódio. É isso. Tem que ter alguém ali, que não é que ele é o dono da verdade, mas que traz essa disciplina para o jogo e fica jogando a realidade na cara de todo mundo, que é o seguinte: eu não sei se nós estamos tendo sucesso. Para saber se estamos tendo sucesso, está tendo um esforço desgraçado aqui. Nós temos que pensar o que nós vamos medir. Nós temos que pensar como é que a gente mede. Depois nós temos que medir (inint), depois nós temos que ver se o que a gente está… aí nós vamos saber se temos sucesso. Agora, por que tem que fazer isso? Porque se a organização está investindo todo esse dinheiro nisso e se isso é diferencial estratégico, só tem sentido fazer tudo isso se (inint) de sucesso. Não é porque é legal, inventamos. Esse episódio podia servir para sensibilizar as pessoas disso. E é engraçado, porque em nome de produtividade e eficiência, se o time ficar um sprint tentando medir coisa, alguém vai achar que ele entregou feature e vai encher o saco do time. Se o time ficar tentando marcar reunião para (inint), afinal, como é que eu sei se eu estou tendo sucesso? O time pode ouvir de algum líder aqui: vocês estão perdendo tempo, faz logo o troço que nós estamos pedindo para vocês. Todo mundo é cheio de certeza, só que isso é totalmente inconsistente com esse mundo vuca, com o mundo bane e com o próprio C-Level do (inint) que você está enfrentando. É isso aí, Onofre. Muito obrigado. Acho que você trouxe reflexões interessantíssimas e já temos o gancho aqui para um episódio onde a gente discute essa dificuldade de medir como é que um time faz isso e como é que ele faz isso no estilo café com leite, que é ir aos pouquinhos. Porque, senão, todo mundo assusta aqui e desiste também.
M2: É o meta ágil.
M1: Exatamente. A gente tem usado essa expressão aqui. A gente sempre fala: (inint) ágil sendo ágil. É fácil se assustar quando você pensa assim: nossa, então quer dizer que para saber se eu tenho sucesso, eu tenho que pensar no indicador, eu tenho que pensar no fator de sucesso. O cara desiste, porque ele não sabe disso tudo. Mas começa e aí vai lá no nosso episódio do fucking first step. É isso, Onofre. Obrigado pela participação. Você, certamente, participará de outros.
M2: Valeu. Foi bem bacana.
M3: Obrigado, vocês. Contem comigo aí para outros temas.
M1: Valeu, Onofre. Abraço. Abraço a todos aí, gente.
