Temporada 2 Episódio 6 – Ricardo Retamal
PROJETO: Desenhando Produtos

Pai da Leona. Apaixonado por música, fotografia e tecnologia. Há muitos anos trabalhando com produtos digitais, acredito em processos de melhoria contínua e nos princípios e valores do Manifesto Ágil. Me sinto completamente à vontade em ambientes colaborativos e que prezam por autonomia. E se por acaso, o lugar onde estiver não for assim, pode ter certeza que estarei trabalhando para mudá-lo.

A lista de recomendações:

Livro: Introdução A Comunicação Não-violenta (Marshall Rosenberg) – Porque comunicação é a base de tudo!

Livro: Strategize: Product Strategy and Product Roadmap Practices for the Digital Age (Roman Pichler)

Artigo: Products over projects (Sriram Narayan)

Artigo: Product vs Feature teams (Marty Cagan)

Artigo: Product Team FAQ (Marty Cagan) – “Uma espécie de continuação do artigo Product vs Feature teams”

Livro: Crucial Conversations (Kerry Patterson, Joseph Grenny)

Livro: Rápido e devagar (Daniel Kahneman)

Livro: Escaping the Build Trap (Melissa Perri)

Artigo: Product Management: por onde estudar de acordo com seu conhecimento (Jessica Seixas)

Está começando mais um Desenhando Produtos e Construindo Histórias. Eu sou o Josias Oliveira.

E eu sou o Leonardo Salvador.

Hoje nós vamos falar com ele, o nome mais difícil dito até agora, que ele é líder do chapter de produto ArcTouch. Acertei, Rica?

Ricardo – É isso mesmo.

Ricardo Retamal. 

Ricardo – Prazer estar aqui conversando com vocês. Espero que eu consiga trazer boas ideias, bons insights aqui.

Rica, você é professor da Tera também? Você é professor?

Ricardo – É, é expert, o professor tem aquela coisa de alguém que detém, num conhecimento absurdo e que passa para pessoas que estão buscando conhecimento. Eu gosto mais de… aquela pessoa que está ali para facilitar, para trocar, para colaborar e para extrair das pessoas coisas úteis, eu gosto mais desse tipo de abordagem, de igual para igual.

Vamos começar contando a sua história. O tempo que você quiser, o tempo é seu, sinta-se à vontade. A casa é sua.

Ricardo – Valeu, obrigado. Bom, eu nasci na cidadezinha chamada Rosário do Sul, no interior do Rio Grande do Sul, quase fronteira com o Uruguai. Até os meus 13, 14 anos eu nunca tinha tocado em um computador na vida. Um belo dia eu ganhei um computador, um 486 do meu pai. Eu vendi o cavalo que eu tinha, acho que esse é um negócio bem inusitado, eu sempre gosto de contar, porque eu vendi um cavalo para comprar um kit multimídia, que tocava música. O meu computador começou a falar comigo, começou a cantar em mit. E desde então, a minha vida foi indo sempre para os lados de tecnologia, eu comecei, eu fui para Porto Alegre, eu entrei na faculdade de desenvolvimento, e decidi que desenvolver não era a minha praia, eu mudei para a administração, com ênfase em análise de sistemas. E nessa jornada, eu descobri uma vaga para trabalhar como analista de qualidade numa empresa que era terceirizada da HP, entrei lá mesmo sem nunca ter atuado na área de qualidade. Fui muito bem, eu fiquei 4 anos e meio trabalhando nessa empresa. A HP me contratou mais 5 anos, trabalhando na HP, o total foram 10 anos de jornada, eu saí como líder de engenharia de testes, não sei o que lá. Mas, ao mesmo tempo, aquela coisa, esse negócio de colaboração, de troca de experiências, de ter pessoas fazendo coisas juntas, buscando objetivos em comum, sempre esteve presente dentro de mim. E durante muito tempo eu fazia isso nos meus horários vagos, de noite, eu participava de laboratórios para construir soluções para problemas da cidade, eu participava de iniciativas variadas, e eu decidi que era a hora de eu buscar algum lugar onde eu pudesse fazer isso dentro das minhas horas de trabalho também. Foi aí que eu descobri a tal da metodologia ágil, que era possível fazer coisas colaborativas, com times pequenos e ter grandes impactos. Nesse caminho, um grande amigo meu, o Matias, ele foi para a ThoughtWorks e ele começou a me mandar mensagem direto assim: “Cara, você tem que vir para cá, aqui é o seu lugar, vem para cá”. E por 1 ano e pouco eu não ouvi ele, até que um dia eu decidi ouvir, e aceitei ir para a ThoughtWorks. Nos primeiros meses de ThoughtWorks, já ficou muito claro isso: “Meu, você não é um QA, você está muito mais para uma pessoa de negócios, que lida com business, pela forma como você se comporta, pelo o seu relacionamento com os clientes, pelo seu posicionamento com os times”, e aí aconteceu a migração para o tal do business analyst, que era o papel da ThoughtWorks. E nesse caminho de analista de negócios, o nome varia sempre, cada vez que eu era alocado num cliente diferente o nome ia variando, porque, às vezes, eu atuava como PO, como product manager, como product specialist, como product consulted, e tudo mais. Mas estava muito nítido que produto era uma coisa que fazia parte do meu dia a dia, desde sempre, desde antes de eu saber que existia. Na HP eu já trabalhava com novos produtos, mas eram produtos físicos, tinha toda a questão de pesquisar, desenvolver e descobrir coisas novas, limitações de tecnologia e essa parte de… eu lembro que a parte de experimentação, de testar coisas, de colocar coisa fora… às vezes, a gente trabalhava 1, 2 meses e tudo ia para o lixo, porque a gente encontrava uma limitação do hardware, da linguagem, e a galera ficava muito frustrada com aquilo e eu adorava. Porque assim, “pô, eu aprendi para caramba e agora eu sei que não dá para ir por esse caminho, vamos tentar outro caminho”, isso sempre esteve muito presente dentro de mim. Em 2018 eu passei um tempo imerso dentro de um cliente da ThoughtWorks, quando eu saí desse cliente, eu fiquei quase 2 anos atuando nesse cliente, e eu falei: “Cara, preciso me reconectar com o mercado, ver o que está acontecendo”, e eu descobri o curso da Tera, eu me inscrevi no curso de produto da Tera, eu fiz o curso e pouco tempo depois me chamaram para dar aula, e eu estou lá dando aula desde então, compartilhando as minhas experiências.

