Ep. 88 - Não existe demanda técnica! Existe demanda de produto!

Tudo começou em 2017, no Agile Brasil, em Belém do Pará, quando o apresentador e uma pessoa identificada como CFC fizeram uma palestra em formato de duelo: "a ditadura do técnico" contra "a ditadura do negócio". Ninguém venceu de verdade aquele duelo, e quatro anos depois o tema volta ao podcast sob um novo título, mais provocador: Não Existe Demanda Técnica.

Para discutir o assunto, o programa recebe Rodrigo Martins, o Zé, que traz a perspectiva de produto e agilidade organizacional, e Mari Barcelos, que traz a perspectiva de engenharia, hoje trabalhando no PagSeguro, empresa com a qual a K21 tem uma relação de anos. Zé já adianta o resumo do duelo antigo: quando negócio e tecnologia não trabalham alinhados, é muito provável que o resultado não seja atingido, todo mundo perde. Mari lembra que essa tensão foi uma das primeiras "tretas" que ela viveu justamente ao lado da K21, lá no PagSeguro: a engenharia sentava em um andar, o produto sentava em outro, e para achar o PO era preciso subir e descer de elevador ou escada, não havia sequer uma ferramenta de comunicação como o Slack para facilitar isso.

Zé começa a destrinchar o problema: dentro de qualquer empresa há pessoas de engenharia, produto, marketing, design, jurídico, financeiro, todas voltadas para o mesmo objetivo. Se algo que está sendo feito não traz benefício nenhum, por que estaria sendo feito? Ele descreve uma cena comum no mercado: a área de produto diz que não priorizou porque não recebeu estimativa e prazo da tecnologia; a tecnologia diz que não deu prazo porque produto não escreveu critérios claros; e aí começa o burburinho entre disciplinas que gera silos. Mas quando alguém está usando um aplicativo, não vai comentar "nossa, que bom esse roadmap técnico, migraram a rota do banco de dados", vai dizer "nossa, carregou muito mais rápido" ou "consegui fazer isso com muito mais facilidade". Qualquer mudança técnica, seja rota de banco de dados ou outra coisa qualquer, só se justifica pelo que melhora na vida de quem usa o produto, por isso, para Zé, não existe demanda técnica: o que existe é demanda de produto.

Zé completa com uma observação sobre a separação que ainda existe hoje: seu Instagram é seguido por uma galera de agilidade e produto, seu Twitter por uma galera de desenvolvimento de software, duas tribos diferentes. Ele pergunta a Mari se ela ainda percebe esse racha no dia a dia das empresas e de onde ele pode ter vindo.

Mari não sabe apontar a origem, mas confirma que o problema existe. Do lado da engenharia, é comum fazer alterações sem comunicar a área de produto, e o PO acabar encontrando mudanças que não entende. Do lado do produto, é comum chegar com um pedido sem informar quanto tempo ele deve levar. Na visão dela, existe menos uma rixa de verdade e mais uma falta de comunicação: quando alguém quer melhorar a velocidade da aplicação e outra pessoa quer lançar um menu novo, as duas coisas podem andar juntas, basta conversar, traduzir o que cada mudança técnica representa e explicar por que cada entrega de produto importa. No fim, cada lado tende a olhar só para o próprio painel, engenharia olhando gráficos de performance, produto olhando roadmap, quando, na prática, é a junção dos dois que produz o resultado final.

O apresentador conecta essa hipótese de comunicação a uma referência do autor Ken Wilber, já citada antes no podcast Pontos e Elefantes e no episódio sobre pensamento sistêmico do Love the Problem: a teoria dos Olons. Um Olon é uma parte que também é um todo, uma célula é um todo em si mesma, mas também é parte de um órgão; um órgão é um todo em si, mas também parte de um corpo; o corpo é um todo, mas parte de algo maior, como a sociedade, e assim por diante. Da mesma forma, a engenharia não deveria se ver apenas como um todo fechado em si mesma, mas como parte de algo maior, que é o produto, e uma "demanda técnica" também não é um todo isolado, é parte do produto. O gap de comunicação, sugere o apresentador, vem justamente dessa falta de visão mais sistêmica e ampla.

