Chegou a hora de falarmos 
sobre o método ágil,

não somente pelo viés 
da parte de fintechs ou startups

que há necessidade de entregas tão ágeis,
mas também pela visão de grandes players.

Eu sou o Rafael Ronqui, e hoje estou 
aqui com dois grandes convidados.

Olá, Pantolfi, tudo bem?

Como você está?

Olá, Rafa! Olá, pessoal de casa!

Meu nome é Robson Pantolfi, eu 
sou head de tecnologia e produtos,

e também sou professor no MBA da FIAP.

E, obviamente, é um prazer enorme
estar aqui mais uma vez com vocês.

Obrigado, Pantolfi, pelas palavras.

Eu tenho certeza que não vai faltar 
conversa, e experiência, né?

Obrigadão!

Estou aqui também com o meu 
grande amigo Anadão.

E aí, Anadão? Como você está?

Muito bem.

Obrigado, Rafa, pelo convite, 
o Pantufo, por estar aqui.

Eu sou gerente de TI 
de uma multinacional de alimentos

com foco na área de compras.

Eu vim aqui para batermos um papo 
sobre essa metodologia e tudo mais.

E aí eu já começo
apimentando essa conversa, né?

Como podemos trazer aqui,
para quem está nos escutando,

o que realmente seria
a gestão de projetos ágeis?

Como podemos definir?

Quem consegue ajudar?

Lógico que deveria ser um podcast 
para explicar essa pergunta, né,

mas um dos dois vai conseguir 
dar essa soma para nós.

Vamos lá, eu vou fazer 
uma introdução aqui.

De forma geral, tudo 
o que falamos em métodos ágeis

é uma cultura que começou ali
na sua primeira apresentação

no evento do Uppsala,
lá nos Estados Unidos, em 1995.

E a proposta ali foi 
uma visão mais moderna

de como inicialmente fazíamos gestão 
e desenvolvimento de software.

Mas hoje já é culturalmente utilizado
em várias outras áreas,

inclusive áreas de marketing,
RH, áreas de negócio.

E qual seria a proposta?

Desenvolver e simplificar métodos

para que tivéssemos menos 
problemas, que eram históricos.

Eu ainda lembro quando 
eu estava me formando

no colegial técnico 
de processamento de dados,

que o professor falava:
"Você quer trabalha em TI?

Se prepare porque em final 
de projeto você não tem feriado,

não tem final de semana, 
não tem madrugada.

Você vai se matar.

Cuidado para não entregar idade, hein!

"War room", né?

Mas era muito interessante, poder 
acompanhar toda essa mudança.

E no método ágil começou a se entender
que boa parte dessa problemática

era porque no projeto tradicional...

Você tinha lá um projeto de um ano,

você construía tudo de uma vez 
e entregava no finalzinho para o cliente.

Nesse momento, você já tinha mudança
de legislação, mudança de regra de negócio,

funcionalidades que já não faziam 
mais sentido para o cliente...

- Fica desconectado nesse um ano, né?
- Exatamente.

E aí, com a filosofia ágil, 
começou a se pensar:

"Bom, vamos deixar todo 
mundo junto desde o começo,

cliente, time de desenvolvimento, enfim,

e, gradativamente, nós vamos 
fazendo pequenas entregas

para fragmentarmos 
os problemas de um projeto,

tornar isso cada vez mais natural,
equilibrando dois pontos principais,

produtividade e sustentabilidade".

Ou seja, em métodos ágeis
não existe projeto de sucesso.

Você teve que arrancar
sangue do time para executar.

Então, a filosofia ágil e a gestão ágil,
buscam justamente

respeitar essa cultura 
e buscar esse equilíbrio

entre produtividade e sustentabilidade.

E tendo o cliente no centro.

Então eu acho que um dos principais pontos,

porque eu sempre faço uma analogia
com a construção de uma casa.

Eu já tive uma experiência como essa
que, em determinado momento,

usando o método antigo da cascata,
eu pensei: eu preciso construir uma casa.

Eu tinha um projeto 
que eu morava na Colômbia.

Deixei tudo certo com arquiteta.

Vai lá... Beleza.

Quando eu voltar, vou morar na casa.

Quando eu voltei, a planta 
que eu tinha feito era uma...

- E a entrega era outra.
- Estava bem distante da sua expectativa, né?

Eu olhei e falei: o que é isso?

Então, assim, quando você está no ágil,
você tem as pessoas muito próximas,

existe muita comunicação e feedback,
você também tem as entregas muito curtas,

aumenta a qualidade, né?

Então são vários pontos 
que nós temos a favor.

E o mundo evoluiu também.

Não dá mais para seguir como no passado.

Tão tradicional, né?

? espera um ano.

Eu estava comentando com o Rafael,
antes aqui do podcast

que existe uma situação em que você
inicia com uma determinada solução,

que você busca no mercado, 
é o que está mais atualizado,

e se você demorar para implementar, 
ela já fica obsoleta.

Isso não existia no passado, e estamos 
falando de um passado muito recente.

Deixe-me jogar uma pimenta na conversa,
e eu tenho certeza você vai se sair bem.

Aí você ajuda ao que foi

Mas, pessoal, não foi nada treinado.

Foi uma conversa de café só para fazer 
um briefing do que vai rolar.

O ágil prega que se realmente
fizermos em sprint...

Vamos dizer que por um período de um ano,

você cria vários sprints, você vai ficando
próximo do cliente, conforme a cartilha,

você realmente consegue entregar
com mais qualidade, mais assertividade.

Mas como é isso no dia a dia da empresa?

Como você vive isso na empresa?

É realmente o que está escrito lá?

É fácil assim mesmo?

Pô, se é ágil, então é realmente 100% 
conforme foi pedido e na qualidade esperada.

Como é no dia a dia?

- Não. Na verdade...
- Pode mandar a verdade, tá?

Na verdade não é assim.

E quando falamos que, se não 
colocamos o cliente no centro realmente

e ele realmente entende o que ele quer,

e existe essa comunicação e tudo isso,

é muito fácil de se perder.

Então, a pessoa que desenvolve...

Eu sempre vejo assim: a pessoa 
que desenvolve, quer desenvolver.

Quanto mais próximo do computador
e programando, melhor.

E essa parte de reunião e comunicação,
eles fogem, querem fugir um pouco.

Mas precisa entender que essa 
comunicação com o cliente é importante

porque o cliente talvez não
consiga visualizar o produto,

e nessas interações
pequenas que temos dia a dia,

você vai trazendo o cliente
para próximo daquilo

para ele materializar aquilo,
porque ele tem uma ideia, um foco.

Mas, de repente, se você não o traz junto

e não vai contando a historinha para ele
dia a dia, é muito fácil de se perder.

Então, quando estamos falando de grandes 
empresas, de projetos e tudo mais,

você acaba tendo vários 
projetos simultâneos

ao mesmo tempo, com a mesma pessoa.

E às vezes esse cliente também tem 
vários projetos que ele está demandando

com squads diferentes...

- Ao mesmo tempo ali, né? 
- Ao mesmo tempo.

Então, assim, se não tiver um balanço
e não conseguir harmonizar bem isso,