Quanto tempo faz, Rica?

Ricardo – Foi no começo de 2019, eu acho, que eu comecei a dar aula lá. Eu não lembro exatamente quando agora, mas no LinkedIn, diz. Mas eu gosto muito de falar sobre isso, sobre essas experiências com clientes em ambientes hierárquicos, ambientes onde as decisões são mais complexas, onde tem gente que toma decisões, onde a gente não tem muita autonomia para fazer, como que a gente consegue fazer para encontrar brechas para usar dos princípios da agilidade, para buscar resultados melhores. Porque eu não vejo desconexão nenhuma entre os princípios da agilidade e a forma como se desenvolve produtos digitais, eles são totalmente entrelaçados na minha cabeça. Não tem como pensar em agilidade e não pensar em desenvolvimento de produto, não faz sentido.

Está aí uma baita pergunta. Essa a gente já vai ter que fazer para você.

Ricardo – Mas eu acho que é isso, agora em junho desse ano que eu recebi essa proposta para mudar de emprego, a ideia foi passar a liderar o time de produto da ArcTouch, que é uma outra consultoria também, focada em desenvolvimento de aplicativos, experiências web, realidade aumentada, experiências conectadas, como o pessoal diz. E tem sido uma experiência muito legal, porque lá eu saí desse papel de atuar dentro de times, de construir redes de influência dentro de clientes e passei a atuar numa camada mais “apoio das pessoas do time”, trazendo ferramentas, fazendo perguntas, mas eu não estou lá no front, no dia a dia, nesse exato momento. Então é uma experiência diferente, é uma experiência nova e está sendo bem interessante o que eu tenho feito nos últimos tempos.

Eu achei super interessante essa questão, como trabalhar em consultoria não é tão simples assim, não é como trabalhar num produto específico, numa companhia que desenvolve um produto específico. E você comentou de algumas dificuldades, seria muito legal se você pudesse falar um pouco sobre esse assunto.

Ricardo – Eu acho que os anos trabalhando em consultoria… a gente sofre bastante, porque a gente nunca tem controle de tudo, a gente tem controle de pequenos fragmentos da jornada do produto, ou até, acessos fragmentados aos stakeholders do produto que a gente está trabalhando, existem camadas, às vezes, que bloqueiam. Tudo depende muito do cliente, de como funciona a hierarquia, de qual foi a área que contratou a consultoria, isso influencia bastante também. Às vezes, a área de marketing contrata e aí o TI não gosta muito. A área de TI contrata e as outras áreas têm um pouco de complicação, mas acho que o fato de estar em lugares, onde não necessariamente todas as pessoas queriam que eu estivesse, me fez pensar que o principal trabalho era unir as pessoas através de um objetivo. Eu acho que liderar times, liderar ideias, mesmo sem ter o crachá de líder, é um papel fundamental de consultoria, e é um papel fundamental que eu vejo de gestão de produto, eu não gosto muito dessa analogia de produto ser o CEO, aquela ideia de “mini chefe” do produto. Não, eu acho que nós somos uma pessoa com habilidades e com o tempo dedicado a coisas diferentes. E na consultoria eu acho que eu consegui desenvolver bastante essa parte, porque eu precisava muito construir relacionamentos com determinadas pessoas, às vezes, eu não acessava aquela pessoa, eu precisava ir pelas beiradas, conversando com gente que podia chegar naquela pessoa que eu precisava ter algum tipo de acesso, e os conceitos da agilidade, trazer isso. Normalmente, na ThoughtWorks, principalmente, a maioria são clientes e empresas grandes que buscam a ThoughtWorks, então tem uma questão de hierarquia muito pesada, de como a gente quebrar essas barreiras através dos princípios, de ter uma comunicação transparente. Tiveram times que eu participei que o meu maior objetivo era fazer com que o designer do time sentasse nas mesas junto com o time, para que a troca acontecesse e não acontecesse um processo de cascata, do cara desenhar todas as telas e entregar para o time fazer e “se vira aí”, sabe? Então, esses pequenos avanços, essas pequenas conquistas, usar isso para benefício da gente e mostrar para o time: “Cara, eu não sou mágico, eu não tenho todas as respostas, não tenho todas as soluções, mas a gente está aqui junto para conseguir, para construir”. O papel da consultoria também de: “Eu não estou aqui para ameaçar o seu emprego, eu estou aqui justamente para te ajudar a fazer melhor o seu papel, como um apoio”, e o principal objetivo de fazer o cliente brilhar e não sair como a estrela. Então, eu vejo muito o papel de produto como esse, de fazer com que a engrenagem funcione de uma maneira adequada, e não ser a estela “product manager fulano do produto tal arrasa”, não, se está assim está errado. O time precisa arrasar, as pessoas precisam estar engajadas. Então, tem muito a ver. Nesses trabalhos de consultoria a gente fazia algumas estratégias, até assim de conversas internas, o fulano vai sentar do lado da pessoa X, do cliente, para tentar convencer, conversar e trazer ela para mais perto do time. Sabe? Pequenas estratégias de dominar terreno, ganhar uma batalha para tentar vencer a guerra. Acho que esse é o principal ponto que a bagagem de consultoria traz, a questão de comunicação, a habilidade de negociação, de facilitação, todos esses são pontos que trazem, que eu vejo vínculos diretos com a vida de produto. Mas ser pessoa de produto em consultoria é extremamente complicado, porque você tem que estar desapegado dessa coisa de jornada, de acompanhar o produto. Às vezes, você faz coisas que você não vai ver os resultados, às vezes, você entra na empresa para apagar um incêndio e você tem que olhar para o todo, entender a fase do produto, em que momento do ciclo de produto aquilo está, usar as ferramentas adequadas e, provavelmente, daqui a um tempo você não vai estar mais ali. Então, como que eu resolvo um problema, preparo um terreno e oriento as pessoas? Tipo, o meu entregável não pode ser só um código bonito, algo que funcione na mão dos usuários. Eu considero um entregável de sucesso quando a gente saía de dentro de um cliente e as pessoas sabiam como continuar tocando, que métricas continuar acompanhando, o processo, a cultura de desenvolvimento ágil começava a estar ali encrustada no dia a dia das pessoas e do cliente. Então, é muito mais do que entregar software, sabe? É muito mais, o impacto pode ser imenso. Eu vejo e algumas pessoas vêm conversar comigo no LinkedIn, alunos da Tera, pessoas que se conectam comigo por diversas formas, assim: “Ah, eu sou consultor, eu não consigo fazer isso, não consigo fazer aquilo”, e eu: “Tá, vamos fazer um mapinha básico. Quem são todos os stakeholders? Quem você envolve nas suas decisões? Quem são as pessoas que você consulta quando você precisa fazer alguma coisa”? Você pode não ter o controle do negócio, mas se você mostrar para elas que você está perto, que você está ali disponível, que está colaborando para que a coisa aconteça, a tendência é que o resultado seja mais fácil. Eu lembro de uma história, eu estava dentro de um cliente, e nesse cliente tinha uma coisa muito forte de “somos da empresa e vocês são terceiros”, tinha essa divisão muito forte. E uma pessoa importante da empresa, uma pessoa de negócios entrou no elevador junto comigo, olhou para mim e falou assim: “Você é daqui da empresa”? Eu falei: “Olha, depende do que você está dizendo, se você está perguntando se eu sou uma pessoa que está ajudando a construir o produto da empresa, sim. Agora, se na minha carteira de trabalho diz que eu sou dessa empresa, não”. Sabe? Então, acho que esse ponto de conseguir navegar em organizações, navegar em estruturas diferentes, em alguns clientes as pessoas do cliente não sabiam que eu era terceiro, às vezes, porque eu me dava bem, eu me relacionava, eu me comunicava, eu conseguia trafegar. E isso é uma habilidade que para fazer o trabalho de produto dentro de uma consultoria, é extremamente importante, não dá para ser só “seguir o framework”, tentar aplicar, fazer o que o guia manda, você tem que ter o jogo de cintura, tem que ter esse entendimento. E o ponto de: O resultado não é o Rica que fez o negócio. O resultado é: As pessoas do cliente brilharam, o time do cliente começa a ser reconhecido pelos resultados que estão sendo entregues, aí é sucesso.

