Redescobrindo o Lean

Introdução

Para aqueles que amam a melhoria contínua, a engenharia de software se encaixa como uma luva. Para onde olharmos, encontramos pontos potenciais para melhorar, aumentar a velocidade e a qualidade. Podemos adotar novas metodologias, práticas e capacidades, ler milhares de livros e analisar centenas de milhares de vídeos com a promessa de melhores resultados.

Conseguimos melhorar mudando de "algo sem nenhum processo" para cascata, SCRUM e Kanban, adotando TDD, BDD para CI/CD, migrando monólitos para microservices e passando de documentos de requisitos para execução de equipes autônomas.

Essas mudanças funcionaram. Com base nas métricas delineadas no excelente livro "Accelerate" (Tempo de Espera, Frequência de Implantação, Tempo Médio para Restauração e Alteração da Porcentagem de Falhas), estávamos desempenhando um alto nível. Mas será que era verdade?

Estresse

O problema é que, no fundo, sabíamos que não estávamos! As métricas de engenharia eram ótimas, melhores do que nunca, porém as métricas piratas (YO HO HO e uma garrafa de rum!) estavam sendo sugadas. Onde estava o impacto real do usuário que gostaríamos? Estávamos exaustos. Cada nova iniciativa e cada prática que adotamos alterava nosso modo de trabalhar, o que exigia um esforço consciente para descobrir, aprender, implementar e refinar. Gastar toda a energia mental em melhorar as métricas de entrega era ruim, mas melhorar continuamente a coisa errada era péssimo.

No meio dessa crise de confiança, o chefe de engenharia pediu para liderar o desenvolvimento de um novo produto mobile. Seria um grande negócio que iríamos abordar, baseado na necessidade real do usuário, entretanto dentro do pacote estava também a grande probabilidade de fracasso. Um ano antes, com toda a certeza teria aceito sem titubear, mas com um pouco mais de autoconsciência em torno das limitações pessoais para entregar um projeto tão grande, neguei a oferta.

A oportunidade

Como a abordagem não estava funcionando, precisava mudar. Seria um processo complicado mas será que iria resolver os problemas de maneira instantânea? Ou deveria manter o modo de pensar e trazer mais modelos de como se trabalhar? Por sorte, os livros que estava lendo me mostraram uma saída mais reflexiva.

Ler o "The Goal", de Eli Goldratt, deixou claro que estava me concentrando nas coisas erradas, e que esses processos e práticas eram substitutos para o trabalho real. Marty Cagan, no livro "Inspired", lembrou-me que o motivo no qual entrei para a indústria de software não era para ser o melhor engenheiro, mas para construir produtos que as pessoas adorassem. O "Coaching for Performance", de John Whitmore, mostrou-me que precisava dar confiança a equipe para que estivessem em uma melhor posição para resolver os próprios problemas.

Foi então que decidi mudar, para sair das capacidades ágeis e táticas exauridas, colocando os esforços para o novo objetivo e para solucionar os problemas dos clientes.

O princípio

A principal diferença neste projeto em relação aos outros anteriores foi o objetivo: Fazer uma venda do novo produto mobile em seis meses.

A maioria dos objetivos na vida começam simples, mas no momento em que as pessoas que trabalham no objetivo recebem os requisitos, vemos que estão fora da realidade e cheias de ambiguidade.

Considere o objetivo a seguir: Aumentar a qualidade e a confiabilidade do painel de vendas. Parece algo simples certo? Essas competências são ótimas, mas quando os recursos estão acabando, focamos em qual das duas?

A ambiguidade deixa uma equipe autônoma brigando entre si, e neste caso, discutem a definição correta do termo qualidade, e quanto de confiabilidade é o suficiente!

Em vez disso, precisamos dar ao time diretrizes claras para serem criativos. A equipe exige um modelo para se basear nas decisões de maneira objetiva. Temos uma meta para bater e um prazo de seis meses, com foco total no cliente. Se não resolvermos o problema real, significaria não vender!

Confiança