é muito fácil de se perder, muito fácil.

E aí vira uma uma grande 
complicação para corrigir, né?

Para voltar, e às vezes o tempo já passou.

É, o tempo já passou, o dinheiro 
também já se consumiu, já se gastou.

Estressou a equipe, 
estressou os envolvidos.

Exato. E esse é outro ponto, porque o stress 
da equipe também é algo que acontece

se você não tem
essa harmonia entre todos.

E aí, Pantolfi? Ele falou aqui em colocar 
o cliente como centro do projeto,

o centro das atenções,

Isso agrega e talvez realmente 
consiga ter mais assertividade.

Como você soma?

Eu concordo plenamente 
com o que ele comentou.

E até complementando isso,
as dores não estão atreladas...

Na execução do dia a dia nas empresas,

elas não estão ligadas 
ao fato de elas estarem

seguindo à risca ou não os métodos ágeis,

mas especialmente de elas não estarem
seguindo a proposta da cultura.

Então, alguns exemplos práticos

que eu vejo muito, muito, muito,
muito nas empresas,

quem usa Scrum, por exemplo, 
parte do princípio que...

Na verdade, métodos ágeis como um todo,
mas especialmente o Scrum.

A estimativa, quem define o quanto 
vamos executar dentro de cada sprint,

sendo sprints de duas semanas, três,

o quanto vamos construir
dentro daquele tempo,

é uma definição das próprias pessoas
que estão com a mão na massa

de quem está construindo de fato.

Só que muitas empresas ainda têm muito
aquela filosofia de comando e controle

que reinou especialmente
na década de 1970 e 1980,

mas que até hoje ainda está por aí.

Como assim? Quem vai desenvolver é 
quem vai ditar como o bumbo vai tocar, né?

Exato.

Então, assim, tem muita 
empresa que até fala assim:

"Não, aqui nós respeitamos a cultura ágil.

Você pode estimar.

Só que o prazo para você 
entregar o projeto é esse aqui".

E a partir daí, você já cria 
várias complicações.

Você começa a não respeitar
os problemas que o time pode passar...

- Durante aquela construção...
- Compromete qualidade, né?

Compromete qualidade.

Hoje em dia, em época de LGPD,
você pode comprometer segurança.

Tem muitos fatores 
que são importantes você olhar

com a devida atenção e cuidado a cada etapa,
mesmo você entregando gradativamente,

mesmo você chegando 
no principal ponto mais rápido.

E uma outra coisa que, historicamente,

foi o principal fator pelo qual 
o método ágil existe,

se não me engano, final da década 
de 1990, começo de 2000,

uma entidade global 
chamada "Standish Group",

que é uma entidade de pesquisa 
de projetos de tecnologia,

chegou a uma conclusão, num catado
de pesquisa no mundo inteiro,

que cerca de 20% daquilo que era
produzido nos projetos em geral,

era o core que resolvia
a dor que o cliente estava pedindo.

E, em média, 45% do que era feito
no projeto, o cliente nunca usava.

Ou seja, você já tinha naturalmente
uma cultura de desperdício

de pelo menos metade 
de tudo que era produzido.

Beleza.

Como você muda isso?

Você vem, pega o seu escopo, e revisa
constantemente para entender a prioridade,

para entender que dor ele resolve,
para entender os porquês.

E é muito comum ainda nos dias de hoje
você chegar na empresa

e as pessoas não saberem
por que estão fazendo aquilo,

qual o problema a ser resolvido,
e assim por diante.

Acha que a forma de se resolver,
de entregar mais rápido,

é botando todo mundo para correr.

Mas será que não ajuda o Anadão falou?

É legal o que você trouxe aí, o cliente 
como centro, estando próximo.

Menos código e sim estar 
próximo para entender mais, né?

E aí, é o que eu falo, né?

Temos que contar aquilo 
que acontece na prática, na vida real.

- É isso que queremos ouvir, viu?
- Coloca lá o cliente, né...

Depois eu faço aqui a contenção.

Coloca o cliente no centro, 
e aí, o que acontece?

O cliente muda, o cliente muda.

Chega outro cliente para substituir aquele.

Olha o projeto e tudo, 
e fala assim: "Não era bem isso".

Então, assim, o foco, né?

O que eu quero?

O que eu preciso?

E uma das coisas que eu tenho visto aí,

quando nós falamos dos sprints,
entregamos melhor, entrega melhor, e aí vai,

às vezes, enquanto você está
desenvolvendo e entregando,

já está surgindo alguma coisa 
nova para o segundo sprint,

que você precisa estar
atualizado e antenado,

porque o cliente sabe disso,
e ele vem até você e fala assim:

"Olha, já tem isso aqui!".

Então, é dinâmico, é muito dinâmico,
é essa interação o tempo todo,

e tem que estar sempre 
com uma escuta ativa.

É o que eu falo, o princípio de tudo 
é essa conversa, esse feedback.

O feedback tem que ser real, ele tem 
que ser construtivo, e ele tem que existir,

porque se não teremos 
surpresas na entrega.

E ainda no gancho do cliente no centro,
o cliente tem que estar no centro

porque é ele que financia, é ele que nos 
direciona aonde temos que chegar.

Está tudo certo.

A questão é se esse cliente 
também faz parte dessa cultura

da cultura ágil, ou não.

- É isso.
- É um outro ponto.

Esse é um ponto excelente.

Desde a primeira formação 
do Product Owner...

Tem um exemplo que eu acho 
muito legal, que é o seguinte:

imagine, Rafa, que você é o nosso cliente.

Eu cuido da logística, o Anadão 
vai cuidar do produto em si,

e você nos encomendou um bolo, tá?

Você está lá, já com a festa pronta,
tem um momento para chegar o bolo,

estamos comprometidos 
em entregar, tudo direitinho.

Ele entregou o bolo em perfeitas
condições.

Eu combinei com você que em 40 minutos 
eu chego na sua festa com o seu bolo.

Só que, por algum motivo, duas horas
depois, eu cheguei com o bolo,

mas o bolo está todo 
esbagaçado, todo quebrado,

e você não entende o que aconteceu.

Você já está louco da vida porque chegou
atrasado e ainda chegou com problemas.

Essa é a situação A.

Situação B: eu fui buscar você, você 
foi comigo, e retiramos o bolo juntos.

Fomos lá para a sua festa.

Só que você viu que teve 
um acidente na nossa frente,

seja com um motoqueiro ou com um caminhão.

Aconteceu um monte de fatores que não 
dava para evitar e assim por diante.

Eu participei, nesse caso, né?

Nesse caso, você estava dentro do táxi,
você estava dentro do carro, né?

Então existe uma diferença muito grande
do cliente que está fora, distante do time,

de tudo o que está acontecendo,
e do cliente que está dentro.

Não quer dizer que na situação B
você não se sentiria frustrado, né?

Só que, diferente da frustração A,

na segunda, você entende o
porquê daquela frustração.

Então as dores são diferentes.

E você ainda consegue participar
e elaborar comigo outros caminhos...

- Para nós...
- Alternativas para solucionar...

E minimizar o impacto.

Exatamente, para diminuirmos essa dor.

