O livro “Leading Lean Software Development: Results Are not the Point” é o tipo de livro que só deve ser lido pelas pessoas que gostam de desafiar suas crenças e conceitos-chave a cada capítulo.

O capítulo 3 “Reliable Delivery” (entrega confiável) descreve em detalhes o processo de  construção do Empire State Building, que, lançado em 1931 manteve por 40 anos o título de edifício mais alto do mundo. Por que o edifício é exemplo de entrega confiável? Porque ele foi construído em apenas 20 meses.

A maior parte dos fatores que levaram a esse sucesso de entrega também fazem sentido quando pensamos em desenvolvimento de software e eu sugiro que todos os interessados em entrega leiam pelo menos esse capítulo.

Eu sempre prego que “entrega” ou “delivery” devem ser preocupação do analista de negócios, afinal, nenhum trabalho feito pelo AN (a não ser aquele que evita que software seja desenvolvido) faz sentido se o software não estiver disponível no momento certo, contudo, o que mais me chamou atenção nesse capítulo foi o fato de que apesar de ter atendido às expectativas da santíssima trindade prazo, custo e escopo com qualidade, o Empire State, como NEGÓCIO foi um fracasso.

No momento em que foi lançado, dia primeiro de maio de 1931 o edifício estava localizado em uma área da cidade com pequeno fluxo de pessoas, havia uma enxurrada de ofertas de escritórios baratos na cidade e o país ainda não havia saído da grande depressão econômica. Esses fatores levaram o empreendimento a decolar apenas 15 anos após a sua construção.

Após anos me preocupando com como entregar os projetos da melhor forma, como elicitar os requisitos e comunicá-los, como aprender com o feedback que recebemos do desenvolvimento iterativo e incremental de software e aplicar o aprendizado em seguida, como aproximar quem paga, quem vai utilizar e quem está construindo em um ambiente harmonioso, não atingi a paz de espírito, muito pelo contrário, uma pulga enorme surgiu atrás da minha orelha:

Será que faço esse trabalho todo sem nem ao menos saber se estamos construindo a coisa certa? Passeio esse tempo construindo meu Empire State Building?

Para trabalhar essa hipótese passei em exame mental as iniciativas das quais eu participei nos últimos 15 anos e notei que elas se separam, quase que naturalmente, em duas categorias bem distintas com base no que se esperava do meu papel de analista de negócios.

A primeira categoria, que batizei de “eficácia”, possui as iniciativas nas quais eu tinha acesso de fato ao negócio, compreendia seu funcionamento de ponta a ponta e via em primeira mão como a nossa iniciativa o impactaria, permitindo adaptações, modificações no curso. A melhor delas envolveu o gerenciamento de um produto já estabelecido no mercado.

A segunda categoria, a “eficiência”, possui as iniciativas nas quais eu estruturava todo o meu trabalho sobre uma ou mais premissas passadas a mim por alguém. Eu tomava essas premissas como verdadeiras com base na autoridade de quem as repassou e desenvolvia todo o trabalho a partir dali.

A primeira categoria reúne iniciativas em organizações menores, nas quais eu atuei na maior parte das vezes como colaborador interno, como “intraempreendedor” enquanto a segunda categoria tende a reunir as iniciativas de organizações maiores, nas quais eu atuei como consultor externo.

É muito natural que isso ocorra, afinal, quando você contrata alguém para fazer um trabalho para você, o objeto dessa contratação, esse trabalho, já nasce como uma premissa, ela é o que “deve” ser feito e entregue.

Quando as organizações são maiores, mesmo quando não existe a contratação de agentes externos, existe a “contratação de outras áreas”, no nosso caso TI, e essa contratação tende a seguir o mesmo modelo mental da terceirização.

Isso se dá porque poucas empresas sabem trabalhar como modelos como mapa estratégico e acabam cobrando as áreas com base no seu desempenho individual gerando mais negociação de contratos do que cooperação.

Qual seria então a diferença primordial entre essas duas categorias? Apelo à frase de Peter Drucker para explicar:

“a eficiência consiste em fazer certo as coisas
e a eficácia em fazer as coisas certas.”

Veja, não estou propondo uma falsa dicotomia, não existe uma escolha obrigatória entre eficiência e eficácia, o que existe no nosso trabalho de análise de negócios é um foco na eficiência e desapego pela eficácia.

Abraçamos a premissa, seja qual for, e fazemos o nosso melhor para atendê-la. Chegamos ao cliente e ouvimos “oferecer o produto x até a data y nos trará N% de retorno e possibilitará que yada yada yada aconteça”. Colocamos isso no coração e partimos para o trabalho.

Isso está errado? Teoricamente não. Veja a definição de análise de negócios:

“Análise de negócios é o conjunto de atividades e técncias utilizadas para servir como ligação entre as partes interessadas, no intuito de compreender a estrutura, políticas e operações de uma organização e para recomendar soluções que permitam que a organização alcance suas metas”.

