A "liberdade de escolha" é um princípio que rege muitas das práticas ágeis. Chamamos esse princípio de Opções Reais. O entendimento desse princípio nos permite desenvolver e refinar práticas ágeis, levando o Agile onde nunca esteve. As Opções Reais podem, inclusive, ajudar a compreender a razão que leva tantas pessoas a resistir a algumas dessas práticas.
As Opções Reais são relacionadas à ideia de "adiar decisões até o último momento responsável", um dos princípios explícitos das abordagens de Desenvolvimento Lean de Software. Ao se evitar o comprometimento antes da hora, ganha-se flexibilidade nas escolhas a se fazer mais tarde.
Olhando o Agile através das lentes das Opções Reais
As Opções Reais podem ser vistas em quase todas as práticas ágeis. Para ilustrar, vamos escolher algumas práticas do Agile e tentar encontrar em que ponto adiam-se os compromissos ao máximo. Apesar das poucas práticas exemplificadas a seguir, uma vez que se entenda a ideia das Opções Reais, será possível percebê-la em ação em diversas outras práticas.
O BDD (Behaviour Driven Development, Desenvolvimento Orientado a Comportamento) e o TDD (Test Driven Development, Desenvolvimento Orientado a Testes) oferecem muitas opções, especialmente "a opção de alterar o software, sabendo-se que não vai quebrá-lo". Sem os devidos testes automatizados, a prática da refatoração seria inviável. Pode-se dizer, em outras palavras, que o TDD elimina a necessidade de se comprometer com decisões de design. Ou seja, as decisões de design podem ser deixadas para um momento posterior ao início da codificação.
De forma mais sutil, o TDD permite ao desenvolvedor saber com certeza que o trabalho foi concluído, em vez de determinar previamente quando a programação está finalizada. O TDD não requer que nenhuma decisão seja tomada; basta parar de codificar quando os testes estiverem verdes (passarem). De forma análoga, os objetos mock permitem aos desenvolvedores adiarem decisões sobre como implementar uma classe até o momento em que tenham mais informações sobre o que de fato é necessário nela.
O XP e o Scrum também utilizam a técnica de adiar a decisão de qual história de usuário será desenvolvida, até um momento bem próximo ao início da codificação. Isso permite à equipe incorporar informações que chegam no último momento, tais como novas solicitações dos clientes. O próprio backlog do Scrum oferece um fórum no qual qualquer ideia de funcionalidade pode ser adicionada sem exigir um compromisso imediato de trabalhar nela.
No projeto em que Chris Matts está trabalhando, o desenvolvimento é priorizado com base nas requisições de clientes. Na verdade, a equipe de vendas direciona o processo de priorização ao estabelecer a importância relativa de cada cliente. A equipe de desenvolvimento não começa a trabalhar em uma funcionalidade até que os clientes a tenham requisitado. As reuniões de "estratégia" foram canceladas, pois se pareciam com tentativas de prever o futuro das funcionalidades desejadas pelos clientes. Agora a equipe espera para saber o que os clientes querem de verdade.
Ao adiar comprometer-se com as funcionalides a serem desenvolvidas, a equipe é capaz de reduzir o tempo de entrega para novas funcionalidades requisitadas. Quando o cliente pede uma funcionalidade, a equipe está livre para agir, pois ninguém está preso trabalhando em funcionalidades possivelmente indesejadas. Isso só é possível com iterações curtas e ciclos rápidos de testes de regressão.
O desenvolvimento em pares oferece opções, na medida em que mais de um desenvolvedor terá bom conhecimento sobre qualquer parte do sistema. Isso reduz o chamado "truck number", o menor número de pessoas que, se atingidas por um caminhão, colocaria o projeto em problemas sérios; também reduz muito o risco de dependência de uma pessoa chave. Ao espalhar o conhecimento do sistema pela equipe, reduz-se o efeito da saída de alguém.
Afinal, o que são Opções Reais?
Opções Reais são uma abordagem que permite se tomar decisões melhores no contexto atual. Pode parecer difícil, mas na realidade é uma forma diferente de encarar a forma como tomamos decisões. As Opções Reais apresentam dois aspectos: a matemática e a psicologia. A matemática das Opções Reais, que vem da Teoria Financeira das Opções, oferece um processo otimizado de decisões. A psicologia da incerteza e da tomada de decisões (com base na Programação Neurolinguística e na teoria do comportamento cognitivo) nos mostra a razão das pessoas não seguirem esse processo de tomada de decisões, tomando decisões irracionais como resultado.
Opções financeiras são opções escritas, e ações e participações. Uma grande quantidade de matemática foi desenvolvida para estabelecer preços e gerenciar o risco atrelado a essas opções. Opções Reais é o termo que cunhamos para descrever nossa utilização da matemática das opções financeiras para nos ajudar a tomar melhores decisões na vida real, pois é disso que as Opções Reais tratam.
Grande parte da literatura existente procura explicar como utilizar a fórmula Black Scholes para precificar opções reais. Fisher Black, Myron Scholes e Robert Merton são economistas ganhadores do Nobel que inventaram uma equação para avaliar o preço das opções financeiras. Infelizmente, a maior parte dessa literatura se torna inadequada quando aplicada a Opções Reais. Não se pode avaliar o preço das Opções Reais utilizando a famosa equação de Black Scholes. Apesar de ser necessário um PhD ou um mestrado em matemática financeira para derivar a equação de Black Scholes ou para provar a afirmação que acabamos de fazer, nenhum entendimento de matemática é necessário para utilizar os resultados dessa matemática.
As "únicas" coisas que a matemática aplicada às Opções Financeiras pode nos dizer sobre as Opções são:
- As Opções têm valor;
- As Opções expiram;
- Nunca se comprometa cedo, a não ser que se saiba porque.
Ou seja, a matemática recomenda não assumir um compromisso até o último minuto, a não ser que se saiba com certeza o porquê de tomar uma decisão cedo. Soa familiar?
O processo de decisão das Opções Reais não é novo. Preston Smith foi um dos pioneiros a cunhar a frase "Assuma um compromisso no último momento responsável", no livro "Flexible Product Development". A afirmação de Smith era uma opinião com base em diversas observações, porém as Opções Reais têm fundamento na matemática financeira.
No verão de 2006, apresentamos uma série de sessões sobre Opções Reais, e um dos participantes, Iain Brocklehurst, gerente sênior de TI na JP Morgan, disse "Isso é apenas bom senso enlatado". As Opções Reais, apesar de fundamentadas na matemática, têm foco nos aspectos psicológicos da tomada de decisão, aspectos que são provavelmente mais importantes que os matemáticos. Sem o entendimento da psicologia, a maior parte das tentativas de implementar um novo processo de decisão falhará.
Escolhas
Dada qualquer decisão a ser tomada, surgem naturalmente três categorias de decisão como possíveis escolhas: a categoria das "decisões corretas", a das "decisões erradas" e a das "sem decisão". A maioria das pessoas costuma achar que existem apenas duas: ou se está certo ou errado. Como normalmente não se sabe qual a decisão certa, a melhor opção acaba sendo não tomar decisão, de forma que o compromisso seja adiado até que se tenha mais informações, para que uma decisão mais bem embasada possa ser tomada.
Contudo, ao se observar o comportamento da maioria das pessoas, percebe-se que há quase uma aversão à incerteza, induzindo as pessoas a tomar as decisões cedo demais. As Opções Reais tratam essa aversão à incerteza ao definir a data exata para uma decisão, ou as condições a serem cumpridas antes que a decisão possa ser tomada. Em vez de dizer "ainda não", a abordagem das Opções Reais diz "tome a decisão quando...", dando às pessoas a certeza sobre quando a decisão deve ser tomada, e criando certo conforto em adiar as decisões. Adiar o momento de comprometimento dá aos tomadores de decisão mais flexibilidade, na medida em que eles continuam a ter mais opções, e podem gerenciar os riscos e a incerteza na utilização dessas opções.
As Opções Reais estão relacionadas não à tomada de decisões, mas sim a comprometimentos. É bastante comum que se tome decisões que levam a um comprometimento emocional em relação a uma ideia, não percebendo que ainda se pode mudar de perspectiva.
As Opções Reais não parecem inicialmente algo natural ou intutitivo. Algumas pessoas adotam a ideia naturalmente, já outras necessitam de ajuda, tempo e treinamento para chegar lá. Talvez seja como o Agile? Talvez o sentimento de falta de naturalidade dessa incerteza seja uma das razões pelas quais algumas pessoas se opõem ao Agile.
Marcar para sair com um amigo é uma opção ou um comprometimento? Muitos dirão que é um comprometimento, pois há um acordo com tal amigo; mas na realidade trata-se de uma opção. Caso algo aconteça que ofereça valor maior (como um convite da pessoa dos seus sonhos), pode-se conversar com o amigo e remarcar. Um acordo é uma opção.
As opções financeiras possuem data de expiração definida contratualmente (data na qual terminam ou expiram). A data de expiração das Opções Reais é a habilidade de adiar uma data de expiração de uma opção, dando mais tempo para que uma solução ótima seja encontrada. Ou seja, existe valor em pagar para postergar o comprometimento.
Exemplos nos negócios
As práticas apresentadas já se encontram em uso; afinal não há nada novo nisso. Três empresas conhecidas utilizam essa abordagem com sucesso: Toyota, Microsoft e Google. A Relação da Toyota com opções é bem documentada no livro sobre "Desenvolvimento Lean de Software" de Mary e Tom Poppendieck. A Toyota é famosa por esperar que um cliente compre um carro antes de começar a fabricá-lo, adiando ao máximo o comprometimento.
A relação da Microsoft com as Opções Reais também é bastante conhecida, como na famosa exposição comercial na qual o estande da Microsoft mais parecia um bazar. Enquanto as outras empresas apostavam em um único produto ou estratégia, a Microsoft estava se defendendo de forma que ainda pudesse vencer a batalha para ganhar a automação de escritórios, mesmo que perdesse na batalha dos sistemas operacionais.
A Microsoft parece ter se tornado a mestre na arte de esperar, esperar e esperar, para definir sua estratégia. Veja o caso do Internet Explorer, em que a Microsoft esperou até que a internet tivesse se consolidado como tecnologia antes de entrar nesse mercado. A questão que gostaríamos de saber a resposta é: "Quantas equipes de desenvolvimento e soluções a Microsoft levou em conta quando enfrentou essa crise?" Será que adotou a tradicional "otimização de custos" como melhor abordagem, ou procurou diversas alternativas? A resposta parece óbvia.
Por outro lado, o Google é uma das primeiras empresas "informacionalistas": em vez de entrar em conflito com seus clientes, a empresa coopera com eles. Não mostra banners com anúncios aleatórios, e sim a publicidade de produtos e serviços em que o usuário pode estar realmente interessado.
O futuro do Agile
Costuma ser fácil destruir as opções das outras pessoas. Dessa forma, as Opções Reais funcionam de maneira mais efetiva se todos os participantes cooperarem entre si, o que acaba sendo contrário à pratica comum de não revelar nossas intenções. Pode-se, contudo, tirar lições da abordagem do Google, afinal de contas, como alguém pode lhe ajudar se não souber o que você pretende? Talvez esse devesse ser o ponto de partida de muitas das práticas gerenciais do Agile.
É preciso aprender como ficar antenado para compreender o que as pessoas precisam, de forma que possam ser ajudadas em seus objetivos. Ironicamente, "escutar" é uma palavra que não aparece na "Declaração de interdependência" da APLN (Agile Project Leadership Network). Os líderes devem oferecer e criar opções para as pessoas que trabalham com eles, em vez de tomar a decisão no lugar deles.
As Opções Reais são um conjunto de princípios que validam certas práticas, como vistas acima, e podem ser utilizadas para criar novas práticas. No presente momento, o Agile precisa desenvolver práticas de liderança e de gestão (indo além da gerência de projetos), que deem apoio à mentalidade ágil, com o intuito de ampliar sua ação para muito além do departamento de TI.
Para citar alguns exemplos de como isso pode funcionar, vamos analisar processos para tomada de decisão e gestão de recursos.
Processos de tomada de decisões
O processo otimizado para tomada de decisão deveria ser assim:
1. Para cada decisão, identifique as opções disponíveis.
Identifique o último ponto em que uma decisão pode ser tomada. Por exemplo, as condições para se comprometer, o que é calculado a partir da data limite para a implementação da opção e então trabalhado de trás para frente até o ponto de decisão. A primeira decisão é tomada quando a primeira opção expirar.
2. Até essa data, continue procurando por novas opções.
Procure adiar o hora de tomar a decisão, o que comumente não apresenta custos ou se apresenta, são muito baixos. Para conseguir isso, é necessário ser capaz de implementar uma opção o mais rápido possível. Durante o tempo de folga, trabalha-se em como acelerar o processo (exatamente como a Toyota faz em suas fábricas)
É importante entender que otimização de custos não é a mesma coisa que otimização de receita ou redução de riscos. Algumas vezes vale a pena investir em mais de uma opção, mesmo que custe mais; afinal de contas, as próprias opções têm valor.
Espere para tomar decisões até que as condições sejam ideais. Quando se precisa assumir um compromisso e agir, aja o mais rápido possível e com confiança, pois você sabe que a decisão foi feita com o maior embasamento possível.
Veja a experiência de Chris Matts com algumas dessas ideias:
Estive recentemente em uma reunião em que era discutida a necessidade de um "Plano B". Estava se discutindo se havia mesmo a necessidade desse plano. Ninguém sabia ao certo as chances de sucesso do plano principal; alguns achavam que era 99%, outros 50%, entre outros percentuais. Aplicamos a abordagem das Opções Reais e buscamos primeiro identificar qual seria o ponto ideal para migrar para o "Plano B" caso fosse necessário. Também identificamos todo o investimento prévio necessário para tornar o Plano B uma opção.
A princípio parecia que o esforço seria de dez minutos, mas foram necessários alguns dias, devido ao grande número de passos e departamentos envolvidos. Colocamos a opção do Plano B em ação e fizemos um rascunho desse plano. O Plano A acabou não dando certo, e sabíamos exatamente o momento correto para migrar para o Plano B. Todos sabiam o que deveria ser feito, e a mudança foi um processo tranquilo. Em vez de tarefas urgentes e do caos que isso resultaria, o Plano B aconteceu tão suavemente que muitos nem perceberam que mudamos de rota no último minuto.
Uma das maiores lições que tiramos das Opções Reais foi que o momento correto para decidir se uma ideia é boa ou não é após ter experimentado com ela.
Gestão de recursos
As Opções Reais, quando aplicadas à gestão de recursos, mostram que os recursos devem ser alocados partindo dos menos para os mais experientes, em outras palavras, os integrantes mais experientes da equipe com mais opções (mais habilidades etc.) deveriam ser alocados por último.
Assim, os mais experientes podem ser utilizados para tratar quaisquer problemas que surjam. Enquanto não forem alocados, podem ensinar os menos experientes (criar opções) pareando com eles. Isso garante que boas práticas possam ser mantidas e que uma a arquitetura do sistema seja acompanhada de perto. Essas pessoas mais sênior podem ser o Gerente de Projetos ou o desenvolvedor líder, e devem aprender a ser "preguiçosos" - um bom começo é ler o livro "Slack" de Tom DeMarco.
Executivos devem adotar uma estratégia de investimento fundamentada em opções ao invés de se comprometerem com os orçamentos de projetos. Devem adiar o comprometimento de investir todo o orçamento, até que possam ver o sucesso de um investimento inicial ou a validação de um "business case". O investimento deve ser feito para cada release com base em algum critério de sucesso. O sucesso não deve ser relacionado ao desenvolvimento, mas sim a um projeto de negócio, como por exemplo aumentar o valor do negócio.
Um projeto em que o desenvolvimento de funcionalidades custa o dobro do valor estimado inicialmente deveria ser considerado um sucesso se o aumento de receita for grande o suficiente. Da mesma forma, o projeto perfeito, que custa metade do estimado deve ser engavetado se não gera receita suficiente. Os executivos devem ser capazes de aumentar o investimento em um projeto se este estiver indo bem. Para isso, é preciso a "liquidez" do pessoal de desenvolvimento, o que é facilitado pela gestão de recursos fundamentada nas Opções Reais.
Por fim, os executivos em uma empresa relacionada a TI devem avaliar a possibilidade de adotar o desenvolvimento voltado ao cliente, no qual clientes reais escolhem e priorizam as funcionalidades (clientes externos à empresa, não os do XP, que são parte da equipe do projeto). Para tanto, as equipes de vendas e de desenvolvimento devem ser integradas.
A equipe de vendas se encarrega de dar um cardápio "a la carte" de funcionalidades (opções) aos clientes, em vez de uma lista de funcionalidades para a próxima entrega. A equipe de vendas oferece qualquer coisa no cardápio, ou a opção de escolher até algo que não esteja listado. Para introduzir novo item, a equipe faz brainstorms de funcionalidades, faz apenas o mínimo de análise para chegar ao Takt Time daquela funcionalidade e identifica os principais riscos. À equipe de vendas são passadas as estimativas dos Takt Times para que possam fazer melhores ofertas aos clientes. Dese modo, só se desenvolve o que os clientes escolherem, de forma que se evita o desenvolvimento de 67% das funcionalidades identificadas no Standish Chaos Report como "Raramente ou nunca utilizados".
Essa é a abordagem que temos utilizado em nossos projetos. A equipe de vendas está muito satisfeita, pois ao invés de vender aos clientes funcionalidades que não desejam, é dada a oportunidade de os clientes dizerem o que querem. Temos visto a equipe de vendas começar a convidar a equipe do projeto para reuniões com os clientes, com o intuito de que a abordagem seja melhor explicada.
Há muitas práticas a se descobrir
Um ponto ao qual ficar atento é que as Opções Reais é uma estratégia ativa de gestão de riscos. É necessário monitorar constantemente o portfólio de opções para garantir que não sejam destruídos. Além do mais, esse é um processo que consome muitas informações, demandando do praticante que as busque ativamente. Lembre-se também que não fazer nada também é uma opção, que deve ser vista como parte de um processo ativo de decisão. A abordagem de Opções Reais não é uma desculpa para a procrastinação.
Conclusões
O conceito de Opções Reais é subjacente ao Agile. Muitas das práticas ágeis adiam as decisões o máximo possível. Empresas de sucesso como Toyota e Google estão tirando proveito da utilização desse princípio, e Opções Reais oferecem a habilidade de projetar a mentalidade ágil em áreas até agora intocadas.
Uma última observação: no ano passado, Chris Matts (coautor deste artigo) se encontrou com uma amiga em um bar em Londres. Diferentemente da maioria das pessoas, essa amiga"captou" a ideia das Opções Reais imediatamente. Nos próximos minutos identificou muitas das suas implicações e concluiu que "são para ajudar a criar um lugar melhor para se trabalhar". Ela está correta em parte, mas há muito mais que isso!
Sobre os autores
Chris Matts é gerente de projetos e analista de negócios, com mais de dez anos de experiência no desenvolvimento de sistemas financeiros, para os bancos JP Morgan Chase, BNP Paribas e Dresdner Kleiwort Wasserstein. Foi desenvolvedor e possui mestrado em Matemática aplicada a Trading e Finanças, incluindo matemática de opções financeiras.
Olav Maassen é engenheiro chefe na empresa QNH e possui nove anos de experiência em TI, trabalhando com projetos para instituições financeiras. É coautor do livro "Applied Java Patterns". Seu principal interesse é ajudar as equipes a desenvolverem software mais efetivamente. Busca intensamente a melhoria contínua tanto para ele quanto para quem trabalha com ele.
No momento, Matts e Maassen estão escrevendo um livro sobre as Opções Reais.