O foco explícito no cliente teve um impacto imediato no comportamento da equipe. Adoramos debater os prós e contras das abordagens técnicas, arquiteturas e processos, mas desta vez nos baseamos na pesquisa de produtos, tiramos mais conhecimento do negócio e nos aprofundamos no real motivo. Ficou claro que a importância estratégica deste projeto e a confiança que a empresa depositou na equipe para entregá-lo eram enormes.

A propriedade e a iniciativa cresceram com essa confiança e motivação. Um engenheiro cujo padrão era sair desenvolvendo, em vez de começar a programar, perguntou o que queríamos aprender primeiro. Que evidências poderíamos reunir para dizer se o prazo de seis meses era algo palpável?

O conceito

Essa foi a pergunta correta. Não mergulhamos de cabeça na construção, pelo contrário, identificamos uma oportunidade para aprender e fazer as medições. Houve uma reunião com os clientes durante um período de três semanas, com trezentos dos nossos mais valiosos clientes participando, para conseguirmos chegar a resposta das seguintes perguntas: Quais eram os problemas que este aplicativo mobile resolveria? Qual a importância de resolvê-los?

Se nós, como equipe, estivéssemos nos comprometendo, então iríamos querer algum compromisso em troca. Fazer com que cinco clientes se inscrevessem em um programa piloto para colaborar conosco na construção do produto nos próximos cinco meses foi nossa principal medida deste compromisso. Não alcançar esse número significava novas informações para o negócio. Para executar este teste, tivemos que desenvolver rapidamente!

Retornamos para a fase de planejamento, com um quadro branco e uma caneta para organizar o trabalho. O objetivo era dar orientações claras e ter uma equipe motivada, nada mais que isso. O que alcançamos nessas três semanas foi notável. Construímos um MVP do aplicativo e um backend mobile para os usuários. Nesta etapa o objetivo não foi trabalhar rápido, focamos em escolhas difíceis e eliminamos todo o desperdício, como por exemplo:

• Escrever sem testes unitários. Ficar próximos aos usuários para que pudéssemos aprender era a prioridade número um, ao invés de escrever um código mais limpo;
• Eliminar silos de informação na equipe multifuncional. Em vez de aperfeiçoar o design de telas, nosso designer de experiência de usuário aprendeu a reagir nativamente para ajudar na criação do aplicativo;
• Aproveitar os serviços nativos da nuvem. Jamais esquecerei o olhar do CEO quando passou apenas dois dias de projeto para que déssemos uma demonstração da funcionalidade da autenticação do aplicativo em funcionamento.

E antes que qualquer pessoa comente sobre não fazermos nenhuma menção de testes unitários, criamos a qualidade jogando fora todo o código e começando do zero. Poderíamos conversar com os testers da equipe sobre o que a qualidade representava naquele momento do projeto e poderíamos tomar decisões imparciais sobre o assunto. Veja, ter um objetivo específico significava que é fácil definir o desperdício, e os atalhos aparecem por toda parte quando sabemos para onde estamos indo.

Se não sabemos quem é o cliente, não sabemos o que é qualidade.

Lean Startup, Eric Ries.

As reuniões com os clientes e o feedback que obtivemos superaram as expectativas, com oito clientes se inscrevendo em nosso programa piloto, interessados em ajudar a modelar o aplicativo em torno de suas necessidades. Mas antes de passarmos para a próxima fase, regredimos…

Regressão

Estava ansioso para começar o piloto para ter o melhor início possível. O estilo orgânico e fluido que tomamos durante a prova de conceito teria que mudar. Com os clientes agora envolvidos, precisávamos ter mais estrutura. Para nos colocar no caminho certo, fui obrigado a realizar uma reunião de planejamento semanal no estilo mais tradicional e isso acabou sendo uma péssima ideia.

Um observador naquela reunião teria notado uma ou duas pessoas conversando e o restante com a cabeça baixa desejando estar em outro lugar. Isso contrastou com os níveis de energia e engajamento das três semanas anteriores. Estava trazendo soluções dos problemas que encontrei para o grupo, ou seja, mostrando como executar o piloto, mas não estava engajando os participantes, uma ótima maneira de perder uma boa equipe. As pessoas que fazem o trabalho, aquelas com o problema, estão melhor posicionadas para resolvê-lo.