E aí, nessa linha, eu vou trazer
mais um ponto aqui para vocês.

Vai começar um projeto, 
está alinhado, vamos fazer.

Definido então, você vai fazer 
no ágil, ou cascata, ou PMI que seja,

ou talvez num modelo híbrido.

Como é essa negociação?

Como você, TI, que vai 
entregar um produto,

seja para a sua empresa 
ou para um cliente, e negocia isso?

Porque tem essa visão.

Você quer ágil? Mas você está preparado 
para receber um projeto em ágil

Você tem alguém para designar
como Product Owner?

Você sabe o que é um Product Owner??

Como é essa negociação?

Como vocês estão vivendo isso?

Eu acho que depende muito
do tipo de projeto, né?

Por exemplo, nós trabalhamos com SAP.

Quando falamos que o SAP é um RP
não tem muito o que discutir.

Modelo de cascata
serve, funciona, é perfeito.

Então às vezes...

Perdão, Anadão, é porque é um cenário...

- É um cenário conhecido, do começo ao fim...
- Com um sistema estável...

Sistema estável, todo mundo 
sabe o que tem que fazer

no tempo que tem que entregar.

Então, assim, funciona perfeitamente.

Agora, quando eu vou desenvolver alguma coisa

que precise dessa interação
com o cliente,

aí você vai para o modelo ágil.

Esse exemplo do bolo é 
perfeito, essa participação.

Por exemplo, nós desenvolvemos 
um chatbot que interagia com o ERP.

Era uma coisa nova, uma coisa que não tinha 
no mercado no momento que fizemos.

Então você precisava estar com o cliente
o tempo todo, porque até para ter certeza

do que ele estava pedindo 
e do que estávamos construindo,

estava adequado,
era aquilo que ele queria.

E tivemos n ações de correção 
ao longo desse caminho

para chegar naquela data 
que ele queria o produto

e conseguir receber esse produto.

Então eu acho que não é tão formal,
na minha visão, falar:

olha, bandeirinha do ágil, 
bandeirinha do PMI.

Mas você dosa.

Eu concordo plenamente que a pessoa 
que vai gerenciar isso, ou o usuário,

tem que entender um pouco da metodologia,

porque senão atrapalha 
muito, atrapalha muito.

Um puxa para um lado, o outro 
para o outro, viés diferentes.

É um pouco complicado de lidar.

Eu vivi agora, mas um pouco menos,
que quando você quer...

Você sabe o que é um Product Owner?

"Como assim?"

É que eu preciso que alguém 
seja responsável pelo produto,

para não falar em techinês.

"Não, tem uma pessoa aqui...

Um junior aqui que vai assumir".

Não, espera aí! Alguém 
que vai representar o produto,

que toda a minha equipe 
vai tirar as dúvidas, consegue?

"Ah, não. Então eu vou colocar um sênior."

Mas esse profissional 
tem tempo? "Não tem."

Então espera aí. Vamos nos sentar para conversar.

E essa é uma das holes que eu
vejo que está mais deturpada,

porque na minha visão
o Product Owner é uma pessoa

que tem que ver o todo do produto,
o ciclo completo.

Então ele tem que ver, por exemplo,
a parte de suporte.

Porque não adianta implementar
e ter um custo absurdo de suporte,

não adianta implementar ir no mercado 
para ver o que tem novo,

o que eu posso substituir, 
o que que eu posso melhorar.

Ele tem que manter vivo aquele produto.

Eu vejo que as pessoas 
ficam presas à entrega,

param no tempo, e não atualizam aquilo.

Então, assim, o Product Owner é 
uma hole fantástica e uma hole grande,

é uma coisa viva, latente.

Mas ela acaba ficando no passado

porque talvez a escolha 
da pessoa não seja a correta.

E eu acho muito interessante em cima disso
tudo que vocês estão falando

é que muitas vezes a empresa parte 
do princípio que ela está adotando o ágil,

mas ela não se preocupa
com essas amenidades, né?

O meu Product Owner, que vai 
representar a visão do cliente,

está preparado ou não para isso?

Ele sabe priorizar?

Ele sabe montar um backlog?

Ele sabe direcionar o time
para atingir primeiro

aqueles 20% que são mais importantes?

Não sabe?

São questões que vão aparecer 
ao longo do caminho.

Eu já tive trabalhos em empresas que, 
tradicionalmente, era o método cascata,

e que eu fiz uma célula ágil, 
que ela começou a gerar resultado,

e fomos entendendo se fazia sentido 
outros times migrarem ou não,

outros que se sentiam mais confortáveis
no planejamento clássico.

Eu sempre parto do princípio que...

E eu aprendi isso diretamente
com o Ken Schwaber,

um dos fundadores do Scrum,

quando ele fez a primeira turma, em 2010,

e eu tive o privilégio de participar.

- Eu estava no lugar certo, na hora certa.
- Fantástica essa sua experiência.

Essa é boa, hein!

Dá para voltar o tempo 
para você me convidar?

Também vou nessa!

E aí era muito interessante, porque 
nós fomos perguntando para ele

como que ele chegou naquelas conclusões,
naquelas dinâmicas, e assim por diante.

Eu só ouvi a história, tá? Eu não o conheço.

Então uma das perguntas 
que nós fizemos foi:

"Cara, beleza, você diz que, no Scrum,

o seu time tem que ter no mínimo quatro
pessoas, no máximo nove.

Qual foi a matemática, o cálculo 
que você fez, para chegar nisso?

Aí ele falou: "Cara, testamos 
com dois, não deu certo,

com três não deu certo, 
com quatro deu certo, cinco, seis, sete...

Até nove deu certo.

Com dez começou a dar ruim?

Que legal!

E aí, qual foi a grande dica dele?

"Cara, é teste, acerto, teste, erro, 
teste, acerto, e teste, erro.

- Então, quanto mais...
- Que são os princípios.

Exato. Então, quanto mais 
você vai experimentando,

mais você vai trazendo riqueza.

Se você está num ambiente que as pessoas 
não possuem maturidade em utilizar o ágil,

coloque uma prática de cada vez.

Já teve caso, por exemplo, que, cara,
estava tudo um caos, nem cascata era.

Era "caoscata".

Caoscata? Essa é boa, hein!

É um bom termo.

E aí pediram para eu dar 
uma ajuda para o time,

inclusive era um time tradicional de Cobol,
mainframe e tal, que é uma linguagem

e um modelo que o pessoal está 
mais acostumado, no formato cascata.

Eu falei: pessoal, vamos fazer 
um pequeno exercício aqui.

Ao invés de só sair fazendo um planejamento aqui
de dois, três meses,

vamos planejar o que vamos
fazer nas próximas duas semanas?

Separar essas tarefas, discutir aqui, 
entender a complexidade,

organizar quem vai 
fazer o quê, e executar?

Aí, beleza.

Nossa! A turma ficou super feliz,
já ficou mais claro,

não tinha mais aquilo de duas pessoas
fazendo a mesma coisa ao mesmo tempo.

Já diminuiu um pouco o caos.

"Ah, legal."

O que vocês acham agora
de a cada dia batermos um papinho

só para entender quem está fazendo
o quê, se está tendo problema.

