A FÓRMULA DA EFICÁCIA

(1)

A FÓRMULA DA EFICÁCIA

COMO FAZER A COISA CERTA NO SEU PROJETO DE SOFTWARE

ALISSON VALE

(2)

(3)

SUMÁRIO

Prefácio ix

PARTE I

O ENCAIXE PROBLEMA-SOLUÇÃO

1.A principal medida de progresso 3

2.Foco no problema 13

3.Qual é a sua capacidade? 24

4.Ceticismo 32

5.Quanto custa não fazer o que precisa ser feito? 42

6.A busca pelas pessoas certas 54

7.O poder e a política 63

8.Epílogo: Em busca de significado 68

PARTE II

A EFICÁCIA EM ESSÊNCIA

9.Por que deveríamos nos importar com nossas

suposições? ⁷⁷

10.As suposições trazidas pela nossa forma de

pensar ⁸⁸

11.Resolvendo o problema da eficiência 101

12.Em busca da gestão eficaz 115

13.O design do processo 130

PARTE III

APLICANDO A FÓRMULA DA EFICÁCIA 14.Entendendo os trade-offs da Fórmula da

Eficácia ¹⁴³

15.Hipóteses em cada linha de código 148 16.Garantindo que o software faça a coisa certa 168

17.Visualizando o sistema 186

18.Lidando com handoffs e filas 201

19.A coordenação tática 217

20.Estamos entregando o produto certo? 231 21.Estamos fazendo do jeito certo? 253

(4)

Conclusão: Uma nova Thinking Tool 274

Sobre o autor 279

Agradecimentos 283

(5)

1a. Edição.

http://softwarezen.me

Texto revisado por: Nathalia Barboza

Dados Internacionais de Catalogação na Publicação (CIP) (Câmara Brasileira do Livro, SP, Brasil)

___________________________________________________________

Vale, Alisson

A fórmula da eficácia: como fazer a coisa certa no seu projeto de software / Alisson Vale. -- Brasília, DF: Software Zen, 2020.

ISBN 978-65-00-04973-2

1. Administração de projetos. 2. Gerenciamento de configurações de software. 3. Software - Desenvolvimento. I. Título.

20-38490 CDD-005.1068

__________________________________________________________

Índices para catálogo sistemático:

1. Software: Desenvolvimento: Projetos:

Gerenciamento: Ciência da computação 005.1068

Cibele Maria Dias - CRB-8/9427

Todos os direitos reservados. Nenhuma parte dessa obra poderá ser reproduzida ou transmitida por qualquer forma e/ou quaisquer meios (eletrônico ou mecânico, incluindo fotocópia e gravação) ou arquivada em

qualquer sistema ou banco de dados sem permissão escrita do autor.

(6)

(7)

para Felipe,

a quem tenho o orgulho de poder chamar de filho.

(8)

(9)

PREFÁCIO

No que diz respeito à performance com a qual conduzimos nosso trabalho, somos julgados o tempo todo e em tudo o que fazemos. Ninguém gosta de ser ineficiente: não ter feito de um jeito melhor. Ninguém gosta também de ser ineficaz: não ter resolvido bem o problema que precisava ser solucionado.

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 “o jeito certo” com “a coisa certa”.

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 autografada do recém- lançado livro do David Anderson: “Lessons in Agile Mana- gement: On the Road to Kanban”¹. O trem estava vazio, o sol morno. A paisagem do interior austríaco mantinha meus olhos entretidos enquanto minha mente tentava criar novas conexões para o que eu havia vivido nos últimos dois dias.

Ao folhear o livro, um dos artigos me chamou a atenção.

Ele mencionava Peter Drucker e, depois de lê-lo, foi como se, subitamente, dezenas de pontos se conectassem na minha

(10)

cabeça formando um novo padrão coerente de entendi- mento. Naquele momento, eu fora inundado por uma sensação de intensa clareza em torno de várias questões e problemas conceituais que tentava resolver. Uma verdadeira epifania que culminou no trabalho que você está lendo agora.

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ên- cias do Lean Software and Systems Consortium². Esse é o tipo de evento 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 disci- plina que ainda precisa ser bastante melhorada. Não havia melhor lugar para eu estar.

