-
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 conversa é
o que não vai faltar, 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,
ao Pantolfi, 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 como 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!
-
Igual run, 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
estávamos como no passado, né?
-
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á está 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 ERP
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
ao mercado para ver o que tem novo,
-
o que eu posso substituir,
o que que eu posso melhorar.
-
Ele tem que manter vivo aquele produto.
-
Eu vejo que as pessoas
ficam presas à entrega,
-
param no tempo, e não atualizam aquilo.
-
Então, assim, o Product Owner é
uma hole fantástica e uma hole grande,
-
é uma coisa viva, latente.
-
Mas ela acaba ficando no passado
-
porque talvez a escolha
da pessoa não seja a correta.
-
E eu acho muito interessante em cima
disso tudo que vocês estão falando
-
é que muitas vezes a empresa parte
do princípio que ela está adotando o ágil,
-
mas ela não se preocupa
com essas amenidades, né?
-
O meu Product Owner, que vai
representar a visão do cliente,
-
está preparado ou não para isso?
-
Ele sabe priorizar?
-
Ele sabe montar um backlog?
-
Ele sabe direcionar o time
para atingir primeiro
-
aqueles 20% que são mais importantes?
-
Não sabe?
-
São questões que vão aparecer
ao longo do caminho.
-
Eu já tive trabalhos em empresas que,
tradicionalmente, era o método cascata,
-
e que eu fiz uma célula ágil,
que ela começou a gerar resultado,
-
e fomos entendendo se fazia sentido
outros times migrarem ou não,
-
outros que se sentiam mais confortáveis
no planejamento clássico.
-
Eu sempre parto do princípio que...
-
E eu aprendi isso diretamente
com o Ken Schwaber,
-
um dos fundadores do Scrum,
-
quando ele fez a primeira turma, em 2010,
-
e eu tive o privilégio de participar.
-
- Eu estava no lugar certo, na hora certa.
- Fantástica essa sua experiência.
-
Essa é boa, hein!
-
Dá para voltar o tempo
para você me convidar?
-
Também vou nessa!
-
E aí era muito interessante, porque
nós fomos perguntando para ele
-
como que ele chegou naquelas conclusões,
naquelas dinâmicas, e assim por diante.
-
Eu só ouvi a história, tá?
Eu não o conheço.
-
Então uma das perguntas
que nós fizemos foi:
-
"Cara, beleza, você diz que, no Scrum,
-
o seu time tem que ter no mínimo
quatro pessoas, no máximo nove.
-
Qual foi a matemática, o cálculo
que você fez, para chegar nisso?
-
Aí ele falou: "Cara, testamos
com dois, não deu certo,
-
com três não deu certo,
com quatro deu certo, cinco, seis, sete...
-
Até nove deu certo.
-
Com dez começou a dar ruim?
-
Que legal!
-
E aí, qual foi a grande dica dele?
-
"Cara, é teste, acerto, teste, erro,
teste, acerto, e teste, erro.
-
- Então, quanto mais...
- Que são os princípios.
-
Exato. Então, quanto mais
você vai experimentando,
-
mais você vai trazendo riqueza.
-
Se você está num ambiente que as pessoas
não possuem maturidade em utilizar o ágil,
-
coloque uma prática de cada vez.
-
Já teve caso, por exemplo, que, cara,
estava tudo um caos, nem cascata era.
-
Era "caoscata".
-
Caoscata? Essa é boa, hein!
-
É um bom termo.
-
E aí pediram para eu dar
uma ajuda para o time,
-
inclusive era um time tradicional de Cobol,
mainframe e tal, que é uma linguagem
-
e um modelo que o pessoal está
mais acostumado, no formato cascata.
-
Eu falei: pessoal, vamos fazer
um pequeno exercício aqui.
-
Ao invés de só sair fazendo
um planejamento aqui de dois, três meses,
-
vamos planejar o que vamos
fazer nas próximas duas semanas?
-
Separar essas tarefas, discutir aqui,
entender a complexidade,
-
organizar quem vai
fazer o quê, e executar?
-
Aí, beleza.
-
Nossa! A turma ficou super
feliz, já ficou mais claro,
-
não tinha mais aquilo de duas pessoas
fazendo a mesma coisa ao mesmo tempo.
-
Já diminuiu um pouco o caos.
-
"Ah, legal."
-
O que vocês acham agora
de a cada dia batermos um papinho
-
só para entender quem está fazendo
o quê, se está tendo problema.
-
Se tiver problema, é para avisar esse
cara aqui, que esse cara vai ajudar.
-
"Ah, legal! Pô, bacana!
-
Nossa, eu bati a cabeça três dias por causa
de um problema para compilar o meu programa.
-
Agora tem um cara que ajuda,
já endereça no mesmo dia".
-
Legal.
-
Vamos fazer agora
uma cerimônia de entrega?
-
Vamos fazer uma uma cerimônia
de retrospectiva agora
-
para discutirmos aqui o que aconteceu,
se foi legal, se não foi,
-
se o Product Owner apresentou
de uma forma legal ou não para você,
-
se o que ele priorizou fez sentido ou não.
-
Então todas essas coisas foram criando
gradativamente a cultura para aquele time
-
e aí o próprio time vai
se ajustando, entendendo...
-
"Beleza, tudo isso faz sentido para mim.
-
Não, isso aqui não faz.
-
Podemos melhorar", e assim por diante.
-
Então, de forma geral,
-
é uma leitura muito mais do quanto
as pessoas que já estão lá
-
têm conhecimento, de fato, da cultura ágil
como um todo, ou do método adotado,
-
e gradativamente executando
teste, acerto, teste, erro,
-
para ver se para aquele time
está funcionando bem,
-
para aquela empresa, para aquela
cultura, está funcionando bem.
-
E aí você vai gerando conhecimento...
-
- É isso aí.
- E multiplicando a experiência.
-
Deixe-me trazer um tema aqui que...
-
Senão alguns professores
que estão envolvidos aqui na FIAP,
-
inclusive vocês aí,
vão ficar bravos comigo.
-
E aí, o PMI está morrendo?
-
Cara, na minha leitura, ele
diminuiu muito a força, né?
-
Eu só joguei aqui.
-
Depois vai ter a minha
opinião também, tá? Vai lá!
-
Eu não tenho uma leitura
que vai morrer, tá?
-
É a minha visão também.
-
Tem o PMBOK mais atual
agora
-
E não se enganem...
-
Eu sou um grande
defensor da cultura ágil,
-
mas muito mais da cultura
do que só de um método ou de outro,
-
até porque quando falamos
em métodos ágeis,
-
muitas vezes a pessoa
associa mais a Scrum.
-
Só que você tem Scrum,
KanbanFlow, SAFe, OKR,
-
e cada um por uma coisa diferente, né?
-
XP, enfim.
-
Mas o grande ponto, ao meu ver, é...
-
Um exemplo que eu gosto muito
é a fabricação de placas de computador.
-
Você normalmente faz um desenho uma vez,
-
a especificação com todos
os detalhes, com todo o material,
-
coloca na linha de produção,
e ele já constrói a placa por inteiro
-
e você já a valida inteira do outro lado.
-
que é o conceito do método
cascata.
-
Peças de carro...
-
Exato.
-
Se você faz de pouquinho
em pouquinho a entrega disso,
-
além de você não conseguir,
de fato, utilizar do outro lado,
-
você ainda tem o problema
do desperdício de material,
-
do vai e volta, do vai e volta.
-
Aqui é algo bem específico, mas
eu acho que deixa muito claro...
-
Inclusive o estoque desses materiais, né?
-
Exato, exato.
-
Então eu não acho que morre,
-
mas ele obviamente começa
a aprender com novas filosofias.
-
Como você mesmo colocou, o PMI
criou lá um módulo incremental e tal,
-
para se buscar aprender
um pouco dessas novas referências.
-
Então ele se adapta a novos contextos.
-
Agora, sim, antes, PMI...
-
Inclusive o PMI também nasceu na década
de 1970, junto com o método cascata.
-
- Então bebeu da mesma filosofia.
- Estava junto, né?
-
Exato.
-
Só que ele foi perdendo força,
no mercado como um todo,
-
especialmente em desenvolvimento
de software, porque fomos entendendo
-
a magia de se entregar um pequeno
módulo, um pedacinho, o famoso MVP,
-
e aí o cliente já começa a rentabilizar...
-
- A resolver o problema daquele sistema...
- ? tem um retorninho ali, né?
-
Exato.
-
Mesmo antes de terminar o projeto.
-
Então essa é a magia.
-
Até começamos a pensar
projetos diferentes.
-
Eu estava simulando
com a turma, por exemplo,
-
um projeto de locadora de veículos.
-
Tradicionalmente, nós sempre
priorizávamos os cadastros.
-
Então, na locadora de veículos, você
cadastra o carro, cadastra o cliente.
-
Foco, né? Recebeu dado/cadastro.
-
Só que, pensando no cliente
já começar a usar,
-
o que você tem que fazer primeiro
é a parte da reserva, do pagamento etc...
-
- Porque ele já...
- Senão você não gera ganho ali para ele.
-
Exatamente.
-
Para começar a operação, eu posso
cadastrar direto no banco de dados lá,
-
e ele vai operacionalizando.
-
Então é uma forma de eu fazer
um contexto menor,
-
já colocar para rodar,
já começar a gerar dinheiro em cima,
-
e aí nós vamos executando o restante
do projeto sem a mesma pressão
-
daquela primeira entrega,
daquela primeira rodada.
-
E eu até trouxe isso, Antolfi e Anadão,
-
porque eu sei o contexto que vocês vivem.
-
Foi legal até o contexto de SAP
que você trouxe, né,
-
o grande sistema ERP.
-
Até o presente momento,
vemos que faz sentido,
-
se não em todos, mas
na maioria dos casos,
-
implementarmos um novo módulo
que seja, ou uma mudança, o PMI.
-
E aí, para provar que o PMI existe,
e ainda vai existir,
-
mas não sabemos por quanto tempo,
e nem o ágil, ainda tem o híbrido hoje.
-
Ou seja, para mostrar que o ágil
faz sentido, criar esse novo.
-
Até se você der uma pesquisada,
um dos nomes que intitularam aí é "flex".
-
E aí, Anadão, como está lá?
-
Para você, morre, não morre, está igual?
-
Vamos usar tudo aí, depende do momento?
-
Eu acho que é aquilo
que estávamos conversando aqui.
-
Morrer, eu também acho que não.
-
Eu acho que ele vai passar
por uma transformação,
-
e está passando a cada dia.
-
Mas existem muitos segmentos
que ainda precisamos desse modelo,
-
do modelo de cascata,
do modelo de entrega,
-
do modelo de ter as fases,
celebrar as fases.
-
E, por exemplo, na construção civil,
ele funciona, ele tem certas coisas...
-
Na entrega de um ERP,
ele tem esse benefício.
-
Então eu acho que morrer não.
-
Mas eu acho que sai um pouco desse....
-
Antes eu costumava dizer
que era um pouco acadêmico, né?
-
Tinha as fases, engessado,
pesado, duro...
-
No passado era assim, né?
-
O mundo não aceita mais isso.
-
E a evolução tecnológica que estamos
passando, não permite mais essa lentidão,
-
não permite mais...
-
Assim, "Vamos marcar
uma reunião de blueprint".
-
Ou, em uma semana, todos
os executivos numa só sala...
-
Não dá mais isso, não dá mais.
-
Mesmo que tranque,
está todo mundo ali offline, né?
-
Nós vamos contando
a história e caminhando,
-
porque já temos que entregar,
já temos que mostrar valor.
-
Outra coisa, as margens de lucro
das empresas reduziram muito.
-
O mercado está muito mais apertado,
a concorrência está muito mais...
-
Antes nós falávamos de qualidade.
-
Você tinha um ou dois que tinham
uma qualidade absurda,
-
e a concorrência começando aqui,
com uma qualidade completamente diferente.
-
Hoje equiparou.
-
Então, assim, a divisão no mercado
está muito mais apertada,
-
e aí, se você não entrega rápido,
o acionista já começa a falar assim:
-
"Eu não vou colocar dinheiro aí
se eu não tiver retorno rápido".
-
- Andando junto com a entrega, né?
- Eu preciso realizar rápido.
-
Então eu acho que não morre,
perde força, e tem que se reinventar,
-
como tudo que está
acontecendo no mundo hoje.
-
Ou nos reinventamos
ou vamos ficando obsoletos.
-
Eu até dei um exemplo
para o Ronqui antes daqui
-
quando estávamos tomando
um café, num papo informal lá,
-
falando que eu comecei um projeto
desse chatbot que eu comentei aqui
-
com uma empresa que era
número um do mundo...
-
E, durante a implementação,
ela ficou obsoleta.
-
Ela passou a ser nem a quinta do mundo.
-
Olha, a concorrência, hein?
-
Às vezes não é que fizeram algo errado lá.
-
É a concorrência, né?
-
É assim, de tanto criarem novos produtos,
melhorar, atender demandas de mercado,
-
porque a pandemia trouxe isso,
a pandemia acelerou,
-
ela veio com problemas
que precisava resolver...
-
Por exemplo, o cara que não vendia...
-
E eu tenho amigos...
-
Assim, isso vai do pequeno ao grande.
-
Eu tenho amigos que eles vendiam
roupa para nenê numa loja física,
-
uma loja física tradicional
em Vargem Grande Paulista,
-
perto de Cotia, no interior de São Paulo,
-
Uma lojinha pequena, que vendia ali,
todo mundo bem, sobrevivi.
-
Veio a pandemia,
a loja deles não vendia.
-
Eles tiveram que se reinventar,
-
arrumar um software, colocar
na internet, não sei o quê...
-
E hoje a loja não abre mais.
-
A loja física não existe mais.
-
- Então, assim...
- Que interessante isso.
-
E o negócio está vivo?
-
Estão vivos e muito melhores
do que estavam antes.
-
- Que legal essa história.
- Então você vê a transformação...
-
De tudo que vai acontecendo, né?
-
E esse foi ágil, com certeza.
-
É que às vezes ele nem percebeu, né?
-
- Ele nem percebeu.
- É, porque é um pequeno comércio, né?
-
Eu gostei do conceito de você ir
implementando aos poucos,
-
porque, na realidade, você vai
treinando as pessoas na demanda
-
sem que você fale: "Vamos
colocar uma meta aqui".
-
Tem gente que se assusta quando você
fala: "Não, vamos fazer isso aqui ágil".
-
O cara:
-
- "Não, vou sofrer...
- "Não, ágil não!
-
- Não, não sei o quê...
- É sem vida.
-
É sem vida".
-
O pessoal vai mudar o escopo toda hora".
-
Se você faz de pouco em pouco,
a coisa vai fluindo,
-
e, naturalmente, vai embora.
-
E aí, Pantolfi, até para somar a isso,
uma conversa que nós tivemos uma outra vez
-
também foi nessa linha.
-
Tem que tomar um cuidado também
para que, de alguma maneira,
-
não vire uma pastelaria, né?
-
Também tem que ter
uma boa gestão ali na frente,
-
e falar: "Tudo bem, é flexível,
aqui é o escopo...".
-
Eu acho que você deve concordar, ou não.
-
Fique à vontade.
-
Mas até um certo nível, né,
senão também se sacrifica a equipe,
-
o famoso "dev team" ali.
-
Quando você vê, você
não tem mais ninguém, né?
-
O que eu acho muito louco...
-
Ou flexibiliza tudo?
-
Fique à vontade, tá?
-
Não, eu acredito que cada caso é um caso.
-
Eu tive um cenário,
especificamente em 2010,
-
onde fizemos um projeto
para a Secretaria da Fazenda,
-
na época, eu trabalhava
numa consultoria,
-
e lá, eles já tinham como pedido
a utilização de Scrum
-
com o método ágil, cultura ágil.
-
Então nós tínhamos todos
os papéis, tudo certinho.
-
Só que o nível de documentação
que a própria entidade,
-
por ser governamental, precisava,
-
divergia daquela
documentação mais enxuta
-
que buscamos até no ágil.
-
Só que aí, o que nós entendemos?
-
A documentação para eles...
-
Então não vamos fazer
uma história, uma user story.
-
Nós vamos fazer um caso de uso detalhado,
passo a passo, interação homem-máquina.
-
Só que, mais do que isso, temos
uma estrutura que cria essa documentação,
-
porque ela é uma entrega para o cliente,
-
e depois que eu tiver ali um cenário
acumulado de pelo menos três meses,
-
esses requisitos se tornam
insumos de entrada
-
para começarmos a rodar,
de fato, os times Scrum,
-
e aí sim, entregando
o desenvolvimento em sprint.
-
Inclusive é um exemplo de modelo híbrido.
-
Mas eu acho que o ponto principal
em relação a essas expectativas,
-
como isso vai acontecer, se vai ser
a entrega que eu estou querendo,
-
se eu tenho que respeitar
um time e tal...
-
Na vivência real ali, né, em campo.
-
É. Eu brinco muito
com a questão da realidade.
-
Porque na prática, se você
observar a maioria das empresas,
-
especialmente projetos grandes,
você tem lá o cronograma,
-
aí tem todas as atividades, com data
de entrega, tudo direitinho, a sequência.
-
Muitas vezes é usado aquele pequeno
semáforo verde, se está tudo bem.
-
Amarelo, ponto de atenção,
vermelho, já deu ruim e tal.
-
E aí, o que começa a acontecer?
-
Eu já reparei em inúmeros lugares
que a tarefa está lá, 75% pronta.
-
Legal.
-
Aí, na semana seguinte, ela está 80% pronta,
-
na semana seguinte, 90% pronta,
na outra semana, 99% pronta.
-
E aí ela está num percentual altíssimo
de pronta, e nunca está pronta.
-
Então, no final das contas,
as pessoas querem a expectativa,
-
mas essa expectativa está
constantemente sendo quebrada.
-
Então é muito mais um documento
para ficarmos gerenciando as dores,
-
e trazendo a sensação que está toda hora
devendo, do que qualquer outra coisa.
-
Como eu normalmente trabalho
isso dentro de uma empresa,
-
já trazendo para a cultura ágil?
-
Eu começa a mostrar...
-
Você nunca acaba o projeto, né
-
Se você também for flexível ao ponto
de vai me mandando, eu vou fazendo...
-
É sem fim, sem data.
-
Mas eu acho que mais que isso, eu começo
a trabalhar aquelas expectativas de datas
-
com aquilo que, de fato, está entregue.
-
Ou é sim, ou é não.
-
Está pronto, o cliente pode usar.
-
Não está pronto...
-
Não importa se está 99% pronto.
-
Não está utilizável
ao nível que se esperava.
-
E junto com isso, eu direciono muito,
inclusive a equipe estratégica,
-
para sempre revisitarmos o planejamento
com base naquilo que já está pronto,
-
naquilo que já está operacionalizando,
e assim por diante.
-
E sempre trabalhando para você não ter
só as suas métricas e os seus resultados
-
no final do projeto, mas você
já os ir criando no começo,
-
porque toda pressão, toda a preocupação
com essas expectativas, vão reduzindo.
-
Porque... "Ah, eu tenho um lançamento
aqui de um mobile banking".
-
Então tem algumas
funcionalidades básicas ali,
-
do saldo, extrato, transferência etc.,
-
que precisam estar no aplicativo.
-
"Ah, mas eu tenho uma parte
de investimentos, outros módulos aqui...".
-
Até e-commerce é muito comum hoje em dia.
-
Que não necessariamente precisa
estar nessa primeira versão.
-
Então, legal, entrego
aquela primeira versão,
-
a operação já começa a fazer contato
com os clientes, começa a fazer download,
-
começa a fazer cadastro, começa
a utilizar, começa a movimentar
-
e antecipa o que seria uma operação
para acontecer só lá no final.
-
E aí a empresa já vai gerando
resultado em cima daquilo.
-
Quando eu tiver pronto...
-
Esse é o ganho.
-
- ?
- Exato.
-
Tanto que, se você for avaliar, tudo quanto
é aplicativo quem usamos no dia a dia
-
já passou por esse processo, e volta e meia
tem atualização, tem novas funcionalidades.
-
Através dos feedbacks que ele
vai recebendo, ele vai atualizando.
-
- Exato.
- Tem o Product Manager gerenciando ali.
-
Exato, exato.
-
É o Product Owner na verdade.
-
Isso.
-
Que é aquele que fica ligeiro ali.
-
Vamos ver os feedback para ? vivos.
-
Mas pegando o gancho aí, você não
acha que essa cultura da cascata,
-
que temos enraizado, principalmente
nas pessoas que já trabalham,
-
já tem há um longo tempo, não criava
um buffer, um conceito de buffer,
-
de falar assim:
"Bom, eu tenho que entregar isso.
-
O primeiro objetivo é entregarmos
esse projeto esse ano.
-
Vamos construir uma fábrica nova".
-
Então as pessoas colocavam os seus
bufferzinhos lá porque elas sabiam...
-
"Olha, em teoria...".
-
Até já trabalhamos juntos,
nós sabemos disso.
-
Aí ia lá e falava assim: "Eu vou
fazer a configuração no sistema".
-
Em teoria, dura cinco dias.
-
Mas na hora que você
vai fazer a configuração,
-
aparece um Frankstein no sistema, que você
não sabe o que aconteceu, e dura 2.
-
A operação vai acabar, né?
-
Exato. Aí você vira a noite,
vira sábado, domingo.
-
Eu ia colocando aquele negócio.
-
Aquilo vai ficando cada vez mais inchado.
-
E aí às vezes o cara já está
com a tarefa pronta,
-
mas ele vai colocando 99,9,
para chegar no dia ele falar: "100"...
-
No modelo lá.
-
Quando vamos com o ágil,
quebramos tudo isso.
-
Não, espera aí, entregas curtas, todo
mundo alinhado, está todo mundo vendo...
-
- O que está acontecendo...
- Eu vou sentindo, eu preciso fazer...
-
Eu entrego um pedacinho...
-
Se eu estou enrolando,
eu estou enrolando...
-
O cara está vendo que eu estou enrolando.
-
Não tem como enrolar.
-
É tempo real.
-
- É falar se eu fiz ou eu não fiz.
- A entrega.
-
Amanhã eu tenho que entrar e falar assim:
-
eu resolvi o problema do dia anterior
que nós conversamos.
-
Eu mostrei aqui o que eu fiz,
e já estamos discutindo o novo.
-
Ou seja, não tem como eu...
-
Não tenho 99,9.
-
É ou não é?
-
É preto ou branco.
-
Não tem esse meio termo.
-
E as pessoas ainda estão,
na minha visão, relutantes de...
-
"Como que eu solto esse buffer,
essa proteção, esse negócio,
-
e passo a entregar, e passo a viver,
-
e falar se eu tenho um problema 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, 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.