Se tiver problema, é para avisar esse 
cara aqui, que esse cara vai ajudar.

"Ah, legal! Pô, bacana!

Nossa, eu bati a cabeça três dias por causa 
de um problema para compilar o meu programa.

Agora tem um cara que ajuda,
já endereça no mesmo dia.

Legal."

Vamos fazer agora
uma cerimônia de entrega?

Vamos fazer uma uma cerimônia 
de retrospectiva agora

para discutirmos aqui o que aconteceu,
se foi legal, se não foi,

se o Product Owner apresentou 
de uma forma legal ou não para você,

se o que ele priorizou fez sentido ou não.

Então todas essas coisas foram criando 
gradativamente a cultura para aquele time

e aí o próprio time vai 
se ajustando, entendendo...

"Beleza, tudo isso faz sentido para mim.

Não, isso aqui não faz.

Podemos melhorar", e assim por diante.

Então, de forma geral,

é uma leitura muito mais do quanto
as pessoas que já estão lá

têm conhecimento, de fato, da cultura ágil 
como um todo, ou do método adotado,

e gradativamente executando
teste, acerto, teste, erro,

para ver se para aquele time
está funcionando bem,

para aquela empresa, para aquela 
cultura, está funcionando bem.

E aí você vai gerando conhecimento...

- É isso aí.
- E multiplicando a experiência.

Deixe-me trazer um tema aqui que...

Senão alguns professores 
que estão envolvidos aqui na FIAP,

inclusive vocês aí,
vão ficar bravos comigo.

E aí, o PMI está morrendo?

Cara, na minha leitura, ele 
diminuiu muito a força, né?

Eu só joguei aqui.

Depois vai ter a minha
opinião também, tá? Vai lá!

Eu não tenho uma leitura 
que vai morrer, tá?

É a minha visão também.

Tem o PMBOK mais atual
agora

E não se enganem...

Eu sou um grande 
defensor da cultura ágil,

mas muito mais da cultura
do que só de um método ou de outro,

até porque quando falamos 
em métodos ágeis,

muitas vezes a pessoa 
associa mais a Scrum.

Só que você tem Scrum, 
KanbanFlow, SAFe, OKR,

e cada um por uma coisa diferente, né?

XP, enfim.

Mas o grande ponto, ao meu ver, é...

Um exemplo que eu gosto muito
é a fabricação de placas de computador.

Você normalmente faz um desenho uma vez,

a especificação com todos
os detalhes, com todo o material,

coloca na linha de produção,
e ele já constrói a placa por inteiro

e você já a valida inteira do outro lado.

que é o conceito do método
cascata.

Peças de carro...

Exato.

Se você faz de pouquinho 
em pouquinho a entrega disso,

além de você não conseguir,
de fato, utilizar do outro lado,

você ainda tem o problema
do desperdício de material,

do vai e volta, do vai e volta.

Aqui é algo bem específico, mas 
eu acho que deixa muito claro...

Inclusive o estoque desses materiais, né?

Exato, exato.

Então eu não acho que morre,

mas ele obviamente começa 
a aprender com novas filosofias.

Como você mesmo colocou, o PMI
criou lá um módulo incremental e tal,

para se buscar aprender
um pouco dessas novas referências.

Então ele se adapta a novos contextos.

Agora, sim, antes, PMI...

Inclusive o PMI também nasceu na década 
de 1970, junto com o método Cascata.

- Então bebeu da mesma filosofia.
- Estava junto, né?

Exato.

Só que ele foi perdendo força, 
no mercado como um todo,

especialmente em desenvolvimento
de software, porque fomos entendendo

a magia de se entregar um pequeno módulo,
um pedacinho, o famoso MVP,

e aí o cliente já começa a rentabilizar...

- A resolver o problema daquele sistema...
- ? tem um retorninho ali, né?

Exato.

Mesmo antes de terminar o projeto.

Então essa é a magia.

Até começamos a pensar
projetos diferentes.

Eu estava simulando 
com a turma, por exemplo,

um projeto de locadora de veículos.

Tradicionalmente, nós sempre
priorizávamos os cadastros.

Então, na locadora de veículos,
você cadastra o carro, cadastra o cliente.

Foco, né? Recebeu dado/cadastro.

Só que, pensando no cliente 
já começar a usar,

o que você tem que fazer primeiro
é a parte da reserva, do pagamento etc...

- Porque ele já...
- Senão você não gera ganho ali para ele.

Exatamente.

Para começar a operação, eu posso 
cadastrar direto no banco de dados lá,

e ele vai operacionalizando.

Então é uma forma de eu fazer 
um contexto menor,

já colocar para rodar,
já começar a gerar dinheiro em cima,

e aí nós vamos executando o restante
do projeto sem a mesma pressão

daquela primeira entrega,
daquela primeira rodada.

E eu até trouxe isso, Antolfi e Anadão,

porque eu sei o contexto que vocês vivem.

Foi legal até o contexto de SAP 
que você trouxe, né,

o grande sistema ERP.

Até o presente momento, 
vemos que faz sentido,

se não em todos, mas 
na maioria dos casos,

implementarmos um novo módulo 
que seja, ou uma mudança, o PMI.

E aí, para provar que o PMI existe,
e ainda vai existir,

mas não sabemos por quanto tempo,
e nem o ágil, ainda tem o híbrido hoje.

Ou seja, para mostrar que o ágil 
faz sentido, criar esse novo.

Até se você der uma pesquisada, 
um dos nomes que intitularam aí é "flex".

E aí, Anadão, como está lá?

Para você, morre, não morre, está igual?

Vamos usar tudo aí, depende do momento?

Eu acho que é aquilo 
que estávamos conversando aqui.

Morrer, eu também acho que não.

Eu acho que ele vai passar 
por uma transformação,

e está passando a cada dia.

Mas existem muitos segmentos
que ainda precisamos desse modelo,

do modelo de cascata,
do modelo de entrega,

do modelo de ter as fases, 
celebrar as fases.

E, por exemplo, na construção 
civil, ele funciona, ele tem certas coisas...

Na entrega de um ERP,
ele tem esse benefício.

Então eu acho que morrer não.

Mas eu acho que sai um pouco desse....

Antes eu costumava dizer
que era um pouco acadêmico, né?

Tinha as fases, engessado, 
pesado, duro...

No passado era assim, né?

O mundo não aceita mais isso.

E a evolução tecnológica que estamos
passando, não permite mais essa lentidão,

não permite mais...

Assim, "Vamos marcar
uma reunião de blueprint".

Ou, em uma semana, todos 
os executivos numa só sala...

Não dá mais isso, não dá mais.

Mesmo que tranque,
está todo mundo ali offline, né?

Nós vamos contando 
a história e caminhando,

porque já temos que entregar,
já temos que mostrar valor.

Outra coisa, as margens de lucro
das empresas reduziram muito.

O mercado está muito mais apertado,
a concorrência está muito mais...

Antes nós falávamos de qualidade.

Você tinha um ou dois que tinham 
uma qualidade absurda,

e a concorrência começando aqui,
com uma qualidade completamente diferente.

Hoje equiparou.

