A História da Fórmula da Eficácia

Aqui eu conto a história do que ficou conhecido como a “Fórmula da Eficácia”. Esse texto é o prefácio do livro de mesmo nome, cujo projeto de publicação está sendo conduzido de forma iterativa e incremental.

No que diz respeito a performance com a qual conduzimos nosso trabalho, somos julgados o tempo todo e em tudo o que fazemos. Ninguém gosta de ser ineficiente: fazer o que poderia ser feito de um jeito melhor. Ninguém gosta também de ser ineficaz: não ter resolvido bem o que precisava ser resolvido. Os deuses da eficiência e da eficácia nos observam a cada instante. São eles os donos da equação que precisamos resolver para balancear “a coisa certa” com “o jeito certo”.

Comecei a desvendar essa equação em junho de 2012. Eu viajava de Mayrhofen, na Áustria, em direção a Viena. Acabara de deixar o retiro anual de líderes da comunidade Kanban. Comigo, levava uma cópia do novo livro do David Anderson: “Lessons in Agile Management: On the Road to Kanban”. O trem estava vazio, o sol morno e a paisagem do interior austríaco mantinha meus olhos entretidos, enquanto minha mente tentava criar novas conexões baseado no que eu havia vivido nos últimos dois dias. Foi enquanto eu folheava esse livro do David que tive o insight que culminou na fórmula que dá título a esse texto.

Mas eu preciso voltar um pouco mais no tempo para começar a contar essa história. Um ano antes, em maio de 2011, fui a Los Angeles para participar de uma das conferências da Lean Software and Systems Consortium (LSSC Conference, 2011). A LSSC era uma dessas conferências que você não vai para conversar sobre os problemas dos seus projetos, mas para debater sobre gestão e desenvolvimento de software como ciência, como uma disciplina que ainda precisa ser bastante melhorada. Não havia melhor lugar para eu estar.

Nesse momento, o problema que fervilhava na minha cabeça era o do “design do processo de trabalho”. Para mim, estava claro que os projetos eram sempre diferentes. Nunca existiria um projeto igual ao outro e a ideia de que poderíamos usar métodos pré-definidos como receitas de comportamento ou ação me parecia uma pressuposição incorreta. O que levava um projeto ao sucesso? O método que se usa? Ou aquele que usa o método?

Eu precisava entender o que estava por trás das metodologias, das formas de trabalho que emergiam desses projetos de sucesso. Notei uma coisa em comum: pessoas e métodos instanciavam suas ações a partir de um padrão de comportamento abstrato. Alguns chamavam essa abstração de princípios, mas, para mim, era muito mais profundo. De uma forma ou de outra, os princípios absorvem nossos valores. Temos que acordar o que valorizamos para, daí em diante, nos organizarmos para trabalhar juntos. Mas o que eu buscava não estava em princípios, estava na natureza do terreno onde o trabalho acontece. Em um lugar onde não é preciso acordo de valores; onde o terreno se apresenta como ele é.

Foi na LSSC de 2011 que eu comecei a expor a conceitualização desse terreno. As pessoas pareciam entender e os feedbacks eram motivadores. O que eu defendia era que, em nossos projetos de software, o que fazíamos era caminhar em um terreno de suposições e hipóteses. A cada passo que você dá, ocorre uma entre duas opções: ou você valida uma suposição pré-existente e, assim, torna o terreno mais sólido; ou você cria uma nova suposição, tornando o chão que você pisa menos estável. O que acontece nos projetos de verdadeiro sucesso é um fluxo constante de validação mais rápida ou mais lenta das suposições existentes. O que diferenciava um método de outro, ou uma prática de outra, era o ritmo dado a esse processo de validação, e sua manutenção ao longo do tempo.

Eu simbolizei essa ideia no almoço do primeiro dia da conferência para o Alan Shalloway, desenhando a seguinte expressão em um guardanapo de papel:

? — min(t) → !

Onde:

? representa a criação de uma suposição
! Representa a validação dessa suposição
min(t) representa o foco em minimizar o tempo entre a criação e a validação de uma suposição.

O Alan é uma das grandes mentes na área de gestão de software. Ele é autor de vários livros que cobrem desde o uso inteligente de Design Patterns em um projeto, até a uma das visões mais abrangentes sobre a aplicação de Lean para projetos de software. Enquanto conversávamos, ele se mostrou bastante interessado, empolgado até eu diria. Ele imediatamente envolveu dois outros grandes nomes: Robert Charette e Chet Richards.

