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 precisa 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 "cascata".
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 ou não".
Eu associo isso à 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 para que ele foi criado,
não sei por que eu tenho que fazer cerimônias,
não sei por quê, por quê, por quê, não sabemos o por quê".
Essa é normalmente a primeira.
E a segunda é: "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".
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, muita parte,
você normalmente não tem cursos disso para 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,
não conheciam o modelo de negócio de meios de pagamento,
e tínhamos dores muito específicas para resolver.
O que eu fiz então?
A primeira conversa com eles foi...
Beleza, o que é meio de pagamento?
- Então aqui tem o adquirente... - Não vamos falar de código, né?
Esquece código.
Aqui tem adquirente, aqui tem a bandeira, aqui tem o banco,
aqui tem o gateway, ou o PSP, aqui é o serviço para cartão de crédito,
aqui funciona autenticação para débito.
Ecossistema sistema inteiro.
Para loja aparece desse jeito aparece daquele, a experiência assim.
Beleza.
Entenderam melhor?
Lógico que isso foi gradativamente...
- Várias conversas... - Não uma sessão de duas horas ali, né?
Exato.
Só que aí, o que foi interessante?
O pessoal começou a falar: "Cara, beleza.
Então, mais que a tarefa que eu tenho que construir,
agora eu entendo porquê, aonde, como".
E aí começa a simulação.
Beleza, qual dor o nosso cliente tem?
Então, hoje, ele vai cadastrar uma conta de pagamento,
ele começa aqui, muda de tela, recebe dois e-mails,
faz uma autenticação aqui, faz isso...
Aí o próprio time fala: "Cara, que revolta!
O nosso cliente tem que querer muito ser nosso cliente.
Temos que melhorar isso para ele".
Então, você criar essa cultura para o time
começar a sentir a dor do cliente, e pensar...
E muitas vezes, era engraçado, o Product Owner até tinha uma visão muito legal
do que priorizar, de como fazer.
Isso ajuda.
Mas o time contribuía...
"Pô, Product Oner, tem esse conjunto aqui de funcionalidades.
Eu acho que, tecnicamente, já dá para separar
para você já entregar para o cliente lá e já diminuir essa dor".
- Pô, legal... - Pô, aí deu uma sinergia, hein?
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 Product Owners já chega aqui com um script pronto...
"Pessoal, vocês têm que fazer isso, isso, isso e isso. Vai!"
E muitas empresas que não têm a cultura...
"Ó, vocês precisam fazer isso, isso e isso, e o prazo é esse".
Cadê a colaboração dos dois lados aqui...
- Para construirmos juntos, né? - Exato.
Então, o que eu costumo dizer?
Quando falamos em 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 outra", alguma coisa.
Cara, não tem condenação aí.
Só que entenda se os problemas que você está tendo
não estão atrelados ao fato de não seguir alguma coisa.
Eu até ia trazer mais uma polêmica agora, no final.
Quando eu sei que, trabalhar com ágil, vai ser um problema,
ou trabalhar com PMI vai ser um problema?
Ninguém tem uma resposta fixa.
Mas como vocês trazem essas conversas?
Não dá para mandar um e-mail e falar: "Hoje é ágil".
Não, não dá.
Mas o que eu vejo que acontece muito?
Por três prints pequenos, dependendo do projeto,
e a grande maioria tem esses prints 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,
querem programar, querem fazer, querem entregar, querem 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 entrega, entrega, e 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 falamos num modelo de cascata, ele tem picos.
Eu sempre digo assim: você sabe quando vamos subir a ladeira, quando vamos descer.
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 você desce um pouquinho de novo,
de repente você vai, aí você chega no realization,
Hypercare, não sei o quê, entregou o projeto.
E eu vejo que hoje nós estamos saturando muito
por demandar muito da pessoa, por sempre querer o vaso cheio.
Quem entrega é a pessoa, né?
Exato, e quem entrega é a pessoa.
E aí, um outro lado que eu também falo é que, se você satura demais,
ele perde a inovação, 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 e propor...
Eu tive um caso, que estávamos falando assim:
o usuário entrava, apertava o botão na tela. Por quê?
Porque estava do lado direito, certo?
Então, em vez de ele ler o texto, ele "pá", para passar.
Aí o cara que estava desenvolvendo falou assim:
"E se colocarmos o botão do lado esquerdo?".
Aí eu falei: mas qual a lógica disso?
Ele falou: "Olha, o cara vai entrar, olhar a tela,
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: "Mudou a performance, mudou tudo.
Nós temos mais assertividade".
Por quê?
Estávamos processando fatura, e era sumamente importante
ler aquele trechinho ali para interagir com o dado.
Como estava para a direita o botão, o cara já plugou.
Agora, se o cara está saturado aí ele não consegue ter esse insight
porque ele está no limite dele.
Você já falou isso para mim uma vez.
"Rafa, às vezes tem que ter um tempo para ele dar uma respirada".
- Não é fazer nada, né? - Exato.
- Eu já trabalhei em equipe com você. - Para criar, para inovar...
Para trazer algo novo,
Porque cansado, você não faz.
Eu acho que eu sou muito suspeito, porque, assim, todos os cenários
que eu consegui fazer, acabaram dando ótimos resultados
e todos as partes gostaram.
Eu diria que é o método ágil não é uma fórmula mágica,
eu estou aqui e está tudo resolvido.
- Assim... - Puxa, o pessoal que está ouvindo isso...
Está louco para dar uma pausa e anotar.
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, né?
Tudo depende de como ser usado.
Tem um lado muito bom, te manter vivo, ou pode ser o inverso.
Então acho que vem muito disso.
Tentamos trazer uma cultura nova para resolver um caos que existia antes,
mas o olhar caótico, seja de quem está no ponto de decisão,
seja de quem está definindo prazos, demandas etc., 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 para ter uma visão mais assertiva.
Hoje em dia existem aí uma biblioteca de dinâmicas que ajudam isso,
Benchmarking, brainstorm, Design Thinking 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, trazer o time para essa cultura.
E isso de tornar mais leve o time, mais participativo, equilibrar os pratos, né,
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, entregar valor,
e ser cada vez mais participativo naquilo que resolve a dor real do cliente.
Então, ao meu ver, mais que um método ou outro,
é você ir encontrando a melhor forma de executar, né?
Agora, sim, no Agile, historicamente falando,
ele veio para você poder fragmentar os problemas.
Os problemas vão acontecer, né?
Não importa o método, o dia a dia é assim.
O problema segue o mesmo.
Exatamente.
Então é como você lida com esses problemas.
- Você se antecipa aos problemas, né? - Exato
- Ficar mais próximo... - Estar mais próximo
E o cliente ali no centro.
Tem dev team, todo mundo integrado, né?
E às vezes ele percebe coisas que você não perceberia no método anterior.
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 nós queremos.
Que é o cenário que foi criado ali, né?
Sabe uma coisa que eu vejo?
Nós estamos ganhando confiança, e quando você ganha confiança,
você consegue ser transparente, porque você vai com qualquer stakeholder. e fala...
- Exato, exato. - Isso é verdade.
Eu até estava comentando de uma experiência pessoal minha
que me convidaram para assumir uma hole global
para implementar um processo de fatura eletrônica com quatro pessoas.
Aí eu falei: olha, é impossível.
- Global, né? - Global.
É impossível, em um ano, com quatro pessoas, eu consegui ter êxito.
Então eu 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 com você,
você consegue ser realmente transparente e verdadeiro,
e dizer: "Olha, não dá"..
Não vamos nem começar, né?
- Não é que eu quero negar. - Exato.
Então, esse é justamente o ponto.
Você precisa criar um ambiente que favoreça isso.
Porque não adianta você falar que está usando métodos ágeis
e você está toda hora sabotando essa confiança, essa transparência.
Exato.
Eu posso dizer que, algumas das melhores...
- É praticar o que prega. - É.
Algumas das melhores contribuições
muitas vezes vieram das pessoas menos experientes no time,
porque elas se sentiram à vontade de trazer ideias..
E aí gerou até mudança ali, né?
- E elas tinham um ponto de vista diferente. - E elas têm um insight.
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ê acata, transforma aquilo numa ação,
o time gosta, aceita, cara, você criou aí uma cultura maravilhosa.
A partir daí, as coisas tendem cada vez mais a funcionar melhor.
Pantolfi e Anadão, vocês falando aqui, eu estava refletindo.
Nós abrimos um podcast trazendo dois grandes profissionais,
vamos falar bastante de ágil, aí talvez o aluno vai falar:
"É hoje que eu vou fazer em duas linhas.
Quando eu uso o ágil, quando eu uso PMI, ou quando eu uso híbrido?".
Não é uma frustração, você que está nos escutando,
se você não conseguiu sair com essa definição,
porque não era esse o objetivo aqui, né?
O objetivo era explanarmos mesmo, entender esse ponto de vista
que o Anadão e o Pantolfi trouxeram para nós,
de como é feito no dia a dia.
Não tem um fluxo.
Se alguém tiver aí, pode trazer.
"Olha, segue esse fluxograma aqui."
Você saber quando é ágil, quando não é, quando é cascata, não existe.
O que existe é saber lidar com pessoas, trabalhar com pessoas,
entender o que o seu cliente quer, estar próximo, ele no centro.
como o Pantolfi falou agora, trazer também um clima favorável.
E aí, depois de tudo isso, eu acho que você pode falar:
"E agora, o que eu faço da minha vida?
O que eu estudo?".
Estamos falando com os nossos estudantes aqui
que estão se preparando para o mercado de trabalho, ou já estão e querem evoluir.
Se pudéssemos, ficaríamos horas e horas aqui.
Talvez virasse um "filme casting" aqui.
Nem existe esse termo, tá?
É só para descontrair.
Fica um disclaimer.
Eu acho que esse termo nem existe, mas...
Para tentarmos deixar uma dica para quem está nos escutando.
o que vocês poderiam deixar para os estudantes?
Estudar o quê?
Ágil, estudar o PMI, tudo isso tudo,
ou tenha calma, deixa fluir, ganhem experiência?
O que cada um poderia deixar de dica final para nossos alunos?
Olha, como um conselho de um pai, eu diria assim:
aproveite um pouco de cada coisa.
Não coloque esses rótulos, não coloque essa camisa...
Aproveita um pouco, se joga, entendeu?
Participe.
Uma das coisas que eu sempre penso:
vai profundo, aprenda, teste, vivencie aquilo,
para você realmente sentir...
Sair um pouco da teoria e entrar na prática.
Ver na prática como é, e tirar proveito disso.
Então, assim, nós estamos num mundo que é perfeito para isso.
No meu tempo, quando eu comecei, não existia isso.
Você ia aprendendo uma coisa, aquilo levava dez anos para mudar.
Quando mudava, mudava uma cor da tela.
Saía da tela preta, daquelas cabeças de lata que tínhamos,
uma tela mais coloridinha, azul e branco...
- Depois de alguns anos, né? - E não acontecia mais nada.
Hoje, o jovem tem um mundo para mergulhar,
para ele se aprofundar, para ele experimentar.
Ele tem que fazer, e 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 à outras experiências".
Então aproveite esse momento, tire esse peso das costas.
Tira essa coisa de falar assim: "Eu preciso ser assertivo,
eu preciso ser bem-sucedido.
Isso vai acontecer naturalmente.
Isso vai se montando de pouquinho em pouquinho.
Então eu acho que a mensagem final seria isso: aproveite, se jogue.
Vocês estão num momento fantástico da vida.
E aí, Pantolfi? Nós falamos que o primeiro sobe a régua,
enquanto isso o outro fica calibrando onde eu vou me encaixar aí, né?
Mas eu sei que você manda bem também.
Qual é a dica que você deixa aí?
Eu acho que complementar isso, do exercício do teste, da validação,
de sentir o que funciona melhor, o que não funciona.
É justamente respeitarmos as pessoas.
E o que eu costumo dizer que 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ífica,
por que naquele lugar as pessoas fazem as coisas
de um jeito A, de um jeito B, e ao mesmo tempo buscar aprender com as pessoas
sendo a pessoa que tem menos vícios,
para, de repente, poder enxergar algo que pode ser melhorado,
contribuindo 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 você 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 estiver.
Pantolfi, Anadão, eu fico feliz quando alguém fala para fechar.
O meu papel aqui é só intermediar,
porque senão um terceiro iria ser quase impossível.
Eu queria agradecer a vocês todo esse contexto,
e pedir que, nessa fala final, vocês deixassem uma dica,
porque todos nós já passamos por uma mesa de estudante.
Na verdade, continuamos sendo, né?
Vocês, alunos, não sabem, mas aprender é uma coisa contínua.
Já passamos pela graduação, mas se pudéssemos voltar,
curtiríamos novamente o momento.
Novamente, eu quero agradecer vocês terem aceito o convite,
até mesmo transmitido da sua experiência conosco.
Obrigado, hein!
Obrigado a você, Rafa, Anadão, todas as pessoas aqui envolvidas.
Temos uma grande produção aqui por trás.
E obrigado especialmente a você que está aí assistindo.
É sempre muito especial esse momento, essa troca, o compartilhar,
sempre aprendemos um pouquinho mais aqui também,
e muito sucesso na sua carreira, nas suas escolhas.
Obrigado mesmo, Anadão, obrigado por também ter aceitado o convite,
até mesmo o seu tempo na empresa.
Ou talvez estaria no interior agora, né?
Eu que agradeço.
Agradeço a FIAP através de você, Rafael Ronqui, que me convidou,
por conhecer o Pantolfi, por conhecer 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 crescemos com isso.
Obrigado pela oportunidade, obrigado por estar aqui.
Obrigado, Anadão! Obrigado, Pantolfi!
Depois de falar tanto sobre o ágil,
você tem que entender que não é somente sobre velocidade
e sim também assertividade, qualidade, estar sempre próximo ao seu cliente.