Naquele 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 igual ao outro. A ideia de que poderíamos definir receitas detalhadas sobre como agir a priori me parecia uma pressuposição incorreta. O que levava um projeto ao sucesso?

O método que se predefine para ele? Ou o método que é construído ao longo dele?

Eu precisava entender o que estava por trás das metodolo- gias, das formas de trabalho que emergiam desses projetos de sucesso. Um método é um modelo abstrato para o agir. Ele é então instanciado e utilizado como ferramenta para resolver problemas de organização e coordenação do trabalho. Eu acreditava que, logo a partir do primeiro dia do projeto, o método não estava mais sendo implantado. Ele estava sendo construído. Não era mais uma abstração, mas a expressão do agir enquanto se tenta dar soluções para os problemas dos clientes envolvidos. Uma expressão única e especialmente x | Prefácio

(11)

moldada pela necessidade das pessoas lidarem com as carac- terísticas específicas do ambiente em que atuam.

Essa atividade de “design do processo de trabalho”

parecia respeitar uma lei universal. Foi na conferência do LSSC de 2011 que eu comecei a expor a conceitualização dessa ideia. 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 preexistente 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 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 apresentei essa ideia no almoço do primeiro dia da conferência para o Alan Shalloway. Desenhei 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é uma das visões mais abrangentes sobre a aplicação de Lean para Prefácio | xi

(12)

projetos de software. Enquanto conversávamos, ele se mostrou bastante interessado, eu diria até empolgado. 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 à ideia de que o fator mais relevante era, de fato, a velocidade do ciclo (repre- sentada pelo min(t) na minha expressão).

Depois dessa conversa, o Alan escreveu um artigo³ 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 conferência Agile Brazil 2011 em Fortaleza sobre o assunto. No mês seguinte, fiz o keynote de encerramento da conferência 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 dife- renciaçã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 xii | Prefácio

(13)

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 microação, de cada microdecisã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? Quando eu valido essas hipóteses? Não seria quando eu compilo o programa ou quando o executo pelo meu interpre- tador? 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 validade?

Não é possível prever que você estará certo em cada ação que 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 vali- dação de suposições era, na verdade, uma fórmula para a eficácia.

Esse trabalho é minha tentativa de articular essa ideia primeiramente de uma maneira mais prática, com uma histó- Prefácio | xiii

(14)

ria, e depois de forma mais profunda e conceitual, embasando assim o importante modelo teórico que a suporta.

O livro está dividido em três partes:

Parte I: O Encaixe Problema-Solução Parte II: A Eficácia em Essência

Parte III: Aplicando a Fórmula da Eficácia

Por meio dessa estrutura, 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. A primeira parte tem o título de “O Encaixe Problema-Solu- ção”, o que ilustra bem o desafio que temos nas mãos quando desenvolvemos software. Aqui apresentarei duas histórias em paralelo. A busca é para ressaltar, via contraste, as sutilezas que se apresentam na forma como os projetos são conduzidos nas duas narrativas. Enquanto uma história destaca os problemas que emergem por causa do tipo de relação que se forma com o cliente ainda antes do projeto, a outra vai ajudar a entender o caminho para a solução: gerar valor para o cliente antes mesmo de escrever a primeira linha de código.

Na segunda parte, eu vou trazer uma perspectiva conceitual mais profunda que nos ajudará a entender o que realmente queremos dizer quando falamos de eficácia, e como isso se desdobra no mundo. Vamos investigar uma dramática transição que estamos vivendo nesse novo milênio em termos de forma de pensar (Capítulo 10); entender como resolver o problema da eficiência, introduzindo o conceito de Eficiência de Fluxo (Capítulo 11); as componentes envolvidas quando pensamos em adotar uma gestão orientada à eficácia (Capí- tulo 12); e entender a necessidade de assumirmos a responsa- bilidade para projetar os nossos próprios processos de trabalho (Capítulo 13).

xiv | Prefácio

(15)