Isso leva à pergunta: em que momento isso já foi diferente? O apresentador lembra que a cerimônia de planning, no Scrum, provavelmente nasceu como um espaço para discutir o todo, e hoje virou um espaço em que cada disciplina discute só a sua parte, inclusive existe o hábito, em muitos times, de dividir a reunião em "planning 1" (negócio) e "planning 2" (técnica, quebrada em tasks), o que já denuncia a própria separação que o episódio critica.

Zé responde que sim, já foi diferente, e recorre a uma explicação histórica: a sociedade se move em pêndulos. Ele lembra os 4Ps do marketing de Kotler, produto, preço, praça, promoção, e nota que, quando a produção era tratada como commodity, previsível e escalável, ela foi tirada do centro dessa cadeia, separando-se do restante. O desenvolvimento de produto surgiu como disciplina de marketing há cerca de 40 anos, desgrudado da produção enquanto bem comum, e foi o Manifesto Ágil que tentou trazer essa produção de volta para perto do negócio, defendendo que as coisas só se resolvem quando vistas como um todo. Zé lembra que, uns dez anos atrás, quando começou a trabalhar com Scrum, a planning ainda era "o evento do dia": não havia agenda lotada de 15 reuniões; o PO conseguia refinar com folga e trazer o time inteiro para colaborar, porque o tempo, hoje o recurso mais escasso, era protegido para esse propósito.

Mari concorda e acrescenta a pandemia como fator de piora: antes, era preciso reservar uma sala física para se reunir; depois, as pessoas passaram a levar o notebook para a planning e fazer outra coisa durante a reunião; a pandemia, somada a outras prioridades concorrentes, fez o time perder o hábito de sentar, focar e perguntar se o que estava sendo feito fazia sentido, e assim as pessoas foram virando "tarefeiras", executando sem entender o porquê.

O apresentador propõe duas hipóteses históricas complementares. A primeira: os signatários do Manifesto Ágil, nomes como Kent Beck, Martin Fowler, Uncle Bob, Andy Hunt e Dave Thomas, vieram quase todos de um perfil de engenharia, sem diversidade de competências; mesmo tentando pregar o trabalho conjunto, a rixa entre disciplinas já existia antes do próprio Manifesto. A segunda, mais recente: o mercado de tecnologia "estourou", aprender a programar praticamente garante emprego, e a disputa por profissionais de engenharia deu um certo prestígio a se apresentar como "desenvolvedor" em vez de "alguém de produto", o que na prática contraria a essência de colaboração e foco no cliente que o próprio Manifesto defende. Ele soma ainda uma terceira hipótese, citando o livro "The Principles of Product Development Flow", de Donald Reinertsen: o desenvolvimento de produto ainda operaria sob um paradigma tão equivocado quanto o da manufatura antes do Lean, separando produção de entrega.

Para ilustrar como esse paradigma aparece na prática, o apresentador conta um caso real (sem revelar o produto, por acordo de confidencialidade, mas descrito como um produto historicamente muito usado desde os primórdios da internet): ao chegar em um time e perguntar o que estava sendo feito naquele ciclo, a resposta foi "estamos refatorando". Perguntado sobre o roadmap e o prazo previsto, o PO admitiu não ter nenhum roadmap, porque o refactoring já estava rolando havia oito meses sem que ele soubesse exatamente o que estava sendo feito. Nesse período, a engenharia seguia feliz implementando tecnologia nova, e o produto esperava "a hora" de retomar o discovery, e nenhum dos dois lados enxergava o todo. O apresentador relaciona isso ao clássico diagrama em que produto fica na intersecção entre negócio, experiência e tecnologia: colocar a pessoa de produto "no meio" muitas vezes a transforma em gestora de conflitos entre as outras disciplinas, em vez de dona de uma visão de conjunto.

Mari traz a resposta pelo lado da engenharia: hoje engenheiros não querem só programar, querem construir coisas que as pessoas realmente usem, e podem ajudar bastante a área de produto trazendo dados, por onde o usuário navega, onde ele desiste, o que ele mais acessa. Na prática dela, hoje, ela e sua parceira de produto revezam reuniões, se encontram semanalmente, compartilham o mesmo quadro e caminham para o mesmo objetivo, sem que o produto fique perdido "no meio", sem saber para onde ir.

