A principal medida de progresso em projetos de software
Esse é o Capítulo Um de um ensaio que estou escrevendo e que descreve uma batalha de transformação que ocorre, acredito eu, em cada indivíduo enquanto busca por clareza para lidar com os desafios dos projetos de software em que atua ou lidera. Antes de continuar, certifique-se que tenha lido o prefácio desse mesmo ensaio nesse outro artigo.
Novo projeto na empresa. Um time dedicado é formado para atender o cliente. Coisa rara, mas digna de servir como contexto para a história que conto nas próximas linhas. Vamos chamá-lo de “Time Alfa”. Depois das habituais tratativas contratuais, sua liderança se encontra pela primeira vez com o cliente para uma reunião preliminar de levantamento. Com a confiança e tranquilidade reservada apenas para reuniões de kickoff, o recém-eleito “Product Owner” do projeto faz a pergunta que abre a discussão sobre o escopo dessa iniciativa:
— “Prezado Cliente, como podemos te ajudar?”, pergunta o atencioso Product Owner.
O cliente, dono de uma pequena agência que monta pacotes de educação especializada no exterior, sempre usa como exemplo um sistema que ele operou nos tempos que trabalhava em uma outra grande agência, que hoje é sua concorrente. Sua referência, é claro, são as funcionalidades desse antigo sistema. Não é uma surpresa que, após o início da reunião, o cliente dispara a listar as funcionalidades de que precisa. Poucos minutos se passam, mas o suficiente para a mesa ficar abarrotada com um substancial backlog de funcionalidades já esperando ganhar vida na forma de “software funcionando”.
O cliente é então convidado para uma segunda reunião, dessa vez com toda a equipe. É hora de planejar a primeira sprint do projeto. Backlog novamente esparramado na mesa. A equipe pede para o cliente apontar o que é mais importante. Convicto, ele resgata da pilha de cartões um item descrito como “Construção de novo website dinâmico”. O cliente explica:
— “Nosso website atual é visualmente feio e pobre em recursos. Eu gostaria de reconstruí-lo do zero. A ideia é que ele apresente páginas puxadas dos nossos próprios cadastros, mostrando uma página bem bonita pra cada um dos países, cidades e escolas que trabalhamos. Gostaria de ter uma opção para colocar as fotos das escolas também, além das informações de cursos, tipos de hospedagem e outros recursos que cada uma delas oferece. Assim, os alunos terão acesso a informações atualizadas para decidir para onde vão e escolher qual escola se encaixa melhor com o que eles querem.”
Depois de ouvir as explicações do cliente, a equipe de imediato o classifica como um épico, e transforma-o em múltiplas outras histórias de usuário. A equipe estima os pontos de cada uma. Nem todas as histórias do épico cabem na sprint, mas é possível fazer um corte para que o cliente já consiga ser capaz de alimentar os dados que servirão de base para dar vida a seu novo website. As seguintes histórias são selecionadas para a primeira sprint: login; cadastro de cidades e países; cadastro de escolas; cadastro de cursos e tipos de curso; tipos de hospedagem; upload de fotos das escolas, cidades e países. Todas as histórias relacionadas com a exibição das páginas a partir dos dados que serão inseridos por meio dos novos cadastros foram deixadas para as próximas sprints. A meta para a primeira Sprint foi então definida:
“Permitir que o cliente possa por conta própria alimentar os dados que servirão de base para montagem dinâmica de seu website”.
— “Essa será a nossa primeira Sprint!”, comemoram todos, confiantes de que o planejamento foi um sucesso.
Até esse ponto você provavelmente identificou um projeto Ágil típico. Uma abordagem “by the book”, eu diria. Mas isso é o que está dito; e o meu desafio aqui é te mostrar o que não está. Porque o que não está dito é o que faz a diferença entre um time que entrega o que o cliente pede (um time eficiente) e um time que entrega o que o cliente precisa (um time eficaz). E eu te digo, sem nenhuma hesitação, que é nessa segunda categoria que estão os grandes times.
Vamos começar com uma simples definição para você entender melhor a argumentação que será travada aqui: "Ser eficiente é fazer do jeito certo. Ser eficaz é fazer a coisa certa" — uma pequena amostra do brilhantismo do Peter Drucker em duas sentenças curtas. Russell Ackoff pegou essa deixa e avançou um pouco mais na direção que queremos ir: “A performance de qualquer sistema tem duas dimensões: A eficiência com a qual ele faz o que faz (fazer do jeito certo), e a eficácia daquilo que é feito (fazer a coisa certa)”. Eficiência e eficácia são, assim, duas dimensões complementares, mas, como veremos em breve, sujeitas a leis de funcionamento bastante diferentes entre si.
Atrevo-me a constatar logo na primeira interação com o cliente que a postura do “Time Alfa” aponta por um viés de busca por eficiência. São várias as pistas. Há um backlog de compromissos crescendo de forma antecipada. A equipe se submete ao backlog como um garçom que se submete aos pedidos soberanos de seus clientes. A meta emerge das funcionalidades selecionadas para a sprint, ou seja, não está direcionada para um ganho real no negócio, mas para a entrega dos pedaços de software solicitados.
A estrutura das interações do sistema está baseada na dinâmica “o cliente pede, nós fazemos”. Isso significa que a dimensão de eficácia (fazer a coisa certa) é tratada como uma responsabilidade do cliente. É um modelo onde o sucesso do projeto depende do cliente definir bem o que deve ser feito e de nós (equipe) executarmos bem o que ele nos pede. Como se o ganho da ação dependesse do advogado executar bem a estratégia de defesa formulada pelo seu cliente; ou como se a cura dependesse do médico receitar o remédio que o paciente quer tomar. É fato, entretanto, que, quando o cliente está em um táxi, é ele que define onde quer ir; ou quando em um restaurante, é ele que decide o que quer jantar, mas quando o terreno é o da geração de valor, cliente e equipe são cúmplices do resultado. Não é bem o que o cliente quer, mas o que ele precisa. O desafio é ajudá-lo a querer o que precisa.
Quando o cliente conduz a interação para que você faça o que ele quer, ele está direcionando você para uma solução antes mesmo que você tenha dominado o entendimento do problema. Como você pode participar do processo de definir a coisa certa, de definir a solução para o problema que o cliente tem, se você nem sequer tem um entendimento mínimo sobre ele? Fazendo assim, o cliente te posiciona como um mero implementador das soluções que ele cria. Você se torna um mero executor de pedidos, desperdiçando inteiramente seu potencial como um solucionador de problemas.
Como um executor de pedidos, você será cobrado pela sua eficiência; agora, como um solucionador de problemas, você seria premiado pela sua eficácia. A eficiência é remunerada, fixa e tratada como custo para o contratante. A eficácia é premiada, variável e pode ser tratada como um investimento.
Acredito que, a essa altura, o leitor já percebe que o papel de solucionador de problemas parece ser mais nobre do que o de um executor de demandas. Será? O Russel Ackoff nos dá uma boa explicação para esse fenômeno. Segundo ele, a eficiência é VALUE-FREE, ou seja, em um processo produtivo, um ganho de eficiência não gera um produto melhor, sequer diferente. O ganho de eficiência é sempre em cima do processo, nunca em cima do produto final. Assim, se você produz sabonetes e, por alguma razão, consegue tornar seu processo produtivo mais eficiente, o sabonete que sairá no final será o mesmo. Você apenas produzirá mais sabonetes, em menos tempo ou de forma mais barata. A eficácia, por outro lado, é um processo VALUE-FULL; ou seja, qualquer ganho de eficácia em um processo produtivo vai gerar um produto de mais valor no final. Mais eficácia só pode ser alcançada por meio de algo mais valioso sendo produzido ao final do processo.
Assim, como um eficiente executor de pedidos, você será avaliado pela sua capacidade de entregar mais, mais rápido ou de forma mais barata aquilo que está sendo requisitado. Tais características são provenientes do seu processo, não do produto final em si. Já como um solucionador de problemas eficaz, você será avaliado pela capacidade de resolver bem os problemas que servem de obstáculos para que o negócio do seu cliente evolua e prospere. Tal característica é do produto final que você cria, não do processo em si.
É o caminho do executor de pedidos que o “Time Alfa” escolhe; e ele o faz de forma inconsciente já nos primeiros passos do projeto. É natural que, ao percorrer essa via, o time assuma uma postura de busca pela eficiência. Fará do jeito certo. Seguirá o método “by the book”. Se esforçará para cumprir seus compromissos de entrega de escopo no prazo. No entanto, faltará a preocupação com a coisa certa. Essa é a parte que não está dita no método. E é disso que precisamos falar. Focando nas features que precisa entregar, o “Time Alfa” se perde na definição clara do problema que precisa resolver. E é aqui que precisamos estabelecer o nosso ponto central de discussão: Qual é o problema que você está resolvendo?
O que há nas entrelinhas da história do “Time Alfa” é que a relação de compromisso que se desenvolve com o cliente acontece em termos de entrega de software com certa frequência, ao invés de problemas solucionados a partir de um esforço conjunto e concentrado. Sob o ponto de vista do cliente, o problema que essa relação resolve é “eu posso ter uma certa quantidade de software em certo tempo” — os famosos story points da sprint timebox. A princípio, parece uma relação perfeitamente válida. Muitos projetos de sucesso foram conduzidos dessa forma e funcionaram bem. Entretanto, me sinto na obrigação de te ajudar a aprofundar essa reflexão para que você entenda o tamanho do desperdício, em termos de geração de valor, que você terá caso decida orientar a relação com o seu cliente dessa forma. No pior dos casos, essa forma de se relacionar com o seu cliente pode se tornar a origem de muitas das dores e dificuldades que se observa em projetos de software atualmente.
Para exemplificar, voltemos a nossa história do “Time Alfa”.
Analisemos a meta criada para a primeira sprint: “Permitir que o cliente possa por conta própria alimentar os dados que servirão de base para montagem dinâmica de seu website”. Essa meta não emerge da necessidade do negócio, mas do escopo selecionado! Primeiro, time e cliente decidem qual é o escopo da iteração, depois tentam (e conseguem) definir uma meta que circunscreva ao escopo selecionado. Não é à toa que grande parte dos projetos Ágeis que vemos por aí acabam abandonando as metas de suas sprints porque suas metas acabam se tornando apenas: “entregar o que foi prometido”.
Assim, quando o “Time Alfa” alcançar sua meta no final da primeira sprint, produzirá software, mas não resolverá nenhum problema concreto que o cliente tenha em seu negócio. Zero problemas resolvidos não é progresso, e se não há progresso, a meta que se persegue não é uma meta que valha a pena ser perseguida.
Deixemos a meta da sprint de lado e observemos o escopo por um momento:
- login;
- cadastro de cidades e países;
- cadastro de escolas;
- cadastro de cursos e tipos de curso;
- tipos de hospedagem;
- upload de fotos das escolas, cidades e países.
Todas as features são de entrada de dados (input), nenhuma processa dados e gera um resultado útil, um output, que o cliente possa usar a favor do seu negócio. Eis aí uma lição que vale a pena anotar: não existe valor em features de input. O valor está só no output. Em input, só há custo.
Assim, a conta é simples: ao receber essa primeira entrega, o cliente receberá software funcionando, mas não receberá valor. Muito pelo contrário, se ele começar a usar o software que será gerado após a primeira sprint, ele estará apenas aumentando seu custo operacional. Cada cadastro que ele agora precisa usar para alimentar o sistema representa um custo de operação que antes ele não tinha. E com essa explicação vem mais uma lição que vale a pena anotar: uma entrega que aumenta o custo operacional do cliente não é uma entrega que merece ser feita.
O Manifesto Ágil diz que a principal medida de progresso é software funcionando. Essa mensagem já foi válida quando o grande gargalo da indústria de software era entregar. Hoje entregamos muito, mas entregamos mal. Não, não é software funcionando a principal medida de progresso. A principal medida de progresso de um projeto são problemas de negócio resolvidos. E isso só se alcança por meio de uma cultura com foco em eficácia. Software é um proxy para algo muito mais importante e fundamental. Software é o que está entre o cliente e o seu problema resolvido. Se for o software errado ou se for software demais, será um obstáculo, um esforço, uma força de sucção da energia que deveria estar em outro lugar. O cliente não quer seu software, quer ter seus problemas resolvidos. Às vezes é preciso lembrá-lo disso. Não há outra conclusão possível, caro leitor. Entregar a coisa certa é muito mais valioso do que entregar o que foi pedido. Muito mais importante que o seu software, é o propósito dele.
O “Time Alfa” usa um método Ágil, mas não culpe o método. Poderíamos estar diante de qualquer metodologia ou processo. Falta ao time a sabedoria que vai além do conhecimento procedimental que qualquer método pode oferecer. Falta ao time entender que há um custo caro a se pagar na dinâmica de apenas “fazer o que é pedido”; e que há grande valor em “ajudar o cliente a descobrir o que fazer, e fazer”. Você pode até se tornar bastante eficiente em fazer o que é pedido, mas a eficiência é de pouco valor quando aplicada à coisa errada. Antes de aplicá-la, é preciso descobrir qual é a coisa certa a se fazer; e esse processo de descoberta é a base do que significa ser eficaz.
A eficácia é a meta sempre que o desafio é ajudar o cliente a resolver seus problemas de negócio. É o esforço constante para encaixar o problema mais importante com a solução que o resolva da forma mais adequada dentro das restrições existentes. O que deixa seu cliente satisfeito não é o software que você entrega pra ele, mas os problemas que ele deixa de ter por causa do seu software. Se, no contexto apresentado aqui, você apenas desenvolve o software, você faz a coisa errada; você deveria estar resolvendo problemas, pois um problema resolvido é a principal medida de progresso em um projeto de software.
Sendo assim, está na hora de se perguntar: qual é mesmo o problema de negócio que você vai resolver quando sua próxima sprint acabar?
No próximo capítulo: Em um universo paralelo, um outro time é contratado pelo mesmo cliente. Como é um time comprometido com a eficácia, ele assume uma postura que gera surpresa e deixa o cliente entusiasmado. O resultado é surpreendente.