A conversa com Chet foi especialmente importante porque uma das grandes inspirações para o conceito que eu apresentava vinha do trabalho do John Boyd’s e da teoria do ciclo OODA (Observe, Orient, Decide, Act), algo na qual ele era grande especialista. Foi estudando essa teoria que eu havia feito uma grande descoberta: a de que a velocidade da iteração é mais importante do que estar certo quando se itera. Isso foi o que me levou a ideia de que o fator mais relevante era, de fato, a velocidade do ciclo (representado pelo min(t) na minha expressão).

Depois dessa conversa, o Alan escreveu um post em seu blog sobre o que aconteceu e depois combinamos por e-mail que eu escreveria com mais profundidade sobre o tema. Um mês depois, finalmente consegui publicar um artigo com todos os detalhes dessa ideia. Comecei a divulgá-la como “Ciclo de Avaliação de Pressupostos”.

Depois dessa publicação, palestrei na AgileBrazil 2011 em Fortaleza sobre o assunto e, no mês seguinte, fiz o keynote de encerramento do Agile Vale em São José dos Campos para endereçar o mesmo tema. A ideia parecia fazer sentido para todos que a ouviam.

Um ano depois eu estava naquele trem, em direção a Viena. Folheando o livro do David Anderson. Ali me deparei com um artigo citando Peter Drucker e explicando sua diferenciação entre eficiência e eficácia.

Eficiência = fazer do jeito certo
Eficácia = fazer a coisa certa

Claro! Tão simples! Tão óbvio! Enquanto eficiência implica um processo de aderência, de conformidade; a eficácia indica a necessidade intrínseca de escolhas! A cada passo que damos em nossos projetos, temos várias opções, várias possibilidades de caminhos. Dentre tais opções, precisamos selecionar aquela que é correta. Em um terreno de hipóteses, não temos como selecionar a coisa certa a priori. É preciso fazer a escolha, percorrê-la. Somente depois de validarmos as hipóteses que usamos para tomar nossas decisões é que saberemos se fizemos a escolha certa, se fomos eficazes.

É um processo iterativo no nível de cada micro-ação, de cada micro-decisão que tomamos. Seja na escolha da próxima linha de código que escreveremos, ou na decisão de quem se responsabilizará pela próxima tarefa necessária para o progresso do projeto. Quando escrevo a minha linha de código, crio hipóteses. Está sintaticamente correta? Ela faz o que deveria fazer para resolver o problema que preciso resolver? Valido essas hipóteses quando compilo o programa, ou quando ele é executado pelo meu interpretador. O que é melhor? escrever 300 linhas de código e só tentar compilá-las e testá-las no final do dia? Ou escrever uma única linha e já obter feedback instantâneo sobre sua corretude?

Não é possível prever que você estará certo em cada ação que você executa, mas é possível evitar que você avance estando errado! Fazendo sempre a coisa certa, você estará constantemente mantendo o encaixe entre o que faz e o resultado que quer. Essa conclusão me ajudou a perceber que a expressão que eu usava para descrever o ciclo de validação de suposições era, na verdade, uma fórmula para a eficácia.

Esse livro é minha tentativa de articular essa ideia de uma maneira prática, sem perder o embasamento do importante modelo teórico que a suporta. Pensei em dividi-lo em três grandes ensaios:

Ensaio I: O Encaixe Problema-Solução
Ensaio II: A Narrativa da Eficácia
Ensaio III: A Estratégia do Fluxo Eficaz

No primeiro ensaio, eu vou argumentar sobre a postura necessária para ser eficaz enquanto você interage com o seu cliente para ajudá-lo a resolver problemas de negócio. O ensaio tem o título de “O encaixe problema-solução” e esse título ilustra bem o desafio que temos nas mãos quando desenvolvemos software. O ensaio apresenta duas histórias em paralelo para que o leitor entenda a real diferença entre entender ou não as implicações da eficácia na postura junto aos seus clientes.

No segundo ensaio, vou falar sobre a eficácia em suas práticas e micro-rotinas. Além disso, darei uma explicação detalhada da base teórico-conceitual da Fórmula da Eficácia. A ideia desse segundo ensaio é levar você para uma viagem ao micro-cosmo da natureza do seu trabalho e explicar porque as coisas são como são e como poderiam ser diferentes.

No terceiro e último ensaio, vamos entrar a fundo no mundo do fluxo de entregáveis de um projeto. Como entender as leis da eficácia pode nos ajudar a criar sistemas de trabalho onde as demandas fluem em alta velocidade desde o momento em que nascem até o ponto em que geram valor.

Espero que tanto o tema quanto a leitura sejam de grande valor para você.

Alisson Vale
Brasília, agosto/2017