Eu já anotei 259 perguntas para fazer aqui, mas eu vou fazer uma só, senão a gente vai ficar 5 horas aqui. Uma das coisas que eu sou muito grato à consultoria é que eu fiquei, praticamente, quase 5 anos em produto, especialmente em um produto. O Salvador trabalhou comigo, a gente estava dentro de um produto. Só que antes disso eu tinha tido a minha agência, eu tive um tempo a agência, que de certa forma trabalhava como consultoria, porque o produto não era nosso, a gente sempre fazia algo para alguém. E uma das coisas que eu sou muito grato à ThoughtWorks ali, por esse tempo que eu trabalhei na ThoughtWorks, junto contigo até, é que fez resgatar umas coisas, do tipo: “Peraí, a gente vai ter que influenciar legal agora, porque não é mais nosso”, antes a gente podia ir lá, podia pegar, inclusive, o código, subir o código, e era nosso. Não é mais, é do cliente. E como a gente faz, um pouco daquilo que você falou, aquilo do designer sentar junto na mesa, o time não ficar esperando as telas do designer? Como a gente pode fazer no ambiente, onde é super cascata, e que é tudo super segmentado, separado, a gente começar a influenciar as pessoas? O que, na sua visão, são os primeiros passos para começar a quebrar essas barreiras que você falou?