Então, assim, a divisão no mercado
está muito mais apertada,

e aí, se você não entrega rápido,
o acionista já começa a falar assim:

"Eu não vou colocar dinheiro aí
se eu não tiver retorno rápido".

- Andando junto com a entrega, né?
- Eu preciso realizar rápido.

Então eu acho que não morre, 
perde força, e tem que se reinventar,

como tudo que está 
acontecendo no mundo hoje.

Ou nos reinventamos
ou vamos ficando obsoletos.

Eu até dei um exemplo 
para o Ronqui antes daqui

quando estávamos tomando 
um café, num papo informal lá,

falando que eu comecei um projeto 
desse chatbot que eu comentei aqui

com uma empresa que era 
número um do mundo...

E, durante a implementação,
ela ficou obsoleta.

Ela passou a ser nem a quinta do mundo.

Olha, a concorrência, hein?

Às vezes não é que fizeram algo errado lá.

É a concorrência, né?

É assim, de tanto criarem novos produtos, 
melhorar, atender demandas de mercado,

porque a pandemia trouxe isso,
a pandemia acelerou,

ela veio com problemas 
que precisava resolver...

Por exemplo, o cara que não vendia...

E eu tenho amigos...

Assim, isso vai do pequeno ao grande.

Eu tenho amigos que eles vendiam
roupa para nenê numa loja física,

uma loja física tradicional 
em Vargem Grande Paulista,

perto de Cotia, no interior de São Paulo,

Uma lojinha pequena, que vendia ali, 
todo mundo bem, sobrevivi.

Veio a pandemia,
a loja deles não vendia.

Eles tiveram que se reinventar,

arrumar um software, colocar 
na internet, não sei o quê...

E hoje a loja não abre mais.

A loja física não existe mais.

- Então, assim...
- Que interessante isso.

E o negócio está vivo?

Estão vivos e muito melhores 
do que estavam antes.

- Que legal essa história.
- Então você vê a transformação...

De tudo que vai acontecendo, né?

E esse foi ágil, com certeza.

É que às vezes ele nem percebeu, né?

- Ele nem percebeu.
- É, porque é um pequeno comércio, né?

Eu gostei do conceito de você ir
implementando aos poucos,

porque, na realidade, você vai
treinando as pessoas na demanda

sem que você fale: "Vamos 
colocar uma meta aqui".

Tem gente que se assusta quando você 
fala: "Não, vamos fazer isso aqui ágil".

O cara:

- "Não, vou sofrer...
- "Não, ágil não!

- Não, não sei o quê...
- É sem vida.

É sem vida".

O pessoal vai mudar o escopo toda hora".

Se você faz de pouco em pouco,
a coisa vai fluindo,

e, naturalmente, vai embora.

E aí, Pantolfi, até para somar a isso,
uma conversa que nós tivemos uma outra vez

também foi nessa linha.

Tem que tomar um cuidado também 
para que, de alguma maneira,

não vire uma pastelaria, né?

Também tem que ter 
uma boa gestão ali na frente,

e falar: "Tudo bem, é flexível, 
aqui é o escopo...".

Eu acho que você deve concordar, ou não.

Fique à vontade.

Mas até um certo nível, né,
senão também se sacrifica a equipe,

o famoso "dev team" ali.

Quando você vê, você 
não tem mais ninguém, né?

O que eu acho muito louco...

Ou flexibiliza tudo?

Fique à vontade, tá?

Não, eu acredito que cada caso é um caso.

Eu tive um cenário,
especificamente em 2010,

onde fizemos um projeto
para a Secretaria da Fazenda,

na época, eu trabalhava 
numa consultoria,

e lá, eles já tinham como pedido 
a utilização de Scrum

com o método ágil, cultura ágil.

Então nós tínhamos todos 
os papéis, tudo certinho.

Só que o nível de documentação
que a própria entidade,

por ser governamental, precisava,

divergia daquela 
documentação mais enxuta

que buscamos até no ágil.

Só que aí, o que nós entendemos?

A documentação para eles...

Então não vamos fazer
uma história, uma user story.

Nós vamos fazer um caso de uso detalhado,
passo a passo, interação homem-máquina.

Só que, mais do que isso, temos 
uma estrutura que cria essa documentação,

porque ela é uma entrega para o cliente,

e depois que eu tiver ali um cenário 
acumulado de pelo menos três meses,

esses requisitos se tornam 
insumos de entrada

para começarmos a rodar, 
de fato, os times Scrum,

e aí sim, entregando 
o desenvolvimento em sprint.

Inclusive é um exemplo de modelo híbrido.

Mas eu acho que o ponto principal
em relação a essas expectativas,

como isso vai acontecer, se vai ser 
a entrega que eu estou querendo,

se eu tenho que respeitar 
um time e tal...

Na vivência real ali, né, em campo.

É. Eu brinco muito 
com a questão da realidade.

Porque na prática, se você 
observar a maioria das empresas,

especialmente projetos grandes,
você tem lá o cronograma,

aí tem todas as atividades, com data 
de entrega, tudo direitinho, a sequência.

Muitas vezes é usado aquele pequeno 
semáforo verde, se está tudo bem.

Amarelo, ponto de atenção,
vermelho, já deu ruim e tal.

E aí, o que começa a acontecer?

Eu já reparei em inúmeros lugares 
que a tarefa está lá, 75% pronta.

Legal.

Aí, na semana seguinte, ela está 80% pronta,

na semana seguinte, 90% pronta,
na outra semana, 99% pronta.

E aí ela está num percentual altíssimo 
de pronta, e nunca está pronta.

Então, no final das contas,
as pessoas querem a expectativa,

mas essa expectativa está 
constantemente sendo quebrada.

Então é muito mais um documento
para ficarmos gerenciando as dores,

e trazendo a sensação que está toda hora
devendo, do que qualquer outra coisa.

Como eu normalmente trabalho 
isso dentro de uma empresa,

já trazendo para a cultura ágil?

Eu começa a mostrar...

Você nunca acaba o projeto, né

Se você também for flexível ao ponto 
de vai me mandando, eu vou fazendo...

É sem fim, sem data.

Mas eu acho que mais que isso, eu começo 
a trabalhar aquelas expectativas de datas

com aquilo que, de fato, está entregue.

Ou é sim, ou é não.

Está pronto, o cliente pode usar.

Não está pronto...

Não importa se está 99% pronto.

Não está utilizável 
ao nível que se esperava.

E junto com isso, eu direciono muito,
inclusive a equipe estratégica,

para sempre revisitarmos o planejamento
com base naquilo que já está pronto,

naquilo que já está operacionalizando,
e assim por diante.

E sempre trabalhando para você não ter 
só as suas métricas e os seus resultados

no final do projeto, mas você 
já os ir criando no começo,

porque toda pressão, toda a preocupação 
com essas expectativas, vão reduzindo.

Porque... "Ah, eu tenho um lançamento 
aqui de um mobile banking".

Então tem algumas 
funcionalidades básicas ali,

do saldo, extrato, transferência etc.,

que precisam estar no aplicativo.

"Ah, mas eu tenho uma parte
de investimentos, outros módulos aqui...".

