Capítulo 1: A principal medida de progresso

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 líder de projeto faz a pergunta que
abre a discussão sobre o escopo dessa iniciativa:

— Prezado cliente, como podemos ajudar? — pergunta o líder atencioso.

O cliente, dono de uma 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 dispare 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 unidades de ensino 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 querem.

Depois de ouvir as explicações do cliente, a equipe de imediato classifica esse

item do backlog como um épico , e o divide em múltiplas outras histórias de
usuário, de tamanho menor. A equipe estima os pontos de cada uma. Nem todas
as histórias do épico cabem em uma única sprint (arbitrariamente definida para
durar 2 semanas). 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 é 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 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 [1] — 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)” [2]. 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 para 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 de trabalho 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 dele. É 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. Desenvolvedores de software reclamam desde sempre que o cliente
não sabe o que quer. Entretanto, a verdade é que não é bem o que ele 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
posiciona você 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, nessa situação, é 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, você percebe que o papel de solucionador de

problemas parece ser mais nobre do que o de um executor de demandas. Será?
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. Um aumento de
eficácia só pode ser alcançado 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. Esse conjunto de benefícios é fruto do seu processo, não do
valor do produto em si que ele gera. Já como um eficaz solucionador de
problemas, 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. Esse,
por sua vez, é um benefício do produto final que você cria, não da capacidade de
produção do seu processo em si.

Eficiência e eficácia são dimensões de performance do seu sistema de trabalho. O

que foi descrito até agora não torna uma dessas dimensões mais ou menos
importante do que a outra. Todos os empreendimentos como um todo precisarão
das duas coisas. Mas a diferença na natureza das duas traz implicações
significativas para aqueles que lutam para otimizar os resultados em seus
ambientes de trabalho. A busca por fazer mais e mais barato segue leis
completamente diferentes da busca por fazer melhor, com mais valor, dando a
solução certa para o problema certo dentro das restrições existentes. Quando o
terreno é o da solução de problemas conhecidos por meio de soluções inéditas, a
eficácia é a meta e a eficiência, um pressuposto. Esse é o terreno onde atua o
desenvolvedor de produtos.

Apesar de estar nesse terreno, o “Time Alfa” escolhe o papel de executor de

pedidos; 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 funcionalidades 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 lhe 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. Em muitos casos, essa
forma de se relacionar com o seu cliente pode se tornar a origem de muitas das
dores e dificuldades que se observam em projetos de software atualmente.

Para tornar a argumentação mais concreta, voltemos à 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 circunscrita ao escopo
selecionado. Não é à toa que grande parte dos projetos Ágeis que vemos por aí
acabam abandonando a definição de metas em suas sprints porque os objetivos
acabam se tornando sempre: “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:

1. Login;
2. Cadastro de cidades e países;
3. Cadastro de escolas;
4. Cadastro de cursos e tipos de curso;
5. Tipos de hospedagem;
6. Upload de fotos das escolas, cidades e países.

Todas as funcionalidades 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 registrar: não existe valor em
funcionalidades de input . O valor está só no output . Em input , só há custo. Uma
funcionalidade de input representa o custo operacional a ser pago pelo seu cliente
para que ele obtenha valor em um momento posterior por meio de uma
funcionalidade de output .

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.
O Manifesto Ágil diz que a principal medida de progresso é software funcionando
[3]. 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! Software
funcionando não é a principal medida de progresso… A principal medida de
progresso de um projeto de software 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. 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: 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. Como já dizia Peter
Drucker: “ Não há nada tão inútil do que fazer com grande eficiência aquilo que
não deveria ser feito”. Antes da eficiência revelar o seu valor, é 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 de negócio, pois é assim
que você progride em um projeto de software.

Está na hora de você se perguntar: qual é mesmo o problema de negócio que eu

vou resolver quando minha próxima sprint acabar?

1 DRUCKER, Peter Ferdinand. The effective executive . London, England: William

Heinemann Ltd., 1967.

2 ACKOFF, Russel. Re-creating the Corporation . New York, NY: Oxford University
Press, 1999.

3 MANIFESTO para Desenvolvimento Ágil de Software. [S.l: s.n.], 2001. Disponível

em: http://www.agilemanifesto.org/iso/ptbr/manifesto.html. Acesso em: 18 ago.
2017.