#13 Ignorância Intencional - dti
M1: Olá, Pessoal. Bom dia. Boa tarde. Boa noite, fazer igual o Café Brasil. Estamos aqui mais um episódio dos agilistas. Felipão como é que você está?
M2: Estou bem, muito obrigado.
M1: E aí a Vinição. Tudo joia?
M3: Beleza.
M1: Pessoal, hoje a gente está querendo falar sobre um tema. Quem viu o título do podcast pode estar pensando sobre o que a gente está querendo falar nesse podcast. A gente está chamando esse episódio de ignorância intencional. O que significa isso? O que a gente está querendo trazer aqui para discussão nesse episódio. Como todo mundo está acompanhando o podcast, está vendo que no fundo a gente está falando basicamente de que? As empresas estão ficando digitais, e isso significa que o negócio está praticamente se fundindo com a TI para poder usar os artigos de TI, as tecnologias tudo da melhor forma possível.
M2: Sistema em rede total.
M1: É exatamente tudo entranhado, e cada vez mais difícil de você até entender onde está a TI, onde está o negócio, porque o negócio está ficando digital. Então se a gente está num mundo onde o negócio está ficando digital, quando se está quase começando a ter uma confusão de o que é TI, e o que é negócio. Os times imaginam já um futuro, as empresas estão trabalhando em squads, os squads tem parte TI, e parte negócio, representantes de todas as áreas resolvemos os problemas juntos, e etc. Será que nesse mundo a conversa entre negócio e TI vai ser a mesma que existe hoje em dia ou a conversa entre as pessoas que estão lá. Será que os executivos, eles vão enxergar a TI ou as tecnologias da forma como eles enxergam hoje. Indo mais além que, na verdade, a provocação principal que eu gostaria de fazer. Será que eles vão poder se manter intencionalmente ignorantes em relação a certos temas, que passam a ser tão relevantes quanto quaisquer outros temas da empresa? Vejam bem porque eu estou falando de ignorância intencional, porque hoje dá para fazer até uma tirinha com isso, se o sujeito chegar numa reunião com um executivo da empresa e falar (cloud) [00:02:19], é capaz de alguém falar assim: você é doido, você está falando muito técnico um cara, ele não vai entender nada.
M2: Pessoal é muito técnico.
M1: Essas caras são muito técnicos você tem que falar uma linguagem mais simples, mas será que uma empresa que está ficando digital você não pode falar em (cloud) [00:02:35]. Será que realmente que o cara quando vai conversar com Jeff Bezos ou com (inint) [00:02:40] ele evita falar esses termos. É claro que eu peguei extremos, mas na medida que a empresa vai se apoiando em plataformas digitais, porque eu falo que a ignorância é intencional porque hoje em dia o executivo faz questão de não saber isso, porque ele fala, assim: "isso é um assunto técnico. Isso não tem a ver com o meu negócio. Então não venha você com esse técniquez", você tem que traduzir para minha linguagem.
M2: Não quero que você fala do como, não quero saber como vocês vão fazer.
M1: Qualquer detalhe o cara já fica indignado. Nós vamos explorar várias facetas desse tema. Eu já queria ver com Felipão e Vinição. Como é que vocês enxergam isso. Isso acontece mesmo nos clientes que vocês estão acostumados a frequentar? Qual é o primeiro insight que vocês têm sobre isso, será que dá para realmente os executivos modernos que querem conduzir a transformação digital, eles podem realmente intencionalmente ficarem ignorantes de temas como cloud, como entenderem o que é o próprio agilismo. E aí nós vamos falar mais para a frente, e saber que é um débito técnico e coisas desse tipo ou não? O que vocês acham?
M2: Eu acho que é bem por aí. Acho que existe sim a ignorância intencional e muito das vezes até institucionalizada. O executivo não só tem a intenção de se manter distante desses tempos, ou as vezes a própria construção organizacional da empresa o impede de se envolver com termos e os assuntos que permeiam a porção digital da empresa. Então acho que isso é um problema que realmente causa um impacto muito grande na capacidade dos times de conduzir entregas com, realmente buscam, obstinado por valor e com diligencia, autonomia e agilidade de fato [00:04:41]M3: A gente fala muito na área DTI sobre auto-organização é um tema, talvez a característica mais importante sistêmica de sistemas complexos, e linguagem tem muito a ver com auto organização. Então, por exemplo, no Livro da Donella Meadows fala de teoria de sistemas complexos, se você quer ter uma empresa que tem características de resiliência tem que falar sobre resiliência. Então, como é que você vai ter uma empresa que precisa de escalabilidade de solução escalável, você vai meio intencionalmente querer ser ignorante em relação a isso. Eu acho bem difícil provocar auto-organização em relação a alguns temas que são, que estão se tornando cada vez mais a diferença de competitividade das empresas. Então não tem como você meio que separar o que é um assunto que eu posso falar, de um assunto que eu não posso falar.
M1: É interessante porque, pensa bem, ouvindo você falar. Você tem a parte técnica e tem a parte organizacional também tem que ser trazido à tona, tanto que esse podcast é sobre o agilismo. Então, assim, você tem tanto a parte técnica toda, palavras como escalar, computação em nuvem e coisas desse tipo, (inint) [00:06:10] que o cara tem de começar a entender, mas ele também tem que começar a entender, por exemplo, e usar bem, que é o que o Vinicius falou da auto organização, que agora ele não trabalha mais com requisitos, mas com hipóteses, e isso faz uma diferença brutal já pensaram nisso? Imagina e isso tem a ver com a ignorância intencional, porque o cara ele quer ficar ignorante de qualquer coisa sobre o como se fazem as coisas, porque do ponto de vista do negócio ele quer que entrega para ele alguma coisa.
M2: A ignorância, ela traz muito menos angústia.
M3: (inint) [00:06:43].
M2: Talvez seja um dos motivos, que quando você vai para posições de gestão você tem muito, a gente observa muito a questão de muitos gestores eles intencionalmente quererem ser ignorante sobre as coisas porque fica menos angustiado.
M3: Mas o curioso é que, igual você mesmo citou, às vezes, existe até uma ignorância seletiva também, porque às vezes um gestor comenta: esse produto que estou demandando ele tem que escalar, porque ele é um produto nacional ou global. Mas na hora de se decidir ou na hora de entender o que é que realmente um time precisa de fazer para que aquele produto seja escalado, ele fala: não, aí vocês já estão entrando no como, isso já não pode ser dito.
M1: O negócio é pior do que isso. Deixando bem claro, a gente gosta de ser coerente, e ter uma linha aqui que norteia todos esses podcasts nossos e no fundo o que a gente está sempre tentando falar são aspectos que são fundamentais para que as empresas possam fazer a transformação delas mesmo, para que elas possam ser ágeis para poder navegar nessa nova era digital. E o que a gente está falando é o seguinte, que se a empresa na linguagem dela no dia a dia, na conduta dela no dia a dia, e na auto-organização que ela acaba provocando, ela não usar uma linguagem diferente mais apropriada para os tempos modernos. Ela não vai fomentar o comportamento correto e ainda vai tomar decisões erradas. Então, se um líder prefere ignorar, que agora se fala em hipóteses e não requisito, e acha que isso é uma mera questão linguística. Ele está causando um dano maior do que ele imagina na empresa, porque se ele acha realmente que o mundo é VUCA, se ele quer fazer experimentação não tem mais requisito. Como é que vai ter requisito?
M2: Se é obrigatório, você não precisa nem pôr a prova.
M1: É muito diferente numa conversa onde um squad, um grupo multidisciplinar está tentando atingir um objetivo, juntos as pessoas traçaram uma hipótese e correr atrás dessa hipótese, concorda?
M3: Sobre essa questão de hipótese, é uma leitura bacana que eu fiz recentemente foi do livro do Sense and Respond, o pessoal até dá um nome para uma estratégia realmente orientada, a hipótese raramente, realmente, de verdade orientada a MVP, que nada mais é do que uma hipótese que você quer testar bem rápido e amplificar ela se der certo, ou amenizar ela se começa a dar errado. Ele chama de Mágico de Oz. Na estratégia de Oz, porque O Mágico de Oz, quando ele foi para o mundo da fantasia, ele era um artista de circo, não era um feiticeiro, mas chegou lá e se colocou como um feiticeiro. Então, ele se fez parecer um feiticeiro, mas ele não era. E aí ele chama esse tipo de estratégia quando, por exemplo, uma coisa que é muito utilizado na área de marketing, por exemplo, ou produtos de varejo é você colocar uma landing page você testar o produto porque você constrói uma landing page bem rápido, mas as engrenagens por trás podem ter pessoas trabalhando ali. Se você tem um feiticeiro ali que navega por baixo dos panos, é um mágico fazendo alguns truques ali manuais para que você tenha um retorno bem rápido daquela solução. No Sense and Respond, ele cita muito a Amazon, por exemplo, que já faz há algumas décadas e grande parte do sucesso dela parece ter a ver…
M1: Só tentar conectar com o que a gente está falando, ver se estou entendendo bem. A gente está falando o seguinte, se a fórmula de gerar valor da empresa agora passa por squads, e esses squads têm como estratégia deles poderem fazer, por exemplo, essa questão do Mágico de Oz. Eu estou entendendo que o que você está falando claramente (inint) [00:11:19] para brincar com assuntos da ignorância intencional, é o seguinte: não tem como mais toda a empresa entender que existe esse tipo de estratégia e conversar sobre isso sim. Hoje o que é engraçado, é como se você tem um negócio e tem um valor que a TI pode ser gerada em algum lugar, tem alguém subcontratado que a própria TI da empresa, aquilo que a gente já falou em outro episódio, a TI é como se fosse um provedor interno, e ele fica atendendo a requisições, ele fica encapsulado escondido do mundo. Nós estamos falando o seguinte. Gente o cerne da empresa agora, a geração de valor ou no mínimo uma coisa muito importante já que a empresa pode se tornar uma plataforma digital, ou pode ter vários novos produtos, vários novos modelos de negócio, o cerne na geração de valor está ali no digital, se o cerne da geração está ali no digital, como é que os executivos, o negócio, todo mundo, estou falando de executivos, mas eles são tipo o símbolo máximo…
M2: A representação do negócio.
M1: A representação do negócio e a vontade explícita de ignorar esses termos, como se eles fossem coisas que tinham atenção deles do negócio não, mas o cara tem que cair na real, o negócio dele agora é digital. Então esse cara, que tem um feeling ótimo para tomar a decisão e para sabatinar e para ajudar. Ele tem que entender, por exemplo, isso que o Vinicius falou, que existe uma forma de testar alguma coisa mais rápida por exemplo, ele não pode ignorar isso.
M2: Tem que se digitalizar também.
M3: Não só ignorar, mas ele, eu quis dar esse exemplo do Mágico de Oz, é da criação de símbolos de auto-organização em relação a algumas coisas tipo hipótese, de começar quase a ser proibido falar requisito, porque é requisito só quando fosse uma coisa legal.
M2: Realmente uma restrição. E é curioso, a gente está falando aqui de termos. O que esse mundo com essa revolução digital traz. Isso tem que realmente ser replicado no negócio e na gestão. Nesse mesmo livro lá do Sense and Respond, existe uma parte do livro que eles também citam quando você vai… Como seria um fluxo ideal para colocar um produto novo no mercado. A primeira parte do ciclo é construir algo baseado numa hipótese bem rápido, colocar no mercado e assumir que vai falhar. Então você já gerencia sua própria expectativa. O que eu acredito que hoje em dia também tem uma ignorância seletiva, uma ignorância intencional sobre as expectativas. A gente sempre tenta trabalhar, assim: "não eu quero todo o escopo", e também fixo a data, a gente sabe que nos tripés do desenvolvimento onde a gente tem qualidade que não dá para negociar escopo e tempo não dá para se amarrar escopo e tempo. Então, se você quer realmente ter o seu (inint) [00:14:12] de marketing muito rápido tem que ser algo muito simples igual esse exemplo do Mágico de Oz que o Vinícius deu.
M1: Então, queria avançar em um negócio. Acho que vocês vão conseguir dar um exemplo concreto bem interessante, que é o seguinte. Tem um autor aí que eu esqueci o nome agora, mas que ele cria um modelo que eu acho interessantíssimo, e, para mim, mostra muito claramente o que a gente está querendo dizer, é o seguinte, ele fala: o negócio é, assim… eu acho que nós onde no futuro vamos parar de falar o negócio, é tudo uma coisa só. Mas hoje acaba que é obrigado a falar isso, porque existe essa separação. Mas assim o negócio ele tem que entender o que um squad pode produzir para ele e squad lembremos não é a equipe da TI, o squad é uma equipe multidisciplinar. Mas o negócio tem que entender isso bem, ele tem que entender isso bem para que ele possa tomar decisões corretas, e o que um squad pode produzir para o negócio em um determinado momento, ou ele está fazendo features, e isso o negócio está cansado de saber, é isso que o negócio quer o tempo todo. Mas o squad pode estar corrigindo bugs, ele pode estar resolvendo algum defeito técnico ou ele pode estar tratando de algum risco enxergado naquele momento, seja um risco de segurança, algum risco dessa natureza e isso vai muito a ver do assunto que eu estou falando. Não é possível que o negócio seja ignorante em relação a isso, porque ele vai junto com o squad passar a priorizar decisões. Esse autor ele conta um caso aí que infelizmente acho que eu estou ficando velho e esqueci o nome da empresa também. Mas é uma empresa centenária que atuava com segurança, vamos dizer assim, guardar documentos e segurança. E com o passar do tempo ela foi se movendo para ficar digital, e ela começou a se concentrar tanto na questão de rapidamente mostrar para o mercado que estava ficando digital, que ela acabou deixando de lado certos débitos técnicos e riscos e num dado momento ela foi invadida, e aquilo ali praticamente dizimou o negócio da empresa. E é engraçado porque qual que é a análise não sistêmica que alguém faz isso, as pessoas adoram procurar cabeça, alguém vai caçar um arquiteto ali, e falar assim: aquele arquiteto maldito não bolou uma arquitetura segura, a gente está cansado de ver esse cenário. Aliás só um comentário, tem frase do (inint) [00:16:55] de 1920 onde ele já afirmava que 90% dos problemas nas empresas são sistêmicos.
M2: Por exemplo também sobre a questão de sistemas, o potencial de alteração de comportamento do sistema em menor nível é de um elemento sistémico. Isso é uma coisa básica de teoria de sistemas, se você ficar mexendo só nos elementos, a não ser que seja um elemento capaz de mudar a estrutura.
M1: Ele é o que menos afeta o sistema. Mas isso que é interessante. Olha a profundidade disso. Então, na verdade, esse autor faz uma provocação que é assim: "Gente, o que causou aquela falha de segurança foi uma coisa sistêmica muito maior que é qual?" É aquela empresa não entender que pensar no negócio significa em certos momentos priorizar ações totalmente técnicas, e que as ações não são fruto de incompetência, elas são frutos de escolhas que vão sendo feitas e que o negócio está junto ali tomando essas decisões. Uma empresa dessas que faz isso, obviamente que ela está muito mais digital e percorrendo esse mundo novo do que é uma empresa onde a área de negócios insiste em se manter ignorante deste tipo de assunto e fica falando "eu tenho que pedir as coisas, as features aqui, esses caras tem que me dar essas features". Vocês têm algum exemplo aí bacana aqui que possa ilustrar isso.
M3: Legal essa questão que você colocou do que um squad realmente, que tipo de entrega um squad pode fornecer. E como a gente gosta muito de citar o agilismo na prática. Vou dar um exemplo bem recente de um processo de coaching que eu fui fazer com um de nossos times. O time estava claramente tenso e estava nervoso. Aí eu fui analisar a causa raiz, era justamente essa essa relação dificultada com o negócio de que o negócio só tinha a expectativa de que as entregas deveriam ser novas features. Aí quando eu fui analisar um pouco mais profundamente o que tinha no (backlog) [00:19:03] para o time construir tinha alguns débitos técnicos. E aí fazendo um parêntese, pontuando o que é um débito técnico, um débito técnico são decisões possíveis plausíveis e que o time toma para tentar fazer alguma entrega, às vezes porque tem alguma restrição de data ou porque a gente quer colocar alguma coisa à prova mais cedo ou porque naquele momento a complexidade para se construir toda solução técnica, a solução técnica completa, ela não é compatível com a realidade, às vezes de número de usuário, de escala que o sistema tem que tomar. Então toma-se algumas decisões arquiteturais e armazena-se alguns débitos técnicos, isso metodologicamente é possível e aceitável. Mas então o time tinha alguns débitos técnicos no backlog e alguns bugs de fato. Eu até brinco em algumas palestras que eu dou. Eu também não vou lembrar qual o livro, mas algum livro do (Kent Beck) [00:19:58].
M1: Você é mais novo do que eu.
M3: Não deveria estar com esse problema de memória, mas em algum livro do Kent Beck sobre (inint) [00:20:05] que eu li, onde ele falava, se a gente tem que aceitar que não existe sistema livre de bug, só não foram encontrados. Então se um dos pais do agilismo, e do desenvolvimento orientado a testes coloca algo dessa forma a gente tem que aceitar que bug é inerente à aplicação e a construção.
M1: Só um comentário rapidinho, a pessoa tem que entender o modelo econômico por trás disso.
M3: É meio absurdo pensar que a questão de risco que muitas vezes até… não vou falar que é fácil, é plausível você transforma aquele risco ali economicamente em grana, o (inint) [00:20:52] que alguns autores de lean falam, é claro que a decisão deveria ser orientada a isso, mas isso tem muito a ver, até o Schuster fala, de um padrão sistêmico do (inint) [00:21:02], de buscar um objetivo errado, se o objetivo for só feature, porque o negócio é ignorante em falar outra coisa que não seja feature. Então você vai realmente, nunca vai priorizar uma questão de débito técnico, por exemplo, que vai gerar um risco muito grande.
M2: Exatamente. E aí nós temos duas possibilidades, dando sequência no exemplo. Ou você vai realmente deixar de priorizar a solução de um risco ou um débito técnico, que aí pode recair nesse exemplo que o Schuster deu, no futuro você ser engolido por esse por esse débito e ou acontece o que aconteceu nesse exemplo que eu estava dando aqui. O time acabava absorvendo todo o ônus de solução, porque se você tem um time que realmente é comprometido, eles não vão aceitar que o sistema continue (inint) [00:22:00] uns malucos tentando absorver todo o ônus.
M1: E ao mesmo tempo…
M2: E ao mesmo tempo tentando criar as novas features que foram as que foram priorizados pelo, isso é fato, isso tem um limite, porque o que acontece? Aquele time realmente comprometido vai começar a trabalhar depois do horário, vai começar a trabalhar o final de semana para tentar carregar tanto peso das novas features, quanto dos débitos técnicos que eles não concordam em deixar desenrolar. E isso tem um impacto muito grande no médio prazo. O time estafa, e aí inclusive a qualidade das novas features começa a descer. Então você cria um problema sistêmico muito grande.
M1: Eu sou fascinado com essas coisas. A gente tem falado muito sobre novas formas de liderança e de enxergar a empresa como um sistema complexo adaptativo. Aí gente, imagina, um cara vai estuda e tenta entender isso e na prática quando tem um débito com bug, ele fala isso é incompetência de alguém, traga-me a minha cabeça desse alguém, é uma visão muito estreita.
M2: É a visão do elemento sistêmico que eu acabei de falar.
M1: Mas as pessoas foram treinadas para isso. É aquela história de procurar efeito de causa e consequência muito próximo e de dar cacetada em alguém que é muito mais fácil do que procurar mudar o sistema. Quando um líder hoje ele tem medo do que ele vai fazer nesses novos tempos já que ele não vai mais ficar provando e demonstrando poder no dia a dia. Veja que tem muita coisa para fazer. Por exemplo, ser um líder consegue entender isso que a gente está falando e causar esse tipo de transformação. Você imagina assim. É um cenário comum nas empresas são sistemas legados que começaram bonitos e depois ninguém consegue mexer mais, tem inúmeras causas disso. Uma das causas é simplesmente não se investir continuamente na melhoria daquilo, mas uma causa também forte é essa, não deixar ter débito técnico. Eu só queria dar um exemplo aqui..
M2: Não deixar ter débito técnico não.
M3: É até bom ter débito técnico. Em algum momento que ele seja resolvido como parte do escopo do produto.
M1: É. Saber tomar decisões compatíveis com o modelo de negócio.
M3: É encarar o débito técnico, simplesmente como incompetência.
M1: Para o negócio, essa ignorância causa isso. O cara está ali ansioso para fazer alguma coisa. Aí você fala assim: Ok, mas antes vamos fazer tal coisa para deixar o sistema mais escalável. Vamos separar tal modo para fazer tal coisa. O cara fala sim: "Esse pessoal de TI não dá para confiar mesmo. Os caras são uns incompetentes. Em vez de me atender agora vão pedir dinheiro para ficar gastando mais dinheiro"
M3: Com problemas que eles mesmos criaram.
M2: Esse ainda seria o caso mais radical, vamos fazer antes, muitas vezes gente pede simplesmente para reservar um pouco. Nem isso pode. Na verdade, você tem que fazer tudo ao mesmo tempo, e com a priorização total de feature.
M1: E é curioso o que você falou. Eu já lembro de ter lido artigos que no fundo recomendavam que você jogasse de alguma forma na hora de estimar o… Você quase que engana…
M2: Artigo acho que até do Gartner.
M1: Eu não tenho certeza se é o Gartner, mas eu falo assim, quase que te falando assim, essa visão que é o seguinte, como isso é uma coisa técnica você não vai conseguir explicar para os caras ou eles não vão ter compreensão, joga em um fator seu de estimativa que você tem tempo para isso. Cara, mas isso não é a melhor decisão que uma empresa que está ficando digital. Uma coisa é uma época e seria até aceitável o seguinte tem um momento a vida antigamente, que a empresa precisava…
M3: Momento de transição.
M1: Imagina assim, o cara precisava de algum momento de um sistema, e o sistema era acessório para ele. Então ele não está lá querendo saber detalhes. Mas agora não é isso. Esse sistema está no cerne do negócio dele, esse sistema muda com o negócio dele, esse sistema gera novos modelos de negócio.
M1: Às vezes esse sistema é o negócio.
M1: O sistema pode virar o próprio negócio, pode virar um spinoff da empresa, pode ser a empresa que vai substituir a empresa atual no futuro. E aí o cara vai se manter ignorante? Um exemplo que eu queria trazer aqui, que vocês conhecem bem, tem um exemplo real. A gente tem vários clientes. Imagine o seguinte, só para tentar deixar bem claro que isso não é uma questão de incompetência, é uma decisão estratégica tanto quanto várias outras empresas têm que tomar. Imagine a seguinte, que você tem uma empresa, que ela consegue operar em escala seja porque tem múltiplas lojas, múltiplas agências, múltiplas unidades, mas ela consegue operar em escala. E aí você percebe num design sprint, que você consegue ter um ganho fabuloso num processo, se você fizer uma determinada solução. Só que isso é apenas uma hipótese. Você não tem certeza disso, porque é humilde de saber o seguinte eu sei lá na hora H pode ser que nós vamos descobrir coisas que nessa salinha aqui nós não estamos imaginando. Então você toma a decisão de falar o seguinte: "Olha eu quero em curto prazo saber o mais rápido possível…"
M2: Eu quero o Mágico de Oz.
M1: ….se isso aqui realmente é tão bom quanto nós estamos imaginando que é". Vou reduzir os meus riscos de segurança botando isso só numa unidade ou numa loja onde for, vou fazer alguma ação, mas vou forçar o que puder para poder testar essa minha hipótese logo, com isso eu criei um débito que eu vou ter que pagar um dia. Quando nós somos pessoas honestas a gente quer pagar os débitos.
M3: E tudo se encaixa, se encaixa até com a teoria de lean, você trabalhar com small (bets) [00:28:04], você trabalha com um lote pequeno que já agrega valor.
M1: Então imagine o cenário, para ficar tangível para quem está escutando, aí o cara foi lá botou numa loja, por exemplo, ou numa agência que seja, pode ser qualquer tipo de negócio, um negócio de escala. E aí que ele percebeu que aquilo é bom mesmo, ele quer espalhar. Cara, mas na hora de espalhar é uma decisão de negócio entender o seguinte: agora tem que alterar um pouco, por exemplo, a arquitetura para tornar isso mais seguro e tem que fazer tal coisa para tornar isso mais escalável, por exemplo. Aí se for uma incompetência alguém pode falar: "Por que vocês não fizeram isso antes? Como é que você responde isso, Felipão? Por que vocês não fizeram isso antes? Você que é um grande arquiteto.
M2: Porque o dia que alguém inventar uma bola de cristal, eu vou ser o primeiro a comprar. Mas eu vou dar um exemplo bem prático de um projeto que eu participei no passado que exemplifica na prática o que você acabou de falar. E aí os ignorantes intencionais que me perdoem, vou usar alguns termos técnicos aqui. Uma aplicação de IoT que a gente construiu na DTI. E a gente queria testar a hipótese de se aqueles objetos que a gente estava conectando realmente iriam gerar informações válidas para que se a gente montasse uma base de dados, a gente conseguisse tirar insights para os nossos clientes. Aí quando a gente estava nesse processo decisório arquitetural, uma das coisas que a gente parou para decidir era a arquitetura de cash, para tornar a solução mais escalável, com a performance melhor, e a gente decidiu deliberadamente utilizar um cash em memória bem mais simples que de fato a capacidade de escalabilidade muito menor gerando um débito técnico sabendo que se a solução que a gente está pondo a prova realmente funcionasse, escalasse, e a gente está falando de internet das coisas em que a gente poderia ter milhares de sensores espalhados com o cash em memória a gente sabia que a aplicação não ia escalar, mas se a gente já construísse, gastasse o custo da contratação de um cash distribuído, do curso de desenvolvimento disso, a gente ia que gastar talvez meses, semanas a mais para poder fazer um teste, que poderia se provar falho e a gente teria desperdiçado. Então isso exemplifica bem o que você falou, uma decisão arquitetural.
M3: Só fazer uma provocação, a gente está falando muito de débito técnico, se o débito técnico não for deliberado muitas vezes é mulambagem, significa que se qualquer débito técnico é a (inint) [00:30:40].
M1: Tem coisas que você já sabe.
M3: Tem que analisar e ver que você provavelmente vai deixar aquele débito.
M1: Esse ponto seu é interessantíssimo, porque a gente sempre trabalha nessa, o mundo real é ambíguo, não é um mundo muito prescritivo. Então você pode ter um arquiteto ruim, inexperiente que tomou uma decisão horrorosa, já sabendo de uma determinada restrição que aquela aplicação tem de um determinado público que ela vai atingir, com certeza. Por isso que a liderança passa a ter que ter essa sabedoria de saber interpretar situações de forma diferente. Nós estamos chegando aqui no final do nosso tempo. A mensagem é até muito óbvia quando você reflete sobre ela, mas ela tem que ser repetida à exaustão, que é simplesmente: olha se o seu negócio está ficando digital, se você tem que mudar totalmente a sua cultura, sua forma de trabalhar. Você não pode mais ficar ignorando certas coisas, e você vai ter que mudar sua linguagem, e ao mudar a linguagem você vai começar inclusive a mudar o comportamento de um tanto de gente. É isso aí. Até a próxima.