quando você tem as informações que precisa
para tomar a decisão de comprometer-
se de verdade.
Uma opção é uma escolha, uma decisão de escolher uma estratégia em vez da
outra, de escolher um caminho em vez do outro, de comprar um produto em vez do
61
3.12. Mantenha as Opções Abertas
Casa do Código
outro, de trabalhar em uma funcionalidade em vez de em outra. Cada uma dessas
escolhas tem um retorno sobre o investimento. O desafio é trabalhar com a opção
que tiver o melhor retorno sobre o investimento.
A diferença principal entre compromissos e opções é que podemos mudar de
escolha de opções sem custo algum, ou com um baixo custo, mas mudar um com-
promisso, geralmente, gera custos ou problemas caso ele não seja cumprido. Temos
o custo da opção e o retorno sobre o investimento que cada uma oferecer.
O mais interessante é que há valor nas opções que conhecemos e naquelas que
não conhecemos também. Por isso é sempre importante considerar todas as opções
possíveis e procurar aprender sobre opções até então desconhecidas antes de se com-
prometer com uma determinada opção.
Decidir no último momento possível (não confundir com negligenciar) é um
dos princípios de Lean Software Development, e também é algo que faz parte de uma
série de práticas utilizadas em equipes ágeis como Refactoring e Design Emergente (o design não é definido de antemão mas vai evoluindo ao longo do desenvolvimento),
Planejamento Iterativo (a equipe se compromete apenas com as histórias de usuário
de um iteração e o resto do backlog torna-se uma opção para o Product Owner; essas
histórias podem ou não se tornar uma obrigação se incluídas no planejamento da
próxima iteração), Incrementos Potencialmente Entregáveis (O PO pode exercer ou
não a opção de fazer um release do resultado de uma iteração) etc.
Já com métodos tradicionais, o cliente precisa decidir sobre todo o escopo de an-
temão, e se precisar de alterações terá custos extras, por isso, é levado a tomar uma série de (más) decisões antecipadas, e esse mesmo erro permanece no Big Requirements Up Front e no Big Design Up Front.
Muitas pessoas preferem estar erradas do que estar em dúvida. Por isso, acabam
tomando decisões ruins, por serem precipitadas [30]. Opções Reais nos apresentam
uma melhor forma de lidar com nossas decisões.
Três regras das Opções Reais:
1. Opções são valiosas: Opções são valiosas porque podem ser executadas. No
exemplo do ingresso do cinema, para o comprador é uma opção que está justamente
na possibilidade de entrar na sessão para ver o filme. O valor está em ter opções em poder escolher.
2. Opções expiram: Opções têm um tempo de vida, no caso do ticket de cinema, ele só vale durante o tempo do filme, após a sessão do filme, a opção perde seu valor, independente de ser sido exercida ou não.
3. Nunca se comprometa cedo, a menos que saiba o porquê: Quando você se
62
Casa do Código
Capítulo 3. Foco em Valor para o Negócio
compromete com uma opção está abrindo mão de todas as outras e do valor que elas
podem oferecer. Quando nos comprometemos cedo demais, há um grande risco de
não conhecermos todas as opções ou não escolhermos a melhor.
Injeção de Funcionalidades
Muitos projetos começam com uma grande lista de funcionalidades abstratas a
serem desenvolvidas e, então, o time precisa correr atrás de um valor de negócio
pouco claro e desconhecido. Ou seja, é como se soubessem que têm que correr, mas
não soubessem a direção e nem por que estão correndo.
Quando alguém lhe pede para alterar algo da interface de usuário, por exemplo,
qual é o valor que está por trás dessa mudança? Reduzir o tempo do Processo? Ga-
nhar novos Usuários? Reduzir a chance de que um erro aconteça? Quando o cliente
diz Preciso que seja incluído o Campo X no Sistema, você sabe o motivo? Que valor está por trás disso? Será que isso realmente vai agregar algum valor? Para quem? De que forma?
Às vezes o PO dá ênfase no como em vez de enfatizar o porquê. Mas se isso
for invertido, e o PO trouxer o porquê, junto com o time, podem chegar a um como
muito melhor.
A Injeção de Funcionalidades é um Processo de Análise de Negócios criado por
Chris Matts com base na Teoria das Opções Reais para resolver esse problema. O
processo possui três passos bem simples.
1. Persiga o Valor de Negócio
Quando o valor de negócio não está claro, as equipes não podem buscar for-
mas diferentes e mais eficientes de se conseguir o valor. A funcionalidade pode ser entregue, porém de forma distorcida e não levar o valor que era esperado.
A Injeção de Funcionalidades (em inglês Feature Injection) propõe que tudo co-
mece com um modelo de entrega de valor [6], como por exemplo: Nós esperamos
que o tempo médio de faturamento reduza de 20 minutos para 5 minutos, que o nú-
mero de colaboradores dedicados ao processo reduza de 100 para 40, e a quantidade
de emissões incorretas reduza de 900 notas fiscais para 100 notas fiscais.
Um modelo como esse permite que o time avalie as funcionalidades que estão