M1: É Roberto, muito obrigado pela pergunta. Vamos explorar esse tema,
acho que é um tema bem importante, e ele está muito atrelado com essa
cultura tradicional das empresas, que no fundo nunca entendem que o
roadmap poderia, na verdade, ser a mesma referência inicial, por exemplo,
que você iria perseguindo e iria se adaptando aquilo. Mas, para ir mais
direto no ponto, a gente descobriu (dos participantes), queria
primeiro que o Felipão explorasse esse assunto. Felipão, no final das contas,
não é uma mera questão de praticar continuamente engenharia de valor?
M2: Acho, é exatamente isso. Você praticamente já deu a resposta mais
simples possível para essa pergunta, eu acho que você está certo sim. Eu
acho que a criação, a necessidade do roadmap ela surge muito, acho que a
gente pode discutir mais o assunto, com a necessidade de orçamentação,
de garantir esse sponsorship com alta liderança, mas quando na verdade,
eu acho que o time tem que enxergar o roadmap como nada mais do que
um guia inicial do que vai ser tratado como o maior valor ou quais são as
maiores hipóteses. Ele fala sobre como a gente trata isso em relação aos
feedbacks do mercado, eu acho que o feedback do mercado ele é muito
maior do que o roadmap, afinal ele é um dos princípios ágeis, adaptar a
mudança ao invés de seguir um plano. Igual você disse: ” é uma engenharia
de valor constante”; o feedback tem que gerar reflexão e esse roadmap
pode e deve ser revisto constantemente.
M1: A gente respondeu a pouco uma pergunta sobre os livros, o Vinição
citou o livro: the principles of product development flow, alguma coisa
assim, Donald Reinertsen. Uma das coisas que ele, é interessante que ele
começa o livro, se eu não estou enganado, o Vinição deve lembrar, mas ele
começa meio que falando assim: “você tem que partir do modelo
econômico correto”, digamos assim, e o modelo econômico que ele começa
é partindo do modelo de ser(cost descending) que é puxado pelo
cliente, e nesse modelo pensando em (linha), o que mais importa
é cost of delay. Ainda que isso não seja tão simples na prática, ninguém está
falando que isso é simples na prática, é como se você sempre tomasse as
decisões, principalmente em um mundo mais dinâmico, baseado no custo
que o atraso daquela funcionalidade pode trazer para você. Por que você
deixa de fazer um experimento, deixa de botar uma funcionalidade e o
custo desse atraso pode ser muito alto, mas, eu penso assim, essa é a
resposta direta, mas o que é interessante para poder tentar contribuir
bastante com a pergunta.
M3: Só complementando o que você falou, eu acho que o jeito de praticar
a engenharia de valor, é de fato através desse modelo do Donald, que ele
coloca no livro, do cost of delay, e o que ele explora muito, o que é a
explicação do cost of delay, você pode estar mitigando um risco, você pode
estar explorando um ganho que só vale naquela janela de tempo ou você
pode estar evitando um custo. Tem toda parte também de (self cost)
[00:03:05], o que vale é o que você está enxergando no presente em relação
ao cost of delay. Então, se você fez uma funcionalidade toda, está apegado
a ela, mas não que você vá fazer uma engenharia de valor, tem uma outra
coisa que você deveria finalizar em (th)[00:03:18] ou deveria priorizar, você
deveria de fato ignorar e desapegar do que você já fez, independente disso.
M2: Quer falar Regis? Você quer terminar o que você ia falar
M1: Não, pode completar.
M2: O que eu ia comentar é que existe até um modelo diferente de você
enxergar o projeto e por isso que às vezes a gente acaba caindo nas
discussões do valor que o roadmap tem para isso ou não. É que assim, o
roadmap, no fundo, é construído em cima de algumas hipóteses o que você
acha que vai ser melhor entrega que você vai fazer resolver um problema,
conseguir aproveitar uma oportunidade, quando você enxerga isso como
uma hipótese a sua primeira entrega, ela nada mais é do que a maneira que
você está confirmando a sua hipótese. Então, o que é esse feedback no
fundo, esse feedback que você está recebendo dos seus clientes, essas
solicitações mudança, essas solicitações de melhorias, elas nada mais são
do que a validação da sua hipótese, elas estão te informando se a hipótese
que você tinha sobre aquele produto que você entregou eram verdadeiras
ou não. E a gente propõe até que não seja só o feedback dos usuários, mas
que você tenha indicadores de negócio atrelado aquela entrega inclusive,
para você saber se aquela entrega confirmou ou não a sua hipótese Inicial.
Vamos dizer que esse feedback está te dizendo que a sua hipótese Inicial
estava errada ou estava incompleta, quase que irracional você continuar
com o roadmap que você tinha inicial, irresponsável você continuar com
roadmap que você tinha inicialmente. Por isso que a gente bate tanto na
tecla de que existe valor no roadmap para mostrar o que é a sua intenção,
com a informação que você tem hoje o que você espera que vai acontecer
para questões de orçamentação, aprovação, sponsorship, etc. Mas, ele
deve ser, a ferramenta deve ser usada dentro das limitações dela, se a
primeira entrega está te mostrando que a sua hipótese estava errada ou
incompleta você deve refinar sim. Eu sei que eu estou abstraindo das
dificuldades práticas, que eu acho que é isso que o Szuster estava
colocando.
M1: Não, eu sei que vocês vão concordar comigo, mas sabe o que eu acho
curioso o seguinte, pensa bem, para mim ainda um erro fundamental por
trás de tudo, porque eu acho interessante explorar o porquê isso não
acontece, porque é tão difícil. Para mim, ainda tem um erro fundamental,
que quando se faz um roadmap desses você poderia estar respondendo
uma pergunta que é o seguinte: quais os principais resultados que eu vou
buscar nos próximos meses e isso vai virar o (que é) para o meu
time, que já tem o orçamento já fundeando, dando fundos para cuidar
desse time, isso seria, para mim, um time ágil. Assim, não é, você não está
usando o roadmap para saber o preço de um sistema você nem sabe qual
é, o roadmap é mais no sentido seguinte: “olhando para esse ano nós
vamos procurar isso, isso, isso é esse o objetivo”, por exemplo. Por que eu
estou falando isso? O roadmap normalmente cumpre uma outra função,
que é dar um conforto para alguém, de quanto, possivelmente, custa
aquilo. Ele começa já assim: “quanto que custa isso? ”, e todo mundo, em
altíssimo nível, tenta dar isso. Só que por algum motivo misterioso dá
psique humano e talvez porque a empresa não fez a transição na verdade
para trabalhar ágil, aquele: “quanto que deve custar isso? Ou quanto vai
custar cada módulo? Etc. “, vira muito mais, vira uma verdade. E vira uma
verdade assim, aquilo já começa a contaminar o ágil, por isso que a gente é
tão chato com o escopo e chamam o teu episódio eu acho uma maldição
do escopo. Porque o que acontece por trás disso tudo está o seguinte, por
mais que o roadmap, vamos supor que é de um banco, então se eu achava
que ia gastar x 1000 para um modo de abertura de contas e já gastei, e
agora? Se vier um feedback disso eu peço aprovação disso ou eu consumo
dinheiro do próximo modo? Ou então, eu deveria ter feito aquele modo já
com uma reserva para esse dinheiro? Mas, se o objetivo tivesse sido
engajar, conseguir abrir tantas contas ou engajar os clientes, etc. Você
deveria ir gastando um dinheiro que é razoável para trazer aquele retorno
de negócio e continuar gastando enquanto fosse importante, e o cost of
delay, seria um cost of delay de não conseguir trazer esses clientes, por
exemplo, você está perdendo para outro banco. Mas, entende o que eu
falo? Eu falo: Por traz de isso tudo, por isso eu acho que transformação é
tão duro, porque por trás disso tudo ainda existe um modelo orçamentário.
O dia em que asempresassimplesmentetiveremos (squads) e
ela já admitiu que aquele custo é dado “eu tenho aqueles squads” e o
roadmap, se existir é mais só para dar aquela visão inicial do ano daqueles
caras e eles procuraram o resultado, você já descontaminou um pouquinho,
entendeu?
M3: E não é só, você falou o conforto da quantidade de dinheiro do
orçamento, porque o orçamento, você poderia ter o orçamento sem definir
necessariamente o que vai ser feito e quando vai ser feito. Ainda, tem um
conforto meio de reputação, é meio feio você chegar lá e falar assim: “de
fato, existe um nível de certeza muito grande em relação ao que deve ser
feito e quando deve ser feito”, é difícil de um diretor, por exemplo, chegar
e falar assim: “é, de fato, não sei ainda, exatamente, não sei nem se vai ter
que fazer isso”, então, porque você poderia definir uma orçamentação, mas
sem estar tão raciona, tão detalhado, tão cientificamente comprovando.
M: O problema maior do roadmap é essa definição do como tem que ser
feito, da minha visão, porque você falou assim: “o módulo, o módulo”, e eu
fiquei tentando trazer na memória aqui alguns projetos que eram
orientados a roadmap e realmente, eles definem módulos. Então, quando
você está definindo módulo, você está dizendo aquilo que tem que ser feito.
O roadmap deveria ter muito mais a hipótese, e essa essas hipóteses que
sejam revistas, como o Regis disse, à medida que se for recebendo
feedback, “vou fazer um módulo”, um módulo é (inint) [00:08:50 –
00:08:55], você está medindo escopo, você não está medindo resultado.
M1: Uma empresa, ela tem n times que não precisa de um roadmap para
ser justificado, mas esse time que está fazendo um software tem, por que?
Porque no fundo ela está focando no escopo do software e não, na verdade,
acreditando que ela tem um time que deve existir e entregar resultado.
Acho essa discussão importante porque veja, por trás dessa pergunta,
porque você pode falar mil vezes para o cara: “faz engenharia de valor e
tudo”, mas a conversão é lá no início do troço alguém acreditar.
M: Volta de novo no modelo Taylorista, se você parte do princípio que dá
para saber de antemão, por que você não deveria saber (que você vai
utilizar os recursos, as opções, você executa).
M1: É incrível, a empresa é cheia de time que não tem que se justificar a
existência com roadmap ou escopo não, você tem aquele time porque ele
é importante e gera valor para o negócio, e esse é mais um time. Mas, hoje
a visão de projeto que você vai lá, coloca os recursos para fazer uma coisa,
você continua indo lá pedir um dinheiro fazer aquilo, e você fala: “não, eu
estou pedindo dinheiro de forma mais genérica”, mas aquilo vira uma
sombra. Sobretudo para ser feito, porque aquele dinheiro de alguma forma
já está comprometido. Eu, realmente, acho assim, a empresa pode até não
começar assim, mas com o passar do tempo aqueles times vão tendo
sentido de existir e sabe, eles já vão automaticamente sendo. Inglês é bom
que tem os (funds), e automaticamente já vão sendo orçados
para todos os anos, e eles começam a ganhar uma certa liberdade para
começar a entregar resultado, mas eu acho que se for lá no amago da
questão é muito isso, no fundo é o diabo do escopo ali.
M: Maldição do escopo.
M1: Que está amaldiçoando. Ontem, o cliente chegou aqui para conhecer
e foi engraçado, porque ele deu uma volta e viu o cartazinho nosso, da
maldição do escopo. Na reunião eu falei: “vamos te explicar porque a gente
acha isso tão importante”, você vê isso contamina tudo e a partir disso já
começa tudo meio contaminado. Porque você tem que dar satisfação em
torno daquilo e a engenharia de valor acaba que vira um jogo secundário,
porque você já gastou um dinheirão.
