F1: Está começando agora Os Agilistas. O maior podcast de agilidade do
Brasil. Para mais conteúdo sobre o episódio, acesse: www.osagilistas.com.
Novos episódios toda segunda e quinta.
Marcelo: Bom dia, boa tarde, boa noite. Vamos começar mais um episódio
dos Agilistas. Hoje vamos abordar um tema que está sempre relacionado
aqui com vários episódios e com transformação digital, que é você
conseguir tomar decisões mais orientadas a dados, as empresas se
tornarem data-driven. É aquele tipo de coisa que é fácil na teoria e difícil na
prática. Você tem que realmente empenhar um esforço grande para
conseguir fazer isso, porque isso exige uso de tecnologia, mas exige um
empenho muito grande dos times, uma mudança cultural forte também.
Para falar sobre isso, falaremos sobre um caso que aconteceu no contexto
da (WPP) e no contexto de uma ferramenta usada no processo
criativo. Então eu acho que será bem interessante, porque justamente é um
caso real, e em um contexto de criação, no qual normalmente é mais difícil
ainda de tomar esse tipo de decisão. Antes de entrar no caso, queria
apresentar os convidados. E como sempre, queria que eles se
apresentassem ao público. Primeiro, Victor Pontello. Tudo bom, Victor?
Victor: Tudo bom. Bom dia, boa tarde, boa noite para todo mundo aí
também. Um prazer participar da gravação dos Agilistas nesse tema, que
participamos desse projeto. Foi muito interessante. E que tem tudo a ver
com o agilismo. Vamos falar um pouquinho mais para frente, mas essa
convergência entre agilismo e ser data-driven, e a própria incerteza que
tem dentro dos dados. Mas, enfim, vou deixar os outros convidados se
apresentarem antes de começarmos a debater.
Marcelo: Fale um pouquinho sobre o seu background, só para o pessoal te
conhecer.
Victor: Eu sou cientista de dados aqui na DTI. Também trabalhei com
engenharia de dados e com a estratégia de dados nesse projeto, liderando
o time de dados na criação desse produto na (WPP) . Acho que é
basicamente isso.
Marcelo: Estamos aqui também com Lucas Morais. E aí, Lucas?
Lucas: Beleza? Bom dia, boa tarde, boa noite, pessoal. Obrigado, Szuster.
Eu sou o Lucas, designer de produto aqui na DTI. Faço parte da (inint)
. Entrei na DTI em abril justamente para esse projeto junto com
o grupo da WPP. E é um prazer estar aqui nos Agilistas.
Marcelo: Para começar a falar sobre, Victor, conte um pouquinho do que se
trata. Do que estamos falando?
Victor: Esse foi um projeto voltado, como o Szuster já adiantou, para a
tomada de decisão baseada em dados. Um projeto com o foco data-driven
mesmo para auxiliar no processo criativo do grupo WPP. Aí, dentro desse
projeto a ideia é ter dados de uso dessa ferramenta que auxilia no processo
de criação desse grupo, que é uma ferramenta muito importante nesse
processo de criação do grupo como um todo, e ter esses dados e conseguir
entender como as pessoas utilizam aquela ferramenta; quais ferramentas
dentro desse software que são as mais utilizadas; quais casos de uso que as
pessoas normalmente fazem para cada tipo de tarefa. Enfim, entender
melhor como essa ferramenta tão importante, e as licenças tão importantes
para o grupo são usadas, baseado nos dados que os próprios usuários estão
gerando ali. Nesse caso, o objetivo é buscar esses dados, colocá-los de uma
maneira organizada e produtizar esses dados de forma a fornecer aos
stakeholders os insights que eles precisam para a tomada de decisão com
base nesse uso e nesse processo criativo. Ou seja, tentar fazer com que o
usuário utilize a ferramenta de maneira mais otimizada para aumentar a
capacidade daquele usuário, ou até mesmo identificar alguns pontos fortes
e fracos dentro desse processo criativo do grupo.
Marcelo: Você atuou como estrategista de dados, como comentou. E o
Lucas, como designer de produto, se eu entendi corretamente. Então, acho
isso um assunto interessante de abordamos. Porque se eu entendo
corretamente – me corrijam se eu estiver errado – eu posso ter uma boa
estratégia de como analisar e capturar os dados, e talvez colher insights,
mas é uma estratégia de produto que vai me fazer pensar como eu mostro
aquilo efetivamente para quem for consumir aquilo, e faço com que
aqueles dados sejam acionados. É isso mesmo, Lucas? O papel do produto
seria esse nesse contexto?
Lucas: Isso mesmo, Szuster. Esse projeto especial exige uma parceria muito
grande entre a parte de design, a parte de dados e a equipe de
desenvolvimento de software para trabalharmos em equipe e construirmos
esse produto. No caso, como o grupo WPP tem várias empresas voltadas
para comunicação, marketing, publicidade e propaganda, eles têm um
grande número dessas licenças de software de criação. E o objetivo deles
com esse projeto era melhorar o custo-benefício com esses softwares.
Então o que a gente quis fazer foi: utilizar essa estratégia de dados em um
produto que pudesse auxiliá-los a melhorar a forma como os designers,
enfim, pessoas que trabalham com esses softwares estavam utilizando,
para que eles pudessem aumentar a produtividade. Em todo processo de
descoberta (que a gente queria fazer) do produto e tudo mais,
nós avaliamos algumas oportunidades que a gente tinha. (Uma delas)
, tentar reduzir o número de licenças, (e a outra foi o que a gente
optou), que foi otimizar a forma como as pessoas já usavam as
licenças que elas tinham. Então a gente foi por esse caminho. E no final o
que a gente conseguiu fazer foi mostrar os dados para os designers
enquanto eles estavam utilizando os softwares através de um plug-in, e
também mostrar os dados que foram coletados para os stakeholders, as
pessoas envolvidas na questão da construção do produto em dashboards
que foram construídos junto com eles, pensando no que eles tinham como
objetivo para aqueles softwares. Então foi uma colaboração muito grande
nessa área de dados e produto, e acredito que a gente conquistou um
resultado muito bom justamente por conta dessa sinergia entre os times.
Marcelo: Muito interessante isso. Não foi uma frente de dados isolada, que
fica ali trabalhando isolada tentando colher uns insights e um dia a
organização vai tentar usar aqueles insights. Aí queria que o Victor falasse
sobre isso. Logo na sua introdução você comentou isso, que havia muita
incerteza e que o uso do agilismo foi fundamental para ir reduzindo
incertezas e ir caminhando mesmo nesse sentido de ser data-driven. Você
pode entrar um pouco mais nesse tema, por favor?
Victor: Claro. Primeiro, o projeto de dados nunca existe por causa dos
dados. O objetivo de um projeto de dados, pelo menos dos projetos de
dados que tem algum sucesso, é sempre o negócio. Então o objetivo é
sempre a geração de valor com base naqueles dados. Nunca o dado por si
só. E esse sempre foi o nosso foco, de alinhar as expectativas com os
stakeholders e seguir naquele caminho. E isso também com todo o time: o
time de design e o de desenvolvimento que trabalhou em conjunto. E com
relação ao agilismo no contexto dos dados, são duas filosofias totalmente
convergentes. Porque a própria existência do dado infere ao projeto uma
quantidade de incerteza muito grande. Porque você não consegue dizer o
quão difícil vai ser aquela tarefa, ou você não consegue dizer o que pode
ser feito com os dados até o momento em que você mergulha nos dados,
os explora e vê o que tem ali, o quão difícil é fazer aquela transformação e
disponibilizar um dashboard, por exemplo, ou um relatório, ou um modelo.
Enfim, nesse contexto o agilismo ajuda muito na flexibilidade, de a gente
conseguir pegar as tarefas que tem que ser feitas, criar as histórias e
priorizar aquilo de uma forma em que, se a gente descobre algum problema
no meio do caminho, rapidamente conseguimos mudar de direção e
sempre ir corrigindo ao longo do caminho para conseguir manter um
alinhamento com o negócio e essa geração de valor alinhada com o objetivo
do projeto como um todo. Esse tipo de situação é muito interessante,
porque o contexto do desenvolvimento de software, que já é um contexto
de incerteza muito grande devido ao Mundo VUCA e todos os temas que
são tratados aqui no podcast, ainda com esse ingrediente especial dos
dados, faz com que seja uma incerteza muito grande. Inclusive é até difícil
de fazer uma estimativa de quanto tempo será gasto para fazer uma análise
de dados. É uma coisa sempre muito complexa de dizer, porque depende
do próprio dado. E aí a gente consegue ter, principalmente utilizando… no
nosso caso, a melhor alternativa que descobrimos foi fazer uma segregação
maior de tipos de história baseado no fluxo de trabalho com dados, e na
utilização do (lean kanban), principalmente devido a essa
questão de conseguirmos colocar em uma ordem de prioridade, mas não
necessariamente ter que traduzir aquele esforço em pontos de história,
enfim. E quando fomos descobrindo essa melhor forma de trabalhar, a
produtividade da equipe foi aumentando e a gente conseguiu entender
melhor aquele contexto e entregar mais valor para o cliente no final das
contas.
Marcelo: Entendi. É muito interessante isso que você falou, porque essa
atividade de ciência de dados é mais experimental por natureza, não é? Só
que ao mesmo tempo, você não pode simplesmente falar a vida inteira que
está fazendo algo experimental. Você tem que achar… mas (no contínuo, é
como você disse), o ágil já admite um nível de (incerteza)
, mas é um nível de incerteza muito ligado ao que deve ser feito.
E claro, em algumas histórias você também não tem certeza da
complexidade, faz um (spike, explora), e vai tentando descobrir
o caminho. Mas é uma atividade de natureza menos exploratória e um
pouco mais… assim: uma vez que você escolheu uma aposta, é mais fácil de
você estimar o que é aquilo, exceto em situações mais específicas. Aqui são
duas coisas: você tem que apostar em alguma coisa, e você não consegue
(chamar) muito bem também. Você consegue dar um exemplo
assim? Porque eu acho isso superinteressante. Tentar materializar mais
para quem está ouvindo o uso do lean kanban e essa segregação das
histórias. Aqui a gente tem uma obsessão em tentar sempre usar o ágil
como força de convergência. E no fundo, o que você está dizendo é isso:
mesmo nesse contexto de ciência de dados e de exploração, sem perder a
natureza exploratória dá para botar uma força de convergência ali usando
o lean kanban e essa segregação de histórias. Se puder falar um pouquinho
mais sobre isso.
Victor: Com relação à segregação de histórias, a gente percebeu que tem
uma característica muito distinta de história para história dentro do
contexto da data science. E para conseguir até aplicar o lean kanban de
maneira mais assertiva, vamos dizer assim, e conseguirmos entender
melhor o que está sendo feito ali, a gente separou o fluxo das histórias de
acordo com uma fonte grande de inspiração que usamos, que foi o (CRISPDM), que é um framework relativamente antigo, da época em
que data science ainda era chamado de Data Mining. E lá tem uma série de
tarefas, uma série de tipos de histórias que são feitas dentro de um
contexto de ciência de dados. Ele começa pelo business understanding, que
é basicamente o entendimento do negócio e esse alinhamento com o que
deve ser feito até o final para geração de valor, e isso entra como primeira
etapa. Dentro da segunda etapa, seria o data understanding, que é a
imersão nos dados para entender o que tem ali de matéria prima para
trabalharmos e conseguirmos fazer essa geração de valor alinhada no
business understanding. Depois tem o data preparation, em que você
precisa realmente refinar aquele dado e colocá-lo em uma forma em que
essa geração de valor seja possível – seja na forma de um dashboard,
relatório, modelo ou alguma tomada de decisão baseada em um indicador.
E no final, o modeling, que é basicamente a criação desse artefato com base
nesses dados todos. E estou falando aqui em sequência, mas na verdade o
próprio framework mostra que essas tarefas não são necessariamente
sequenciais. Você pode criar uma hipótese, por exemplo, no business
understanding, e no data preparation você descobre que aquilo não é a
hipótese que você queria. Por exemplo, eu queria mostrar um indicador
que eu não consigo calcular com os dados que eu tenho. Então, tenho que
voltar para o business understanding e fazer o processo de novo. Então é
um processo muito interativo. Não existe uma sequência clara. E essa
segregação das histórias facilita nisso também. Outra coisa que também
fizemos foi criar um tipo de história que seria o improvement interaction, a
interação de melhoramento. Voltando um pouquinho: a nossa ideia com
(isso tudo) é sempre, dentro de um contexto de dados, entregar
um valor e (iterar) sobre esse valor, sobre essa entrega
melhorando-a aos poucos. Ou seja, entregar o mais rápido possível e iterar
de forma que o cliente já consiga gerar valor com base naquela entrega
desde o início, e depois os melhoramentos vão aumentando esse valor
entregue. E esse improvement interaction é basicamente um resumo
dessas fases que eu citei, só que um pouquinho de cada, de forma em que
no final das contas há uma melhoria naquele artefato e esse processo cíclico
vai acontecendo de maneira que aquela entrega vai sempre melhorando e
o cliente vendo o valor daquilo.
Marcelo: Entendi. É como se (primeiro fosse) mais sequencial,
apesar de não ser obrigatório, mas você segue. E na medida em que você
avança, é como se fosse uma revisão de tudo que foi feito à luz de cada uma
dessas tarefas, não é?
Victor: Isso.
Marcelo: (E conhece melhor os diversos aspectos), e um
influencia o outro, não é?
Victor: Exatamente. Aí as vezes eu posso fazer alguma coisa nessa data
preparation, na preparação dos dados que já melhora o resultado do
artefato. Não preciso nem mexer no modeling. Ou eu melhoro a
visualização daqui que já foi calculado antes, sem precisar fazer as outras
etapas. Enfim, para cada interação o foco pode ser em fases diferentes
dessa cadeia de valor.
Marcelo: Entendi. Aquilo que é mais necessário naquela fase, naquele
momento.
Victor: Exatamente. E isso que estou falando é basicamente da ciência de
dados. além disso ainda tem a infraestrutura e a transformação dos dados,
que são tarefas mais da engenharia de dados. A gente tem provisionamento
de infraestrutura, que é a criação do ambiente em que aqueles dados vão
ficar armazenados e que vão ser transformados, e a transformação dos
dados é tirar desde aquele estado mais cru do dado até colocá-lo em uma
forma em que todo esse processo do data science possa ser feito.
Marcelo: E do seu ponto de vista, Lucas, gerindo o produto como um todo,
como fica essa integração entre essa parte de dados e a parte funcional
mesmo? São ritmos diferentes? Vocês integram essas duas coisas? Como
acontece isso na prática?
Lucas: A gente tem alinhamentos em que conseguimos sincronizar essas
entregas tanto da parte de produto quanto da parte de dados para que um
não esteja ultrapassando muito o outro, e que as (dependências)
que existem entre os times possam ser coordenadas. Então, se tem uma
dependência um time consegue entregar primeiro para que o outro consiga
seguir. E a gente utiliza muitas ferramentas para direcionar esse
desenvolvimento para os objetivos de negócio. No nosso caso, utilizamos
muito a ferramenta de árvore de oportunidades, criada pela Teresa Torres,
que é uma gerente de produtos conhecida. E o que fizemos foi basicamente
colocar esse objetivo de negócio que comentei, que era a questão do custobenefício com as licenças, em OKRs. A partir dessas OKRs, geramos
oportunidades que são os desafios que a gente quer para poder chegar
naqueles OKRs. E dessas oportunidades, nós (inint)
experimentos que podíamos fazer para escolher qual seria a melhor
história, a melhor funcionalidade a ser produzida dentro do produto. Então,
utilizando essas sincronizações entre os times para alinhas o que está sendo
desenvolvido, ajustar essas dependências e tendo essas ferramentas para
poder pegar isso tudo e orientá-las ao objetivo de negócio, a gente
consegue construir um produto que esteja com todos esses aspectos tanto
da parte de produto, quanto da parte de dados, quanto da parte de
desenvolvimento de software alinhadas em sinergia.
Marcelo: Mas ainda fiquei com uma dúvida. Como vocês fizeram para que…
vocês estavam tentando criar uma solução em que depois as decisões
seriam orientadas a dados, baseada nos dados que essa solução fosse
mostrando, ou vocês já estavam tomando decisões orientadas a dados?
Tipo, essa frente de data science estava subsidiando as oportunidades que
vocês iriam explorar nessa frente mais funcional, por exemplo?
Lucas: Houve uma colaboração principalmente na parte de pesquisa.
Dentro da área de design a gente tem essa parte voltada para pesquisa. E
aí os profissionais da área de dados, tanto o cientista de dados quanto os
engenheiros de dados nos auxiliam nessa parte também para estruturar
essa pesquisa de uma forma que fique fácil de consumir e fácil de fazer o
cruzamento das informações para chegarmos nos pontos em que
precisamos tomar uma decisão. Mas o principal trabalho deles foi
justamente na parte de como chegar no resultado final utilizando esse
produto dentro do software de criatividade, coletando os dados que são
gerados pelos designers dentro dele, e processando esses dados com as
ferramentas que eles utilizam, que a gente conseguisse mostrar para as
pessoas – que no caso eram os próprios designers, ou então os stakeholders
– quais seriam os pontos que eles poderiam melhorar para melhorar a
eficiência na utilização das ferramentas.
Marcelo: Então o trabalho era esse: coletar dados dessas ferramentas que
são distribuídas, e de alguma forma gerar os insights que permitiriam saber
o caminho a ser tomado ali né. Sendo que os insights eram normalmente
provenientes desse time de data science.
Lucas: Exatamente. As ferramentas utilizadas pela equipe de data science
auxiliam a chegar nas informações que são mais interessantes (partindo
desses) insights. Então teve uma parte mais voltada para o
stakeholders que mostrava os dados das ferramentas que são melhores
para serem utilizadas, as ferramentas que têm mais potencial de gerar
algum produto que eles consigam utilizar. Mas também teve uma parte
diferente, voltada a um objetivo diferente, que foi para os designers. Então
mostrava para ele o tipo de ferramenta que ele mais utilizava, como
poderiam mesclar essas ferramentas para poder gerar um resultado
melhor. Então, são objetivos diferentes utilizando os mesmos dados que
foram processados e mandados para essas personas diferentes.
Marcelo: Estou fazendo essa pergunta que pode até parecer meio básica,
mas é porque eu falo assim: uma coisa é um produto que já incorpora nele
certos indicadores que vão fazendo com que as decisões sejam tomadas
baseadas naqueles dados, nos indicadores. Então o produto incorpora aqui
nele. Outra coisa é: durante o processo de criação de um produto eu
embaso minha tomada de decisões em pesquisa, digamos assim, baseada
em dados. Que é o que essa (frente) está fazendo, e que a gente
sente muita falta mesmo, não é? Eu tenho falado muito que a teoria de você
estabelecer hipóteses e depois verificar se elas são verdadeiras é fácil de
entender, mas difícil de aplicar. É muito fácil de entender: ok, eu pego uma
hipótese e… por quê? Para aplicar a própria verificação da hipótese envolve
um esforço enorme, ainda mais se você quiser realmente que não seja no
feeling, que seja comprovado com dados – que é o que vocês fizeram aí.
Beleza, temos essa hipótese, mas e aí? Como eu mensuro isso? De onde eu
tiro dado? Como eu confio naquilo? Como eu meço isso depois para um
volume maior de pessoas e vejo que aquilo se confirma mesmo, para
finalmente ter certeza de que estou no caminho certo? Acho que as pessoas
subestimam o esforço para fazer isso. Você não acha, Victor? Se subestima,
e aí você investe um esforço enorme. E aí, o que eu acho que é um problema
sério? Estamos falando aqui de virar data-driven. A gente já até falou uma
vez, tem um Enzimas antigo meu que tem uma expressão que o meu pai
gosta de usar, que é assim: a gente volta às origens muito fácil. Então é
como se fosse assim: você começa cheio de boas intenções de ser datadriven, só que isso requer um esforço grande. E ainda tem tudo isso que
você falou. Além de requerer um esforço grande, tem hora em que você
nem tem certeza de quando aquela (frente) vai te dar um
resultado, porque o cara vai voltar e falar: “não deu para medir esse dado
desse jeito. Não deu para modelar aqui”. Aí, o que eu chamo de voltar à
origem? Aí o cara vira e fala: “então desenvolve mais funcionalidade aí”. Eu
acho que isso é um problema seríssimo. As pessoas subestimam isso e
desistem muito rapidamente, sendo que isso é que mostraria que estamos
no caminho certo.
Victor: Muitas vezes é quase um método científico mesmo que a gente usa
para tentar validar uma determinada hipótese. Teve até um caso muito
interessante dentro do próprio projeto: eu e o Lucas criamos uma
sequência de testes para identificarmos os casos de uso dentro do produto
que estávamos desenvolvendo, para tentar reconhecer um padrão dentro
do uso dos designers para a gente conseguir identificar através dos dados.
e fizemos várias entrevistas com designers e o Lucas tinha uma sequência
de tarefas ali que ele pedia para o designer fazer alguma atividade ali
dentro. E no final das contas a gente não conseguiu, através da coleta
normal dos dados, validar aquilo. Os dados estavam muito conturbados e a
gente não conseguia identificar muito bem o caso de uso com base no
caminho normal. A gente teve que pivotar para outra situação em que o
Lucas, baseado nos vídeos das entrevistas, conseguia identificar muitos (use
cases) . A gente consolidou esses dados em outro lugar e
utilizamos para geração de um modelo de machine learning que lia os dados
reais e conseguia identificar quais eram os (use cases) . Então a
gente criou uma distribuição de dados nova com base em vídeos para
identificar os dados reais que eram gerados realmente pelos usuários. Aí
mostra um pouquinho dessa incerteza, dessa necessidade de pivotação e
do tanto que é trabalhoso, muitas vezes. Mas, recompensador ao mesmo
tempo, porque no final das contas esse modelo não seria possível sem esses
dados gerados através dos vídeos e da experiência do Lucas, e a gente não
conseguiria utilizar o machine learning para treinar com base nesses dados
e identificar os (use cases) na situação real.
Lucas: Pode pegar um gancho no que o Szuster estava falando? Acho que
também o fato de termos profissionais de dados na equipe desde o início,
tanto cientistas de dados quanto os engenheiros de dados, nos dá uma
confiança maior e meio que empodera a equipe para poder tomar essas
decisões. Porque ela sabe que ali tem pessoas que trabalham diariamente
com aquilo, que tem a mentalidade voltada para tomar decisões com base
no que eles veem na realidade, e não na opinião das pessoas. Isso nos dá
essa confiança para poder fazer esses experimentos e mostrar (para o
cliente) : “está vendo o que a gente pegou aqui e o que está
acontecendo na realidade? É por isso que estamos tomando essa decisão”.
Então acho que esses profissionais na equipe ajudam muito.
Marcelo: Eu achei maravilhoso esse exemplo que vocês trouxeram, porque
ele ilustra exatamente isso. Pessoal, queria lembrar a todos que estão nos
ouvindo que os episódios de Os Agilitas também estão disponíveis no
Youtube. Lá você assiste a este e a outros episódios, além de ter acesso ao
conteúdo do nosso podcast de forma visual. Além de nos ouvir, agora você
pode nos assistir. É só procurar Os Agilistas, se inscrever e ativar as
notificações para receber nosso conteúdo em primeira mão. E pensa bem,
a cultura das empresas é de foco total em eficiência. O ser humano não
consegue sair disso. A gente é taylorista. Só que você está criando um novo
produto e você sabe que é exploratório, então é incompatível você querer
ser tão eficiente. Se não, você na verdade não vai conseguir explorar novos
caminhos. E aí você imagina: uma gestão tradicional pega esse exemplo do
Victor e cancela a frente de dados no momento em que os dados estavam
conturbados. “Vocês estão aqui para que então?”. Sendo que esse é que é
o ponto. Acho que uma mensagem importante aqui seria essa: o objetivo é
aprender, e para aprender você tem que errar de vez em quando. Porque
se você não está errando, obviamente você não está experimentando nada
diferente. Você está partindo só de coisa que você sabe, ou está fabricando
os resultados. Não tem jeito, esse é um ambiente de incerteza. Então, como
alguém pretende ganhar o jogo da inovação focando na eficiência somente,
e não abrindo espaço para esse tipo de comportamento? Ou seja, olha
como a experimentação é difícil. A pessoa até abre caminho para a
experimentação, mas baseado no feeling de todo mundo e fica lá meio que
deixando rolar. E um dia, talvez – é o que percebemos em muitos lugares –
o cara acorda e fala: “nossa, já gastei não sei quanto. Estou colhendo
resultados?”, justamente porque ele não botou… essa certeza ele podia ter
desde o começo. Não a certeza: essa procura pelo valor podia ter desde o
começo. Como o Lucas disse: se você tem um squad completo ali, é melhor
fazem em um ritmo mais devagar as funcionalidades e ir montando uma
estrutura que permita ser data-driven do que acelerar completamente. A
não ser que seja uma coisa muito clara, sabe? Você está migrando um
produto que você já sabe que tais funcionalidades serão usadas, sabe? A
gente nunca é radical aqui. Você tem que analisar o contexto. Mas se você
entra em uma parte exploratória, é isso que o Lucas comentou: ter junto
um time que subsidia a tomada de decisões e que consiga te ajudar a
explorar as hipóteses com mais firmeza é fundamental.
Victor: E até pegando o gancho do que o Lucas falou e que você ressaltou
agora, em um contexto de análise de dados principalmente, é muito
importante – e aí cabe um pouco às lideranças também tomarem muito
cuidado com isso – não fazer com que as pessoas que fazem o dashboard
sejam fazedores de dashboard. Porque você está perdendo uma
capacidade muito grande do profissional que está trabalhando ali, ele tem
contexto dos dados, tem acesso aos dados. Ninguém melhor que ele para
falar o que tem naqueles dados e como usá-los. E você perde essa
capacidade toda a partir do momento em que chega uma decisão topdown: “eu quero um relatório dessa forma”. Por que, então? Aí você perde
toda a capacidade desse profissional. Você deixa o profissional em um
cenário totalmente taylorista, como você mesmo disse, de simplesmente
repetir uma tarefa e criar um dashboard que foi top-down, imposto que ele
queria daquela forma com aqueles indicadores. E morre ali. A equipe fica
desmotivada porque não tem um desafio intelectual. E no final das contas
fica todo mundo insatisfeito: o cliente, porque aquele algo a mais que ele
queria, ele mesmo proibiu de acontecer; e a equipe, porque todo mundo
fica alienado em uma situação em que, ao invés de eu ser uma pessoa que
utiliza da racionalidade e dos desafios que estão ali para gerar um valor
interessante no projeto que estou trabalhando, eu fico como um fazedor
de dashboard e não coloco toda essa potencialidade para aflorar.
Marcelo: Acho curioso, porque isso traz outra reflexão: é óbvio que várias
pessoas experientes do negócio, diretores, e qualquer pessoa – você falou
da questão do top-down: um tanto de gente ali tem insights importantes.
Ter insights importantes é diferente de ter a solução para definir, ou de
impor essa solução. Isso que acho que as vezes o pessoal não entende como
ele contribui… eu falo isso muito em uma palestra da DTI que falamos sobre
(inint) eu falo: o líder continua com uma função muito
importante, é óbvio, e ele tem o direito. O cara está lá a 30 anos no negócio.
Como que ele não vai ter um tanto de insight, não vai alimentar aquele time
com insight, não vai fazer um tanto de pergunta? Mas ele quer botar todo
mundo no jogo, não quer? Para botar todo mundo no jogo, ele tem que
fazer essas boas perguntas, oferecer esses insights e deixar o pessoal usar
isso como alimento para poder testar. E não criar um time que vai virar um
entregador de dashboard. Como você disse, depois ele vai cobrar inovação,
ou vai cobrar que não tem as informações que ele precisava? Se ele estiver
medindo um time por dashboards, por exemplo? Não tem jeito.
Victor: Então a diretoria faz com que a equipe tenha que torturar os dados
até o dado falar o que ela quer ouvir. E no final das contas, eles tomam uma
decisão fake data-driven que leva ao fracasso, sendo que eles não deram a
oportunidade para os dados realmente darem as respostas.
Marcelo: Eu entendo bem o que você fala, porque eu acho engraçado. É
igual modelo de negócios em Excel, não é? Você coloca 500 parâmetros, aí
mexe em um, mexe e chega no que você quiser, não é?
Victor: Exatamente.
Marcelo: A decisão é emocional. O cara quer fazer o negócio, aí ele gera o
modelo. Aí: “se eu aumentar 0,1 aqui na receita, se eu diminuir o custo aqui,
se aumentar o crescimento aqui e não sei o que”, sempre chega aonde você
quer. Isso que eu acho curioso. Se você pensa em mais longo prazo, você
quer equipes que questionem o status quo. E aí essa equipe deveria ter
espaço para questionar esse insight desse cara que pode estar errado. Eu
falo que são lições importantes, mas é difícil. Porque a estrutura da
empresa… por isso que quando falamos de (business) (inint)
fala tanto sobre liderança. A liderança normalmente se coloca
em uma posição – e não é uma crítica à liderança, é a forma como as coisas
evoluíram – onde ela está sujeita a esse tipo de insight ser mostrado falso,
isso demonstra fragilidade. E aí essa liderança tradicional nessa estrutura
muito hierárquica não pode demonstrar essa fragilidade. Então o dado vai
ter que mostrar o que ela pensava, porque ela tem que ter certezas. E em
um mundo em que você tem incertezas, o que ela teria que ter muito mais
são perguntas. E aí deveria ser natural que várias perguntas e repostas
surpreendessem. Isso que estaria demonstrando que você está seguindo
um caminho novo. Beleza, pessoal. Mais alguma coisa que eu esqueci de
perguntar e que vocês queiram comentar e considerem relevante?
Lucas: Só trazendo: a gente fala muito sobre essa questão do ágil, a
capacidade de se adaptar. E o propósito de se adaptar é justamente para
você conseguir navegar nessa incerteza, nesse mundo com tantas
incertezas como falamos bastante aqui. E acredito que por mais que no
curto prazo você tenha essa dificuldade de provar para as empresas que
fazer experimentação, deixar espaço para as pessoas testarem coisas novas
e diferentes que podem não apresentar os resultados que elas estão
esperando, isso possa parecer um pouco intimidador para as empresas a
curto prazo, quanto mais esse prazo se estende, mais aquilo vai se tornando
algo mais do que benéfico: algo necessário. E que a (inint) de
incerteza que ela está fazendo naquele processo na verdade está
garantindo mais eficiência quanto mais o prazo se estende. Então eu não
vejo esse período de experimentação como uma ineficiência, mas sim como
um processo inicial para uma eficiência ainda maior com o prazo um pouco
mais alongado – que acredito que é o que funciona para a maioria das
empresas.
Marcelo: Perfeito. E é aquela história: a pandemia jogou na cara de todo
mundo essa necessidade de você se adaptar rápido. Então o cara não é mais
cobaia, ele não está sendo o first mover. Ele está ficando para trás. Se quiser
em outras palavras, é isso. Não fica para trás porque o tempo está
passando. Você está ficando para trás. Porque tem uma época em que o
cara acha que está sendo precipitado. Ele acha que isso é modinha, que ele
não precisa disso ainda. Só que nós já passamos dessa época. Estamos na
época em que isso tudo é extremamente necessário. Já é questão de
sobrevivência.
Victor: E nada menos eficiente do que um projeto fracassado. Então para
ter alguma medida de eficiência cabível, o projeto tem que funcionar. Ficar
tentando otimizar eficiência por eficiência nos grãozinhos do projeto, você
acaba colocando o todo em risco no final das contas.
Marcelo: São os ótimos locais que na verdade não otimizam o todo, nem o
fluxo de valor. Pessoal, muito obrigado. Gostei muito do episódio. Achei
interessante. Essa discussão de data-driven leva a ter um time de dados o
tempo todo, mas um time jogando o jogo junto com os outros times; um
time que tem um método que mesmo permitindo experimentação, permite
convergência – que é o que a gente falou no começo. É fundamental ter
experimentação, mas é fundamental ter convergência. É fundamental que
esses times tenham espaço e não virem meros executores de pedidos prédefinidos de alguém para comprar hipóteses já estabelecidas por alguém. E
é fundamental que a liderança abra esse espaço. É uma coisa que a gente
sempre deixa. Acho que foi muito bom. Muito obrigado a todos. Espero que
possamos gravar outros episódios sobre esse tema. Um grande abraço.
Victor: Valeu, pessoal. Um grande abraço. Muito obrigado pela
oportunidade.
Lucas: Valeu, pessoal.