Ricardo – Acho que o primeiro passo é fazer as pessoas entenderem que existe uma forma diferente de fazer as coisas. E começar dentro do time. Se o meu poder de influência é o time que eu estou trabalhando, é começar ali a mostrar para as pessoas que têm valor elas não serem apenas entregadoras de cards. É a conversa, antes de começar a fazer uma tarefa. É eu voltar de uma reunião, aonde algo foi alinhado e conversar com o time, explicar o porquê as decisões foram tomadas. É criar espaços de troca de conhecimento, demonstrar interesse pelo trabalho das pessoas. Por exemplo, você chega num lugar onde o desenvolvimento é visto como um departamento e as pessoas de outros departamentos tiram pedidos lá, tipo uma pastelaria, tipo: “Me vê um de carne, me vê um de queijo”, e a tecnologia está sempre atrasada, correndo para entregar aquilo. Se você chegar para essas pessoas de desenvolvimento e disser: “A partir de agora, nós somos um time de produto e todo mundo vai trabalhar junto”, o cara vai dizer: “Você está louco. Me deixa aqui no meu canto fazendo as minhas tarefas, porque é o que eu quero fazer. Eu sempre fiz assim”. Então, acho que o primeiro passo é essa aproximação, quebrar um pouco essa barreira de, o analista de requisitos, a pessoa de produto traz as demandas e mostra, mas não, senta do lado, conversa, discute, pergunta a opinião, o time começa a trazer insights, gerar espaços de reflexão, de melhoria contínua dentro do time, e isso faz as pessoas começarem a trabalhar numa forma um pouco mais leve, um pouco mais felizes, e isso começa a contagiar. Eu já usei essa estratégia dentro de alguns clientes, o meu time começou a ser referência em ambiente divertido de trabalho, e onde as pessoas eram ouvidas, elas eram mais do que só o seu papel, mais do que a sua job description. E aí começa a influenciar outros times, e alguém começa a olhar para isso. Mas só isso não muda nada. Essa é uma primeira camada de causar impacto. Quando essas pessoas começam a falar para os colegas, para os seus pares de que aquele trabalho é diferente, aí é hora de entrar numa camada com o trabalho de consultoria, de entender quem são os tomadores de decisão, quem são as pessoas que podem influenciar numa mudança e tentar se conectar com elas para dizer: “Olha, o que eu estou fazendo de diferente aqui? Vamos tentar ampliar isso”? E, de novo, como qualquer transformação digital, muito se fala de transformação digital agora, principalmente depois da pandemia, não dá para eu transformar a empresa inteira numa tacada só, começa por um pedaço e mostra que funciona, começa por um time e mostra que funciona. Uma vez eu entrei num cliente que eles tinham o mesmo fluxo de trabalho no Jira para todos os times da organização. Eu falei: “A minha missão aqui é fazer com que o time defina qual é o fluxo de trabalho que funciona para ele”, porque a galera pulava colunas, criava o card só quando a parte de desenvolvimento já estava pronta, porque era um “saco” passar por todas as etapas antes. Ou seja, as métricas eram uma bagunça. Quando eu consegui, depois de muito esforço, eu e umas colegas da ThoughtWorks também, que a gente entrou nessa missão de: “Vamos mudar isso, esse é o nosso objetivo”, quando a gente mudou isso, foi um efeito dominó, todos os outros times começaram a querer também ter autonomia e poder construir um boarding… Olha que coisa básica. Cara, é uma ferramenta que funciona para ajudar o time, não é um processo para atrapalhar. Então, quando você mostra isso para as pessoas, que o trabalho pode ser mais tranquilo e que você tira insights daquilo, aquela ferramenta começa a te ajudar, começa a ajudar o time a ordenar priorização, a pensar em objetivos, a ter mais previsibilidade dos entregáveis, do que está acontecendo, para onde a gente está indo. O time começa a tomar conta do processo. Eu sempre brinquei que o meu papel dentro dos times era me tornar obsoleto, porque não adianta eu querer concentrar as coisas dentro de mim, em cima da minha cabeça e no meu papel, não. Como que eu faço para empoderar dev, QA, designer, para serem tomadores de decisão, para puxarem conversas e pensarem no produto que a gente está fazendo e não na tarefa que eles estão fazendo. E aí, eu acho que esse é um ponto bem importante, da forma como a ThoughtWorks se posiciona também, acho que ajuda bastante, não é body shop, não vende um dev, dois devs, tem essa coisa de “a gente entrega times”. Esse conceito de “a gente entrega times”, eu levo para a vida, porque eu saí de lá, mas o conceito me acompanha, porque grupos de pessoas juntas com habilidades diferentes trabalhando em busca de um objetivo em comum. Então, quando a gente faz um grupo de pessoas que, às vezes, está cada um em um canto… Eu já fui, quando eu comecei a minha carreira de QA lá, eu ficava numa salinha lá no fundo da empresa, que nem janela tinha, era completamente separado, eu recebia o pacotinho do dev para testar. Então, eu entendo a importância de estar dentro desse fluxo, de estar dentro do processo, de trocar ideia, de dar uma opinião e ser ouvido, daquilo ser levado em consideração. Então, o primeiro passo é isso, é fazer as pessoas se sentirem parte do que elas estão fazendo. Não pode esperar uma mudança da noite para o dia, tipo, isso não vai mudar, não vai acontecer assim, porque é uma mudança cultural e mudanças culturais exigem muito esforço, exigem muita dedicação. Acho que tem um ponto bem importante nisso, que dá para adicionar aqui, que é: Colaboração e autonomia são coisas que a gente não é naturalmente treinado para trabalhar, para ser. A pessoa entra no time, a gente esperar que naturalmente ela colabore de uma maneira linda e maravilhosa, e que ela saiba usar da sua autonomia, isso é mentira. O mercado, o meio acadêmico, as escolas, tudo nos colocam em caixinhas, tentam nos moldar, você tem que fazer isso, você tem que fazer aquilo, você não pode fazer isso, isso é coisa de menino, isso é coisa de menina. Vem desde lá de trás. Então, ser intencional, dar espaço para as pessoas, estimular colaboração, muito mais do que cobrar por velocidade de tarefa, é cobrar pelo desenvolvimento pessoal, por quem você quer ser. Como extrair o melhor das pessoas que estão ao seu redor, sabe?

A minha visão é que velocidade acaba sendo a consequência disso, não é? E não o contrário, do tipo, você querer a velocidade: “Galera, temos que reduzir o tempo de entrega”. Não, cara, esse é o resultado. A mesma coisa: Qual é o objetivo de vida? Ganhar dinheiro, você vai se frustrar muito rápido.

Ricardo – Se for ganhar dinheiro, tudo bem, “vem aqui, eu vou te ajudar a encontrar formas de você performar muito bem e ganhar muito dinheiro. Vamos lá”, pode ser. O mundo aí fora permite todos os tipos de sonhos. 