Para conseguir o melhor das pessoas, temos que acreditar que elas são as melhores.

Coaching for Performance, John Whitmore.

Acontece que as pessoas gostaram da maneira leve que havíamos trabalhado desde o início do projeto. Sentiram que poderíamos executar o piloto da mesma maneira, pois nos sentamos um ao lado do outro, apreciamos a comunicação aberta. Quando os impedimentos surgiram, trabalhamos para desbloqueá-los. Quando várias opções foram apresentadas, escolhemos o melhor caminho a seguir. Também estendemos essa abertura aos nossos clientes, nosso quadro branco era um simples radiador de informações, cujo espaço limitado mantinha o trabalho em andamento e uma lista de pendências simples sob controle. Isso era o suficiente. Sem reuniões sem motivo, sem cerimônia, apenas foco no trabalho.

Essa abordagem funciona para todas as equipes? Provavelmente não. Mas para nossa equipe em particular, funcionou perfeitamente! Felizmente, trabalhamos como queríamos, e o piloto começou a ganhar força.

O piloto

Mostrar aos clientes o que tínhamos feito semanalmente, pegar os feedbacks, resolver os problemas e discutir as opções, tudo isso é a força vital de qualquer piloto. No software, esse sentimento está atrás da curva que pode se tornar a regra. Esse contato com o cliente resolve este problema, criando empatia e impulsionando o desempenho da equipe. Para o time, o resultado foi o progresso. No início de uma ligação em particular, o cliente falou direto sobre um problema que tinha. Acontece que tínhamos acabado de lançar um recurso naquela manhã para resolver esse mesmo problema!

Mas as coisas nem sempre foram tão fáceis e heróicas. Durante uma discussão da equipe sobre o principal ponto problemático dos usuários, ficamos permeando em direção a uma solução específica. Sem parar para questionar, pegamos marcadores e seguimos para o quadro para mapear o design e a arquitetura em torno da solução. Eram bons tempos! Poucas horas depois, com dois meses de trabalho mapeados, ficamos satisfeitos. Podíamos ver o poder da nossa solução.

Tirar conclusões precipitadas é um esporte muito mais seguro na nossa imaginação do que na realidade.

Thinking Fast and Slow, Daniel Kahneman.

Este é um exemplo de ação muito perigosa, tirar conclusões precipitadas. Depois de dois minutos saindo da bolha da equipe e conversando com os usuários reais, ficou claro que estávamos complicando demais. Felizmente, fomos conduzidos para uma direção mais simples. Levamos cerca de dois dias para implementar o que estavam pensando. A partir do acompanhamento das métricas de uso e feedback em torno das atividades, pudemos ver o que os clientes precisavam. Foram economizados dois meses de trabalho com apenas dois minutos de conversa!

Estávamos no caminho para entregar um ótimo produto, a equipe estava feliz, os clientes do piloto também, porém não foi o suficiente.

A venda

Olhando de volta para o objetivo: Entregar um produto que consiga ser vendido, não apenas um produto mínimo viável. Minha visão estava centrada na engenharia, otimizar o desenvolvimento e a entrega do software, é apenas um capítulo da história.

Criar um produto sólido seria inútil se não trabalhássemos juntamente com outras áreas da empresa, com nossos departamentos de vendas e marketing para gerar e desenvolver leads, e com o atendimento ao cliente pronto se e quando uma venda acontecesse, para garantir que o cliente tivesse uma ótima experiência. Havia muito mais do que só a área de engenharia.

Formar uma equipe totalmente multifuncional nos manteve em sincronia. Essa equipe era proprietária do mapa completo do fluxo de valor, do conceito, passando pela venda, até a integração, com membros da maioria das funções em todo o negócio. Esta unidade foi fundamental para identificar e lidar com os gargalos que surgiram em toda a empresa em uma determinada semana.