NADA na definição de análise de negócios envolve questionar ou desafiar as premissas (metas), o trabalho do analista de negócios é facilitar que a organização alcance as suas metas, não questionar as metas, rever as metas e o que seria melhor, testar as metas.

O modelo mental dentro do qual essa definição foi escrita é o modelo mental que subordina a análise de negócios ao gerenciamento de projetos, não ao negócio.

Não existe modelo de trabalho que dificulte mais o desafio de premissas do que o gerenciamento de projetos, porque um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

Uma vez definido um projeto, questionar produto, serviço ou resultado exclusivo é um ato que fere a própria natureza do projeto.

Um projeto traz o mesmo risco para um negócio que trabalhar desenvolvendo épicos ou casos de uso de 45 páginas traz para o desenvolvimento de software. Lotes de trabalho menores são muito benéficos para o desenvolvimento, permitem um feedback mais rápido, descoberta e tratamento de defeitos mais cedo e mudanças de rumo menos traumáticas.

A conta é a mesma para um negócio: o custo de descobrir que a sua ideia estava errada é muito superior ao custo de implementar uma estrutura que permita que você teste suas ideias de forma barata e mais rápida.

A análise de negócios que deveria ser um belo cisne negro desafiador de premissas nasceu e hoje cresce achando que é um patinho feio defensor de premissas.

O que hoje chamamos de análise de negócios deveria ostentar um nome menos pomposo, algo como “promoção do consenso em projetos” e ser sim uma subdisciplina do gerenciamento de projetos.

Isso é o melhor que podemos fazer quando estamos em um ambiente onde as premissas não podem ser questionadas. Se você é analista de negócios em um projeto e seu trabalho contribuir para a eficácia do trabalho dos demais (requisitos mais claros e não ambíguos, consenso entre as partes interessadas e tudo mais) você será considerado um bom profissional indepentende do fato do produto, serviço ou resultado exclusivo criado trazer ou não resultado.

De qualquer forma, a falta de vínculo com o resultado para o negócio deveria impedir que ostentássemos “negócio” no crachá.

Ok, mas nós temos opções? Sim, nós temos opções. Eu vejo pelo menos duas.

A primeira é buscar trabalhar com iniciativas menores como startups. As startups (fora aquelas abertas com o dinheiro do papai) não tem tempo a perder, elas precisam validar as suas hipóteses rapidamente, sentir o pulso do mercado e adaptar, tudo em ciclos curtos. Trabalhar como analista de negócios nesse contexto é excitante e você pode se divertir muito. Contudo, trabalhar assim também é desgastante ao ponto que raramente uma empresa mantém essa forma de trabalhar depois de ter conseguido superar as suas maiores incertezas.

Quando a caça está garantida você pode deixar um pouco de gordura se acumular onde antes havia uma barriga de tanquinho. Nosso sonho inconsciente é o conforto, não tem jeito. Pelo jeito só pessoas como o Steve Jobs não buscam instintivamente estabilizar um dia.

A segunda opção é aceitarmos que o nosso trabalho é de promoção do consenso em projetos e fazermos esse trabalho da melhor forma possível.

Ok, eu chamei esse cara de patinho feio, mas ele não é feio, é só “menos bonito”. Quer saber, talvez seja até mais bonito.

Existe uma beleza na promoção do consenso em projeto e essa beleza está no simples fato de que quando você trabalha com isso você trabalha para ativamente melhorar as vidas das pessoas envolvidas no projeto.

Quando você promove uma melhor comunicação está fazendo com que as pessoas passem os dias com menos receio de serem mal compreendidas. Quando você diminui a ambiguidade dos requisitos você diminui a insegurança de todos, quando você dá espaço para que desenvolvedores interfiram no produto você aumenta o senso de propósito deles e por aí vai.

Dizer que isso não tem valor é como dizer que o trabalho de um profissional da saúde não tem valor porque ele não compreende ou interfere ativamente nas metas do negócio no qual seu paciente trabalha.

Ser um promotor do consenso no projeto implica trabalhar pelo bem-estar dos envolvidos no projeto partindo da sua ferramenta de trabalho, o escopo do produto do projeto, seja ele salvar golfinhos, seja construir a estrela da morte. Isso é fazer o bem de forma tangível e é totalmente válido inclusive como sua meta de vida profissional.

Vale lembrar que esse último parágrafo pode ser uma premissa a partir da qual você pode construir a sua carreira. Nesse caso, insisto que você a questione e a desafie, afinal, o produto aqui é a sua vida e as metas da sua vida são você quem faz.

Esse “negócio” é seu. Nada de simplesmente adotar as premissas dos outros ok?

E quanto a mim? É, eu acredito nessa premissa. Apesar de sentir satisfação quando trabalho no lado da eficácia, os momentos nos quais me senti mais feliz no trabalho foram aqueles nos quais sentia no olhar das pessoas do negócio, dos clientes e dos desenvolvedores que a vida deles havia melhorado em parte por causa do meu trabalho.

Me sinto construindo a coisa certa.

[Post originalmente publicado em http://blog.claudiobr.com/construir-a-coisa-certa em 25/11/2012]