Até e-commerce é muito comum hoje em dia.

Que não necessariamente precisa 
estar nessa primeira versão.

Então, legal, entrego 
aquela primeira versão,

a operação já começa a fazer contato
com os clientes, começa a fazer download,

começa a fazer cadastro, começa
a utilizar, começa a movimentar

e antecipa o que seria uma operação
para acontecer só lá no final.

E aí a empresa já vai gerando 
resultado em cima daquilo.

Quando eu tiver pronto...

Esse é o ganho.

- ?
- Exato.

Tanto que, se você for avaliar, tudo quanto 
é aplicativo quem usamos no dia a dia

já passou por esse processo, e volta e meia
tem atualização, tem novas funcionalidades.

Através dos feedbacks que ele 
vai recebendo, ele vai atualizando.

- Exato. 
- Tem o Product Manager gerenciando ali.

Exato, exato.

É o Product Owner na verdade.

Isso.

Que é aquele que fica ligeiro ali.

Vamos ver os feedback para ? vivos.

Mas pegando o gancho aí, você não 
acha que essa cultura da cascata,

que temos enraizado, principalmente 
nas pessoas que já trabalham,

já tem há um longo tempo, não criava 
um buffer, um conceito de buffer,

de falar assim:
"Bom, eu tenho que entregar isso.

O primeiro objetivo é entregarmos 
esse projeto esse ano.

Vamos construir uma fábrica nova".

Então as pessoas colocavam os seus 
bufferzinhos lá porque elas sabiam...

"Olha, em teoria...".

Até já trabalhamos juntos, 
nós sabemos disso.

Aí ia lá e falava assim: "Eu vou 
fazer a configuração no sistema".

Em teoria, dura cinco dias.

Mas na hora que você 
vai fazer a configuração,

aparece um Frankstein no sistema, que você
não sabe o que aconteceu, e dura 2.

A operação vai acabar, né?

Exato. Aí você vira a noite,
vira sábado, domingo.

Eu ia colocando aquele negócio.

Aquilo vai ficando cada vez mais inchado.

E aí às vezes o cara já está
com a tarefa pronta,

mas ele vai colocando 99,9,
para chegar no dia ele falar: "100"...

No modelo lá.

Quando vamos com o ágil,
quebramos tudo isso.

Não, espera aí, entregas curtas, todo 
mundo alinhado, está todo mundo vendo...

- O que está acontecendo...
- Eu vou sentindo, eu preciso fazer...

Eu entrego um pedacinho...

Se eu estou enrolando,
eu estou enrolando...

O cara está vendo que eu estou enrolando.

Não tem como enrolar.

É tempo real.

- É falar se eu fiz ou eu não fiz.
- A entrega.

Amanhã eu tenho que entrar e falar assim:

eu resolvi o problema do dia anterior
que nós conversamos.

Eu mostrei aqui o que eu fiz,
e já estamos discutindo o novo.

Ou seja, não tem como eu...

Não tenho 99,9.

É ou não é?

É preto ou branco.

Não tem esse meio termo.

E as pessoas ainda estão, 
na minha visão, relutantes de...

"Como que eu solto esse buffer, 
essa proteção, esse negócio,

e passo a entregar, e passo a viver,

e falar se eu tenho um problema,
eu associo isso

a duas problemáticas naturais
e às vezes até subconscientes.

A primeira Ah, eu tenho um método aqui,
mas não sei porque que ele existe.

Não sei pra que ele foi criado.

Não sei por que eu tenho que fazer
cerimônias,

não sei por quê, porque por
porque não sabemos o por quê.

Essa normalmente é a primeira

e a segunda e não sei quais problemas
eu tenho que resolver.

Não sei quem é o meu cliente final,
não sei qual é a experiência que ele passa

no final.

Então eu tive uma experiência
muito interessante de pegar um time

que tinha que construir
todo um ecossistema de meio de pagamento,

que é um conhecimento muito específico,
muito, muita parte.

Normalmente você não tem cursos disso.

Quem trabalha na área

e nenhum

dos desenvolvedores, apesar de serem
desenvolvedores de ponta, conheciam

integração contínua, auto scaling,
coisas de alta performance, mesmo.

Eles não conheciam
o modelo de negócio de meios de pagamento

e a gente tinha dores muito específicas
para resolver.

Então que o que eu fiz
a primeira conversa com eles

foi beleza, o que é meio de pagamento?

Então aqui estão que vamos falar de código
que te esquece, código

que tem que ter a bandeira
aqui tem o banco,

aqui tem o gato e o PSP
tem aqui ao o serviço

para cartão de crédito,
aqui funciona autenticação para débito.

É que o sistema inteiro para loja
aparece desse jeito para se dar aquele

a experiência assim. Beleza.

Entenderam melhor?

Lógico que isso foi gradativamente
para uma sessão de duas horas.

Exato.

Só que aí o que foi interessante,
o pessoal começou a falar Cara, beleza.

Então, mais do que a tarefa

que eu tenho que construir
agora, eu entendo porque aonde, como?

E aí começa a simulação.

Beleza, o nosso cliente?
Qual dor que ele tem?

Então hoje ele vai cadastrar
uma conta de pagamento.

Ele começa aqui, muda de tela,
recebe dois e-mails, faz uma notificação

aqui, faz isso aí o próprio focar
que revolta, não no nosso cliente.

Ele tem que querer
muito ser nosso cliente.

A gente tem que melhorar isso pra ele.

Então você criar essa cultura pro time
começar a sentir a dor

do cliente e pensar.

E muitas vezes era engraçado o produto,
a alma da tela tinha uma visão muito legal

do que priorizar de como fazer.

Isso ajuda, mas o time contribuía.

O produto

só tem esse conjunto aqui
de funcionalidades.

Acho que dá para gente aqui
tecnicamente já separar para você

já entregar para o cliente lá já diminui
essa dor.

É uma sinergia,
começa uma colaboração mútua.

Mas perceba o tamanho do trabalho que dá
para você construir a cultura com o time.

A maioria dos produtos
já chega aqui com um script pronto.

Pessoal, vocês tem que fazer isso, isso,
isso e isso vai.

E muitas empresas que não tem a cultura

precisam fazer isso,
isso e isso é o prazo, é esse ai, cadê?

Cadê a colaboração dos dois lados aqui?

Então constrói junto. Exato.

Então eu costumo dizer quando eu te falei
métodos ágeis são frameworks,

então eles têm ali princípios básicos,
mas permitem adaptações para você

se adequar na sua cultura.

Mas o ponto principal é você
tem que respeitar os princípios

para poder extrair
os melhores benefícios dele.

Ah, aqui tenho uma adaptação e de repente
eu não faço uma cerimônia ou outro

alguma coisa. Cara, não tem condenação aí.

Só que entenda
se os problemas que você está

tendo de não fazer não estão atrelados
ao fato de não seguir alguma coisa.

Até eu trazer mais uma polêmica.

Agora a gente, afinal,
quando que eu sei que trabalhar com ágio

vai ser um problema?

Ou trabalhar a culpa em mim
vai ser um problema que ninguém tem?

A resposta fez.

Mas por que vocês entram nessas conversas?

Nós podemos falar assim,