Você tinha falado do “apagar incêndios” também. Passando, pelo menos, os últimos 10 anos ali, vendo o trabalho de consultoria, trabalhando em startup, scale-up e vendo outras empresas, outras empresas pedindo ajuda. Tem um negócio que eu vi em comum, que é: Os pontos em comum das empresas, sejam elas grandes ou pequenas, empresa que está começando ou empresas enormes, Entreprise, é que as empresas acabam caindo em determinado ponto e o que aquele livro fala, que é a Armadilha da Construção, de Build Trap, a armadilha de ficar apagando incêndio ali. Como que a gente evita entrar no ciclo vicioso de “estou sempre no modo bombeiro”, apagando incêndio e correndo atrás do próprio rabo ali?

Ricardo – É, corre. “Vamos correr, vamos todo mundo junto correr até a data da entrega”, só que ninguém lembra que depois da entrega vem outra entrega. Eu acho que esse é um ponto bem interessante, as gestões das organizações têm muito medo de perder o controle das coisas e acaba criando mecanismos de comando e controle, vamos dizer assim. Tipo, micro gerenciamento. E aí, o medo do desconhecido, medo de não ter previsibilidade de tudo acaba gerando esse tipo de coisa, só que essa previsibilidade é fictícia, porque você sabe quando você vai entregar a funcionalidade X, mas você não tem ideia se aquela funcionalidade vai causar algum impacto ou não, e, às vezes, você nem sabe, como eu ouvi hoje, tipo assim: “Vamos entregar o MVP”, “Ah, legal, vai entregar. Quais são as métricas que você vai acompanhar”? “Se a feature foi entregue ou não”. Isso não me diz nada do problema que está resolvendo. Esse “Escaping the Build Trap”, tipo, escapar dessa correria, eu vejo que tem muito uma mudança de mentalidades, de sair da ideia de atender necessidades de stakeholders, de lideranças, e passar para realmente uma visão centrada no usuário, focada em dores e necessidades dos nossos roadmaps, da grande maioria das empresas ainda é uma lista de funcionalidades. Você nunca vai escapar da correria de construção se a sua meta do bimestre, do trimestre, seja lá qual for o período, for entregar a funcionalidade X, Y e Z, tipo uma listinha de funcionalidades. O que a gente precisa é mudar para que problema a gente está resolvendo, e assim que você sai desse ciclo e começa a focar em valor, em entrega, em que impacto está causando. Essa é uma das conversas mais difíceis que se tem dentro de organizações. Durante bastante tempo eu pensei que isso era uma grande dificuldade do mundo da consultoria. Empresas que são melhor estruturadas não chamam consultorias, porque está tudo bem, está tudo funcionando. Mas quando eu comecei a dar aula na Tera, que as minhas aulas tocam muito nesse assunto, de como os requisitos vêm para o time, priorização, negociação com stakeholders, as pessoas começaram a trazer, pessoas das mais variadas empresas que já passaram pelas aulas, sempre trazendo os problemas similares aos que eu estava vivendo, e que eu tentava lidar e dizia: “Cara, isso é geral”, não tem isso de ser de consultoria, de ser de startup, não, porque a gente está falando sobre pessoas, a gente está falando sobre egos, sobre objetivos e metas que são alinhados em cima de estruturas erradas, de tomadas de decisão, às vezes. Então, alguém senta lá no Olimpo e prepara uma lista de funcionalidades e discutindo: “Vocês têm que fazer isso”, “ah, tá. Mas qual é o usuário que a gente está atingindo”? Um grande exemplo disso foi um cliente que eu passei, que a gente reformulou o App deles, e 98% da base usava Android e a gente tinha que liberar as funcionalidades novas em IOS primeiro, porque todo boarding executivo da empresa usava IOS. Para quem que eu estou fazendo isso? Sabe? Então, é sair dessa ideia de certeza, abrir mão do ego, acho que o principal ponto é ego, é relacionamento de poder, é entender que mesmo usando o meu produto no dia a dia, eu não sou o usuário do meu produto, eu preciso olhar para as pessoas, preciso entender o que elas estão… e conseguir se adaptar. Eu acho que tem esse ponto. Quando as empresas fazem lá os seus planejamentos e suas metas, tem a lista de funcionalidades que vai fazer, a lista acordada para o trimestre, as entregas acordadas para o quarter. Quando acontece um bug em produção, ou algo crítico que você tem que responder rápido, todos os princípios de agilidade que falam em adaptação, em colocar e resolver os problemas das pessoas, vão por água abaixo, porque você tem que seguir o plano. O plano vem antes de atender as necessidades de usuários. E aí complicou completamente. A ideia de criar nomes diferentes para MVP ou para conceitos diferentes, é porque as pessoas não focam no que é essencial, que é “que problema eu estou resolvendo? Como que a pessoa vai se encantar pelo o meu produto, mesmo ele sendo uma versão mínima desse produto”? Sabe? Faz por fazer. Eu já ouvi histórias bem interessantes assim: Ah, o bônus da empresa estava atrelado a uma lista de funcionalidades e a galera entregou coisas que clicavam e era falso, era um mockup, clicava e não tinha ação, os botões ainda estava lá e eles ganharam bônus. Ou seja, a estrutura das organizações premia quem corre para construir algo. Então, para escapar dessa armadilha, só mudando a mentalidade e olhando, de verdade, para o que os usuários, os clientes estão pensando, fazendo e precisando dentro dos nossos produtos.

Interessante que esse tipo de mentalidade, esse tipo de problema que a gente está vivendo agora, a galera falava nos anos 2000. Tipo, o manifesto ágil nasceu por volta do início dos anos 2000 e nós estamos em 2022, e está acontecendo a mesma coisa. 

