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á, tudo bem com vocês?
Olá, Rafa! Olá, pessoal de casa!
Meu nome é Robson Pandolfi, 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 pelas palavras.
Tenho certeza que não vai faltar
experiência na conversa aqui.
Estou aqui também com o meu
grande amigo Adam
e já era da hora, como vocês sabem muito bem.
Obrigado, Rafa,
pelo convite e 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 toda
e aí eu começo já com Z
apimentar essa conversa.
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,
mas um dos dois vai
conseguir dar essa soma.
Vamos lá, eu vou fazer
uma introdução aqui.
De forma geral,
tudo o que a gente fala 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
era uma visão mais moderna
de como a gente fazia gestão e
desenvolvimento inicialmente 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 a gente tivesse 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ê que trabalha em TI,
se prepara que final de projeto
Você não tem feriado,
não tem final de semana, não tem madrugada, Você vai se matar pra entregar idade
e coisa.
Mas. Mas isso 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
é porque no projeto tradicional
você ia, tinha lá um projeto de um ano,
você construía tudo de uma vez e entregava
no finalzinho aqui para o cliente.
Nesse momento você já tinha mudança
de legislação, mudança
de regra de negócio, funcionalidade
que já não fazia mais sentido.
Portanto, nesse tempo de um ano,
exatamente de idade.
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 a gente
vai fazendo pequenas entregas para a gente
fragmentar os problemas de um projeto
e 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,
ela busca
justamente respeitar essa cultura
e buscar esse equilíbrio
entre produtividade, sustentabilidade
e tendo o cliente no centro.
Então, acho que um dos principais pontos
que 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 eu pensei
usando o método antigo da cascata,
falar assim eu preciso construir uma casa.
Tinha um projeto
que eu morava na Colômbia,
falei Deixei tudo certo com arquiteta,
vai lá, beleza.
Quando eu voltava a morar na casa,
quando eu voltei,
a planta que eu tinha feito era uma.
Estava bem, a entrega era outra,
a entrega era expectativa.
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.
Então assim são.
São vários pontos que a gente tem aí
a favor desse, desse.
E o mundo evoluiu também.
Não dá mais para seguir
como a gente estava no passado.
Tão tradicional, tão tradicional, só isso.
Eu estava comentando com o Rafael aí
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,
é se você demorar para implementar,
ela já está obsoleta.
Então isso não existia no passado
e a gente tá falando de passado.
É muito difícil jogar
uma pimenta na conversa,
que, eu tenho certeza, vai sair bem.
Aí você ajuda.
Até apontou o que foi prévio
aqui ao nosso nosso início,
mas é uma pessoal, não é nada treinado.
Foi uma conversa de uma conversa
de cafezinho só pra abrir o que vai rolar.
O ágil prega que realmente
se a gente fizer, vamos em sprint,
Vai ser um período de um ano.
Você cria vários sprint, você vai estando
próximo do cliente conforme a cartilha.
Lá realmente você consegue entregar
com mais qualidade, mais assertividade.
Mas e aí, como que é isso
No dia a dia, mesmo vivendo na empresa,
assim como você vive realmente
o que está escrito lá?
É fácil assim mesmo, pô, se é ágil,
então realmente 100% conforme pediu
e na qualidade esperada, como quer no dia
a dia.
Na verdade pode ser, mas não,
na verdade não é assim.
E é quando a gente fala assim
se a gente não coloca o cliente no centro
realmente e ele entende realmente
o que ele quer e existe essa comunicação
e tudo isso é muito fácil de se perder.
Então assim a pessoa que desenvolve
eu sempre
veja, assim ela desenvolve,
ela quer desenvolver, ela quer.
Quanto mais próximo do computador
e programando melhor.
E essa parte de reunião e comunicação
é tudo, eles fogem, querem fugir um pouco,
mas precisa entender que essa comunicação
o cliente é importante.
Porque?
Porque o cliente talvez não
não consiga visualizar o produto
e essas interações
pequenas que a gente tem 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 traz ele junto
e não vai contando a historinha para ele,
dia a dia, é muito fácil de se perder.
Então, assim, quando a gente está falando
de grandes empresas, de projetos e tudo,
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 squad
ao mesmo tempo, 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, para voltar atrás.
Já só o tempo já passou,
o dinheiro também já se consumiu,
já se gastou,
estressou equipe, pessoas e empresas.
E esse é outro ponto que
que o stress da equipe também.
E é algo que acontece se você não tem
essa harmonia entre gestão.
E aí ele falou aqui se colocar o cliente
como o centro do projeto,
o centro das atenções, isso agrega.
Talvez consiga realmente
ter mais assertividade.
Como que 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 a 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
se do princípio que,
na verdade, métodos ágeis como um todo,
mas especialmente o Scrum, a estimativa.
Quem define o quanto a gente vai executar
dentro de cada sprint,
sendo sprints de duas semanas?
Três.
Mas dentro daquele tempo,
o quanto a gente vai construir?
Ela é uma definição das próprias pessoas
que estão com a mão na massa
de quem está construindo. Fato.
Eu acho bom,
só que muitas empresas ainda tem muito
aquela filosofia de comando e controle
que reinou especialmente
a década de 70 e 80,
mas até hoje ainda está por aí.
Assim, quem vai desenvolver que vai ditar
como o boom vai tocar.
Então, assim,
tem muita empresa que até fala assim não.
Aqui a gente respeita a cultura ágil.
Você pode estimar.
Só que o prazo para você entregar
o projeto é esse daqui.
E aí, a partir daí
você já cria várias complicações.
Você começa a não respeitar
os problemas que o time pode
passar, como durante a execução
compromete a qualidade.
Hoje em dia, em época de LGPD,
se pode comprometer a segurança.
Se 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 90
e começo de 2001 entidade global chamada
System desse grupo, que é uma entidade
de pesquisa de projetos de tecnologia.
Ela chegou numa conclusão, num catado
aí de pesquisa no mundo inteiro,
que cerca de 20% daquilo que era produzido
nos projetos em geral era realmente
o que era o core, aquilo 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 do que era produzido.
E aí, beleza? Como que 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.
Você coloca 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? Então,
mas será que não ajuda?
Cada um falou talvez.
Não é legal que você trouxe aí o cliente?
Como você está no processo de menos código
e sim, está pronto para entender mais.
E aí você está mais próximo,
fala na vida real
e a gente tem que contar aqui
o que acontece na prática.
Essa gente quer ouvir, viu?
Eu coloco aqui
quando eu faço aqui a gente coloca,
você coloca o cliente no centro e aí
o que acontece?
Ai outro cliente muda,
o cliente muda, chega outro cliente
para substituir uma posição,
olha o projeto e tudo e fala assim
não era bem isso?
Então é assim, esse é o foco.
O que é que eu quero?
O que é que eu preciso?
E uma das coisas que eu tenho visto aí
quando a gente fala de 12 sprints,
a gente entrega melhor, entrega melhor
e aí vai.
Às vezes, enquanto você está
desenvolvendo, entregando,
já está surgindo
alguma coisa nova para o segundo sprint,
que você precisa estar
atualizado e antenado,
porque assim o cliente sabe disso
e ele vem até você e fala assim
já tem isso aqui e a gente, então sim,
você tem, é dinâmico, é muito dinâmico
nessa interação o tempo todo e
tem que estar sempre com uma escuta ativa
e é isso que eu falo,
o princípio de tudo, essa conversa,
esse feedback, o feedback.
Ele tem que ser real,
ele tem que ser construtivo.
Mas é, mas ele tem que existir,
porque se não a gente tem surpresas
na entrega.
E ainda no gancho do cliente no centro,
o cliente tem que estar no centro
porque é ele
que financia, é ele que direciona a gente
aonde a gente tem que chegar, tudo certo.
A questão é se esse cliente, ele faz parte
dessa cultura também, da cultura
ágil ou não.
Então você é um excelente
desde a primeira formação do produto.
E tem um exemplo que eu acho muito legal,
que é o seguinte Imagina, Rafa, aqui
você é o nosso cliente,
eu cuido da logística.
Nadal vai cuidar do produto em si
e você encomendou pra gente
um bolo, Beleza, Você tá lá.
Já com a festa pronta,
você tem um momento para chegar o bolo,
a gente está com encomenda entregar.
Ele entregou o bolo em perfeitas
condições, eu peguei o bolo.
Eu tenho combinado com você
de 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 e o bolo
está todo bagunçado, todo quebrado
e você não entende o que aconteceu.
Se já tá louco da vida porque chegou
atrasado, chegou com problemas,
essa é a situação.
A situação B
Eu fui buscar você, você foi comigo
e a gente retirou o bolo juntos.
A gente foi para lá na sua festa.
Só que você viu que a gente
teve um acidente na nossa frente.
Seja um motoqueiro,
um cara assim. Eu tava.
Nem precisa ser um monte de fatores
que não dava pra evitar
e assim por que participei nesse caso
e nesse caso você estava dentro do táxi,
você tá 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 o cliente que está dentro
não quer dizer que na situação B
você não se sentiria frustrado.
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 dimensionar e minimizar o impacto,
exatamente pra gente diminuir essa dor.
E aí, nessa linha,
eu trouxe mais um ponto aqui para vocês
Vai começar um projeto aí está alinhado,
vamos fazer aí definido.
Você vai fazer no ágio
ou vai fazer cascata?
Por mais que seja talvez um modelo
híbrido, como é que essa negociação?
Como você tem aí que vai entregar
um produto que seja interno da sua empresa
ou para um cliente e negocia
isso porque tem essa visão, você que acha,
mas ele está preparado para receber
um projeto,
Você tem alguém para designar
como Product Owner?
Você sabe o que é um valor?
De como é que essa negociação?
Como vocês estão vivendo isso?
Eu acho que depende muito
do tipo de projeto,
por exemplo, do negócio
vale muito com esse app.
Quando a gente fala com esse app RP
não tem muito o que discutir.
Modelo de cascata
serve, funciona. Perfeito.
Então que é perdão,
Não é porque o cenário que vamos gerar
é conhecido como contestável,
sistema instável.
Todo mundo sabe o que tem que fazer
no tempo só pra dar o brilho
no tempo que tem que entregar.
Então assim funciona. Perfeito de vai.
Agora,
quando eu vou desenvolver alguma coisa
que eu preciso, precise dessa interação
com o cliente, tudo.
E aí você vai pra um modelo ágil, Quer
que esses exemplos do bolo são perfeitos?
Essa participação
quando eu, principalmente, por exemplo,
a gente desenvolveu um chatbot
que interagia com o RP,
era uma coisa nova,
uma coisa que não tinha no mercado
naquele momento, que a gente fez isso.
Então você precisava estar com o cliente
o tempo todo, porque até para ter certeza
do que ele estava pedindo e do que a gente
estava construindo, estava adequado.
Era aquilo que ele queria
e a gente teve 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 acho que não, você não é tão formal
na minha visão de falar olha, chega
e fala bandeirinha do Ajax
é um e-mail mais do que isso.
Mas você agora, aí o PM,
eu concordo plenamente.
Se 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 pra um lado, o outro para o outro,
viés diferentes.
Tudo é um pouco complicado de lidar, né?
Que eu penso assim.
Vivi agora pouco menos que aí
quando você quer.
Mas sabe o que é um Product Owner?
Porque? Como assim é que eu preciso?
Vamos dizer,
alguém que seja responsável pelo produto
para não falar muita pequenez.
Não tem uma pessoa que descubra
um junior aqui que vai sumir,
não espera esse alguém que vai representar
o produto que toda a minha equipe
vai tirar as dúvidas. Consegue? Não?
Então vou colocar um sênior,
mas esse profissional tem tempo,
não tem como sentar pra funcionar.
Uma das roles que eu
vejo que está mais deturpada,
porque pra mim, na minha visão,
o Product Owner, ele é uma pessoa
que ele tem que ver o todo do produto,
o ciclo completo.
Então ele tem que ver, por exemplo,
se a partir de suporte,
porque não adianta implementar
e ter um custo absurdo de suporte,
não adianta,
simplesmente
eu estou no mercado de trabalho
para ver o que tem novo, o que eu posso
substituir, o que que eu posso
melhorar, o que ele tem que manter vivo
aquele produto.
E eu vejo que as pessoas ficam presas
a entrega
para no tempo e não atualizam aquilo.
Então assim, o produto é uma fantástica
e uma rolha sim, grande.
É uma coisa viva, latente.
Mas ela acaba ficando no passado.
Porque é porque talvez a escolha da pessoa
não é a correta.
E eu acho muito interessante em cima disso
tudo que vocês estão falando
é que muitas vezes a empresa,
ela parte do princípio que ela está
adotando o ágil, mas ela não se preocupa
com essas amenidades.
O meu produto owna
quem vai representar a visão do cliente?
Ele está preparado para isso? Não.
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
eram o método Cascata
e que eu fiz uma célula.
Acho que ela começou a gerar resultado
e a gente foi entendendo
que outros times faziam sentido,
migraram ou não,
outros que se sentiam mais confortáveis
no planejamento clássico.
Eu parto sempre do princípio que isso
aprendi diretamente
com quem foi um dos fundadores do Scrum.
Quando ele fez a primeira turma, em 2010,
eu tive o privilégio de participar.
Eu estava trabalhando,
eu estava no lugar certo, na hora certa.
Dá pra voltar o tempo e convidar
a emoção.
E aí era muito interessante,
porque a gente foi perguntando pra ele
como que ele chegou naquelas conclusões,
naquelas dinâmicas e assim por diante.
Só ver a história, estar no conhecer.
Então uma das perguntas que a gente fez
foi Cara, beleza, você diz que não Scrum,
O seu time tem que ter no mínimo quatro
pessoas, no máximo nove.
Qual foi a matemática desse processo?
Enumerar.
E aí ele falou Cara,
a gente testou 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 um link legal.
E aí?
E aí, Qual foi a grande dica para aprender
na prática?
Aqui é teste sem número,
teste, erro, teste, acerto, teste, erro.
Então, quanto mais exato,
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 coloca uma prática de cada vez.
Já teve caso, por exemplo, que cara,
estava todo caos, nem cascata era.
Era cascata. A cascata, cascata
tem mais nome, né?
E aí pediram para eu dar uma ajuda
pro time, inclusive,
tradicionalmente era um time de Cobol,
mainframe e tal, que é uma linguagem
antiga, é um modelo que o pessoal
está mais acostumado, no formato cascata.
Eu falei pessoal, vamos fazer um exercício
zen aqui, ao invés da gente
só sair fazendo um planejamento aqui
de dois, três meses.
Cara, vamos planejar o que a gente
vai fazer nas próximas duas semanas,
separar essas tarefas,
discutir aqui, entender a complexidade,
organizar quem vai fazer o quê e executar.
Ai beleza, Nossa 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 a gente bater um papinho
aqui só pra entender quem está fazendo
o que está tendo problema.
Se tiver problema próprios, aparece cara
aqui que esse cara vai ajudar.
Legal.
Pô, bacana, Nossa, eu bati a cabeça
três dias por causa de um problema
aqui para compilar meu programa.
Agora tem um cara que ajuda,
já interessa no mesmo dia, legal junto.
Ah, vamos fazer agora
uma cerimônia de entrega.
Ah, vamos fazer uma uma cerimônia
agora de retrospectiva pra gente ver,
discutir aqui
o que aconteceu, se foi legal, se não foi,
se o produto se apresentou para você
de uma forma legal.
Não sei o que ele priorizou,
fez sentido ou não.
Então todas essas coisas gradativamente
foram criando a cultura para aquele time
e aí o próprio time vai se ajustando,
entendendo a 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á de fato
têm conhecimento da cultura ágil
como um todo, do método
adotado e gradativamente
executando o teste.
Acertaste eu 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í, é experiência, experiência.
Deixa eu trazer um tema aqui que se não
os 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, só joguei aqui
depois teve opinião também, Tá, vai lá,
eu tenho uma leitura que vai morrer.
Boa revisão, tá?
Minha sala também e vamos lá.
Saiu tempo, ok, mas atual
agora nem é nova.
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 de outro.
Até porque
quando a gente fala em métodos ágeis,
muitas vezes a pessoa associa mais a isso.
Só que você tem Scrum, Kanban, flow,
tem 100 auxiliar
e cada um por uma
coisa diferente XP. Enfim.
Mas o grande ponto, ao meu ver,
é você pega.
Um exemplo que eu gosto muito
é 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 seja valida.
Ela inteira
do outro lado, que é o conceito do metro,
cascata de carro e tudo.
Exato.
Se você faz de pouquinho em pouquinho
a entrega disso,
além de você não conseguir de fato
utilizar o 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 acho que deixa muito claro, plausível
estoca desses materiais.
Exato. Exato. Então
eu não acho que morre,
mas ele obviamente começa a aprender
com novas filosofias.
Como você bem colocou Pia,
ele criou lá um módulo Capitain Elemental
tal, exatamente para se buscar aprender
um pouco dessas novas referências.
Então ele se adapta a novos contextos.
Agora sim, antes pia mais pia maior,
inclusive
nasceu também na década de 70,
junto com o método Cascata.
Então bebeu da mesma filosofia. Exato.
Só que ele foi perdendo força no mercado
como um todo,
especialmente em desenvolvimento
de software, porque foi entendendo
a magia de se entregar um pequeno módulo,
um pedacinho, o famoso pezinho.
E aí o cliente já começa a rentabilizar.
Resolveu daqui, daqui
eu retorno desatando eu mesmo,
mesmo antes de terminar o projeto.
Então, essa é a magia.
A gente começou a pensar
projetos diferentes.
Eu estava simulando com a turma,
por exemplo,
um projeto de locadora de veículos.
Tradicionalmente, a gente sempre
priorizava os cadastros primeiro.
Então, na locadora de veículos
você cadastra o carro, cadastra o foco
e recebeu o dado do cadastro.
Só que pensando
o cliente já começa a usar.
O que você tem que fazer primeiro
é a parte da reserva, do pagamento e etc.
Você já ganha ali para ele exatamente
o cadastro para começar a operação
eu posso cadastrar
direto no banco de dados lá
e ele vai personalizando.
Então é uma forma de eu fazer um contexto
menor,
já colocar pra rodar,
já começar a gerar dinheiro em cima.
E aí a gente vai executando o restante
do projeto sem a mesma pressão ali
daquela primeira entrega,
naquela primeira rodada.
E eu trouxe até isso
o feriadão,
porque o seu contexto que vocês vivem,
por exemplo, foi legal até o contexto.
Daí se a pessoa trouxe
um grande sistema RP.
Até o presente momento a gente
vê que faz sentido, se não em todos,
na maioria dos casos, a gente implementar
que seja um novo módulo ou uma mudança.
O p mai é aí para provar que p mai existe,
ainda vai existir.
Não sabemos quanto tempo, nem o ágil,
quanto tempo ainda tem o híbrido hoje.
Ou seja, para mostrar que ele faz sentido
hoje, faz sentido criar esse novo
até se você der uma pesquisada, existe
um dos nomes que intitularam aí é flex.
E aí, nadam?
Como é que tá lá para você?
Morre, não morre, está igual.
Vamos a tudo.
Eu acho que é aquilo que a gente
está conversando aqui, morrer.
Eu também acho que não.
Acho que ele vai passar por uma
transformação e tá passando a cada dia.
Mas existem muitos segmentos
que a gente ainda precisa desse modelo,
do modelo de cascata,
do modelo de entrega, do modelo de,
de ter as fases, celebrar as fases.
Então, quando a gente fala é, por exemplo,
na construção civil ele funciona,
ele tem certas coisas na entrega do RP,
ele tem essa, essa, esse benefício.
Então eu acho que morrer não.
Mas ele tem saiu.
Acho que saiu um pouco desse.
Antes eu costumava dizer
que era um pouco acadêmico,
tinha as fases
engessadas, pesado do não passado.
Era assim, não aceita mais isso.
É a evolução tecnológica que a gente está
passando, não permite mais essa lentidão,
não permite mais.
Assim, vamos marcar
uma reunião de blueprint ou uma semana.
Todos os executivos numa só sala.
Não dá mais isso, não dá mais
mesmo que tranca todo mundo ali
até falar.
Nós vamos contando a história
e caminhando,
porque a gente já tem que está entregando
e a gente já tem 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 a gente falava de qualidade
se tinha um ou dois
que tinham uma qualidade absurda
e a concorrência começando aqui
com uma qualidade completamente diferente.
Hoje é que parou.
Então assim vou a divisão no mercado,
ela 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 tivesse retorno rápido.
Então, andando junto com a entrega rápida,
então é aquele negócio
acho que não morre, perde força
e tem que se reinventar.
Como tudo está acontecendo no mundo hoje.
Ou a gente se reinventa
e a gente vai ficando obsoleto.
Até meio de um exemplo
provam que antes daqui que a gente
tá 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.
Já era,
já passou a ser nem a quinta do mundo.
Olha, a concorrência tem que ter algo lá.
Não é que aconteça, né?
De tanto criar 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.
Só que hoje a física tradicional em Vargem
Grande Paulista, município aqui
perto de Cotia, no interior de São Paulo,
uma lojinha pequena vendia ali todo ano.
Tudo bem, sobrevivi.
E veio a pandemia,
a loja deles não vendia nada.
Eles tiveram que se reinventar,
arrumar um software, ter,
colocar isso 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
estão
vivos, são vivos
e estão melhores do que estavam antes.
É legal, Interceptor,
a transformação de tudo que vai acontecer.
E esse foi ágil,
com certeza é que percebeu e percebeu.
Então, no começo
eu gostei do conceito de você
implementando aos poucos,
porque na realidade você vai
treinando as pessoas na demanda
sem que você fale.
Vamos colocar aqui uma meta.
Tem gente que assusta quando você fala
nós vamos fazer isso aqui.
Acho que não vai.
Você acha?
Não, não tem vida sem vida pessoal.
Vai mudar o escopo toda hora.
De pouco em pouco
a coisa vai fluindo e a pessoa
naturalmente vai embora.
E aí o fator fator para a soma disso
é uma conversa que a gente teve
uma outra vez também foi nessa linha.
Tem que tomar um cuidado também
para não virar de alguma maneira
a pastelaria tem que também ter uma boa,
alguém, um bom gestor na frente, falar
tudo bem flexível, que é o escopo, tudo.
Acho que se deve concordar ou não,
fica à vontade,
mas tem até um certo nível,
se não também se sacrifica.
A equipe era o famoso deve tinha ali.
Como você vê,
você não tem mais ninguém, né?
O que eu acho muito louco ou flexibiliza
tudo, fica à vontade.
Não vou entrar e vou mudar diariamente.
Eu acredito que cada caso é um caso.
Então eu tive um cenário
especificamente em 2010,
onde a gente fez um projeto
para a secretaria da Fazenda.
Na época
eu trabalhava numa consultoria e lá,
gente, eles já tinham
como pedido a utilização de Scrum
com método ágil, cultura ágil.
Então a gente tinha todos os papéis,
tudo certinho.
Só que o nível de documentação
que a própria entidade,
por ser governamental, precisava,
ela divergia
daquela documentação
mais enxuta que a gente busca pelo ágil.
Só que aí o que a gente entendeu
a documentação para eles,
então a gente não vai fazer uma história,
uma user story,
a gente vai fazer um caso de
uso detalhado,
passo a passo, interação homem máquina.
Só que mais do que isso,
a gente tem 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 -3 meses,
esses requisitos,
eles se tornam insumos de entrada
para a gente começar a rodar de fato
os times Scrum e aí sim,
entregando o desenvolvimento, um sprint
e um inclusive
um exemplo de modelo híbrido.
Mas eu acho que o ponto principal
em relação a essas expectativas,
como que isso vai acontecer
se se vai ser a entrega que eu estou
querendo,
se eu tenho que respeitar um time
na vivência real?
Eu 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
usada, aquele semáforo zinho, verde,
está tudo bem, amarelo ponto de atenção,
vermelho já deu ruim e tal.
E aí o que começa a acontecer?
Eu reparei já inúmeros lugares.
A tarefa está lá, 75% pronta.
Legal.
Aí na semana seguinte ela está 80% pronto,
na semana seguinte
90% pronto, na outra semana, 99% pronta.
E aí ela está num percentual
altíssimo de pronto e nunca está pronta.
Então, no final das contas,
as pessoas, elas querem a expectativa,
mas essa expectativa,
ela está constantemente sendo quebrada.
Então é muito mais um documento
para a gente ficar gerenciando as dores
e trazendo sensação que está toda hora
devendo do que qualquer outra coisa.
Como que eu trabalho
isso normalmente dentro de uma empresa,
trazendo já para cultura ágil,
eu começa
a mostrar você nunca acaba o projeto.
Se você também falou
que flexível o ponto vai andando,
vou fazendo o que eu quero em um ano
sem fim, sem data.
Mas acho que mais do que isso,
eu começo a trabalhar aquelas expectativas
de datas com aquilo que de fato
está entregue ou assim, ou não tá pronto.
O cliente pode usar ou não está pronto,
não importa,
está 99% pronto, não está utilizável.
E o nível que esperava.
E junto com isso eu direciono muito,
inclusive a equipe estratégica para gente
sempre revisitar o planejamento
com base naquilo que já está pronto,
naquilo que já está operacionalizado
e assim por diante.
E sempre trabalhando para você não ter só
as suas métricas e seus resultados
no final do projeto você já ir criando
eles no começo, porque é toda pressão,
toda a preocupação com essas expectativas,
elas vão reduzindo porque beleza.
Ah, eu tenho um lançamento aqui
de um mobile Bank,
então tem algumas funcionalidades básicas
ali do saldo, extrato, transferência, etc.
Que precisa estar no aplicativo.
Ah, mas eu tenho uma parte
de investimentos em outros módulos
aqui até ecommerce.
Hoje em dia muito comum,
que não necessariamente precisa estar
nessa primeira versão tão legal,
entrega 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 o resultado
em cima daquilo quando estiver pronto.
Esse é o ganho.
Se tanto que se você for
avaliar tudo contra o aplicativo,
quem te usa no dia
a dia já passou por esse processo
e volta e meia
tem atualização em novas funcionalidades.
Mais você vai recebendo e vai atualizando
Product Manager gerenciando ali.
Já o Product Owner
na verdade é aquele que fica legal.
Geronimo vai versão de back.
Mas pegando o gancho aí,
você não acha que essa cultura da cascata
que a gente tem enraizado,
principalmente nas pessoas que já
trabalham, já tem um bot há um longo tempo
ele não criava um buffer,
um conceito de buffer, de coisa,
de falar assim
Bom, eu tenho que entregar isso.
Primeira objetiva Esse ano
nós vamos entregar esse projeto,
vamos construir uma fábrica nova.
Então as pessoas colocava os seus pezinhos
lá porque elas sabiam.
Olha, em teoria até a gente trabalhou
junto, a gente sabe disso.
Aí ela falava assim
eu vou fazer a configuração no sistema
e 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 20 vai.
A operação vai se acabar,
não é exata e você vira a noite,
vira sábado, domingo de sol.
O que ia colocar aquele negócio?
Aquilo foi, foi ficando,
vai ficando cada vez mais inchado.
E aí, às vezes o cara já está com a coisa,
com a tarefa pronta,
mas ele vai
colocando 99,99 para chegar no dia.
Ele fala 100
no modelo.
Lá quando a gente vem quase,
a gente quebra tudo isso.
Exato, Não, pera aí,
Entregas curtas, todo mundo alinhado
está todo mundo eu vou acontecendo.
Faz, eu vou sentindo até não adianta.
Se eu estou enrolando,
estou enrolando todo.
O cara tá vendo como
enrolar, vem tentando enrolar em tempo
real, fala assim eu fiz ou não fiz.
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 é?
E preto ou branco não tem esse meio termo?
Então acho que é.
As pessoas ainda estão assim
na minha visão, relutantes,
quase como que eu 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.