Na terceira parte, explicarei a fórmula com mais detalhes e exemplos. Avançaremos nas várias atividades práticas que desempenhamos em projetos de software para mostrar como a Fórmula da Eficácia pode ajudar a desenhar um processo de trabalho eficaz para o seu time. Discutiremos as implicações da eficácia no código que os programadores escrevem (Capí- tulo 15) e nos testes que fazemos em nossos produtos (Capí- tulo 16). Também veremos o impacto de “ver” o sistema de trabalho e suas implicações na eficácia do que fazemos (Capí- tulo 17). Aprenderemos como lidar com a situação de passagem de trabalho entre os membros de uma equipe ou entre equipes diferentes (Capítulo 18).

A questão de como nos organizamos taticamente para fazer o trabalho fluir será essencial para entendermos o dina- mismo do jogo que estamos jogando em nossos projetos. O que eu chamo de Coordenação Tática será o tema do Capítulo 19. Por fim, eu tentarei ajudar a responder duas perguntas:

“Estamos entregando o produto certo?” (Capítulo 20) e

“Estamos fazendo do jeito certo?” (Capítulo 21). Na primeira, vamos mergulhar nas técnicas e práticas que nos ajudam a garantir que estamos realmente desenvolvendo o que os nossos clientes precisam. Para responder à segunda pergunta, vamos explorar a filosofia do Pragmatismo proposta nos EUA no século XIX, mas que hoje explica muito do que fazemos no dia a dia. Essa será a base filosófica que vai nos ajudar a entender como melhorar os nossos projetos de forma continuada.

Espero que essa jornada rumo à eficácia se converta em muitos frutos positivos para você, para os seus times e para sua empresa. Não só nos possíveis resultados que vocês vierem a obter a partir da sua leitura, mas também em toda a sabedoria e discernimento que ele vier a lhe acrescentar durante a jornada.

Prefácio | xv

(16)

É hora de começar a desvendar a arte de fazer a coisa certa, somente a coisa certa.

Boa leitura!

Alisson Vale Brasília, agosto/2017

1. ANDERSON, David J. Lessons in Agile Management: On the Road to Kanban. Seattle: Blue Hole Press, 2012.

2. LSSC CONFERENCE. Lean Software & Systems Conference. Los Angeles, 2011. Disponível em: <http://lssc11.leanssc.org/conference/>.

Acesso em: 18 ago. 2017.

3. SHALLOWAY, Alan. Relationship between Assumptions, Risks and Flow (delay). [S.l: s.n., 2011] Disponível em <http://www.leanssc.org/

2011/05/lssc11-relationship-between-assumptions-risks-and-flow- delay/>. Acesso em: 18 ago. 2017.

4. VALE, Alisson. Cycles of Assumptions Evaluation. [S.l: s.n., 2011]

Disponível em <http://www.alissonvale.com/englishblog/post/Cycles- of-Assumptions-Evaluation.aspx>. Acesso em: 18 ago. 2017.

xvi | Prefácio

(17)

SOBRE O AUTOR

Alisson Vale vive em Brasília, Brasil. Seu trabalho é ajudar pessoas e empresas em todo o país, e no exterior, a melho- rarem os resultados que obtêm de seus projetos de software via diminuição de custos, eliminação dos atrasos, melhoria na qualidade e na satisfação de clientes e das equipes envolvidas.

Começou a desenvolver software aos quinze anos. Depois de trabalhar em várias iniciativas nessa área, principalmente no setor governamental, iniciou seu primeiro empreendi- mento em 1999. Em 2004, fundou a Phidelis, uma empresa focada em produtos para escolas e faculdades privadas. Um ano antes disso, teve seu primeiro contato com o Manifesto Ágil, começando um processo de estudo e aplicação das várias práticas e métodos que incorporavam essa filosofia.

Esse foi o início de um novo modo de pensar o trabalho do conhecimento e também de toda uma nova forma de trabalhar a engenharia de código e design de produtos de software.