Ricardo – Exatamente. Em 2001, fazem 20 anos agora o manifesto ágil, foi no comecinho do ano. Os problemas são os mesmos, as pessoas inventam maneiras de fazer, mas elas querem continuar tendo controle no método tradicional, falando da grande maioria das empresas. Eu acho que o uso da agilidade como uma ferramenta de prateleira, está direcionado, está diretamente conectado com isso, de: Eu compro, eu aplico um scrum dentro dos meus times, mas o método que as coisas andam e chegam para os times, eles continuam iguais. Às vezes, eu me pergunto se a gente realmente saiu, a maioria das empresas realmente saíram do modo cascata de fazer as coisas, quando eu tenho uma pessoa de negócios que pensa num tema, passa por um refinamento, vai para um time de design, o designer desenha as telas, passa para o time de desenvolvimento que implementa iterações. Isso é agilidade ou isso é o cascata? Tipo, eu só estou lá batendo tambor para a galera de TI correr mais rápido. Complicado.

Cara, eu acho que o nosso público não está tão familiarizado com consultoria. Como funciona uma consultoria? Eu até fiquei me perguntando: “Tá, mas e a ThoughtWorks aqui”? Como funciona? Para mim era, eles pegam um produto aqui, fazem e entregam para o cliente. Mas não é isso que eu estou entendendo aqui, são equipes que entram dentro de um produto, que já está meio elaborado e ajudam a construir. Explica um pouco melhor isso? Acho que vai ser legal para as pessoas que vão escutar.

Ricardo – Eu acho que existem vários tipos diferentes de consultoria. Existe consultoria que você vai lá e diz: “Eu preciso de dois dev python, um dev web e dois dev Android e IOS”. “Pum”, está lá no seu time, surge a pessoa aleatoriamente e existe uma grande tendência de que seja um método de trabalho onde as pessoas estão focadas em entregar tarefas. Se a empresa que está contratando não guiar muito bem o trabalho dessas pessoas, elas vão ficar lá fazendo suas tarefas, caiu, resolve e vai embora. E existem outras consultorias que tendem a fazer um trabalho um pouco mais dedicado a entrega de valor. Até quando a gente chama pessoas de recurso, morre um panda em algum lugar. Então essa história de alocar recursos, morreu pandas pelo mundo. Então a ThoughtWorks tem muito essa pegada, assim como outras consultorias, existem outras também que atuam no mesmo estilo, não é exclusividade da ThoughtWorks de ter muito forte a questão da agilidade. Tipo, tem o Martin Fowler, um dos signatários do manifesto ágil, é até hoje um consultor líder na ThoughtWorks. Outras pessoas que também estavam lá presentes, já passaram pela ThoughtWorks, pelo quadro de funcionários da ThoughtWorks e sempre foi muito reconhecida pela cultura de agilidade, pela entrega de software de qualidade. Então os clientes chegavam e pediam: “A gente não quer só o código, a gente quer a cultura de vocês também”. Tem times que atuam isolados, dentro está atuando para um cliente um time só de ThoughtWorks, mas tem times aonde isso se mistura, e aí é muito mais essa coisa de “a gente está aqui fazendo com vocês para mostrar que outra forma de fazer é possível”, é meio que ajudar a pegar pela mão e mostrar como trabalhar com agilidade, como trabalhar pensando no usuário, pensando em valor. Então, esses dois grandes grupos de consultoria: body shop, projetinho contrata, e aí tem várias consultorias ainda que fazem esse tipo de coisa. Assinou um contrato com o cliente, contrata as pessoas do mercado, terminou o contrato com aquele cliente, demite as pessoas. Não tem retenção de talento, não tem retenção de conhecimento, a coisa vai indo numa bola de neve. No outro modelo a gente tem essa absorção de conhecimento pelo time, entendimento de diferentes segmentos. Eu passei por quase 8 anos de ThoughtWorks, eu passei por, sei lá, 6, 7, 8 mercados completamente diferentes. Olha a bagagem que isso traz de chegar num lugar, mesmo que eu nunca tenha lidado com banco, por exemplo, de entrar e conseguir me posicionar, entender as nuances daquele sistema, daquela ferramenta de trabalho e conseguir colaborar e apoiar as pessoas do cliente, que estão ao redor também nesse processo. Então, acho que basicamente é essa divisão, de ir além de só entregar software, ou ser um pull de recursos as grandes divisões de trabalho de consultoria. Esse negócio de ir além, de atuar com talento, com cultura, é onde eu vejo que existe valor, é onde eu vejo que os maiores impactos e as relações mais duradouras, inclusive, surgem isso. Porque quando eu tenho só um pull de devs, eu posso ficar trocando de empresa, alguém cobra mais barato, eu pulo para o mais barato. Já aconteceu de eu estar dentro de clientes e chega uma pessoa de outra consultoria, senta do meu lado, era o primeiro dia de trabalho da pessoa e era um dev Android e o cara olhou para mim e falou: “Como é que eu instalo mesmo Android Studio no Mac”? Aí eu: “Eita”. Ele estava cobrando do cliente uma bela quantidade de dinheiro por hora.

Caraca, é cada uma. Rica, você falou sobre cultura, como criar uma cultura ou influenciar ela de fora para dentro.

Ricardo – De fora para dentro você diz do time? De fora do time para dentro?

Sim, como consultoria. Você está ali na consultoria, você já vai encontrar uma empresa que tem uma cultura e você tem que influenciar ela. Como mudar isso? Como quebrar essa barreira?

Daí eu acho que vale tanto para consultoria, quanto para a forma de pensar. Porque, por exemplo, se você chega numa nova empresa, você é o elemento novo ali. E se você é uma consultoria, você também é um elemento novo em determinado momento.

