M1: Bom dia, boa tarde, boa noite. Este é mais um episódio de Enzimas,
breves reflexões que te ajudam a catalisar o agilismo em sua organização.
M2: Bom, pessoal, hoje vamos falar aqui de um tema, de uma forma
específica de fazer um tipo de transformação que é na linha do que a gente
gosta, que tem tudo a ver com o agilismo que são transformações
incrementais, não é? E aqui na dti a gente fala tanto isso que a gente gosta
até de usar uma das metáforas dos livros que a gente lê aí da transformação
ser parecida com a transformação do café com leite, onde o leite vai
misturando com o café e vai se tornando, de forma gradual, o café com
leite, não uma transformação binária, de uma hora para outra uma coisa se
transforma na outra. Apesar disso, eu vejo aí no mercado, mas eu vejo
inclusive na dti, que tem um ambiente bastante propício para isso, que
muitas vezes a gente tenta fazer essa transformação binária, de sair de um
estado imediatamente para outro. Então a gente não utiliza os próprios
métodos, não utiliza o método do agilismo, o agilismo para fazer uma
abordagem ágil. Então, por exemplo, se você está em um projeto, um
produto, um squad, um time, seja o nome que você quiser dar, um cliente
que está acostumado, por exemplo, a trabalhar com uma linguagem de
produto, por exemplo, mais tradicional, mais arcaica, mais determinística,
do tipo eu tenho um requisito, ou seja, no momento zero eu já parto do
pressuposto que eu sei exatamente qual a solução que vai funcionar para
um produto digital que a gente sabe que, na maior parte das vezes, se a
solução vai funcionar ou não é um fenômeno completamente emergente.
Então se você tem um cenário desse, e de um dia para o outro você já quer
começar a trabalhar com uma linguagem mais de discovery, de hipóteses,
partindo do pressuposto de que as coisas são hipóteses e na verdade não
são requisitos, ou seja, são hipóteses, se determinado comportamento vai
emergir ou não, ou seja uma visão não-determinística do mundo, a gente
muitas vezes quer fazer isso de um dia para o outro. Isso vale para outras
coisas. Vale para a OKRs também; a gente vai até gravar um outro Enzimas
falando de OKRs. Mas um jeito interessante de fazer isso aí é você, por
exemplo, começar a fazer o processo do café com leite, por exemplo,
pegando atividades e coisas que são parecidas com requisitos e começar a
meio que pegar e fazer um (de-para) disso, fazer uma engenharia
reversa disso e traduzir isso aí para uma linguagem de hipótese. Por
exemplo: imagina que a pessoa que é a líder do seu squad é uma pessoa
muito mais tradicional e, por algum motivo, surgiu-se a questão de começar
a trabalhar uma linguagem mais de hipótese. E aí o time está tentando
convencer essa liderança, um chefe, um gerente, alguma coisa. Logo a
pessoa que está estudando já coloca um Cagan: “como Cagan disse”, que é
um dos autores de produtos digitais, aquilo ali já provoca muitas vezes uma
reação meio “nossa, esse pessoal é muito professoral, está querendo me
ensinar o trabalho que eu já faço há anos”. Então essa é uma abordagem
que muitas vezes é muito binária, é querer mudar o negócio de uma hora
para outra. Ao passo que se você provar pela ação, por exemplo: imagina
que você está lá, que você já tem todos os requisitos, entre aspas, da
solução que você está construindo. “Vamos fazer uma tela de registro para
que determinada pessoa ou usuário solicite um determinado bem”, alguma
coisa assim, tipo uma tela do iFood ou alguma coisa assim que você está
solicitando uma coisa. Então você tem uma descrição de escopo, você tem
uma descrição da tela a ser feita. Então, ao invés de ficar falando para rodar
todo um discovery, você pode começar de forma mais pragmática e
começar a traduzir qual é a intenção daquela tela. Por que aquela tela
existe? “Aquela tela existe para diminuir a fricção, porque hoje em dia a
forma de pedir às vezes até já existe uma tela, mas ela tem cinco passos e
nesse novo formato de tela ela vai passar a ter um passo”. Ou seja, a
hipótese por trás daquilo ali é que você vai criar algum mecanismo que tem
menos fricção e vai diminuir o churn, vai diminuir o abandono da transação.
Vamos falar assim: não vai deixar a compra no carrinho, vamos falar assim.
Você vai converter a compra do início ao fim. Então essa seria a hipótese
que você está testando. A hipótese que você está testando é que se reduzir
a fricção você tem um maior nível de conversão. Então fazer isso e depois
de já ter sido feito, eu estou dando o exemplo de uma coisa, uma atividade,
mas se você começa a fazer isso para várias atividades, começa a usar esse
tipo de linguagem, é muito mais fácil, é muito mais pragmático de quem
está liderando aos poucos começar a sofrer esse processo do café com leite
e ir se transformando em algo que é mais digital, algo que é mais fácil de
ser absorvido, algo que é mais fácil de ir contra pessoas muitos céticas, e é
a transformação do jeito que a gente prega muito fortemente aqui na dti.
Então essa é quase uma dica de hoje, ou seja, faça o processo de
transformação em vários aspectos usando os princípios do agilismo de
forma incremental e de forma que você vá criando aos poucos uma cultura
de que aquilo ali passe a ser o novo normal de operação do time. É isso aí.
Valeu, pessoal.