Em 2008, sua empresa estava crescendo e métodos Ágeis tradicionais — a maioria deles orientada mais para o desenvolvimento de novos produtos — não estavam lidando bem com o novo terreno de complexidade na qual a empresa estava operando. Procurando uma resposta, encontrou o Kanban, um método para design evolucionário de processos em organizações. O Kanban lhe permitiu não apenas manter as conquistas trazidas pelos métodos Ágeis, mas também

(18)

adaptar sua organização para sobreviver a um ambiente mais complexo.

Em 2009, depois de ser apresentado a um dos criadores do método Kanban para desenvolvimento de software, David Anderson, foi convidado para apresentar os seu estudo de caso na primeira conferência sobre o tema nos EUA. Foi em Miami, e foi memorável, pois marcou o início de um movi- mento que claramente mudou o mundo da gestão de software desde então.

Em 2010, palestrou em Atlanta, onde ocorreu a confe- rência de Kanban do ano seguinte. Nessa conferência, teve a imensa satisfação de ser premiado com o prêmio Brickell Key Award, que até hoje é dado anualmente a quem se destaca no assunto no mundo todo. Esse prêmio é oferecido àqueles com

“conquistas e contribuições excepcionais a comunidade”.

Desde então tem usado Kanban nas várias iniciativas em que tem se envolvido, além de ajudar outros a fazê-lo também. Seguindo por esse caminho, trabalhou como consultor para uma grande quantidade de empresas. Durante esse tempo, apresentou suas ideias e estudos de caso em conferências e grupos de estudo em todo o mundo: EUA, Europa e em quase todas as capitais do Brasil.

Kanban é um instrumento incrível, com uma comunidade inigualável contribuindo com ideias e histórias. Contudo, hoje não está restrito a ele. Sua atenção tem se expandido para tudo que é necessário e importante em termos de organização de projetos, como, por exemplo, o Pensamento Sistêmico.

Em 2012, foi honrado com um convite para se tornar um

“fellow” da “Lean Systems Society”, uma organização inter- nacional com um propósito muito nobre: melhorar o mundo por meio da melhoria dos seus sistemas.

Finalmente, em 2015, começou uma nova iniciativa, o Software Zen. Uma escola com cursos de gestão e liderança

(19)

que explora muitos dos elementos descritos nesse livro. Seu propósito é simplificar conceitos complexos para aumentar a capacidade de gerentes, líderes técnicos e desenvolvedores de software a obterem melhores resultados nos seus projetos de software. E esse tem sido todo o seu foco de atenção desde então.

facebook.com/alissoncvale twitter.com/alissonvale instagram.com/alissoncvale

(20)

(21)

AGRADECIMENTOS

A jornada que me levou à produção desse trabalho envolveu o apoio de muitas pessoas. Primeiro e, em especial, agradeço à Verônica Machado, que me ajuda todos os dias a escrever um pouco melhor. Agradeço ao Henrique Bastos pela revisão dos temas explorados no primeiro capítulo. Suas provocações me levaram a refletir sobre a robustez das minhas argumentações.

Também deixo meu agradecimento a Rodrigo Toledo, grande amigo, que viu a Fórmula da Eficácia nascer com outro nome, mas que foi um dos primeiros a enxergar o potencial da ideia logo no início.

Agradeço também a amigos, colegas e alunos partici- pantes do Software Zen (meu programa de treinamento on- line) que dedicaram seu tempo para ler o material — especialmente da Parte 1 — sugerir modificações ou me motivar com uma frase de apoio. São muitos, mas alguns deles deixaram sugestões que se refletiram de alguma forma no texto. São eles:

ANDRE NOVAIS, ANDREA PINTO, ANIZAIR LOPES, ARI AMARAL, DANIEL AUGUSTO DE ALCANTARA,

(22)

FRANZÉ LOPES, GUSTAVO EHRHARDT, JENIFER RODRIGUES, JOANA COUTO, JULIANA BEROSSA, KARINA MINEIRO, LUIZ SIGNORELLI, MARCIO SOUZA MOTTA, MURILO NIERI, RICARDO GIROLDO, RODRIGO CARDOSO, RODRIGO DE OLIVEIRA, RODRIGO QUEIROZ, RODRIGO VIEIRA, RODRIGO ZAMBON, THIAGO ALVES SILVA.