Ricardo – Eu acho que tem uma certa liberdade em estar atuando como uma consultoria, ainda mais uma consultoria que você é contratado para influenciar no trabalho, não só para entregar cartões, entregar tarefas, que te dá uma certa autonomia de falar coisas que funcionários da empresa até, não falam. Então, eu sempre gostei disso, e eu já fui até usado em clientes, pessoas de outros times diziam: “Tem uma reunião lá, você quer ir na reunião para me ajudar a defender esse argumento”? E eu: “Bora, vamos lá, porque eu estou aqui para o que der e vier”. Então, acho que o primeiro é não ficar só no discurso. E mais importante do que fazer é mostrar o processo de tentar, mostrar que dá para errar, mas errar pequenininho, corrigir o erro e ir conversando. Não adianta eu ficar trazendo livros, artigos, teorias, porque isso não convence ninguém. Se convencesse, quem entra em biblioteca ia ter todo o conhecimento do mundo, não rola. Então, fazer pequenas coisas. Como eu falei lá a história de quebrar o fluxo do Jira, eu fui fazer uma dinâmica com o time, e obviamente, eu não reservei sala para fazer essa dinâmica, eu fiz no Open Office lá do cliente para todo mundo ver o time discutindo todas as etapas que aconteciam, desde uma ideia surgir, até ir para a produção, depois que aquelas etapas foram mapeadas, a gente começou a definir o que era coluna do boarding, o que não era, você já saia com o boarding estruturado, com uma definition of ready e uma definition of done feita, o time entendendo todo o fluxo e as pessoas que estavam em volta olhando e falou: “Eu quero fazer isso no meu time também”. É um trabalho de mostrar para as pessoas que existe vida além do meu cubículo ou do que está escrito ali na minha descrição de trabalho. Então, para mudar a questão cultural, primeiro que você tem que ter aliados, ninguém faz nada sozinho. E aliados dentro da organização ou dentro dos departamentos, por exemplo, falando de uma empresa, sem ser consultoria aqui, que outros departamentos eu preciso influenciar, que interferem no trabalho do meu time, e como que eu faço para me aproximar dessas pessoas, e trazer elas para uma visão mais lean, mais comunicativa, adicionar aquela pessoa de business lá, extremamente tradicional no canal de slack do time, e no canal das piadas também. Sabe? Ter esses momentos de buscar as pessoas, trazer elas para perto. A cada vitória, compartilhar isso, celebrar isso, mostrar para todo mundo as derrotas também, trazer o time para perto. Eu sempre digo que quando eu perco em alguma coisa que eu estou tentando influenciar, uma priorização de algo dentro de um cliente que eu queria muito, “ah, esse produto precisava, eu acredito muito”, os dados estão dizendo que era para ir para aquele lado, mas o dono do produto não quer. E voltar para o time, usar isso como um ponto de vulnerabilidade, assim: “Eu tentei, não deu. Vamos todo mundo junto resolver essa parada, para tirar isso da nossa frente. Vamos lá, vamos apostar naquela outra coisa lá para mostrar que pode dar certo”. Teve uma vez que o time que eu estava pagou para ver, o cliente queria uma solução, a gente acreditava e os dados apontavam tudo para uma outra solução, e a gente fez… na época eu não tinha filho ainda, eu tinha a vida mais tranquila. A gente fez a solução que o cliente queria, durante o horário de trabalho, e fez a solução que a gente acreditava depois do horário de trabalho, e na hora da entrega a gente entregou as duas para o cliente e disse: “Vamos fazer um teste AB para ver qual que é”? O cliente aceitou, e a solução que a gente tinha proposto… ficou 5 horas o teste AB ligado, e ele disse: “Desliga esse negócio, pelo amor de Deus, e manda todo mundo para o de vocês, porque é muito melhor mesmo”, estava convertendo muito mais. Então, esse foi um “puta” esforço que a gente fez para convencer que era possível a certeza dele não ser tão certa assim. Mas essas pequenas influências, o trabalho que foi feito para botar o designer sentado na nossa mesa, nesse cliente que eu comentei, o cara queria voltar depois para a nossa mesa, e as pessoas do time dele, porque eles ficavam todos numa ilha de designers lá, começaram a querer ir conversar com os times que eles estavam fazendo os trabalhos. Porque você vê o valor do negócio, você entende tipo a redução de complexidade. O cara nem desenhava uma experiência, porque o dev já estava ali, e dizia: “Olha, o nativo daqui do Android tem isso daqui, quem sabe você usa isso aqui também”. Sabe? A troca de experiência, vai adicionando coisas na nossa base de conhecimento e só nos leva para lugares melhores. Então, o trabalho é um trabalho de formiguinha, mas para mudar de verdade, culturalmente, precisa ter apoio de liderança, precisa ter convencimento da base também, das pessoas que estão dentro dos times. Então, por isso começar influenciando o seu time, o seu grupo e tentando expandir, com o suporte da liderança dizendo: “Tira os olhos de cima desse time, porque eles vão fazer uma coisa legal”.

Aproveitando um pouco do que você falou sobre metodologias ágeis, e a provocação que você fez, que foi bem legal, sobre: “Beleza, cara, será que o que a gente tem hoje no mercado não é uma cascata, e a galera batendo o tamborzinho ali mais rápido”? Eu queria saber de você, para você o que é ser ágil então? O que seria um modelo bacana aí, que as empresas não estão fazendo hoje em dia?  