mas assim.

O que acontece muito que eu
vejo você por três prints

pequenos, dependendo do projeto,
e a grande maioria tem esses pequenos,

você vai colocando naquele profissional
vários projetos, vários

e a maioria são pessoas muito jovens
que querem ter essa experiência.

Então elas querem pegar vários projetos,

que quer programar, que quer fazer,
que quer entregar, que quer participar

e isso dá um crescimento
num primeiro momento muito bom.

Só que satura,
porque o cara está o tempo todo

no fio da navalha, está o tempo todo
entregue, entregue.

Ele resolve o problema e volta e faz
e não sei o quê.

E o pessoal coloca mais e coloca mais
e coloca mais e coloca mais.

Chega num ponto que o cara satura.

Quando a gente fala num modelo de cascata,
ele tem picos.

E você sabe, eu sempre digo assim
você sabe quando vamos subir a

quando vamos descer?

Quando você sabe por quê?
Porque tem o ciclo de teste.

Você está vendo, Você está terminando
uma fase, então você está mais suave.

De repente você vai no pico.

Aí de repente, CDS um pouquinho de novo,
de repente vai.

Aí você chega no Realize no seu,
que entregou o projeto.

E eu vejo que hoje
nós estamos saturando muito

por demandar muito da pessoa, por querer.

O vaso cheio sempre entrega a pessoa.

É exato, é que entrega a pessoa.

E aí também outro lado que o que eu falo
é que se você satura demais,

ele perde a inovação, ele perde o ponto
de que perde um pouco da qualidade

porque está preocupado em entregar
e perde o lado da inovação

porque ele está tão saturado
que ele não consegue vir propor, falar.

Se a gente falou eu tive um caso
que a gente tava falando assim,

o usuário entrava,
apertava o botão na tela porque?

Porque estava do lado direito, certo?

Então, em vez de ele ler o texto,
ele pede para passar.

Aí o cara que estava desenvolvendo
falou assim Se a gente colocar

o botão do lado esquerdo,
falamos qual a lógica de ser flow?

O cara vai entrar, olhar a tela
e ele primeiro vai ver o texto e aí

ele vai procurar o botão.

E assim, só essa mudança mudou
o programa completamente.

O cliente ficou feliz, falou ah, mudou
a performance, mudou tudo.

É mais assertividade,
porque a gente tá processando fatura.

E aquilo era como era sumamente importante
ler aquele, ler aquele trechinho ali

para interagir com ele.

Como dava para direito
o botão com o açúcar está saturado

e não consegue ter esse insight
porque ele está no limite dele.

Você falou isso para mim já é uma vez.

Tem que ter um tempo para ele
dar uma respirada e não fazer nada.

Eu já trabalhei aqui para copiar,
para inovar,

para trazer algo novo,
porque de cansado você não faz.

Eu acho que eu sou muito suspeito,
porque assim todos os cenários que

ou que eu consegui fazer,
eles acabaram dando muito

ótimos resultados e todos as partes
gostaram.

Eu diria que é o método Agile,
não é uma fórmula mágica.

Estou aqui e está tudo resolvido.

Assim que eu vi isso,
eu vou dar uma pausa e anotar,

assim como assim como uma dieta não é

a fórmula mágica para você perder peso,
assim como um investimento na bolsa

em uma ação específica
não é a solução da sua vida financeira.

Tudo depende de como você usa
garfo e faca.

Você pode usar para comer,
você pode usar para matar.

Tudo depende de como ser usado.

É muito bom, mas ao vivo pode ser.

Então acho que vem muito disso.

A gente tenta trazer uma cultura nova
para resolver um caos que existia antes,

mas há o olhar caótico,
seja de quem está no ponto de decisão,

seja de quem está definindo
prazos, demandas, etc.

Ele continua sendo o mesmo, muitas vezes
não só desrespeitando a cultura,

mas pequenos detalhes

como deixar o time respirar,
deixar o time ter insights mais adequados

para chegar naquilo que é mais importante
ou ter uma visão mais assertiva.

Hoje em dia existem aí
uma biblioteca de dinâmicas que ajudam

isso benchmarking, brainstorm,
me, enfim, etc.

Que você pode utilizar, complementando aí
o seu dia a dia com times

para tornar o dia a dia mais leve,
mais criativo,

mais dinâmico
e trazer o time para essa cultura.

E isso de tornar mais leve o time,
mais participativo e equilibrar os pratos.

Como eu falei no começo,
sustentabilidade e produtividade

não só um, não só o outro,
é o que faz o time ter mais saúde,

ir mais longe, ter uma produtividade
contínua com menos interrupção

e entregar valor
e ser cada vez mais participativo

daquilo que resolve a dor real do cliente.

Então, ao meu ver,
mais do que um método ou outro método,

é você
é encontrando a melhor forma de executar.

Agora
sim, no Agile, historicamente falando,

ele veio para você poder fragmentar
os problemas.

Os problemas vão acontecer,

não importa.

O método de projeto segue o mesmo.

Exatamente.

Então e como
você lida com esses problemas?

Está mais próximo e mais próximo?

No centro do mundo integrado,
ele percebe coisas que você não perceberia

no método anterior e com o cliente.

E você colocou um ponto muito importante
a transparência.

Ela é a base.

Inclusive
ela é um dos pilares do próprio Scrum,

que foi o primeiro método
que a transparência, inspeção, adaptação

e transparência.

Normalmente ele já é o primeiro

ponta de corte

para você definir quem vai conseguir
trabalhar com o método ágil ou não falou?

Então transparência é tudo, não
só entre o time para todos os envolvidos.

Gente,
não precisa mentir, né? Só amizade. Mas.

Mas a gente ainda vive nas empresas
com essa cultura.

Então, mas esse é o ponto.

Muitas vezes, a depender
de onde você está, você é transparente.

Algumas pessoas te colocam chapéus,
ninho de resistência, de punição.

E aí quando você cria isso, aí
você praticamente faz com que o time não

se sinta à vontade para ser transparente,
que é o oposto do que a gente quer.

É o cenário total. Foi criado, alinhado.

Uma coisa que eu vejo assim
nós estamos ganhando confiança

é quando você ganha confiança.

Você consegue ser transparente,
porque você vai com qualquer você.

Exato.

Eu estava comentando
de uma experiência pessoal minha

que me convidaram
para assumir uma role global

para implementar um processo

de fatura eletrônica com quatro pessoas.

Aí eu falei Olha, é impossível.

Global
não fala nenhum pai possível em um ano

com quatro pessoas
eu consegui ter êxito assim.

Então,

acho que à medida que você vai ganhando
confiança do que você está fazendo

e aí você transmite essa credibilidade
para a rede

ou para as pessoas que trabalham negócio
também.

Você consegue ser realmente transparente
e verdadeira

e dizer olha, não dá, não vamos
nem começar, não dá, Mas eu quero.

Então esse é justamente o ponto
você precisa criar um ambiente

que favoreça isso.

Porque não adianta você falar eu estou
usando métodos ágeis e você está toda hora

sabotando essa confiança,
essa experiência.

Eu posso dizer
que algumas das melhores características

e algumas das melhores contribuições

