Construir a coisa certa

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.

Showcover

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.

Empire_state_building_from_the_top_of_the_rock

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 interessada, 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.

Dada_303

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.

 

Anúncios

7 comentários sobre “Construir a coisa certa

  1. Parabéns, propôs uma reflexão bastante enriquecedora.Concordo com a categorização proposta por você.Até hoje só fui apresentado a analistas de negócios que são pagos para buscar a eficiência.Poucos são realmente competentes e o melhor que conheci dava o seu jeitinho de ir atrás também da eficácia.Realmente faz sentido para mim que a análise de negócios baseada na eficácia tenha terreno mais fértil em startups, onde talvez seja praticada de maneira não formal (por profisionais que não se apresentam como analistas de negócios).

  2. Olá, excelente artigo, afinal, de quem é a responsabilidade por conhecer o negócio, logo, de quem deveria ser o Analista de Negócios ? Passei o Sábado passado no evento BA DAY do IIBA-POA aqui em Porto Alegre, realizado na FACE/PUCRS (Fac Administração) e a grande tônica foi um grande debate sobre Enterprise Business Analysis. privilégio ter escutado as palestras, painéis e debates do Luiz Parzianello, Suzandeise Thomé, Filipe Sardi, Marcelo Neves, entre outros grandes nomes. Não sei se posso compartilhar o relato do evento, mas posto que esta super alinhado ao teu texto e provocação:https://jorgekotickaudy.wordpress.com/2012/11/24/ba-day-turno-da-manha/https://jorgekotickaudy.wordpress.com/2012/11/25/ba-day-turno-da-tarde/

  3. @Rafael Noronha, é, eu ando achando bem difícil trabalhar pela eficácia do negócio atuando em empresas maiores. A maior empresa onde fiz isso tinha 500 funcionários, onde mais funcionou havia apenas 80. Fora isso só startups.

  4. @JorgeE aí Jorge! Como está o melhor scrum master do Brasil? Eu estou no eixo Rio – São Paulo e não pude participar do BA DAY. Com os nomes que você falou e lembrando da organização do BA BRAZIL só posso assumir que foi muito bom. Muita gente boa nesse encontro. Valeu pelos links, vamos ver o que eu consigo capturar daqui.

  5. Oi, o BA DAY 2012 foi uma aula de história, o BABOK 2 (atual) foi construído por um comite formado excencialmente por profissionais de TI, enquanto o BABOK 3 (a ser lançado em Dezembro), teve a colaboração de um mix de profissionais bastante variado e que imprimiu uma visão mais "enterprise" à análise de negócios. Algumas das tuas frases e colocações mostram o quanto estas alinhado com o novo BABOK, "mais que fazer certo um projeto, é fazer o projeto certo", se falou muito em gestão de portfólio … debateram muito o EBA, uma das palestras foi "análise de negócio na TI é tarde demais". Parabéns pelo blog!

  6. Cláudio, ótimo post mesmo.Mostra muito bem a dicotomia que muitos analistas vivem. E você vai bem no ponto: não há mal em fazer certo, você pode fazer sua carreira crescer, pode ser bom nisso.Mas existe um passo a mais, que é muito interessante: fazer a coisa certa. Infelizmente, muitas consultorias vendem o esforço para se fazer um projeto. A análise está voltada para garimpar os requisitos. Poucas as oportunidades de realmente validar as hipóteses, viabilidade econômica, posição mercadológica e etc.Acredito também que em ambientes menores, as famosas Startups, hype atual, podem oferecer este gratificante desafio.Recentemente, tive a oportunidade de participar de um desafio destes mesmo numa grande consultoria. Como vinha de uma empesa que desenvolvia Produtos (ISV) já tinha um background do que viria pela frente. Mas garanto que foi uma experiência muito libertadora. Realmente diferente do "feijão com arroz" tradicional. E deixa um gosto de quero mais.Neste desafio, tudo é diferente. A sua base literária e de conhecimento tem de ir muito além de Pressman, Três Amigos, UML, Agile. Foi uma caminhada através de Eric Ries, Ash Mayuria, Popendicks, Pink, Descartes, Brooks e outros.Foi algo realmente interessante.Desafios assim são enervantes e contagiantes.[]s.

  7. Eu lembro que eu descobri a diferença entre eficiência e eficácia quando trabalhamos juntos em um projeto. Antes de tu entrar no projeto nós fazíamos o trabalho de forma certa, como manda o manual do XP. Estávamos sendo eficientes, como bons desenvolvedores. No entanto o projeto já andava fazia uns 2 meses e nada de valor havia sido entregue. Quando tu entrou no projeto, a eficácia começou a aparecer. Valor começou a ser entregue para o cliente pois apareceu a figura que conduziu o desenvolvimento a não somente ser eficiente, mas também eficaz.Até hoje eu ainda comento com amigos desenvolvedores que eu não acredito mais em desenvolvimento ágil sem esta figura da eficácia (seja lá quem for), e aprendi isso quando trabalhamos juntos. Até porque, o que vale um software feito com eficiência se o que ele faz não é a coisa certa?!?!Parabéns! Abraço.

Os comentários estão desativados.