Ricardo – Acho que o principal é o foco excessivo do mercado em cerimônias e práticas. Tipo, está todo mundo correndo para encaixar o trabalho em frameworks, mas ser ágil não tem nada… se você ler os princípios lá da agilidade que, inclusive, estão lá no site do manifesto ágil, 20 anos de existência, eles não falam nada de seguir um framework, existem frameworks que serviram de base para o pensamento ágil, e existem frameworks que foram criados com base no manifesto ágil depois. Então, focar na comunicação, na colaboração, na responsividade, eu ter o designer junto do time de desenvolvimento, eliminando complexidade, eu ter a pessoa de negócio para tirar dúvida em tempo real e não ter aqueles processos de trocas de e-mail que leva uma semana para o cara me dar uma resposta. Isso é ser ágil. Eu acredito muito num negócio de… a quarta revolução industrial, trazer a tecnologia, o desenvolvimento para o core do negócio. Esse negócio, com a tecnologia dentro dele, ele não pode ser mais uma coisa de: “As pessoas têm grandes ideias e passam para o time de desenvolvimento fazer”, o time de desenvolvimento é parte disso e a gente vê grandes empresas de produto hoje, de sucesso no mercado, tanto fora do Brasil, quanto dentro do Brasil, que seguem essa regra. Eu não conheço nenhuma empresa que tenha produtos de sucesso e que responde rápido à mudança hoje, que não tenha a tecnologia como elemento base da organização. Não é mais um departamento que está lá no cantinho. Então, o foco na agilidade, em satisfação do cliente, em ter cadência nas entregas, mas também ter ciclos saudáveis de desenvolvimento, acho que isso é muito importante de se falar, ainda mais em tempos de pandemia, onde a gente vive a era de Burnout, pessoas pirando por causa de trabalho e as empresas esquecendo que ainda estamos numa pandemia, querendo que todo mundo entregue 100%, correria, não sei o que. Cara, não. Se a gente priorizar o trabalho, se a gente adequar a nossa forma de trabalho para responder as mudanças, para responder as dores dos usuários, a gente não precisa correr tanto. As datas fixas, os escopos, eles sempre vão existir, mas a maioria deles vêm da cabeça de alguém que nem tem um motivo 100% aparente. Tipo, correr para atender a data, porque alguém se comprometeu com a data sem falar com quem vai fazer. Isso é muito comum. E aí põem dentro de iterações o trabalho, e acha que é ágil, não. Sabe? Então é voltar para o básico, sai do foco em práticas e cerimônias, elas são extremamente importantes, mas elas são ferramentas do time. Tipo, fazer reunião diária, fazer retrospectiva no final de ciclos, processos de lean, de melhoria contínua. Isso não é nem de agilidade, isso é de antes do ágil existir. E focar nisso, de conexão entre as pessoas, focar na troca, nas pessoas colaborando, trabalhando juntas de verdade, com as suas habilidades. Um exemplo bem interessante aqui que eu tenho, foi num time meu da ThoughtWorks, inclusive, que o designer começou a parear com o desenvolvimento, ele gostou tanto do negócio que o cara mudou de carreira, virou dev. Ele falou: “Pô, é muito legal esse negócio”. É isso, é aproximar os papeis diferentes. Eu tenho essa ideia, o senso de responsabilidade, “quando isso está pronto”? É quando eu resolvi a dor do meu cliente, quando está na mão do meu usuário. Não é quando eu terminei a minha parte e passei para a próxima coluna do boarding, e que se dane, sabe? Acho que o foco tem que ser nesse processo contínuo de melhoria, usar as métricas, como velocidade, essas coisas que a galera usa para avaliar a performance de time. Não, não compara os amiguinhos com esses dados, vamos usar isso como melhoria do time, do processo interno, como que a gente consegue responder melhor, pensar nessas entregas regulares com uma cadência e sempre focando em mais e mais valor, em maximizar a quantidade de trabalho não feito, que é um dos princípios da agilidade.

Muito bom, cara. Poderíamos ficar tranquilamente mais 18 horas conversando sobre isso, mas o Rica também precisa ir, porque tem a herdeira para cuidar.

Ricardo – Sim.

Eu quero agradecer muito o seu tempo, a sua paciência e por ser essa pessoa maravilhosa que você é, por compartilhar tanto conhecimento conosco. Muito obrigado, Rica.

Ricardo – Foi um prazer. Muito obrigado por essa oportunidade.

Rica, nós temos um espaço, você vai poder sugerir livros, links, tudo que você achar que é interessante compartilhar, depois a gente vai colocar na descrição do seu episódio. Beleza?

Ricardo – Está bom.

Se quiser já deixar alguma coisa aqui também para a galera que está ouvindo, fique à vontade. 

Mensagem final.

Ricardo – Olha, tem muitos livros legais, muitas coisas legais. Eu acho que foco em estratégia, foco em comunicação, muito mais do que ferramentas de trabalho. Como você falou, se você for ver conteúdos do Marty Cagan, falando sobre tipos de time. Cara, ele escreveu aquilo há 15, 18 anos atrás. Esse tipo de material é muito legal, mas tem um livro muito massa, que se chama Strategy, que eu acho que muito bom, que ele fala sobre essas nuances de como conduzir as coisas, como ter um pensamento estratégico, como ter um posicionamento. Eu gosto muito mais dessa coisa de comunicação, no foco de relação com pessoas, porque afinal, é tudo sobre pessoas, é tudo sobre relacionamentos. O resultado é o valor que a gente entrega, a velocidade que a gente faz, é o framework que a gente usa, mas o foco está nessa conexão. Então, para pessoas de produto pensar em como facilitar conversas… eu tenho uma lista de livros, eu posso passar depois. Mas tem muito conteúdo legal. Esses dias eu vi, inclusive, um post, não vou me lembrar o nome da pessoa agora, que organizou… ah, tem uma pessoa que era de uma outra consultoria, chamada Jessica, que ela criou um post no médium, um artigo no médium falando para product manager, para as pessoas de produto, o que estudar de acordo com o nível de carreira da pessoa. Eu achei genial isso, porque ela organizou muito segmentado. Para os meus alunos da Tera eu entrego um pós-aula, aonde eu tenho priorizado, usando uma técnica de priorização, chamado Moscou, que vocês conhecem, o que deveria estar lá no must, no should e no could. Então, eu posso compartilhar isso com vocês, que eu acho que vai ser bem melhor do que eu ficar tentando lembrar de nomes de livros aqui.

Maravilha. Muito obrigado, Rica. Muito obrigado, Salva.