Essa abordagem por muitas vezes foi lenta. Neste estágio de desenvolvimento, o produto estava mudando rapidamente com funcionalidade e design em fluxo constante. Ter que se comunicar fora da equipe de desenvolvimento era uma sobrecarga fácil de ser ignorada, porém esse ato rapidamente culminou em algo que não gostaríamos.

Essa reunião semanal mais ampla da equipe significava que as preocupações eram levantadas e resolvidas. Neste caso, o marketing de produtos veio e ficou com a equipe de engenharia por dois meses, inicialmente observaram como o produto estava se desenvolvendo e sendo mostrado aos usuários-piloto. Levaram isso em conta para os esforços de marketing e também alimentaram facilmente as ideias resultantes da pesquisa de mercado e do posicionamento do produto.

Em vez de repetir alguns dos fracassos anteriores, nos quais acabamos obtendo um ótimo resultado de engenharia, porém com resultados silenciosos em termos de valor comercial, essa equipe multifuncional criou um alinhamento que resultou na entrega conjunta da venda. Este negócio foi fechado na última sexta-feira do nosso período de seis meses!

O sucesso

A primeira venda e o fato de termos alcançado o objetivo foi extremamente gratificante para a equipe. Nas semanas seguintes, uma grande proporção dos nossos clientes-piloto converteu-se em compradores do produto, o que foi uma tremenda validação de nossa estreita colaboração durante o desenvolvimento inicial do produto.

Ao descrever a jornada do conceito até a venda, muitos exemplos de desperdício, aprendizado, confiança, velocidade e qualidade que guiaram nossas decisões foram dados. Estes são exemplos de princípios Lean em ação:

• Ter um objetivo específico nos permitiu "eliminar o desperdício";
• "Deferir o comprometimento", decidindo provar o conceito, em vez de começarmos a construí-lo;
• "Entregar rápido" a prova de conceito, em pouco mais de três semanas;
• "Construímos qualidade", jogando fora a P.O.C. (Proof of Concept, ou Prova de Conceito em português);
• Trabalhamos com os clientes através do piloto e do "conhecimento criado";
• Permitir que a equipe realiza o trabalho decida sobre a melhor forma de fazê-lo "respeitando as pessoas envolvidas";
• Finalmente, o alinhamento entre várias funções no fluxo de valor otimizou todo o negócio.

"Mas espere um pouco. Pensei que fosse dizer que não seguiram nenhuma metodologia?" Bem, acontece que seguimos. Utilizamos o Lean! Todos esses anos de aprendizado e adoção de várias práticas e técnicas deixaram marcas. Absorvemos os princípios por trás deles sem estar verdadeiramente ciente disso. Focando no objetivo, nos nossos usuários e no que parecia certo na equipe, nos permitiu encontrar finalmente uma forma que nos levou ao sucesso que estávamos procurando.

Conclusão

Escolher uma abordagem para o desenvolvimento de produtos é muito difícil. Mesmo com uma decisão tomada, é preciso um esforço real para implementar, tanto que perdemos de vista o motivo pelo qual estávamos fazendo o que fazíamos.

O sucesso, assim como a felicidade, não pode ser perseguido. Ele deve acontecer.

Victor E Frankl

O conselho é bem simples. Pare de perseguir as novas e melhores práticas ágeis. Há uma combinação aparentemente interminável delas, e nosso tempo e energia são limitados. Em vez disso, é preferível gastar esse tempo numa abordagem única com base na meta que foi concedida, nas pessoas que possuímos e nos princípios subjacentes que mantemos, sejam Lean ou não. Essa base tornará as práticas que aplicamos de maneira mais significativa e bem-sucedida e resultará em melhores resultados, equipes mais felizes e talvez até mesmo uma venda ou duas.

Sobre o autor

Kevin Duggan é líder mobile da Poppulo (empresa de software de comunicações internas), em Cork, Irlanda. Passou mais de quinze anos construindo produtos e equipes. Quando não está programando, pode ser encontrado pedalando em mountain bikes, correndo ou tocando violão. Em uma vida passada, também foi um campeão de dança irlandês percorrendo todo o mundo. Aqui está o site dele.