Isso conecta com uma pergunta feita ao vivo por uma espectadora no Instagram sobre como acabar com esses silos. O apresentador retoma uma ideia que já queria trazer: expandir a visão do fluxo do time para além do clássico quadro "a fazer, fazendo, feito", porque, ao olhar dentro de cada cartão desse fluxo, aparecem tarefas muito diferentes (uma reunião, uma descoberta, um refactoring) que não conversam diretamente com o resultado que se quer entregar, reforçando o comportamento "tarefeiro". A proposta é olhar para o fluxo completo de desenvolvimento do produto, o "rio" da K21, que contempla tanto o upstream de descoberta quanto o downstream até depois da entrega, e entender que qualquer coisa que entra nesse rio é demanda de produto: mesmo uma refatoração de módulo só se justifica pelo risco que mitiga ou pelo valor que agrega, e esse raciocínio deveria estar sempre explícito.

Mari reforça que fechar esse silo passa por empatia na prática: uma pessoa de engenharia participar de uma reunião de roadmap para entender a cobrança que o produto sofre, uma pessoa de produto participar de um post-mortem depois de uma crise técnica para entender a realidade do outro lado. Entender a realidade alheia é o que faz cada lado aceitar por que algo precisa entrar no roadmap, seja demanda "técnica" ou não. O apresentador complementa que colaboração não é só esperar que o outro resolva por você, é também convidar ativamente para a conversa, revisitar acordos e tornar explícitas as políticas de como o trabalho passa de uma disciplina para outra. Feito isso, deixa de ser necessário até classificar o que é "demanda de negócio" e o que é "demanda técnica": tudo deveria resolver um problema de negócio ou de quem usa o produto: se algo não melhora nada, está sendo feito por capricho, ou porque ninguém perguntou qual problema aquilo resolveria, Love the Problem.

Antes de encerrar, o grupo cita duas ideias para episódios futuros que atravessam toda a conversa. A primeira é o profissional em formato T: diferente do profissional em formato I, especialista profundo em um único assunto, o profissional T tem uma especialidade, mas também conhecimento superficial em várias outras áreas, considerado hoje um perfil essencial para quebrar silos. A segunda é o modelo dos quatro domínios da agilidade, criado pela própria K21: organizacional, cultural, técnico e de negócios, como uma "criatura de quatro patas" que não anda bem se só algumas pernas se movem. Mari acrescenta que o domínio técnico também tem diferentes altitudes: no nível do código, "técnico" já significa dinheiro para a empresa; em um nível mais alto, é sobre coordenar sistemas de forma sistêmica; e no nível mais estratégico, a tecnologia se torna a própria força motriz do negócio, ou seja, o técnico também vira negócio. Ela destaca ainda que o domínio cultural é tão importante quanto os outros dois: a própria forma de pensar produto, e a própria forma de pensar tecnologia como um produto final, já são, em si, uma cultura.

O apresentador nota que, embora a conversa esteja focada em produtos digitais, o mesmo raciocínio vale para qualquer tipo de desenvolvimento de produto ou serviço, construção civil, logística marítima, pequenos negócios. Mari fecha com uma observação sobre maturidade: quanto mais sênior um desenvolvedor se torna, menos ele efetivamente escreve código, passa a ser a pessoa que conecta as pontas, conversa com todo mundo e traduz negócio para tecnologia; da mesma forma, quanto mais sênior uma pessoa de produto se torna, menos ela mesma escreve histórias de usuário, e mais ela cria o ambiente e mentora outras pessoas para que consigam escrever as suas.

Ao encerrar, o apresentador resume que "Não Existe Demanda Técnica" ganha, ao final da conversa, um sentido mais completo: trabalhar com mais empatia e colaboração, olhando para o mesmo objetivo em comum, sem treta desnecessária, e que o conflito, quando existe, deve ser resolvido de forma construtiva, com políticas e acordos explícitos entre as disciplinas.