Marcelo Schuster: Bom dia, boa tarde, boa noite. Vamos gravar mais um
episódio dos agilistas, como sempre aqui com Vinição. Vinição hoje não fez
da casa dele, mas recuperou que dá tempo, não é Vinicius? Que bom.
Vinicius Paiva: Claro, certamente. Tudo bem, pessoal? Vamos lá.
Marcelo Schuster: Eu já vou falar qual que é o tema, mas só queria
comentar que hoje aí, vamos apresentar as pessoas daqui a pouco, nós
vamos gravar um episódio com o pessoal que também faz um ótimo
podcast, que é o Entre Chaves, daqui a pouco o pessoal pode falar um
pouquinho sobre o podcast. É um podcast com cunho um pouco mais
técnico, para quem realmente desenvolve software, mas tem um assunto
que a gente acredita que é uma sobreposição interessante que é o seguinte,
a gente leu recentemente um artigo na Forbes, um artigo simples, um artigo
pequeno falando sobre um fenômeno, um anti-pattern, digamos assim, que
se chama analysis paralysis. Eu lembro de ler sobre esse pattern desde que
eu era bem novinho, e que esse anti-pattern significa é justamente que você
muitas vezes pode cair aí no ciclo vicioso de ficar paralisado fácil na decisão
por excesso de análise, você fica ali analisando uma quantidade de
informações grandes, uma quantidade de opções grandes, fica querendo
ter uma decisão muito perfeita, fica com medo de estar errado, fica com
medo das repercussões, e no final não faz nada. E obviamente que isso é
gravíssimo e o que esse artigo fala é que isso é mais grave ainda ou se
acentua mais ainda nesse contexto em que a gente vive, que a gente tem
acesso a mais informação ainda, e o que a gente faz fica mais concorrido,
então dá mais medo de errar talvez. Enfim, é como se fosse um anti-pattern
que cada vez tem mais risco de acontecer. E aí esse artigo fala sobre
algumas formas, aí você teria para poder tentar evitar esse anti-pattern, e
a gente achou interessante porque no âmbito de construção de produtos
digitais, e também de decisões arquiteturais, e aí é sobre isso que o pessoal
vai falar daqui a pouquinho, parece ser muito fácil cair nesse anti-pattern,
porque você também, hoje eu fico brincando com o pessoal, eu desenvolvi
software e na minha época você tinha poucas opções de tecnologia, hoje
em dia você tem 500 mil frameworks, 500 mil caminhos, mas quando você
fala só em tecnologia e aí você soma isso a todas as hipóteses de negócios,
indicadores que você tem que levar em consideração, enfim, como é que a
gente faz para navegar nesse mundo? É sobre isso que nós vamos falar.
Então queria começar apresentando o pessoal do Entre Chaves que está
aqui com a gente. Começar aqui pela Fernandinha que já esteve em outros
episódios. E aí Fernandinha, tudo bom?
Fernanda Vieira: Oi, Schuster, oi pessoal. Tudo bem. Bora falar aí sobre
(licença) de padrão aí, que não é só sobre software, como você
bem falou, é sobre vida, são pessoas, sobre a tomada de decisões.
Marcelo Schuster: Exatamente. É fácil de acontecer isso, não é? Tem gente
que para viajar tem um anti-pattern, não é? Acontece isso.
Fernanda Vieira: É. Tem gente que para escolher o filme que vai ver na
Netflix, eu mesma sou uma dessas.
Marcelo Schuster: Você sabe que, assim, eu tenho esse anti-pattern quando
tem uns restaurantes com cardápios muito grandes, sabe? Aquilo me dá um
nervoso danado, eu fico ali tentando ler o cardápio inteiro, e hoje eu tenho
um agravante que eu não consigo nem ler o cardápio que a letra é
pequenininha, sabe? Eu já não leio o cardápio.
Felipe Chagas: O problema não é a letra, é a idade, não é Schuster?
Marcelo Schuster: É, para mim a letra está diminuindo de tamanho.
Aproveitar e botar o Chagas para se apresentar. Chagas também é
conhecido, já participou de vários episódios. E aí Chagas, tudo bem?
Felipe Chagas: E aí Schuster, e aí pessoal. Um prazer estar aqui nessa união
entre os podcasts aí, junto com a Fernandinha e o Lucas representando o
nosso querido Entre Chaves.
Marcelo Schuster: E finalmente apresentar aqui o Lucas, eu adoro quando
tem alguém que eu não sei falar o nome.
Fernanda Vieira: Aí, adoro. Isso acontece no próprio podcast, lá no Entre
Chaves. Todo dia a gente tem dificuldade de falar o sobrenome dele, todo
dia.
Lucas Campregher: No Entre Chaves eles desistiram e virou champagne de
vez, massa.
Marcelo Schuster: Qual seria o certo?
Lucas Campregher: O certo é Campregher, mas a galera me chama de
champagne, então.
Marcelo Schuster: Campregher. Você sabe, é engraçado porque o pessoal
não acerta o meu nome nunca quando eu falo, e falam errado, eu falo: “pô,
mas não é possível, o cara não prestou atenção”.
Lucas Campregher: Schuster.
Marcelo Schuster: É, falam Schuster.
Lucas Campregher: Eu tenho que confessar que quando eu vou escrever eu
aperto todas as teclas do teclado começando com S e terminando com L.
Marcelo Schuster: O máximo de consoantes que der para usar. Mas então
pessoal, eu queria jogar a bola aí, vamos ver quem vai ser o primeiro a pegar
a bola. Isso aí de fato acontece? Vocês observam nos contextos em que
estão esse risco dessa analysis paralysis desse anti-pattern?
Felipe Chagas: É, acontece demais, assim, o medo de errar que eu acho que
é um dos motivos, o artigo traz muito isso, o medo de errar faz com que as
tomadas de decisões, elas às vezes sejam demasiadamente lentas. E
quando a gente está falando no mundo de desenvolvimento de software,
até que o próprio agilistas já comentou muito sobre o sense e respond, a
gente precisa reagir aos estímulos do mercado, aos estímulos externos, e
se a nossa reação for muito lenta a gente vai perder o time, seja um time to
market, ou a gente vai prolongar um problema, como um problema em
produção, uma exposição de dados de segurança, e essa tomada de
decisão, obviamente a gente não está falando aqui que essas tomadas de
decisão tem que ser responsáveis, mas quando ela perde esse tempo ela se
torna, como todo mundo comentou, em um anti-padrão, em um problema.
Marcelo Schuster: Quando fala assim: “o medo de errar é muito grande”,
mas hoje em dia todo mundo não gosta de falar que tem uma cultura em
que é permitido errar? Por que o medo de errar é tão grande?
Felipe Chagas: O pessoal fala, mas na prática essa cultura ainda está muito
distante de muitas realidades, não é?
Fernanda Vieira: É. Eu acho que tem um negócio aí que pega muito, que
principalmente assim, quando as pessoas vão se tornando mais sênior, (eles
têm) mais conhecimento, vira um medo mesmo do julgamento,
como se fosse assim, asvezesvejoalgunsarquitetosqueficamparalisados
mesmo em tomar algumas decisões que querem fazer aquela solução super
perfeita ali no início do projeto, por exemplo, e aí por que eu acho que isso
acontece? Exatamente pelo medo de alguém chegar e falar assim: “nossa,
que tipo de desenvolvedor sênior que fez isso aqui? Que pessoa que não
pensou em segurança, em concorrência, em atomicidade, em a, em b, em
c”. Então assim, eu acho que tem muito isso do medo do julgamento. Então
vira essa coisa meio dupla do, beleza, será que eu sou realmente
perfeccionista demais e quero fazer o melhor para este projeto, ou será que
eu estou realmente com medo do que aspessoasvãofalarseviremqueeu
fiz uma solução super simples?
Marcelo Schuster: Fernandinha, achei interessante porque eu estava
levando até para o lado institucional que às vezes a cultura é uma cultura
que não te deixa errar, mas é interessante e o artigo fala muito isso. Então
ele tem uma coisa anterior que é o nosso comportamento na sociedade
mesmo, ninguém gosta de estar errado.
Fernanda Vieira: É, exatamente.
Marcelo Schuster: Ele fala até a frase da Navratilova, não sei se vocês já
ouviram, é uma campeã de tênis que ela fala assim: “quem fala que não
importa vencer ou perder, provavelmente é porque perdeu”. Então é
tentando ir bem nessa raiz que por mais talvez que as pessoas possam falar:
“não, tudo bem, não tem problema, errar não tem problema, não está
errado”, não é bem assim que a gente ganha reputação e que a gente se
posiciona em relação aos outros, e que talvez torne o problema bem difícil
mesmo.
Lucas Campregher: Nesse sentido, até trazendo o lado oposto que a
Fernandinha falou, aonde eu percebo que, eu pelo menos, sentia essa
paralisia ai de análise, foi no meu início mais como estagiário em que eu
como uma pessoa perfeccionista, indecisa, que não consigo pedir meu
iFood, na hora de fazer meu código e de tomar alguma decisão em que eu
tinha claramente ali duas possibilidades de implementar meu código, duas
maneiras diferentes de fazer, eu poderia até ter o conhecimento necessário
assim para falar: “não, essa aqui é a melhor opção”, mas eu ficava muito
inseguro de ficar quieto, de saber se eu realmente estaria acertando ou não,
e da responsabilidade que eu teria em cima daquele código. E foi algo que
eu aprendi ao longo do tempo, assim, a lidar melhor. Às vezes assumir essas
responsabilidades é até importante para você aprender ao longo do tempo,
assumir essas responsabilidades mesmo que seja a decisão errada, depois
você voltar atrás nela é melhor do que não tomar a decisão.
Marcelo Schuster: É interessante a faceta que você trouxe até de alguém
inexperiente que tem medo de fazer uma coisa errada mesmo, falar assim:
“putz, eu não sei então eu vou acabar fazendo coisa errada”, que é o que
você sentia, não é?
Lucas Campregher: Sim.
Marcelo Schuster: E o que a Fernandinha trouxe é alguém que vai tomar a
decisão, que poderá ser criticada por alguém que ele já deveria saber.
Lucas Campregher: Deveria saber.
Felipe Chagas: É.
Marcelo Schuster: Então tem que deixar na mão dos plenos.
Felipe Chagas: No meio do caminho eles vão tomar a decisão melhor.
Vinicius Paiva: Assim, um ponto de vista, é claro que não é o único, acho
que tem outras questões a serem consideradas, mas assim, um prisma
desse problema é o problema de como entender a natureza das coisas,
como eu, pelo menos, como você considera a natureza das coisas. Porque
se, e aí eu acho que não é só corporativo igual o Schuster falou não, acho
que é meio da sociedade tem um modelo mental dominante, tipo assim, de
que tudo é planejável, tipo assim, se eu tiver todas as informações, fizer
uma análise exaustiva, eu vou chegar a melhor decisão possível. Então
assim, é claro que tem problemas que são assim, mas tem muitos
problemas que não são assim. Tem muitos problemas que você precisa ter
a realimentação para você começar a executar o planejamento, está
emaranhado na execução, então você vai descobrir, você vai evoluir com a
solução do problema, e não chegar à solução linda, maravilhosa, perfeita e
tal. Então eu acho que esse é um dos impedimentos que fazem com que
acabe que gere essa pressão que a Fernandinha citou aí. Porque se você
parar para pensar, se isso for verdade ou se for verdade para um problema
específico, é claro que é melhor mesmo, é melhor gastar um tempão ali
fazendo a análise chegar a uma decisão que é a melhor decisão possível.
Fernanda Vieira: O problema também é que a gente nunca sabe o que é o
suficiente de informação, o quanto está bom de informação, e talvez por
isso também a gente chegue nessa paralisação. Tipo assim, beleza, eu acho
que quando eu tiver informações suficientes eu vou tomar melhores
decisões, mas quando é o momento que eu sinto que eu tenho informações
suficientes, não é? Então eu acho muito que passa por aí também. Mas
falando sobre um negócio que você comentou, Schuster, em relação a
empresa, ao mundo corporativo mesmo, eu acho que também passa por aí,
no sentido de que asempresasprecisamdarespaçoparaqueaspessoas
possam errar, não é? Então eu preciso incentivar que o erro seja
reconhecido não como um problema, mas como um caminho para a
solução.
Felipe Chagas: Como uma parte normal do processo, não é?
Fernanda Vieira: É, e como um caminho de que, beleza, eu errar significa
que eu reconheci que aquilo ali não funciona, isso também é dado, isso
também é um caminho para eu encontrar o que vai funcionar.
Felipe Chagas: E ser responsável não quer dizer nunca errar, não é? Ser
responsável quer dizer lidar com as consequências, sejam elas positivas ou
negativas. Então a forma com que a gente lida com o erro, eu acho que é o
que diferencia um bom tomador de decisão, digamos, de um que foge da
responsabilidade. Porque não dá também para poder falar: “ok, não vou
analisar o todo porque vou ficar paralisado, vou pegar aqui a quantidade de
informação suficiente para tomar uma decisão responsável, mas se der
ruim se esquivar da responsabilidade”, não é? Tem que saber lidar com o
erro como parte natural do processo. E eu vejo esse tipo de pensamento,
puxando aqui até um pouco para o desenvolvimento de software, tendo
outras consequências além da demora de tomada de decisão, então, por
exemplo, às vezes tem um time que vai fazer um blog, vamos supor, e aí
eles constroem uma solução que está na nuvem, que tem um firewall que
faz XPTO, que usa mensageria para poder postar mensagem, que faz uma
super complicação arquitetural muito por conta das mesmas causas dessa
paralisia da análise, que é o medo, que é superdimensionar as coisas, que é
não entender que um sistema ele vai estar sim sujeito a algumas coisas mas
está tudo bem para aquele problema em si. Então acaba tendo algumas
outras consequências, pelo menos eu consigo visualizar isso no ponto de
vista até técnico, que é uma super complicação de um problema que
deveria ser simples ali, um front-endzinho mesmo e fim, problemas
solucionados.
Marcelo Schuster: É porque assim, você está falando, se eu entendi bem,
que essa analysis paralysis, além de deixar eles paralisados ali, ou demorar
para começar uma coisa que você podia demorar, ele pode gerar uma
overcapture, por exemplo.
Felipe Chagas: Exatamente.
Fernanda Vieira: Exatamente.
Marcelo Schuster: Porque obviamente você está parado analisando, você
não está parado fazendo nada.
Felipe Chagas: É, você não está à toa.
Fernanda Vieira: E pode gerar exatamente desperdício de você também
fazer um tanto de coisa que na verdade não vai virar um problema. Eu acho
que isso também entra naquele princípio de que a gente deveria resolver
problemas só quando eles se tornam problemas. Porque tem até um
mantra bem conhecido aí de software que é you ain’t gonna leaded, que é
tipo assim, você não vai precisar disso, para que você está fazendo isso daí?
E eu acho que aqui na engenharia a gente tem um princípio, aqui na DTI,
que é o princípio de sermos descomplicados, que eu acho que também faz
convergência com isso, que é realmente a gente não tentar criar coisas,
tentar resolver de novo problemas que não existem, tentar fazer uma
arquitetura além do que precisa, tentar matar aí uma formiga com um
canhão.
Marcelo Schuster: Então, mas assim, eu quero até avançar para outra faceta
que eu penso desse programa, mas eu ainda acho que vale a pena ficar mais
um pouquinho aqui nessa questão. Porque assim, veja o que nós estamos
falando aqui até agora, que esse medo de errar das pessoas, seja porque
motivo for, mas esse medo de errar que você tem, somado aos incentivos
da corporação, plano de carreira, o que seja, você também vai ter medo de
errar, e manchar a sua reputação, somada a essa cultura de planejamento
que acha que você resolve tudo no planejamento, tudo isso pode na
verdade gerar inação dos times, das equipes, das pessoas justamente para
poder se protegerem. E aí eu fico pensando assim, por que eu estou falando
de prosseguir? Porque a gente tem que fazer um alerta muito grande, é isso
mesmo, porque a gente sempre fala que o ouvinte é aquele que quer
transformar a sua empresa, porque isso não é desprezível, tanto que a
cultura da empresa, a estrutura da empresa ela pode de fato atrapalhar
nisso, sabe? Por exemplo, vocês estão falando aí que sejamos os
complicados e avancemos aos poucos, a coisa que a gente sabe que é
dificílima é um cliente aceitar bem o conceito de débito técnico. Vocês
concordam com isso? Aceitar bem mesmo, sabe?
Lucas Campregher: Com certeza.
Marcelo Schuster: Que você vai gerando débito e vai pagando? É difícil do
cara não ficar com ela pontinha de achar que isso é uma incompetência,
sabe? E que alguém tinha que ter visto aquilo, aí vem esse negócio: “se
alguém soubesse mesmo não tinha esse débito”, sabe?
Felipe Chagas: Não tinha esse problema. É. E normalmente no primeiro
incidente, vamos dizer, o sistema ficou fora do ar 15 minutos: “tá vendo?
Olha lá as dívidas técnicas, isso foi porque não planejou direito”, e aí volta,
parece que quando começa a ter uma flexibilização em relação a essa forma
de atuação um pouco mais ágil, na primeira vez que isso é atestado se
voltam, porque o da cultura é muito difícil, se volta a situação de conforto
ali que é: “não, vamos planejar aqui, vamos para a prancheta fazer um
[00:16:48], tudo mais”.
Marcelo Schuster: É, porque eu falo assim, a antítese desse anti-pattern é
o próprio ser ágil, não é gente? Se você pensar, o ser ágil é um convite a
você não ficar estagnado ali, que é partir de uma posição mais de
humildade, ser mais evolutivo.
Fernanda Vieira: E eu acredito que o débito técnico é justamente aí uma
forma da gente entregar coisas que geram valor de forma mais rápida. É
sempre tentando, de novo, voltar nesse negócio que eu falei, é tentando
resolver problemas só quando eles se tornam problemas. Então eu acho
que o débito técnico é basicamente isso, a gente fazer, pegar emprestado
ali algum tempo para conseguir entregar alguma coisa mais rápido.
Vinicius Paiva: É, nesse ponto, assim, acho que conversa um pouco com o
que eu falei antes, eu acho que de fato é um problema muito sério como
você encara a natureza da coisa, porque assim, pensa bem se você for
analisar mesmo um negócio digital, o nível de incerteza ele é quase que por
definição enorme. Então, por exemplo, você tem decisões que você tem,
tipo assim, um negócio muitas vezes que já está gerando caixa versus, você
pensa: “mas quanto tempo vai durar isso aqui? Não sei, eu tenho que
continuar inovando”, então no fundo você tem que tomar várias decisões
ali que você não consegue ter aquela resposta exata, tipo assim: “putz,
achei a solução perfeita”. E normalmente quando você está fazendo essa
análise extensiva, mais do que deveria, é numa tentativa de encarar o
problema até como se fosse um problema transnacional, tipo assim, um
problema finito. Não um problema finito, tipo assim, você não sabe
necessariamente o que vem depois, então tem até aquela coisa, aquela
questão, aquela lei do diminishing returns, chega aquele ponto lá que você
não tem mais ganho com aquilo ali, entendeu? Então no fundo é sempre
uma aposta do curto prazo versus o longo prazo, e aí você tem que ficar,
você tem que aceitar que tem uma incerteza inerente, e que é um jogo
infinito, sabe? Entendeu? Assim, e aí na verdade você tem que fazer alguma
coisa, não tem opção.
Marcelo Schuster: Vinicius, você me lembrou, eu lembro que, isso desde a
minha época lá na Tam. Às vezes eu chegava para o pessoal e fazia um
gráfico assim de quanto valia a pena pensar com o tempo, sabe? Porque o
cara ficava ofendido achando que você queria que ele, e cara, não é que
não vale a pena pensar, mas vai caindo o retorno, sabe? Que você sai
fazendo de qualquer jeito. O que eu acho engraçado, o ser humano vive
muito nos extremos, já viu? Então já que eu não posso pensar, então eu vou
fazer de qualquer jeito.
Vinicius Paiva: É, exatamente.
Felipe Chagas: Agilismo não é avacalhação, não é? Assim, tem que ter
método, tem que ter estudo antes de iniciar as coisas também.
Marcelo Schuster: É. Isso é muito curioso, da dificuldade que a gente tem
em transitar entre esses dois mundos. E uma coisa que eu acho
interessante, o que eu ia citar antes até de entrar no (must), o
artigo dá umas sugestões aqui que para mim são todas bem aplicáveis e
estão diretamente relacionadas ao agilismo, sabe? Mas só uma última coisa
que eu ia perguntar para vocês que conhecem bem de tecnologia, é porque
a gente está falando muito da natureza do ser humano, da natureza das
organizações, da natureza de como a gente faz as coisas, e mostrando que
é uma natureza que tende a analysis paralysis, só que ao mesmo tempo,
externamente ascoisasmudaramdeumjeitotalqueelasaumentamainda
mais a insegurança, sabe? Porque tem opção demais, igual eu falei no
começo. Eu queria só ouvir um pouco como é que faz também, cara, tem
muita opção, não é gente? Assim, muito framework de mobile, muito
framework disso, muito daquilo, tudo na hora acontece uma coisa na
nuvem, e muda tudo o tempo todo, não é? Vocês concordam também que
é muita opção? E que é até natural você ficar assim: “poxa, estou
navegando em um negócio aqui que sei lá se eu estou agora fazendo a coisa
certa, sei lá se tem uma coisa melhor, sei lá se o que eu estou fazendo já vai
amanhã ser jogado fora”, entendeu?
Felipe Chagas: É, tem até uma piada, não é Schuster? Que o pessoal fala
que a cada cinco minutos nasce um framework de Javascript, e eu acho que
isso acaba atingindo bastante o profissional de TI, ele realmente fica nesse
mar de possibilidades e acaba que muitas aspossibilidadeselassão
efêmeras, elas surgem com o hype, vão embora muito rápido também,
então eu acho que parte da dificuldade e que exige uma maturidade mesmo
do profissional de TI é ele não se deixar levar por novidades, só pelo
buzzword, pelo hype, entender quando que é o momento de continuar
naquilo que já está consolidado, na linguagem, no framework, que já tem
uma validação de anos de mercado, que ainda assim não são muitos anos
porque ciências da computação é uma ciência recente, quando a gente
compra com outras ciências como engenharia civil, por exemplo, é uma
ciência recente, mas que já tem uma comprovação relativamente longa se
comparado com as outras coisas, e quando é necessário dar o passo para
inovar. Tem uma frase que o pessoal normalmente atribui ao Frank Zappa
que é aquele guitarrista, multi instrumentista, etc., que ele fala.
Marcelo Schuster: Meu filho já falou sobre ele.
Felipe Chagas: Já falou sobre ele, Schuster? Que ele fala que o progresso é
um desvio do normal, não é? Que se você faz sempre ascoisasdonormal
você não vai ter um progresso. Então eu acho que não tem resposta certa
para saber quando que você vai dar esse passo além, sabe? Que é abraçar
a nova tecnologia, o novo framework, eu acho que eu até desviei um pouco
do tema do analysis paralysis aqui, que era mais como que lida com esse
tanto de informação, esse tanto de possibilidade, mas é porque eu acho
que é uma disciplina realmente difícil, sabe? Acho que você não pode se
manter ao que você conhece.
Marcelo Schuster: É, não, tem todo sentido o que você está falando, porque
assim, a saída também não é simplesmente, uai, basta eu só fazer ascoisas
como eu sempre fiz antes e pronto, porque é a mesma história do contínuo,
não é? Você tem um framework a cada 15 minutos, igual você disse, cinco,
não é? Não é nem 15.
Felipe Chagas: É.
Marcelo Schuster: Brincando. Mas assim, de vez em quando você tem que
adotar outra coisa.
Felipe Chagas: É, às vezes pode ter nascido um negócio ontem que
realmente é a próxima nova tecnologia revolucionária, entendeu? Quantas
empresas demoraram muito tempo para adotar o react, por exemplo?
Porque quando ele surgiu ele era um novo garoto no play, e aí depois eles
viram vantagem de trabalhar com web company de maneira mais
organizada que o (êmbolo) fazia, enfim.
Marcelo Schuster: Um dos itens aqui do artigo vai falar sobre isso que você
está falando. Que no fundo você tem que meio que ter bem uma boa
sabatina nessas coisas.
Fernanda Vieira: É, exatamente. O artigo fala um pouco disso, de verificação
de sanidade, e eu acho que isso ajuda nesse tipo de beleza, tem um mar de
opções e aí o que eu vou fazer? Conversa com alguém, programa em par,
faz revisão de códigos, sabatina a sua impressão de qual seria a melhor
solução, discute arquiteturalmente. Então assim, eu acho que isso são
possibilidades, verifique aí se você não está achando que a melhor solução
é uma coisa muito louca. A gente até tem um episódio no Entre Chaves, que
é o papel do arquiteto, que a gente discute um pouquinho em relação a
isso, em relação a essa quantidade de possibilidades que existem para
tomar decisões dentro de um projeto.
Lucas Campregher: Parte dessa tomada de decisão aí também asvezesvai
ser mais subjetiva, às vezes não é só olhar ali tecnicamente qual que é o
melhor framework e arquiteturalmente a melhor solução, mas também a
maturidade do time, a curva de aprendizado dessas ideias que você está
querendo implementar, não dá para trazer tudo de uma vez só porque
tecnicamente, teoricamente é uma vantagem. Acho que tem muita coisa
que tem que ser levada em consideração.
Fernanda Vieira: E eu acho também que é sobre ser capaz de reagir a
mudança também, não é? A gente tem que entender que asnossas
decisões elas não são para sempre, a gente pode tomar uma decisão errada
ali no início de um projeto, ir para um caminho que talvez não seja o melhor,
mas conseguir reagir a isso.
Marcelo Schuster: É. Mas sabe o que eu acho interessante Fernandinha,
você já trouxe um dos itens que ele recomenda lá que é get the sanity check,
onde você tem que fazer um check de sanidade. E eu acho curioso que eu
gosto de fazer um paralelo sempre com asempresastradicionaisporquea
gente sabe que tem muito ouvinte de empresas tradicionais que tem dois
aspectos aí que dificultam as vezes o cara fazer check de sanidade,
entendeu? Ele pode estar dentro de um silo, e aí ele não sai daquele silo de
jeito nenhum, e aí a decisão dele fica comprometida igual o Lucas falou,
sabe? Às vezes o cara está no silo, e o time todo tem maturidade de
qualquer coisa, ou a empresa tem um contrato com outro tipo de
tecnologia, entende? Você tem vários outros aspectos aí que deveriam
pesar nessa decisão, e muitas vezes você simplesmente não tem motivo
para conversar com mais gente, porque na cultura é quase que um
rebaixamento em algumas culturas ele fazer um check de sanidade,
entende? Porque ele estaria já colocando o prestígio a prova, não é? Então
eu só acho interessante porque são soluções que parecem simples, mas
você fala: “pô, porque alguém não faria isso?”, mas não faz, e já tem mil
exemplos na vida de pessoas que não fazem isso. Elas se sentam em cima
da decisão, ficam paralisadas e muitas vezes vão tomar a decisão sozinhas
mesmo, com o mínimo de interação, sabe? E você fala: “poxa, mas é óbvio
que uma adesão dessas se resolveria com mais gente te ajudando ou
colocando outros pontos de vista”. Então uma coisa que ele fala é isso. O
primeiro item que ele fala é você ter uma data, é trabalhar com janela de
tempo, não é gente? Por isso que eu falo que é bem ágil você ter data limite,
não tem jeito melhor de você não ficar paralisado do que você não colocar
um compromisso firme para acabar, para tomar a decisão. Concordam?
Vinicius Paiva: Isso inclusive te força a tentar executar algo, a realimentar.
Acho que o grande ensinamento disso aí é como se fosse um pensamento
de investimento, tipo assim, se eu vou investir um pouquinho aqui, vou
executar, e aí vou realimentar e vou falar assim: “pô, agora eu vou investir
mais tempo”, entendeu? Vou renovar meu investimento.
Fernanda Vieira: É. Tem até um negócio nas sprints ágeis que é o Spike, que
é você, por exemplo, você está precisando estudar uma coisa, implementar
uma coisa nova no seu projeto, e aí utilizar desses mecanismos de janela de
tempo, é uma boa forma de não ficar naquela sprint toda durante cinco
meses estudando sobre algo para você implementar dentro do seu projeto.
Lucas Campregher: É, tomar o primeiro passo e ir ajustando a rota, não é?
Fernanda Vieira: É, exatamente, olhando, estudando um pouco e vendo
beleza já está suficiente, bora então, vamos tentar colocar o mínimo aqui.
Felipe Chagas: Esse negócio do investimento que o Vinição colocou eu acho
que ele é muito importante porque quando você define uma data limite,
você está falando assim: “olha, é o tanto do meu budget que eu vou investir,
que eu posso gastar para fazer essa tomada de decisão”, então pode ser
que mais você tomaria uma decisão melhor? Pode ser que sim. Pode ser
que não faria diferença nenhuma? Pode ser que não. Mas você estipulou
ali no seu orçamento, dentre de todas as outras variáveis, quanto você pode
gastar para tomar essa decisão, por isso que a data, realmente, das dicas
do artigo ali a que eu acho que faz mais diferença e uma das mais simples
de implementar é estabelecer essa data limite.
Vinicius Paiva: Assim, para mim isso aí é como se fosse um reconhecimento,
uma humildade de aceitar a natureza do problema que eu falei antes,
porque tipo assim, se você não aceitar, aí é quase que burrice. Porque
vamos supor que alguém, uma bola de cristal me falou: “esse problema aqui
ele é planejável, basta você dedicar mais tempo”, é burrice, para que você
vai executar se na verdade você debruçar lá você vai acabar achando uma
solução? A questão é um certo reconhecimento de falar assim: “não,
dificilmente você vai achar um problema puramente com essa natureza,
então você precisa de executar um pouquinho para você criar um pouco
mais de certeza”, então aí você vai para essa lógica de quase diversificação
de investimentos em várias tentativas, e uma delas vai dar certo, você vai
saber se vai dar certo só testando.
Marcelo Schuster: É, eu diria assim, não é Vinição, a gente já falou muito
sobre isso aqui no agilistas, é quase como se você, por um lado tendo as
dúvidas do problema, e por outro lado tem a vantagem de você estar
fazendo software, a essência do software você poder trabalhar com opções,
digamos assim, você abrir opções, e decidir quais opções você vai
exercendo e quais vão morrendo. Então quando você abre mão disso, é um
negócio engraçado porque você está tratando software como hardware.
Vinicius Paiva: Você falou de software aqui, para mim é verdade, esse
episódio não é válido só, tudo bem que está a galera do Entre Chaves aqui,
mas pelo menos parecem com isso.
Marcelo Schuster: Complica não, cara. Não, estou brincando, é claro, tem
vários problemas que são dessa natureza complexa, mas o que eu estou
dizendo é o seguinte, o software, eu lembro que eu sempre ficava
brincando, eu fazia as vezes umas palestras, eu falava assim: “gente, como
é que vocês contariam para alguém que você inventou o software?”, sabe?
Sempre fiz essa brincadeira. Chega para um amigo e fala assim: “cara,
inventei um negócio aqui sensacional que você consegue fazer um pouco,
você consegue mudar, sabe? Você consegue ir adaptando, vou chamar de
software, entendeu?”. Tipo assim, e não de hardware porque você
consegue mudar, sabe? E aí você pega a principal característica de um
software que deveria ser a maleabilidade, essa capacidade de mudar, etc.,
e muitas vezes joga na lata de lixo, tratando aquilo como uma coisa
absolutamente convencional que você tem que definir tudo a priori.
Felipe Chagas: Mas se bobear é mais fácil alterar uma máquina, uma fábrica
ali que tem disponibilidade de se ajustar com os parafusos, fazer um (tune
in) na máquina do que alguns softwares por aí.
Marcelo Schuster: Não, eu falo isso, eu cheguei a fazer uma vez um projeto,
quando eu estava estudando, eu lembro que, poxa, antes de poder criticar
o waterfall eu lembro que eu li o livro (inint) ao pé da letra, cara,
você não conseguia fazer o software, entende? E aí você mudar uma
bobeira, era tão difícil, entendeu? Que você tinha que mudar, se você
quisesse se guiar pela (inint), sabe? Você tinha que mudar tanto
diagrama, tanta coisa, sabe? Assim, que você realmente não queria ter que
mudar nada não, você fala assim: “deixa eu definir tudo aqui”.
Vinicius Paiva: (inint), livro danado.
Marcelo Schuster: É, não, não dá nada não. Você fica doido.
Lucas Campregher: É, fora que hoje em dia a gente já faz software pensando
em mudar ele no futuro, a gente faz micro serviço, a gente componentizar
tudo, tudo para tornar, tudo para caso a gente precise tirar uma pecinha e
colocar outra e arrepender de uma decisão fique mais fácil da gente se
arrepender no futuro.
Fernanda Vieira: Exatamente.
Marcelo Schuster: Bem lembrado. Assim, não é só porque chama software,
tem técnica, tem várias coisas, como você falou, para poder fazer um troço
útil.
Lucas Campregher: Exatamente.
Felipe Chagas: É legal isso que o Lucas trouxe, tanto que um dos principais
indicadores que indicam times que estão performando bem é o número de
mudanças que ele faz, a frequência de mudanças que ele faz. Então a gente
vê realmente nesse cenário que o Schuster colocou que fazer uma mudança
é algo muito difícil, naturalmente menos mudanças vão ser feitas porque as
pessoas vão ter resistência para fazer asmudançasouelasvãodemorar
muito para conseguir fazer uma.
Fernanda Vieira: E outra coisa também que a gente incentiva muito
também, o mundo do software incentiva muito são os testes, os testes
automatizados e tudo mais, que também são um princípio para otimizar a
manutenção, para que a gente consiga mudar de uma forma mais segura.
Marcelo Schuster: É que um assunto puxa o outro mesmo, por exemplo,
quando a gente fala do medo de mudar, existe um medo legítimo também
que faz o cara ficar paralisado, fazendo análises, que é o medo do impacto
que ele vai causar, sabe? É o medo legítimo. Eu lembro lá no livrinho do
Extreme Programming, que o cara fala que um dos valores é coragem, só
que ele fala coragem como se fosse assim, eu sou corajoso e (inint)
[00:33:00].
Vinicius Paiva: É burrice, na verdade. A diferença de coragem e de burrice.
Marcelo Schuster: É, na verdade você tem que criar um arcabouço, porque
eu lembrei quando você falou de teste automatizado, você tem que criar
um arcabouço que te permita ter a coragem de mudar, sabe?
Vinicius Paiva: Não vai para a guerra com uma faquinha de pão.
Felipe Chagas: E voltando ao artigo, o teste automatizado não deixa de ser
um check de sanidade também.
Marcelo Schuster: Verdade.
Felipe Chagas: Um check de sanidade porque você vai conseguir fazer a
mudança, tendo ali um check até automatizado.
Marcelo Schuster: Legal esse insight cara, nunca pensei dessa forma.
Verdade. Ele te joga na real ali.
Felipe Chagas: Exato.
Marcelo Schuster: Você está ali viajando, ele vai te jogar sempre na real,
sempre na luzinha verde mandando você seguir o caminho. O outro que ele
fala aqui é você tipo cortar a sua curiosidade, ou podar a sua curiosidade,
eu acho interessante porque aí põe adesões mais genéricas, mas eu acho
que vale muito aí para o que o Chagas dos frameworks surgirem a cada
cinco minutos, é como se você também se programasse para falar o
seguinte: “olha, eu vou parar de analisar tanta opção a partir daqui”, sabe?
Eu vou limitar o meu espaço de alternativas a esse, e vou viver bem com
isso, não é? Porque senão você fica doido também.
Felipe Chagas: Uma coisa que eu tento recomendar aos times quando eles
estão com muita dúvida em que caminho seguir é, faz um parênteses entre
duas opções, no máximo três, que às vezes duas está difícil, tipo assim,
tenta restringir no mar de possibilidades três opções que você acha que vão
ser as mais possíveis e factíveis de serem levantados aqui. Então, sei lá,
vamos supor que estavam querendo desenvolver um aplicativo novo e não
sabe qual tecnologia utilizar, coloca três opções ali na roda, um Nativo, um
Flutter e um (Action Date), e se restringe a essas três, e aí sim
você aprofunda. Então eu acho que, seguindo o artigo aqui, o podar a
curiosidade não precisa ser superficial, é escolher onde você vai querer
aprofundar, porque se você quiser aprofundar em tudo vai ser impossível.
[00:35:00]
Fernanda Vieira: É, o artigo fala que para a gente conseguir fazer essa
definição muito clara do que eu preciso saber, e o que eu gostaria de saber.
Eu acho que isso vale para tudo mesmo na vida, até para fazer uma
pesquisa, eu estava pensando nisso, fazer uma pesquisa sobre procurar
uma apresentação, por exemplo, informação, igual eu falei no início,
informação a gente tem milhões de informações, eu posso querer sempre
mais informação, mas na hora eu preciso definir o que eu preciso pesquisar
para agora, o que eu queria saber no futuro? Beleza, eu preciso pesquisar
isso aqui, então esse é o mar de coisas que eu vou trabalhar agora, o resto
vão ser curiosidades que eu vou me aprofundar depois.
Vinicius Paiva: Eu lembrei aqui, é só para trazer mais uma outra fonte que
leva, mais ou menos na mesma direção, são as técnicas de design thinking,
e double diamond, que você diverge para convergir, você vai criando
ferramentas para ter os status. Você tem algo ferramental para divergir um
pouco, mas depois você tem que fermentar para tentar convergir senão
você não chega a lugar nenhum.
Marcelo Schuster: Essa outra aqui parece que é o Vinição que escreveu,
sabe Vinição? Reconheça que as luas não irão sempre se alinhar, a coisa que
eu mais vejo o Vinição ficando bravo em reunião é: “fica esperando asluas
se alinharem, as estrelas”. Fala aí Vinição.
Vinicius Paiva: Os unicórnios, pessoal tentando achar os unicórnios.
Marcelo Schuster: É, isso aí é contribuição sua aqui para o artigo?
Vinicius Paiva: É, isso aí para mim é assim, eu cometi algum deslize aqui
sobre a natureza do mundo, você esperar a solução perfeita ali é
contraproducente na loucura que a gente vive, e essa loucura é
materializada na construção de softwares e artigos digitais.
Felipe Chagas: É aquele ditado, feito é melhor que perfeito.
Lucas Campregher: Exatamente.
Felipe Chagas: Se você for esperar o momento ideal você nunca vai fazer.
Marcelo Schuster: Isso aí me lembra, pena que eu esqueci a expressão, tem
aquele economista que ganhou o prêmio Nobel, que eu acho que é o Henry
Simons, que ele misturava optimize com (sufize), como se fosse
assim, você não vai conseguir achar uma solução lógica quase nunca, que é
o que ele fala basicamente assim, entendeu? Você vai ter que achar algo
satisfatório para aquela condição que você tem naquele momento, e aí
depois você vai evoluindo. Por isso que eu falo que tudo aqui, no fundo, são
formas de se olhar para o agilismo mesmo, não é gente? Formas de olhar
para essa cultura. No fundo tudo se resume a entender a natureza do
problema, que é um problema complexo, sabendo que você vai nessa
região aí, igual no modelo de Snowden, que você vai trabalhar com esse
sense-responding. E aí ele termina justamente falando isso, você pode
tomar pequenas decisões para não ficar parado, você não precisa tomar a
decisão, que é uma outra coisa muito sabia que se fazer também, muito
óbvia por um lado, mas muito sabia por que é muito fácil cair nesse pecado
de tentar tomar uma grande decisão. Isso tem a ver com o que a gente já
falou até de construir opções aqui.
Vinicius Paiva: É, exatamente, falou exatamente isso dá opcionalidade que
o nosso (inint) fala, que na verdade a mesma coisa que um
pacote de experimentos que o Snowden fala, assim, a mesma coisa na
verdade, o mesmo conceito.
Marcelo Schuster: Variações do mesmo tema, não é?
Lucas Campregher: É. Até dividir ali um problema grande e analisar ele em
caixinhas menores, ajudar a gente a tomar decisões menores em vez de
tomar grandes decisões de uma vez, uma metáfora que ele usa aqui
também é que no exército, quando você está em um ataque de um
morteiro, não importa a direção que você escolha mover, o importante é
que você mova. Achei bem legal isso aí porque é realmente isso aí, é a
metáfora perfeita para o que a gente enfrenta nesses casos.
Fernanda Vieira: Falando com essa metáfora aí também, tem até uma
fábula do gato e da raposa, não sei se vocês já ouviram, mas que mais ou
menos fala bastante aqui da análise da escolha.
Marcelo Schuster: Antigamente eu ia falar bem da raposa, hoje em dia eu
estou sem moral para falar da raposa.
Vinicius Paiva: Marcelo que está evitando as raposas. A raposa está assim:
“peow”. Coloca um efeito aí, não, raposa não.
Marcelo Schuster: Muda o bicho aí. Não sei, põe um lobo.
Fernanda Vieira: Qualquer outro.
Marcelo Schuster: Lobo-guará, pronto. Lobo-guará.
Fernanda Vieira: Lobo-guará.
[00:39:29-00:39:37]
Fernanda Vieira: Então vamos falar do lobo. E aí então o lobo, ele esnoba o
gato porque ele fala assim: “eu tenho a arte de milhões de coisas, eu
conheço muita coisa, eu sei escapar de cachorros”, e o gato falou assim: “a
única coisa que eu sei é escapar de cachorro e subir na árvore”, e a raposa
fica lá: “não, mas eu vou te ensinar várias formas de fazer isso, de escapar
de cachorro”, e aí chegaram os cachorros, o gato subiu na árvore e a raposa
ficou parada e foi comida pelos cachorros.
Marcelo Schuster: Ficou pensando.
Fernanda Vieira: Ela ficou parada e ficou pensando em qual escolha ela
faria.
Marcelo Schuster: Excelente. A raposa não, o lobo-guará.
Fernanda Vieira: É, o lobo, desculpa. Bem lembrado.
Marcelo Schuster: A raposa já era.
Felipe Chagas: A gente vê que a fábula às vezes tem alguma similaridade
com a realidade.
Marcelo Schuster: É. Isso que eu ia falar.
Lucas Campregher: Eu não estou gostando desse podcast enviesado aqui.
Marcelo Schuster: Chegou a segundona e nós não conseguimos escapar,
entendeu?
Lucas Campregher: Não é possível que só eu que vou defender a raposa
aqui.
Marcelo Schuster: Falou bicho, eu gostaria viu, de defender a raposa, mas
está difícil. A raposa ainda vai ficar fenomenal, é só ter confiança. Pessoal,
estou chegando aqui ao fim, eu queria até fechar com isso que a
Fernandinha contou, o fechamento que eu faria aqui é isso, gente, um
sintoma muito forte, eu volto a falar com os ouvintes que querem
transformar suas organizações, cara, um grande sintoma de que você não
está no caminho ágil, é exatamente se você se sente preso, analisando o
que eu faço, não consegue quebrar esse ciclo. Então hoje esse episódio foi
mais uma forma de tentar fazer um apelo assim, quebre esse ciclo, se você
não sabe como, vai lá no nosso episódio, o The Fucking First Step.
Vinicius Paiva: The Fucking First Step.
Marcelo Schuster: E ele tem que botar um pi aqui depois, não é, João, no
meu fucking. Mas assim, vai lá no The Fucking First Step.
Fernanda Vieira: Duas vezes, não é?
Felipe Chagas: Três.
Marcelo Schuster: Não esquece de botar um pi lá no fucking. Mas o que a
gente mais quer com o agilistas, com o Entre Chaves é a gente disseminar
essa cultura e fazer um grande convite a ação mesmo de justamente acabar
com esse analysis paralysis e começar a criar ciclo virtuoso aí, que a gente
sabe que é bom para todo mundo, sabe? É bom para os negócios e para as
pessoas que estão lá, que é muito mais satisfatório trabalhar nesses
ambientes onde você consegue gerar valor e ter um propósito mais claro.
Isso aí pessoal, grande abraço, gostei muito de gravar ai com o Entre
Chaves, temos que fazer mais.
Lucas Campregher: Valeu pessoal.
Vinicius Paiva: Valeu pessoal.
Fernanda Vieira: Obrigada.
Felipe Chagas: Valeu pessoal, até mais.
Fernanda Vieira: E ouvintes. Nos escutem. Escutem o Entre Chaves.
Lucas Campregher: É, tomem uma boa decisão e escutem o Entre Chaves.
Felipe Chagas: Toda terça-feira, momento jabá aí, toda terça-feira Entre
Chaves lançando episódios, a gente já tem mais de 94 episódios falando
sobre desenvolvimento de software, só procurar aí no feed do seu podcast
Entre Chaves. Terça-feira tem episódio novo.
Fernanda Vieira: Isso aí.
Marcelo Schuster: Isso aí, pessoal, abração.
Lucas Campregher: Valeu.
Fernanda Vieira: Até mais, obrigada.