vieram muitas vezes das pessoas
menos experientes no time,

porque elas se sentiram à vontade
de trazer ideias e gerou até mudança ali.

E elas tinham isso foi diferente.

E aí você recebe a ideia da pessoa,

mesmo que ela, num primeiro momento ali
pareça quebrar o fluxo de trabalho

ou criar uma mudança muito drástica,
você acaba transforma aquilo numa ação.

O time gosta, aceita, cara,
você criou aí uma cultura maravilhosa.

A partir daí, as coisas tendem a cada vez
funcionar melhor.

O ponto era dar uns seis falando aqui
eu estava dando uma refletida

e nós abrimos o podcast
trazendo dois grandes profissionais.

Vamos falar bastante de ágil aí
talvez só no falar.

É hoje que eu vou fazer em duas linhas.

Quando eu uso o Ágil, quando eu uso P+,
quando eu uso híbrido,

não é uma frustração
você que está nos escutando,

se não conseguiu, sai com essa definição,
porque aqui não era esse

o objetivo, o objetivo era explorar mesmo.

Então, desse ponto de vista

que Ronaldão plantou e trouxe para nós aí,
como é feito no dia a dia?

Não, não tem um fluxo.

Pelo menos se alguém tiver e traz,
segue esse fluxo fluxograma que você

sabe quando é ágil, quando não é,
quando é cascata, não existe.

O que existe é saber
lidar com pessoas, trabalhar com pessoas,

entender o que seu cliente quer
está próximo a ele, no centro,

como ponto você falou agora, trazer também
um clima favorável.

E aí, depois de tudo isso que você fala
e agora, o que eu faço da minha vida?

Estudo que eu estudo?

E aí nós estamos falando nossos estudantes
aqui,

se preparando no mercado de trabalho,
já estão querem evoluir.

Se pudesse deixar que assim a gente
pudesse ficar horas, horas, ia virar

talvez um filme.

O teste aqui não existe termo,
é só para descontrair.

Fica um disclaimer esse termo
acho que nem existe mais

para a gente tentar deixar uma dica
pra quem tá nos escutando.

Vocês darem um de dicas para os estudantes

estudar o que

ajude, estudar o P+,
tudo isso tudo ou tenha calma,

deixa fluir, ganhem experiência

que cada um poderia deixar uma dica final
para nossos alunos aí.

Olha,
eu diria como um conselho de pai na boa,

um conselho de pai fala assim,
aproveita um pouco de cada coisa,

não coloca esses rótulos,

não coloca sacarose,
não aproveita um pouco, se joga, entendeu?

Participa mais assim.

Uma das coisas que eu sempre penso.

Vai profundo, aprende, testa,

vivencia aquilo para você realmente

sentir o que sai
um pouco da teoria e entrar na prática

e ver na prática
como é e tirar o proveito disso.

Então assim nós estamos no mundo
que é perfeito para isso

a gente, no meu tempo,
quando eu comecei não existia isso.

Você ia aprendendo uma coisa
que levava dez anos para mudar.

Quando mudávamos, eu dava uma cor da tela,

saía da tela preta
lá do da cabeça de lata,

que a gente tinha uma tela
mais coloridinha, azul e branco.

Dois anos e não acontecia mais nada.

Hoje, o jovem tem um mundo para ele,
para mergulhar,

ele se aprofundar, para ele experimentar.

Ele tem que fazer e está disponível,
está disponível, é grátis,

tem vídeo na internet,
tem uma série de coisas que permite

com que ele realmente fale assim
eu consigo crescer muito rápido,

eu consigo realmente me aprofundar
em temas, eu consigo desenvolver coisas,

eu consigo errar e voltar rapidamente
a outras experiências.

Então você aproveita esse momento
e tira esse peso das costas,

tira essa coisa de falar assim
eu preciso ser assertivo, eu preciso

ser bem sucedido,
Isso vai acontecer naturalmente.

Isso vem montando um pouquinho
em cima de pouquinho.

Então eu acho que a mensagem final
seria isso Aproveita, se joga.

Vocês estão num momento fantástico da vida

e aí a gente
fala que o primeiro sobrecarrego

e enquanto isso o outro fica calibrando
onde eu vou me encaixar aí?

Mas eu sei que você manda bem também.

Qualquer dica que você deixa aí eu
acho que complementa a isso do exercício,

do teste, da validação, de sentir
o que funciona melhor, o que não funciona.

E justamente a gente
é respeitando as pessoas.

É o que eu costumo dizer
a respeitar as pessoas.

Não é só dizer bom dia, boa tarde,
boa noite, Respeitar as pessoas

é ouvir as referências que ela tem,
as experiências que ela tem.

Por que que naquele lugar existe
uma cultura específico,

por que naquele lugar

as pessoas fazem as coisas de um jeito A,
de um jeito B e ao mesmo tempo

buscar aprendendo com as pessoas
e sendo a pessoa que tem menos vícios

para poder enxergar de repente
algo que pode ser melhorado e contribui.

Isso sempre de forma construtiva.

Quanto mais construtivo, colaborativo
e quanto mais você respeitar as pessoas,

mais você vai entender onde você está
e quais os próximos passos

que você pode dar dentro da experiência
que está construindo,

dentro daquilo que você está
experimentando,

para justamente resolver os problemas
certos,

sempre pensando em resolver
aonde está a maior dor primeiro

e depois resolver aquilo que te torna
mais confortável no contexto

que está fechada.

Eu fico feliz que sempre alguém fala
assim Para fechar eu não preciso.

O meu papel aqui é só intermediar
que será o terceiro e ser quase impossível

agradecer. E vocês?

Todo esse contexto,
somente essa fala final.

Deixar uma dica que todos nós já passamos
por uma mesa de estudante.

Na verdade,
a gente continua sendo vocês alunos.

Vocês não sabem aprender
é uma coisa contínua.

Já passamos pela graduação,
mas talvez se pudesse voltar,

a gente curtiria novamente o momento

novamente e

a agradecer tal convite a isso
ter aceito até mesmo transmitido

da sua experiência conosco. Obrigado.

Obrigado a você, Rafa.

Não todas as pessoas aqui envolvidas
temos uma grande produção aqui por trás

e obrigado
especialmente a você que está assistindo.

É sempre muito especial
esse momento, essa troca, o compartilhar.

A gente aprende sempre um pouquinho
mais aqui também

e muito sucesso
na sua carreira, nas suas escolhas.

E ainda dá um obrigado mesmo também
você para ter aceitado o convite,

Até mesmo seu tempo na empresa aí, ou
talvez não estaria no interior agora, né?

Eu que agradeço.

Agradeço ao FIAP através de você, Rafael
Roque, que me convidou para conhecer,

espantou se a você que está nos assistindo
e toda essa equipe

que está por trás, por essa oportunidade,
por essa troca de experiência.

Eu acho que a gente cresce com isso.

Obrigado pela oportunidade.

Obrigado por estar aqui,
me ligar, ligar, contou F.

Depois de falar tanto sobre o ágio,

você tem que entender que não é somente
sobre velocidade e sim também

assertividade, qualidade
está sempre próximo ao seu cliente e.