Nos três primeiros capítulos da série determinamos o valor que cada iniciativa tem para o negócio, para a realização de seu grande objetivo (aumentar em 30% a rentabilidade das vendas). O último artigo mostrou como o valor, o peso de cada iniciativa, pode ajudar a determinar o rateio do orçamento¹. Finalmente chegou a hora de definir prioridades.

.:.

Valor e custo são as duas variáveis predominantes quando o assunto é classificação e priorização de projetos. Mas não são as únicas. A complexidade técnica das soluções e as oportunidades de aprendizado também podem interferir na sequência de desenvolvimento de projetos.

Facilitamos a vida da turma do “como” (equipe técnica) ao isentá-la de boa parte do trabalho de estimativas. Seguindo uma ‘filosofia’ mais moderna, trocamos estimativas por restrições. Como vimos nos capítulos anteriores, prazos e limites de custos foram pré-fixados. A equipe técnica foi desafiada a encontrar três alternativas de solução para cada grande requisito apresentado.

A seleção das melhores alternativas deve seguir a mesma lógica que define as prioridades. Aliás, seleção e priorização podem ocorrer no mesmo momento. Veja a matriz ao lado. Nela a equipe técnica posicionou as alternativas de solução para cada necessidade do negócio. O eixo Y, como nos diagramas anteriores, apresenta o valor para o negócio. Os custos são representados no eixo X. Podemos utilizar ícones ou símbolos para indicar as outras variáveis, a complexidade técnica e possibilidades de aprendizado. Neste exemplo usamos apenas o tamanho do círculo para indicar a complexidade² de cada alternativa.

Os quadrantes nos ajudam a tomar algumas decisões de forma rápida. Ninguém deseja pesadelos, por exemplo. Pesadelos são alternativas caras que apresentam baixa ou nenhuma possibilidade de retorno. Eles aparecem quando o “limite do bom senso”, apresentado no artigo anterior, não é respeitado. Qualquer alternativa que caia ali deve ser automaticamente descartada pela equipe.

As bobeiras, por outro lado, são baratas. Mas também têm baixo valor para o negócio. Por isso merecem sempre ficar no fim da fila (de projetos e também do processo de seleção e priorização).

Sonhos são raros. Deveriam ser melhor aproveitados. São aqueles projetos que, apesar do baixo investimento, apresentam grande capacidade de gerar valor para o negócio.

E os desafios são aquelas alternativas ou projetos de alto custo e alto valor para o negócio. É aqui que começamos. Três alternativas, duas para a “Captura de Pedidos em Tempo Real” (h) e uma para a “Melhoria do Sistema de Agendamento” (f) aparecem neste quadrante. Neste ponto do processo a equipe técnica deve apresentar as vantagens e desvantagens de cada alternativa sugerida. Representantes das áreas de negócio envolvidas devem ter a palavra final sobre a melhor ou mais viável solução. Em nosso exemplo, a objetiva empresa fictícia escolhe o óbvio sonho (h1) como melhor opção para a captura de pedidos em tempo real. Decide também pela alternativa f3 – a mais sofisticada (e cara) para a evolução do sistema de agendamento dos vendedores. Aliás, para aplacar o chororô dos vendedores, eles também estudam a possibilidade de tocar a iniciativa cd2, que envolve a “aquisição de aparelhos GPS” e a integração destes com o sistema de agendamento. Antes, fecharam que i1 é a melhor alternativa de “sistema de logística”. Sabem que é uma solução meia-boca em termos de funcionalidades, mas representa um bom ponto de partida para uma empresa que nunca teve de lidar com algo parecido.

Relembrando: no processo descrito no parágrafo anterior nossa exemplar empresa fictícia escolheu: h1, f3, i1, cd2. Esta é a sequência determinada pelo valor gerado para o negócio. É a sequência ideal de desenvolvimento? Não. Nossa tão aguardada “fila indiana” de projetos fica assim: f3, h1, i1, cd2³. Como dita o senso comum, devemos sempre começar um trabalho pela parte mais difícil. A matriz utilizada acima nos ajuda a determinar a sequência ideal de desenvolvimento: Desafios, Sonhos, Bobeiras (e nada de Pesadelos).

.:.

Epílogo: Outra Provocação de nossa Exemplar Empresa Fictícia

Você deve se lembrar, nossa honorável empresa fictícia fixou um orçamento de R$ 300 mil para todas as iniciativas. Ao selecionar as alternativas de solução as equipes técnica e do negócio baixaram seu teto para R$ 245 mil:

• h1 = R$ 60 mil
• f3 = R$ 70 mil
• i1 = R$ 50 mil
• cd2 = R$ 65 mil

O que será feito com os R$ 55 mil economizados? Durante os projetos eles ficam reservados, como um fundo de garantia. Se algo não sair como o previsto (nunca sai), é neste fundo que a empresa buscará recursos. A grana que sobrar após a conclusão dos projetos será dividida entre todos os participantes dos projetos. Em espécie ou na forma de uma belíssima festa (churrasco, balada etc).
Para quando está agendada a sua?

.:.

Observações:

1. Curioso o biorritmo desta série. A audiência, forçada ou não, foi praticamente a mesma para todas as quatro partes já publicadas. Não posso dizer o mesmo da divulgação voluntária. Alguns capítulos mereceram elogios e indicações via Twitter. O último passou em branco. Justo aquele que, segundo meu pretensioso julgamento, deveria merecer mais atenção e debate. Por quê? Porque ele propõe a inversão de duas coisas muito comuns em nossas organizações: a) Um orçamento é definido antes que a equipe de TI conheça o(s) problema(s). Os limites são pré-fixados de acordo com o retorno esperado para o negócio; b) Ao invés de falar de “Custos X Benefícios” o artigo fala de “Benefícios / Custos”. E nem chega perto da matemática financeira que costuma “poluir” este tipo de discussão.
   No mundo do gerenciamento de projetos vivemos bombardeados por siglas e termos como VPL (Valor Presente Líquido),  TIR (Taxa Interna de Retorno), Payback e afin$. Até Mike Cohn, em “Agile Estimating and Planning” (Prentice-Hall, 2006), lança mão de sua calculadora financeira na hora de falar de priorização de projetos (temas, no caso dele) com base em grana. Na realidade ele surrupia e resume os escritos de Steve Tockey em “Return on Software: Maximizing the Return on your Software Investment” (Addison-Wesley, 2004). No caso do Mike há um probleminha que precisa ser mais estudado. Um probleminha que vou chamar de TMNUF (“Too Many Numbers Up Front”.. hehe, algo como “Números Demais, Cedo Demais”.
   Resumo (a ser melhor trabalhado futuramente): Trabalhando em um processo iterativo e incremental eu não consigo prever (com precisão de 50 dólares, como faz Mike) o fluxo de caixa líquido de 8 trimestres!!!
2. Muitos autores preferem falar de “riscos” ao invés de “complexidade”. Como me acostumei a falar de “riscos” para dizer “riscos do negócio”, utilizo “complexidade” para representar os riscos técnicos. Na realidade, “complexidade” pode abranger também a quarta variável citada no artigo, “oportunidades de aprendizado”.
3. Este artigo “esconde” uma pegadinha e uma provocação. Quem matar as duas, em comentário aqui registrado, garante uma vaga em uma das próximas turmas do FAN. Vaga impessoal e transferível! Promoção válida até o dia 25/agosto/2010.
4. Hoje encerro o tema principal: Priorização de Projetos. Depois devo publicar alguns artigos isolados para quitar alguns débitos deixados pela série, particularmente sobre BSc’s e seu uso no Planejamento Estratégico.
5. “Creating Solutions” é o cartoon do HikingArtist que encerra a série.

.:.

Antes, porém, vale a pena revisar o caminho que trilhamos até aqui. No segundo artigo eu sugeri o uso de um diagrama que nos ajuda a classificar processos de negócio e, consequentemente, seus respectivos projetos. Sinto ter tratado esse trabalho de forma um tanto rápida, como se ele fosse natural em nossas organizações. Não é.

O diagrama ao lado já exibe o resultado do trabalho de valorização que vimos no último artigo. Mas, antes de explicar o conteúdo, preciso elucidar o rabisco. É um mapa de processos desenhado em uma matriz de classificação. A matriz é um recurso mais didático do que prático. Pretende apenas criar o costume de diferenciar tipos de processos e tipos de processos primários logo no início de um projeto. Como vimos anteriormente, a coluna à direita exibe os processos mais relevantes para a proposta de valor da empresa. São os processos primários do tipo operacional que aparecem no exemplo que estamos desenvolvendo. Porque a proposição de valor de nossa empresa fictícia é a excelência operacional (“vender baratinho”).

Estou utilizando a UML e sua extensão para negócios EPBE. No mapa destaquei apenas os recursos de TI diretamente afetados pelas iniciativas que a empresa pretende disparar (Aqueles rabiscos ao lado das letras são os ‘pacotes’ da UML e representam sistemas ou módulos de um sistema) . Os recursos são organizados por processos. Temos então uma derivação dos diagramas de processos que na EPBE é chamada de “diagrama de linhas de montagem”. Claro, estou mostrando uma versão absurdamente simples deste artefato.

Três processos serão alterados de alguma maneira para que a empresa possa realizar seu objetivo de aumentar em 30% a rentabilidade das vendas. São eles: “Vendas”, “Entrega” e “PGV – Planejamento e Gerenciamento das Vendas”. Foram vinculados a eles três condições (requisitos) apresentados pelas áreas de negócio envolvidas:

f) Melhorar o Sistema de Agendamento;
h) Capturar Pedidos em tempo real; e
i) Adquirir / Desenvolver sistema de logística.

Os itens c (Comprar sistema GPS) e d (Integrar GPS com sistema de Agendamento), classificados no capítulo anterior como os menos relevantes, foram descartados neste momento do trabalho.

Antes de prosseguir, preciso de sua atenção para o seguinte: a “Captura de Pedidos em tempo real” (h) é a iniciativa que deve merecer 43% de nosso tempo e recursos. Opa… 43%?!? De onde veio esse número? No artigo anterior, utilizando a sequência de Fibonacci, valorizamos as iniciativas em 2, 2, 8, 13 e 5 pontos, respectivamente. Total = 30 pontos de valor. A iniciativa h vale 13 pontos, 43% de 30. Já já mostro a utilidade destes números.

Só quando temos uma visão clara e compartilhada sobre o que precisa ser feito é que devemos envolver a turma do ‘como’ – a equipe responsável por determinar a melhor maneira de atender cada um dos requisitos apresentados¹. A partir de agora a equipe técnica precisa estudar e avaliar alternativas de solução para cada solicitação. Apresentar uma só alternativa é arrogância; Cinco ou mais sugestões é exagero que não se paga. Três é o número mágico. Mas a elaboração das 3 alternativas não carece de magia nenhuma. Basta mostrar: a mais simples; a mais sofisticada; e a intermediária.

Não há nada que justifique que a equipe técnica não conheça a ordem de importância das iniciativas. Aliás, seu trabalho será muito melhor se desenvolvido a partir pleno entendimento das decisões estratégicas que deram origem aos requisitos apresentados. Só isso permitirá que a equipe técnica desenvolva uma linha de raciocínio representada pelo gráfico ao lado.

É o valor, a relevância de cada solicitação (requisito) para realização do objetivo maior, que deve determinar o rateio do orçamento.  Ele está representado pelo eixo Y do diagrama. No eixo X podemos distribuir o orçamento (os custos). Vamos supor que a nossa empresa fictícia tenha destinado R$ 300 mil para todo o programa (conjunto de projetos). Isso significa que a iniciativa h (Capturar pedidos em tempo real) poderá consumir até R$ 130 mil, ou 43% do orçamento total. Indica também que a equipe terá apenas R$ 50 mil para “Adquirir ou desenvolver um sistema de logística” (i). E justifica o descarte dos projetos c e d: com apenas R$ 40 mil ela não conseguiria adquirir aparelhos GPS e integrá-los ao sistema de agendamento. Ou conseguiria? Não importa. Não neste momento.

A linha pontilhada representa o “limite do bom senso”. Traduzindo: é muito difícil justificar qualquer projeto que a ultrapasse. Lembre-se: o eixo X representa os custos. Se, por exemplo, a contribuição dos aparelhos GPS para o aumento da rentabilidade das vendas é marginal ou questinável (2 pontos de valor, 7%), como justificar um investimento de R$ 50 mil (16% do orçamento) para a sua aquisição?

Municiada com esses limites lógicos a equipe técnica não perderá tempo “viajando na mayonaise”. De cara ela descartará, por exemplo, a consulta àquele maravilhoso fornecedor de soluções de logística que apresenta custos de licenciamento começando em R$ 200 mil. Pra que perder tempo? O limite de R$ 50 mil está colocado e não é negociável.

Eu sei, esse papo todo é óbvio demais. Mas quantas vezes você teve a oportunidade de discutir um orçamento amparado por tamanha obviedade? Lá na primeira parte da série eu prometi “apresentar sugestões que ajudem a definir o que é prioritário, o que pode aguardar na fila e o que não passa de bullshitagem sem valor”. Estou quase chegando lá. O problema é que eu também havia prometido ser mais prático e… direto! Mas ainda precisarei de um quinto capítulo. Só torço para que as sugestões apresentadas estejam servindo para alguma coisa. No mínimo como provocações. Inté!

.:.

Observações:

1. Iniciei aquele parágrafo com um medo danado de ser mal interpretado. Uma “visão clara e compartilhada do que precisa ser feito” não significa  BDUF (Big Design Up Front), uma tonelada de documentos nem nada do tipo. Os artefatos mostrados até o momento são mais do que suficientes para mostrar: Porque os projetos são necessários; Quem está envolvido; Quanto valor pode ser gerado por cada iniciativa; Onde mudanças são necessárias; Quando elas ocorrerão; e Como elas serão implementadas². Forcei a barra? Então aguarde o próximo capítulo.
2. Você já viu essa sequência de perguntas antes, não?
3. Não sei porque o tipo de análise apresentado neste artigo é universalmente conhecido como “Análise Custo X Benefício“. Prefiro “Benefício / Custo”. Pode parecer preciosismo de minha parte, mas prefiro ver os Benefícios antes de debater e definir Custos. Gastei 3 das 4 partes desta série preocupado exclusivamente com os Benefícios, com o Valor que devemos gerar para o negócio. Só agora comecei a falar de custos.
4. “Almost There” é o nome do cartoon utilizado. Como sempre, do HikingArtist.com.

.:.

Nossa querida e bem administrada empresa fictícia concluiu¹ que a realização de seu grande objetivo, o aumento de 30% da margem das vendas, depende do sucesso de quatro iniciativas: i) Aumentar base de clientes; ii) Reduzir giro de clientes (aumentar fidelidade); iii) Reduzir prazo de entrega; e iv) Reduzir o turn-over (rodízio) de vendedores. Ciente de que iniciativas desprovidas de indicadores e prazos são tão firmes quanto prego no angu, a empresa fixou as seguintes metas para cada uma: 15%; 25%; 2 dias úteis; e 50%, respectivamente. O prazo conhecido para a realização do grande objetivo é o ano que vem . Deve estar claro que requisitos para realização dos indicadores apresentados devem estar satisfeitos antes do início do ano. Considerando que este artigo foi escrito em agosto, vamos entender que temos cerca de 4 meses de prazo.

Todas as áreas do negócio responsáveis pela realização das metas apresentam suas condições – seus requisitos (!). O rabisco ao lado nos mostra que foram apontadas 13 solicitações. Elas são listadas abaixo, estruturadas nas 4 metas:

Meta #1 – Aumentar base de Clientes em 15%
a) Contratar mais 2 vendedores
b) Ampliar área de atuação
c) Comprar sistema GPS
d) Integrar GPS com sistema de Agendamento

Meta #2 – Reduzir giro de Clientes em 25%
e) Aumentar frequência de visitas (2 para 3 visitas mensais)
f) Melhorar sistema de Agendamento
g) Criar programa de Fidelidade

Meta #3 – Reduzir Prazo de Entrega de 5 para 2 dias úteis
h) Capturar pedidos em tempo real
i) Adquirir / Desenvolver sistema de Logística
j) Adquirir caminhões pequenos
k) Alugar armazém de médio porte na zona leste

Meta #4 – Reduzir Turn-over de Vendedores para 50%
l) Mudar esquema de comissionamento e bonificações
m) Fixar áreas de atuação exclusivas

Esta série de artigos tem como principal preocupação os projetos de TI. Então, por uma questão de simplificação, a partir de agora vamos nos ater apenas às condições (requisitos!) que representam ou podem representar demandas para o departamento de tecnologia da informação. Revendo a lista acima concluímos que os itens C, D, F, H e I são demandas diretas. Os itens L e M podem significar alterações em sistemas existentes. E o item G, dependendo de seu desenho, também pode respingar em TI. É trabalho pra chuchu.

Lembram-se de uma provocação colocada no artigo que virou estopim para esta série? As empresas devem colocar seus projetos em “fila indiana”. Neste ponto da história, todas as 13 (5 para TI) condições apresentadas são prioritárias. A empresa tem condições de conduzi-las e gerenciá-las simultaneamente? A empresa precisa executá-las simultaneamente? Um provável *não* para a primeira pergunta e um definitivo *não* para a segunda. Chega a hora de falarmos novamente sobre valor.

Durante muito tempo o mind-set tradicional de gerenciamento de projetos nos prendeu no triângulo custos, prazos e escopo. Quando elevada para a gestão de portfólios de projetos esta filosofia aumenta de maneira exponencial seu poder de estrago. Reparem, ainda estamos muito distantes de qualquer informação (ou preocupação) relativa aos custos das iniciativas. O que nos trouxe até aqui foi a relevância estratégica dos processos e a visão – os grandes objetivos de uma empresa.

Perdida no artigo anterior estava uma questão até agora não respondida: Quem define o valor? Quem define o grau de importância de cada condição (requisito!) apresentada? Não pode ser ninguém que não esteja diretamente envolvido com a realização das metas colocadas. Acontece que clientes e usuários, de mal atendidos ou mal acostumados que são, costumam atribuir o mesmíssimo (alto) valor para tudo o que solicitam. O que difere muito este momento é o fato de suas solicitações (condições ou requisitos!) estarem exclusivamente em seu domínio – são requisitos do negócio. Mais: todas, de uma maneira ou de outra, possuem indicadores (de negócio) atrelados. Traduzindo: seu julgamento de valor não depende de intervenções ou restrições de terceiros (particularmente de TI ou afins). Mas nós podemos ajudá-los².

A quantificação do valor, seja de projetos, requisitos ou histórias de usuários, segue merecendo o rótulo de “puro achismo” em diversas organizações. De certa forma, é melhor que a ignorância completa e absoluta que cerca o tema em tantas outras empresas. Uma certa complexidade do tema, principalmente de algumas propostas, talvez explique a situação atual. Mas não justifica. Existem métodos mais simples para avaliação do valor. Utilizarei neste artigo uma proposta apresentada por Jim Highsmith em “Agile Project Management – 2nd Edition“. Sua sugestão, Análise de Pontos de Valor, foi aplicada em histórias e funcionalidades. Utilizarei o mesmo método para a avaliação de projetos.

Se a avaliação de custos é facilitada pelo uso de valores absolutos (money!), o mesmo não pode ser dito sobre a avaliação do valor (ou benefício, se desejas um sinônimo mais corriqueiro em solo tupiniquim). Para entender o problema, veja o item C de nosso exemplo: “Comprar sistema GPS”. Como quantificar seu valor para o negócio? Ou ainda, como mostrar em termos absolutos sua contribuição para a realização da Meta #1 – Aumentar base de clientes em 15%? Difícil, né? Para não dizer impossível.

O maior erro que podemos cometer neste momento é tratar cada condição (requisito!) de maneira isolada. Não podemos nos esquecer que é o conjunto de condições que fará com que nossa estimada empresa fictícia aumente em 30% a rentabilidade de suas vendas. Dada a impossibilidade de uso de valores absolutos, devemos apelar para valores relativos. São os tais “pontos de valor” propostos por Highsmith. Ele sugere o uso da sequência de Fibonacci para fixação dos números relativos. Com um importante detalhe: a sequência deve ser finita. Em nosso exemplo utilizaremos {1, 2, 3, 5, 8 e 13}.

Vou resumir em poucas linhas um processo que pode durar horas ou até mesmo dias. Todas as partes interessadas devem atribuir um valor para suas condições. O consenso sobre a contribuição (peso) de cada solicitação (requisito!) para a realização do objetivo maior deve ser obtido. Nossa empresa fictícia, exemplar em tudo, rapidamente concordou com o seguinte:

c) Comprar Sistema GPS: 2 pontos
d) Integrar GPS com sistema de Agendamento: 2 pontos
f) Melhorar Sistema de Agendamento: 8 pontos
h) Capturar Pedidos em Tempo Real: 13 pontos
i) Adquirir / Desenvolver sistema de Logística: 5 pontos

Atenção para o que a classificação acima nos diz. Por exemplo: a captura de pedidos em tempo real (h) dá uma contribuição 6 vezes maior que a compra de um sistema GPS (c) para a concretização da visão da empresa (o aumento de 30% na rentabilidade das vendas). Isso significa que este é o projeto mais prioritário entre os prioritários? Ainda não. Mas sinto informar que precisarei de outro(s) artigo(s) para concluir a série³. Inté!

.:.

Observações:

1. Não está no escopo desta série a explicação de todo o processo que levou nossa honorável empresa fictícia a determinar que aquelas 4 metas, se ou quando plenamente atendidas, resultarão em um aumento de 30% da margem ou rentabilidade das vendas. Mas é preciso dizer que ele, o tal processo, faz parte daquela mistura de arte e ciência que convencionamos chamar de “Planejamento Estratégico”. Também devo confessar que raramente pude testemunhar elaboração tão clara, rápida e objetiva quanto a ilustrada neste artigo. Por isso nossa empresa fictícia é tão exemplar.
2. Olha o fio da meada aqui: “Nós podemos ajudá-los”. No contexto: TI pode ajudar as áreas de negócio no processo de definição do valor das iniciativas e projetos. Como? Através da aplicação da *boa* Análise de Negócios. Não através daquela lenga-lenga pequenininha dos “tiradores de pedidos”, mas através da *real* Análise de Negócios – aquela que ajuda a empresa a definir o que precisa ser feito. A isenção em relação à todas as áreas de negócios confere aos *bons* analistas uma posição privilegiada que os permite facilitar e intermediar todo o processo de planejamento e priorização de projetos. E vocês não sabem como fiquei satisfeito quando dois de meus clientes, gerentes ou diretores da área de Análise de Negócios, me contaram que estavam assumindo também o PMO. Ah, se fosse uma tendência…
3. Meu processo de elaboração de artigos é bem caótico e imprevisível. Sério! Quando escrevi o primeiro capítulo não tinha a menor idéia de que viraria uma série, muito menos que seria uma sequência com tantas partes. Por isso mesmo não sei se ainda precisarei de um, dois ou mais artigos até considerar o assunto concluído.
   Outra curiosidade: já escrevi tudo o que vocês estão vendo aqui em outro lugar, no meu fatídico e atrasado livro. Mas eu nunca faço ‘copy & paste’, nem de cá pra lá nem vice-versa. Cada um tem um estilo de redação e exigências de edição bem específicos. Mas é a elaboração cruzada que me dá uma produtividade muito boa.
4. Se chatearam com minha insistência em escrever (requisitos!) assim, entre parênteses e fechados por uma exclamação? Foi para lembrar e lembrar e lembrar que metas e objetivos do negócio são requisitos. Só isso.
5. Promessas feitas em capítulos anteriores e ainda não cumpridas: falar um pouco mais sobre BSc’s (Balanced Scorecards) e sobre projetos que, apesar de apresentarem baixo ou nenhum valor, são prioritários. Promessa é dívida. Pago na sequência da série.
6. “Economist Fortress“ é a imagem do HikingArtist.com utilizada hoje.

Encerrei o último artigo sugerindo que todos os projetos que toquem, melhorando ou criando, processos primários do tipo diretamente vinculado à proposta de valor (perfil estratégico) de uma organização devem ser considerados prioritários. Esta decisão, por si só, joga para um segundo plano algo entre 70% e 90% das demandas que uma empresa costuma apresentar. Basta? Claro que não, e por isso estamos aqui.

Antes, que tal tornar a sugestão acima um pouco mais visual? O diagrama ao lado apresenta três blocos horizontais, cada um representando um tipo de processo de negócio. Mostra também três colunas, A, B e C, que devem ser utilizadas para separar os três tipos de processos primários: Operacionais, de Gestão de Clientes e de Inovação. Ficará na coluna A aquele mais relevante para a empresa. Por exemplo: se sua proposta de valor é o menor custo total (“vendo baratinho”), então a coluna A representará os processos primários do tipo Operacional.

Portanto, o eixo X representa a relevância estratégica dos processos de negócio. O eixo Y, em três estágios, representa o valor daquele processo e respectivos projetos para o negócio. Quanto mais alto no gráfico, maior é o valor daquele processo ou projeto. Valor? O que é isso? Quem o define?

Segundo o Houaiss, além de representar o “preço de um produto ou serviço”, valor também pode significar a “importância que se atribui a algo ou alguém”. É esta segunda definição que nos interessa aqui. Um processo de negócio e seus respectivos projetos podem ter maior ou menor importância para uma empresa. Mas, afinal, o que determina a importância (valor) de um processo? Os grandes objetivos do negócio. Aqueles que, formalmente ou não, representam a Visão do Negócio.

Sinto ter que fazer um breve desvio aqui, porque acabo de entrar em um tema que ainda suscita algumas dúvidas. Ainda há uma certa confusão entre os termos Visão e Missão. Visão é o fim; Missão é o meio. A visão sempre tem um prazo de validade – ela deve ser renovada de tempos em tempos. A missão deve representar apenas a razão social de uma organização, o que ela está prometendo fazer pela sociedade. O exemplo que mais cito de declaração de missão eficaz e clara é da Google: “Organizar todas as informações do mundo e facilitar o acesso a elas”. Se a empresa de Mountain View durar cem anos, é provável que mantenha intacta sua declaração de missão. Já sua visão é renovada a cada triênio ou trimestre, dependendo de suas necessidades e de seu sucesso.

Mesmo quando uma empresa não formaliza seus objetivos na forma de uma Visão, o fato é que um fim existe. Reside aqui boa parte dos problemas que afetam muitas empresas hoje em dia. A falta de uma visão consistente e bem divulgada faz de uma organização uma bagunça. Ela pode estar repleta de colaboradores bem intencionados, mas é uma bagunça. Serei o milionésimo cara a citar “Alice”, de Lewis Carroll: “Se você não sabe para onde quer ir, então é indiferente o caminho que venha a seguir”. E colaboradores bem intencionados e pró-ativos trilharão caminhos mil. Perdidinhos da silva.

Uma boa visão deveria listar poucos objetivos de forma clara e não ambígua. Objetivos de negócio são melhor organizados na forma de árvores hierárquicas¹, onde ilustramos a contribuição de metas e objetivos menores para a realização de algo maior. A visão deveria concentrar apenas aqueles itens que formam a raiz desta árvore. Ou, no máximo, o primeiro nível de quebra.

É muito mais fácil gerenciar e medir o sucesso de projetos que se comprometem com objetivos de negócio bem claros.

Vamos supor que um dos objetivos expressos na visão de uma determinada empresa seja o aumento de 30% da margem ou rentabilidade das vendas. É um de seus objetivos para 2011. Não há neste caso uma iniciativa única que possa atingir este alvo. A empresa sabe que só um conjunto de projetos e mudanças² pode ajudá-la nesta realização. Utilizando o último diagrama como apoio, vemos que a empresa precisa disparar quatro grandes iniciativas e cada uma tem uma meta específica. Só o completo atendimento dessas metas resultará no aumento de 30% da margem das vendas. Neste exemplo as metas são:

1. Aumentar base de clientes ativos em 15%
2. Reduzir giro de clientes em 25%
3. Reduzir prazo de entrega de 5 para 2 dias úteis
4. Reduzir o turn-over de vendedores em 50%

Se considerarmos que o único grande objetivo desta empresa exemplo para 2011 é o aumento de sua margem de vendas, devemos aceitar que todo e qualquer projeto que não contribua diretamente para a realização de uma das metas acima é de baixo valor. Repito: todo e qualquer projeto³. Por outro lado, todas as iniciativas que provarem de maneira inequívoca sua relação com uma ou mais das quatro metas acima devem ser classificadas como prioritárias.

Agora você, atencioso que é, deve estar pensando: “Ok, já aprendi a separar o que tem valor daquilo que é bullshitagem pura. O autor apelou, utilizando como exemplo uma empresa que tem um único grande objetivo para o próximo ano⁴. Tudo bem, facilitou o entendimento. Mas, se eu entendi bem aquele último rabisco, eu vejo ali 13 ‘bolinhas’ que devem representar outras metas e, possivelmente, outros projetos. Esses 13 projetos são prioritários? Devo tratá-los da mesma maneira?”

A pergunta é boa. A resposta, só no próximo capítulo. Inté!

.:.

Observações:

1. Eu prefiro um tipo bem especial de ‘árvore hierárquica’ que atende pelo nome de Balanced Scorecard (BsC para os íntimos). Aliás, legal mesmo é  a representação de BsC’s com UML. Se você conhece a ferramenta, percebeu que no exemplo utilizado, mais precisamente na lista de 4 metas, apliquei a lógica de construção dos BsC’s. Hehe.. bobeira: só utilizei a sequência de perspectivas. No próximo capítulo eu falarei um pouco mais sobre isso.
2. “Projetos e mudanças”. Este trecho deveria ser considerado um pleonasmo: todo projeto representa uma mudança. Toda mudança deveria ser administrada como um projeto? Creio que sim.
3. Calma. O fato de um projeto ser de baixo valor não significa que ele não seja prioritário. Por exemplo: uma exigência legal ou para atendimento de algum padrão. Seu valor para o negócio é baixo mas ele será prioritário. Mais sobre isso no próximo artigo.
4. Desconfio que toda boa empresa, independente de seu porte ou ramo de atividades, mantém algo entre 4 e 6 grandes objetivos. E os revê e renova anualmente, mesmo em tempos de turbulência. Mas eu gostaria de ver exemplos que comprovem ou detonem essa desconfiança.
5. Utilizei outro free-cartoon de HikingArtist.com, desta vez “Looking for a Needle”.

Qual é o problema? Muitas empresas lidam com dezenas ou até centenas de iniciativas simultâneas porque não sabem ou não têm coragem de definir o que é mais importante. Organizações de TI se comprometem com coisas demais e quase sempre entregam de menos.

Qual é a intenção deste artigo? Apresentar sugestões que ajudem a definir o que é prioritário, o que pode aguardar na fila e o que não passa de bullshitagem sem valor. Antes que você me acuse, me permita dizer: é claro que seria pretensão exagerada deste que aqui rabisca qualquer tentativa de esgotar assunto tão cabeludo num simples artigo de 1438 palavras. Por favor, receba este texto como meus 2 centavos. Ou como um bê-a-bá – no sentido de ser um ponto de partida.

.:.

Toda organização, independente de seu porte ou ramo de atividades, tem três tipos de processos de negócios:

• Primários: são aqueles que tocam, direta ou indiretamente, o freguês (cliente externo). É o que os letrados chiques gostam de chamar Core Business. É aqui que uma empresa ganha dinheiro, se diferencia ou se estrepa.
• De Apoio: representam tudo o que a empresa não gostaria de fazer mas é obrigada, por necessidade (apoiar os primários) ou por exigência (legal e / ou social). Como representam “só despesa”, foram os primeiros informatizados, terceirizados, reengenheirados etc.
• De Gestão: governam os outros dois. Segundo Gary Hamel, está aqui a última fronteira da Administração². A onda da tal Governança Corporativa, de certa forma, confirma sua tese.

Não deveríamos consumir muitos neurônios para descobrir que projetos que tocam (melhoram ou criam) processos de negócio primários são prioritários. Se é ali que a empresa “faz caixa”, é ali que a empresa deveria se concentrar. Ou, colocando de outra forma, é ali que a empresa deveria concentrar seus melhores recursos. Mas como saber, entre todos os projetos daquela área, quais demandam mais atenção? Vamos mergulhar um pouco mais no core do negócio.

Existem 4 tipos de processos primários:

• Operacionais: são as vendas (e respectivas compras), as entregas ou operações de suporte, por exemplo. Qualquer operação que envolva o cliente externo, mesmo que de maneira indireta, se encaixa nesta categoria.
• De Gestão de Clientes: pensou no famigerado Marketing de Relacionamento ou CRM? Acertou, mas lembre-se que os processos de gestão de clientes não se limitam ao departamento de Marketing, ok?
• De Inovação: qualquer processo ou conjunto de processos que pretenda criar ou melhorar processos, serviços e / ou produtos também deve ser classificado como primário. Mesmo quando ele não envolve diretamente o freguês (no método Steve Jobs de desenvolvimento de produtos, por exemplo).
• Regulatórios ou Sociais: pois é, até a coleta seletiva de lixo – uma mínima prova de preocupação com a sociedade – deve ser classificada como processo primário. O freguês, de uma forma ou de outra, se beneficia com iniciativas dessa natureza.

Com exceção do último, que deveria existir em qualquer organização minimamente responsável, os outros três tipos de processos primários são tratados de maneira bastante diferente dependendo da proposição de valor de uma empresa. Vou usar uma classificação proposta por Kaplan e Norton, os mesmos autores da lista acima.

Antes, o que quer dizer “proposição de valor”? É a forma como a empresa se apresenta para seus clientes – seu fator fundamental de diferenciação. Apesar de afetar tudo dentro de uma organização (objetivos, recursos, processos e regras), a proposta de valor se prova de verdade na realização dos processos primários. Kaplan e Norton³ sugerem a existência de 4 propostas básicas:

• Vendo Baratinho: uma proposição quase unânime em solo tupiniquim (ao ver comerciais de TV, parece ser a única adotada por aqui). Fleury e Fleury⁴ sugerem um nome mais pomposo para esta proposta: Excelência Operacional. O termo é bom porque nos remete diretamente aos processos primários do tipo operacional. Ou seja, em organizações que se diferenciam pelo menor custo são ou deveriam ser prioritários todos os projetos que toquem os processos de negócio primários do tipo operacional. Essas empresas deveriam privilegiar os investimentos em ERP’s, cadeia de suprimentos, sites de comércio eletrônico, logística etc.
• Inovo pra Caramba: tanto que sou quase uma Apple (ou Havaianas). A empresa se diferencia pela criatividade de seus produtos ou serviços. E só isso as torna o exato oposto daquelas que “vendem baratinho”. São antagônicas em tudo. Enquanto quem “vende baratinho” é ou precisa ser “mão de vaca” (pão duro, seguro), empresas inovadoras são ou deveriam ser naturalmente perdulárias. Algumas mais e outras menos responsáveis, mas perdulárias. E sua proposta (inovação) nos leva diretamente aos processos primários de inovação. É aqui que ela concentrará seus esforços. Empresas deste tipo investem em soluções para gestão do ciclo de vida de produtos (PLC), ferramentas de colaboração etc.
• Aqui você Acha: precisou de qualquer coisa que gire em torno de <objeto>, nós temos. Formalmente esta proposta é chamada “Soluções Completas” por Kaplan e Norton. Pense em um banco ou seguradora, por exemplo. Considerando o perfil dos projetos e critérios para priorização, devemos entender que elas são praticamente idênticas às empresas que
• Aprisionam Clientes: aquelas que configuram seus produtos e / ou serviços como plataformas difíceis de serem trocadas pelos fregueses. Você acertou se acabou de se lembrar de sua operadora de telefonia celular. A semelhança com a proposição anterior fez com que Fleury & Fleury as classificasse como uma só: “Orientadas à Serviços”. De fato, seus processos mais relevantes são os mesmos: os processos primários de gestão de clientes. O que significa dizer que sua atenção vai ou deveria ir para projetos de CRM, telemarketing (argh!) etc.

Um necessário resumo: merecem prioridade máxima projetos relacionados com a melhoria, evolução ou criação de processos de negócio primários. O perfil da empresa, declarado em sua proposição de valor, dirá se merecerão prioridade máxima os projetos que toquem processos primários operacionais (perfil = Excelência Operacional); de gestão de clientes (perfil = Orientação à Serviços); ou de inovação (perfil = Inovação em Produtos e / ou Serviços). Simples assim. Basta? Claro que não.

O que acontece se tivermos duas ou mais demandas que se referem ao mesmo tipo de processo? É claro que elas não têm a mesma relevância para empresa. Mas qual deve ser o critério de desempate? Semana que vem eu conto. Inté!

.:.

Observações:

1. Não canso de recontar a origem de meu slogan: em uma matéria especial da revista Business 2.0, em 2005, perguntaram para o Peter Drucker: “O que os executivos parecem não aprender nunca?”. Resposta: “A perguntar ‘o que precisa ser feito?‘”. É tão verdadeira que olha sobre o que estamos conversando aqui.
2. “O Futuro da Administração“, Gary Hamel com Bill Breen. (Campus, 2007).
3. Claro que Robert Kaplan e David Norton não utilizaram termos como “vendo baratinho”. Sua classificação, apresentada em “Mapas Estratégicos” (Campus, 2004) é a seguinte: Baixo Custo Total; Liderança do Produto; Soluções Completas para Clientes; e Aprisionamento (lock in).
4. “Desenvolver Competências e Gerir Conhecimentos em Diferentes Arranjos Empresariais“, artigo de Maria Tereza Leme Fleury (FEA/USP) e Afonso Fleury (Poli/USP), publicado no livro Gestão Estratégica do Conhecimento (Atlas, 2001).
   É importante dizer aqui que a classificação de propostas de valor ainda não é consenso. Michael Porter, por um bom tempo, disse que haviam apenas duas: preço e inovação. Depois ele apresentou uma classificação próxima daquela proposta por Fleury e Fleury, com termos diferentes: Estratégia baseada na Variedade; Estratégia Baseada na Necessidade; e Estratégia Baseada no Acesso. Cá entre nós, Porter reinventa rodas. Prefiro a classificação de Kaplan e Norton (tópico 3 acima), pela objetividade e clareza. Mas sei que em alguns casos é difícil definir apenas uma proposta. Por exemplo: a Apple inova ou aprisiona? Inova aprisionando? Ou aprisiona inovando? hehe..
5. O cartoon utilizado, “Defining targets differently“, foi liberado para uso no Flickr por HikingArtist.com
6. Não é a primeira vez que brinco com o título “Como Fazer Amigos e Influenciar Pessoas“, lançado por Dale Carnegie em 1937 – o pai de todos os autores de livros de auto-ajuda. Acho que já contei por aqui que é o livro que mais ganhei de presente. Por que será?
   Agora falando sério: Priorizar, tomar decisões, é em certa medida uma forma de Fazer Inimigos e Desagradar Pessoas. Desconfio que o título acima (e todos os seus derivados) contribuíram muito para a criação de ambientes assépticos e exageradamente avessos a debates. Ajudaram a criar pessoas e organizações que morrem de medo de errar, de tomar decisões e de falar um simples “Não!”. Mas eu só desconfio.

Não entendo como eles podem tocar tantos projetos simultaneamente. E, considerando que essas empresas contam com algumas dezenas de AN’s, não entendo como elas conseguem disparar e cuidar de tantas iniciativas.

O burburinho vira debate quando emendo uma segunda recomendação: AN’s deveriam trabalhar sempre em duplas. Uma rápida conta de padaria, que tanto caracteriza a matemática dos novos tempos, deve deixar todos aturdidos: “Hoje tenho 100 projetos e 10 AN’s. Você está sugerindo que eu contrate 190 analistas?!?” Isso sim seria uma bela política para geração de (bons) empregos. Mas reconheço sua inviabilidade.

É fato que a sobrecarga insana de trabalho não é um privilégio dos AN’s. Infelizmente, é outra característica do século XXI. Mas ninguém deveria aceitar isso como um fato consumado e pronto. No caso específico dos AN’s não é difícil descobrir e tentar corrigir as razões de tanto trabalho¹.

Em primeiro lugar é preciso dizer que nenhuma empresa tem tantos projetos assim. Projetos, com ‘P’ maiúsculo, devem representar apenas algo entre 10% e 20% de toda a demanda. O restante trata de alterações ou evoluções em soluções existentes, nos famigerados sistemas legados. E por que as empresas estariam utilizando analistas de negócios para cuidar de solicitações de manutenção em aplicações?

Uma desculpa razoável seria a competência desses profissionais para o desenvolvimento de requisitos. O que muitas organizações não entendem é que não existem, na grande maioria dessas solicitações, requisitos. Não no sentido de existirem necessidades verdes o suficiente para justificar todo o processo de maturação intrínseco à Análise de Negócios. Noventa e tantos por cento das novas necessidades dos usuários são simples e diretas, como por exemplo: “coloca um novo campo assim nesta tela”. Gastar AN’s com solicitações dessa natureza é um belo desperdício.

Sabe-se lá por que cargas d’água inventaram um novo nome para atendentes de help-desk. Sim, porque solicitações de manutenção deveriam ficar no âmbito daquele grupo que um dia batizamos “help desk”.

Ouço de algumas empresas que parte das solicitações tem real necessidade de Análise do Negócio. Ok, mas quantas? Duvido que sejam 10% delas. E insisto: é desperdício. Mas entendo: começaram a colocar AN’s para desempenhar essa função na vã esperança de melhorar um cadinho a qualidade do atendimento. Acontece que a solução virou um tiro de bazuca no pezão: AN’s estão aprendendo a desenvolver um monte de coisa. Leem o BABoK ou participam do FAN e absorvem dezenas de ferramentas que podem tornar seu dia a dia menos desagradável. Pena que sejam coisas que agregam muito pouco ou nada quando o trampo é só de manutenção de sistemas. Pior: são coisas que custam tempo e dinheiro.

Uma grande, imensa empresa tupiniquim se prepara para experimentar um novo desenho. Deve instituir a figura dos Analistas de Demandas ou algo parecido. Seria o meio termo entre analistas de negócios e atendentes de help-desk. Não sei se a solução não deveria ser simplesmente uma melhor preparação do pessoal de suporte. Uma preparação que passasse obrigatoriamente pela especialização. Por exemplo: o cara que atende chamados sobre impressoras não pode ser o mesmo que recebe solicitações para o SAP/R3. Parece óbvio, mas não é tanto assim em alguns lugares que conheço.

Não há processo ou ferramenta que substitua um simples “Não!”

Um segundo fator que contribui muito para a sobrecarga de AN’s é a incapacidade que algumas organizações têm de falar “Não”. Em tempos de nervos à flor da pele, competição interna sanguinolenta, políticas demasiadamente corretas e grave miopia onde deveria existir só *Visão*,  a impressão que fica é que todas as demandas e projetos são prioritários, vitais e pra ontem. Uma peneirinha meio esburacada já ajudaria muito. Gastamos tanto com soluções para gestão de portfólios, PMO’s e afins, e seguimos sem a mínima capacidade de dizer qual projeto merece mais atenção e recursos. Enquanto uma organização não aprender a colocar suas iniciativas e demandas em uma fila indiana (uma atrás da outra, sem exceção) ela seguirá com a sensação de sempre ter mais trabalho do que recursos disponíveis para executá-lo².

Justificando as Sugestões

“Que tal sugerir que cada dupla de AN’s tenha um mordomo ao seu dispor?” Já ouvi algo parecido, de um colega que interpretou de maneira um tanto precipitada minhas sugestões. Não defendo sombra e água fresca para AN’s. Apenas insisto que eles não conseguirão provar seu valor se: i) Trabalharem em mais de um projeto (ou dois projetos pequenos); e ii) Não trabalharem em duplas. Por favor, me permita justificar.

Defendo que todo projeto de software seja desenvolvido seguindo um modelo Iterativo e Incremental. Deve estar implícita nesta sugestão a necessidade dos AN’s permanecerem no projeto do primeiro até o último dia. E, a menos que o projeto seja pequenininho, é impossível que os AN’s cuidem (bem) de mais de um. Repito: impossível.

Pense nas principais tarefas desempenhadas por um AN: entender um negócio e determinado problema ou oportunidade; e entender o usuário, suas necessidades e restrições. Ambos “entendimentos” ocorrem simultaneamente, em diversas situações. Vamos simplificar e usar o modo mais corriqueiro: o AN entrevistando um usuário. Ele deve prestar atenção em seu interlocutor e conduzir a entrevista. O “olho no olho” é importante, assim como a leitura de sinais, caretas e tiques. A explicitação da conversa, seu registro na forma de diagramas, especificações de casos de uso etc, é igualmente importante. E demanda a mesma fatia de atenção. Como um AN pode desempenhar bem, simultaneamente, duas funções tão distintas?³

Já experimentei de tudo para substituir a explicitação anotada: gravação de áudio, vídeo etc. Nada substitui uma segunda cabeça. Ao término de uma entrevista, no momento da análise dos requisitos aprendidos, ela completa o entendimento, ajuda a destacar pontos obscuros e dúvidas. Enfim, duas cabeças sempre serão melhor que uma.

Outra justificativa para o uso de duplas é o melhor aproveitamento das habilidades de cada um. Tem analista que parece ter nascido para a socialização: é bom de papo, transmite segurança e sabe lidar com usuários e clientes. Outros são talentosos na redação e desenho. É relativamente raro encontrar um AN que faça muito bem as duas coisas. Como é impossível que ele faça bem as duas coisas simultaneamente, por que não equipá-lo com seu par ideal?

Eu sei, a implementação dessas sugestões tem que entrar na fila. As empresas que pretendem obter o máximo da Análise de Negócios devem ter outras prioridades: i) Aprender a dizer “Não!”; ii) Colocar os projetos em fila indiana; e iii) Separar o hoje (operação) do amanhã (projetos). E não é que a Análise de Negócios pode ajudá-las até nisso? Bom, acabei de arrumar mais areia para os abarrotados caminhõezinhos dos AN’s. Inté!

.:.

Observações:

1. Eu quis dizer que a identificação dos problemas é fácil. Sua solução, nem tanto.
2. Perguntinha retórica mas necessária: capacity planning só vale para máquinas?
3. Vira e mexe me deparo com uma solução curiosa: o AN diz que anota tudo rapidinho, priorizando o contato “olho no olho” com o usuário ou cliente. Depois volta para casa e “passa tudo a limpo”, inclusive escrevendo os casos de uso. Esforço total: 4 horas, por exemplo. Se ele tivesse um par que o isentasse da anotação, ciente de que “passar a limpo” é desperdício e que especificações de casos de uso são construídas na frente do usuário, consumiria as mesmas 4 horas.
4. A imagem utilizada, “Colorful toy trucks parked in a circle“ é de Horia Varlan e foi obtida no Flickr.

Hoje vou falar sobre motivação em projetos “custom”, aqueles desenvolvidos especificamente para uma organização. O entendimento da motivação para esse tipo de projeto é um pouquinho mais complicado. Em artigos anteriores (1 e 2) eu falei sobre alienação (da equipe de desenvolvimento) e problemas de comunicação. A *motivação* desta série é a dificuldade que equipes apresentam para decidir o que é prioritário em um projeto. A *tese* aqui defendida é que todas as decisões sobre priorização deveriam se basear nos requisitos do negócio – nos objetivos que *motivaram* o projeto. Parece papo de maluco, né? Afinal, não é natural ou óbvio que seja assim? Envergonhadamente devemos admitir que não, não é natural.

Chegamos em um estágio em que o usuário pede, “faz uma tela assim e assado”, e a equipe vai lá e faz. Aquela “tela”, que aos olhos do usuário parece algo banal, logo vira uma dor de cabeça coletiva: não se comunica bem com outras aplicações ou módulos de um mesmo sistema; quebra a ordem conhecida de um processo de negócio; apresenta regras de negócio conflitantes com outras previamente implementadas; recebe frequentes pedidos de alterações etc. Mas o que nos interessa aqui, agora, é que demandas deste tipo carecem de sentido: O que o negócio ganha com isso? Ou o que ele perde se a solicitação não for atendida? E quando chegarem dúzias de demandas parecidas, quais merecerão o início da fila?

O processo não pode ser mecânico assim. TI não é padaria, com todo respeito às padarias. E usuário, mesmo quando guiado pelas melhores das melhores intenções, não deveria invadir o domínio da solução como no exemplo acima. Ele não deveria pedir uma tela, um módulo ou um sistema. Ele deve explicar suas dores, os seus problemas. Se a solução para eles será uma tela ou um sistema, quem dirá é a organização de TI. E TI toma boas decisões quando as fundamenta através da Análise de Negócios.

O bom analista de negócios não começa seu trabalho em um projeto anotando os requisitos de um usuário para determinada tela, módulo ou sistema. Ele começa tentando entender e diagnosticar as dores do usuário. O bom analista sabe que nem sempre a solução será um sistema. E é aqui que o trabalho em projetos “custom” se diferencia demais daqueles que na parte anterior chamamos de “pacotes”. Aqui há um problema específico a ser diagnosticado e sanado.

A necessidade de um diagnóstico rápido e eficaz é o que justifica minha cara de pau de sugerir uma sensível alteração na sequência de perguntas proposta por Dan Roam em “The Back of the Napkin” (Portfolio, 2008). “Por quê” é a primeira pergunta que o analista faz: “Por que este projeto é necessário?”. A resposta e toda a conversa que se desenvolve a partir dela nos ajudam a criar uma das três visões que compõem um modelo de negócios básico, a Visão do Negócio. Esta perspectiva, que pode assumir diversos estilos e formatos, compila todos os objetivos do negócio. Colocando de outra maneira, ela documenta a motivação para o projeto.

É importante que ela, a Visão do Negócio, não seja confundida com o Documento de Visão. Este apresenta a visão (oh!) da solução. Ao desenvolver a Visão do Negócio, o analista ainda está relativamente distante da solução e sua respectiva visão.

A visão do negócio pode ser representada por uma única linha em um documento, como por exemplo: “Dobrar o número de visitas realizadas pelos vendedores“. Mas ela também pode ser mais elaborada, como tenta mostrar o diagrama abaixo. A complexidade de um negócio ou a amplitude e criticidade de suas dores determinarão o formato mais adequado para entendimento e documentação¹ dos requisitos do negócio.

Pois é, apelei para o causo do seu Moreira para dar um pequeno exemplo de diagrama que pode formar a visão do negócio. As duas áreas destacadas mostram todos os requisitos de negócio. O que pode ser apenas uma frase, “Dobrar o número de visitas”, em um diagrama mais elaborado pode ganhar a forma de uma hierarquia de objetivos ou requisitos de negócio. Repare que o “Dobrar nº Visitas” é quebrado em vários objetivos menores. E ele próprio deriva de outro, ou, colocando de uma maneira diferente, é condição para a realização de outro requisito, “Dobrar Faturamento”.

Muito se fala sobre rastreabilidade de requisitos: “Toli Toli Tolá…” – e a cobla ficou lá², vendendo matrizes de rastreabilidade. Perdão. Para o analista de negócios é fundamental que o aprendizado e desenvolvimento dos requisitos obedeçam uma lógica parecida com a ilustrada no diagrama abaixo:

A visão do negócio é a representação direta de todos os objetivos e metas, o que chamamos de requisitos do negócio. Todos os demais requisitos, independente do tipo ou nível de granularidade, devem derivar deles. Ou seja, devem mostrar seu *valor* – como apoiarão, direta ou indiretamente, a realização dos objetivos do negócio. Cada caso de uso, por exemplo, deve exibir de forma clara quais são os objetivos atendidos por ele. E estes objetivos devem ter uma ligação nítida com os requisitos de negócio maiores.

Quando este conceito é bem implementado, a equipe consegue perceber com relativa facilidade o que é e o que não é prioritário em um projeto. No próximo artigo desta série falarei especificamente sobre valor e a priorização de todos os requisitos. Inté!

.:.

Observações

1. Documentação! Palavrinha que causa arrepios, não? Chuto e sugiro que 80% dos artefatos gerados por um analista de negócios vá para o lixo tão logo tenha cumprido sua missão: facilitar o entendimento. Sua manutenção não se justifica na maioria das vezes porque: 1) É cara; 2) É muito frequente. Negócios mudam todo dia. É difícil manter documentos assim 100% sincronizados com a realidade. Acredito que para a maioria das organizações, um diagrama representando cada perspectiva (do Negócio, da Estrutura e dos Processos) seja suficiente. Mas, eu sei: cada caso é um caso.
2. Não entendeu? Então você não passou sua infância ou juventude no início dos anos 80. Paciência. O “toli toli tolá” era cantarolado pelo Honolável Besoulo Japonês toda vez que ele dava um drible a la Neymar em seu arqui-inimigo, a Cobrinha Azul. Hehe… Ok, sei lá porque me lembrei disso agora. Cobra, Azul, eternamente driblada, Matrizes de Rastreabilidade… há um conjunto aqui… eu sei que tem…
3. Abstract é outra foto que surrupio da Tanakawho.

Os dois receberam os primeiros módulos do sistema – para manutenção de cadastros (CRUD para os letrados), um mês após o prazo combinado. Gerente do projeto e um dos desenvolvedores fizeram a entrega. O gerente marcava a página de sua agenda com a fatura do mês. A anterior foi paga, apesar do atraso. Convenceram sobrinho e contador e depois o ‘seu’ Moreira com um pacotinho de modelos e um gráfico GANTT, o cronograma. Agora não tinha jeito. Ou eles viam alguma coisa do sistema ou “nem um centavo” sairia dali, como disse o Moreira. Cinco módulos de cadastros foram instalados no único micro da empresa. “Passa da hora de vocês comprarem o servidor e uma estação de trabalho, hem?”, pediu o gerente. O sobrinho disse que as cotações já haviam sido feitas e que o seu tio apenas esperava a real necessidade antes de fazer o desembolso. “E os micros para os vendedores, vocês já decidiram qual será?”. O contador falou que avaliavam três alternativas, mas não deixou a conversa prosseguir. Queria ver a entrega.

Foram quatro horas de entrega e treinamento, duas além do previsto pelo gerente. Quando ele viu que a coisa ia se prolongar, ligou para o dentista e desmarcou a consulta, apesar da urgência: “Tem duas semanas que esse ciso não me deixa comer nem dormir direito”. Mas ele nem cogitou deixar o desenvolvedor fazendo a entrega sozinho depois que reparou que ele não era muito paciente nem muito bom com as palavras faladas. Gerenciou bem o risco. Até porque o ‘seu’ Moreira invadia a sala a cada meia hora: “e aí, novidades?”

.:.

Enquanto isso, entre uma discussão ou outra envolvendo MySQL, noSQL, ShitQL e coisas assim, a equipe tentava trabalhar. Todo dia tinha uma briga com o DBA, que não conseguia fazer valer o seu modelo. “Mas ele já foi homologado pelo cliente!”, gritava, arrancando gargalhadas. “Cara, o cliente não sabe nem o que é um banco de dados”, tentava explicar um desenvolvedor. O “clima ruim” contaminava até as “happy hours” que aconteciam de terça a sexta. Numa delas, quando parecia inevitável que o arranca-rabo descambaria para as vias de fato, o analista de negócios pediu demissão. “Ninguém merece”, choramingou. Na época ele já trabalhava por meio período no projeto do ‘seu’ Moreira. No restante do tempo ajudava os vendedores em atividades de pré-vendas. Sua decisão realmente não era reflexo dos 11 chopps, como torceu o gerente do projeto. Só voltou na empresa 10 dias depois, para fazer o acerto. Relutante, aceitou uma conversa de hora e meia com o desenvolvedor mais novo e o gerente para passar aquilo que não estava documentado.

O gerente ouviu cético a promessa de que um novo analista seria contratado “asap”. Já aceitava, experiente que era, que teria que levantar ele mesmo os requisitos dos módulos de Mapa de Carga, Estoques e Vendas. Não sabia o que lhe doía mais, se as novas responsabilidades ou o dente de ciso.

{continua}

.:.

Minha intenção original era casar o fim do causo do ‘seu’ Moreira com a estreia dos dois “Jogos dos 7 Erros”. Infelizmente, como vocês podem ver na agenda ali em cima, os eventos foram adiados para 16 e 17 de abril. O lado bom da história: vou poder trabalhar o causo com mais calma (e mais artigos).

Preciso dizer que esta história específica, por ser antecipada aqui, não aparecerá mais nos “jogos”. Como tenho um bom estoque de causos, isso não é problema. Outra coisa importante a ser dita é que o exercício aqui proposto é diferente daqueles (7) que fazem parte do novo evento porque é aberto demais. Lá existirão temas, erros específicos. A história do ‘seu’ Moreira está repleta de enganos. Abaixo dos óbvios, que tem fins meramente ilustrativos e provocativos, existem aqueles que realmente desafiam analistas de negócios, gerentes e demais integrantes de uma equipe de desenvolvimento. Você consegue apontá-los? Alguns colegas participam da “oficina virtual” nesta thread do grupo AN.br. Caso interesse, entre. A casa é sua.

O tema começou a me chamar a atenção quando percebi que vários participantes do FAN não eram analistas de negócios (AN’s) de fato, mas luxuosos atendentes de help desk. Seu dia-a-dia não é o apoio a novos projetos mas sim o tratamento de demandas de manutenção em sistemas. Por favor, não estou dizendo que demandas de manutenção não mereçam a alocação de AN’s. Algumas poucas, que de fato representam mudanças no negócio, justificam isso. Acontece que a grande maioria delas, independente do tipo ou porte do negócio, refere-se exclusivamente aos sistemas. Pior, são fruto de sistemas de baixíssima qualidade técnica.

O imenso e incomensurável backlog de manutenção é o inferno de um sem número de departamentos de TI. Ao que tudo indica, muitos acreditaram que os AN’s representariam uma boa resposta. Caro engano. Tão dispendioso quanto aquele de um famoso instituto que registra “recomendações” numa famosa publicação tupiniquim: em um de seus últimos artigos, “ele” falou que estruturas de projeto e de manutenção não precisam ser separadas. E que tal divisão poderia resultar em acidentes. Céus!

Quando projetos e manutenção começam a concorrer pelos mesmos recursos, e dado nosso “tudo é para ontem”, é claro que a manutenção – a necessidade “indriblável” de apagar de incêndios – sempre prevalecerá. Resumindo: se a empresa nutre uma mínima preocupação com seu futuro, deveria ter uma unidade que cuide exclusivamente de novos projetos. E é aqui que os AN’s podem provar seu valor e justificar seus custos.

.:.

Mas, como antecipei lá nas categorias deste artigo, eu não quero falar apenas sobre a análise de negócios. Quero aproveitar a oportunidade para tocar n’outro tema caro e meio raro (por aqui): arquitetura. Já acreditei que SOA (Arquitetura Orientada a Serviços) era uma excelente resposta à crescente demanda por flexibilidade e agilidade. Bom, ela segue excelente. Mas está longe, muito longe de ser uma resposta universal. Muitos daqueles sistemas que conhecemos como “legados” são tão feios, frágeis e gambiarrados que impedem que o “botox” SOA surta algum efeito. Daí que de uns tempos pra cá resolvi ressuscitar um conselho daquele mesmo instituto que critiquei acima: “aposente 2 ou 3 sistemas legados por ano. Ponto.”

O conselho é anterior às ondas EAI (Enterprise Application Integration) e SOA. Mas a cada dia se torna mais necessário e urgente. O fato é que há um imenso abismo entre a arquitetura tecnológica de vários sistemas legados e as demandas atuais. A ploriferação de modernos canais digitais e a crescente pressão que eles excercem sobre aplicações antigas justificam a incorporação desse discurso de urgência. E é importante notar que não estou falando apenas de coisas de museu como Cobol², Oracle Forms, Delphi, Visual Basic, Fox ou Clipper. Tudo o que nasceu na primeira geração da Internet deve ir para o lixo. Devemos aceitar o fato de que nossos primeiros sites e aplicações Web, mesmo aqueles com “apenas” 5 ou 6 anos de vida, serviram para aprendizado. Mas hoje são pesadíssimas âncoras que impedem nossa evolução. Cada centavo gasto em sistemas antigos (feios, frágeis e gambiarrados) é centavo jogado fora. Mesmo que o centavo seja contabilizado em rubricas chiques como SOA, BPM, BI e afins.

A aposentadoria de aplicações de negócios está longe de ser uma coisa trivial. São raríssimas as empresas que utilizam um processo de gerenciamento do ciclo de vida de sistemas³. Nós desenvolvedores só falamos, através de nossas mágicas metodologias, do ciclo de vida de projetos. Pouquíssima ou nenhuma atenção é dada ao sistema entregue. Até o dia seguinte ao término do projeto, quando aquele sistema vira “legado” e um novo foco de incêndio a ser combatido diariamente.

.:.

Auren Hoffman escreveu um excelente artigo sobre “Ser Bom em Matar Coisas“. Um bom líder de TI deve saber hora e forma de matar (ou aposentar) seus sistemas. Como já falei demais, guardarei “hora e  forma” para futuros artigos. Inté!

.:.

Observações:

1. O colega Saulo Arruda citou, num comentário lá no Graffiti, que uma grande empresa de Telco ainda demanda projetos em ASP (não .Net) com uso incondicional do Windows 2000 e IE6. Falou também de uma montadora com a mesma arquitetura. Qualquer coisa feita em ASP deveria ir para o lixo incondicionalmente. E escrever projetos novos em ASP é o mesmo que “tentar apagar incêndios com etanol”, para surrupiar e adaptar um antigo dito de Fred Brooks (utilizado em outra situação, é claro).
   Pedindo licença aos letrados, tentarei explicar aos leigos porque ASP (Active Server Pages) é uma das coisas mais medonhas e perigosas já inventadas em nossa área. Pensem num texto qualquer escrito de maneira desestruturada e acidental em três dialetos distintos, todos misturados. Três dialetos mais ou menos assim: a língua de participantes do BBB, a linguagem cifrada que a geração Y usa em sites de relacionamento mais um manuscrito original de um Jack Kerouac bêbado. ASP é assim. E na mão de programadores eXpertos vira poesia pura.
2. Há quem diga que Cobol se modernizou. Tem também aqueles que defendem que ainda não inventamos nada para substituí-lo em grandes corporações (o que me faz pensar se Google, Amazon e afins são pequenas). De qualquer maneira, como não vejo a carinha dele (Cobol) há muito tempo, deixo a dúvida no ar.
3. Para falar a verdade, só conheço uma proposta formal de processo que prevê o gerenciamento do ciclo de vida de sistemas. Ele atende pelo nome EUP (Enterprise Unified Process) e foi criado por Scott Ambler. Sim, podemos dizer que é um irmão bastardo (e ainda não reconhecido) do RUP.
4. A imagem utilizada, Tändsticka, é do brandbild e foi liberada como CC-by, por isso está aqui.

Vimos lá no início do causo que o ‘seu’ Moreira repassou para o sobrinho e o contador a responsabilidade pelo acompanhamento do projeto. Em ‘tempo de proposta’, eles tiveram um único encontro com o analista da empresa que venceu a concorrência (por W.O., como vocês devem se lembrar). Hoje voltaremos exatamente para aquele momento, quando o analista solicitou um contato com os vendedores e não foi atendido.

Seguindo uma dica que ele aprendeu com um colega que participou de um tal de FAN, o analista decidiu que utilizaria aquelas quatro horas na empresa do ‘seu’ Moreira para elaborar uma grande ‘fotografia’ de 2km de extensão por 2cm de profundidade. A visão ‘do todo’ era crucial naquele momento. Ele não se preparou para a reunião – nem sabia o ramo de atividades da empresa. E, como vimos no último episódio, ele se atrasou pra caramba para a única visita.

O questionário aplicado, na base do improviso, deu origem a um diagrama rabiscado em uma folha A3. “A Toyota também usa A3, vocês sabiam?”, perguntou o analista para sobrinho e contador que não sabiam nada sobre a Toyota. Também desconheciam UML, a linguagem que teria sido usada na elaboração daquele estranho diagrama. “Mas dá pra entender, não dá?”, perguntava o analista após cada elemento rabiscado. “Aqui estão os vendedores e os clientes. Entre eles esta seta, que mostra o processo de vendas. Aqui tá o depósito e neste mini-diagrama de classes eu mostro como os seus produtos estão estruturados. Ah, o leite é matéria-prima de todos? Por que vocês não falaram antes? Mas é fácil, é só mudar essa seta aqui para mostrar que todos herdam tudo o que a gente definir para o leite, ok? Hã, você não entendeu? Esquenta não, depois eu explico melhor.”

Sobrinho e contador ficaram encantados com a desenvoltura do analista: “Ele aprende rápido, né?”. Mas interrompiam o papo toda vez que ele puxava um gadget de última geração de sua chique mochila: “Você vê os emails aí no celular é? Nossa!!!”. O analista bateu uma foto do A3 com seu ultra-super-mega celular e enviou por email. “Como o projeto é para ontem, uma equipe já vai analisando lá o que a gente tá conversando aqui”. O que o analista não contou é que ele mandou o email para ele mesmo. Não tinha nenhuma equipe “de retaguarda” esperando pelas suas informações.

Aliás, a equipe do projeto, no dia seguinte, resumia-se ao analista, seu chefe e o vendedor. “A proposta é para amanhã”, disse o aflito analista que, pelo andar da carruagem, sabia que ficaria com todo o trampo de elaboração. “Escreve a proposta técnica”, disse seu chefe, “que depois eu sento com o vendedor pra gente calcular o preço final”. Assim foi feito. Um “documento de visão / proposta técnica” de 10 páginas foi elaborado. O analista demonstrou através de um grande e colorido diagrama que existiam 5 grandes funcionalidades requeridas:

• Elaboração da Agenda de Visitas
• Mapa de Carga
• Controle do Estoque dos Clientes
• Venda / Faturamento
• Relatórios Gerenciais Diversos

Além disso, ele destacou que seriam necessários módulos para: cadastramento de clientes, produtos, vendedores, rotas, veículos etc.

Após rápida negociação que resultou em um desconto de 27,5%, ‘seu’ Moreira contratou o projeto: Cinco meses de duração; Seis parcelas, sendo que a última só seria liberada após o aceite final do projeto. Imediatamente a empresa escolhida publicou 3 anúncios de vagas: 1 coordenador de projetos, 3 desenvolvedores ‘web’ e 1 DBA. Dez dias depois estavam todos reunidos com o analista para entender o projeto. Depois de fechado o negócio o analista havia agendado duas visitas para ‘coleta’ de requisitos. Foi apenas em uma, para “refinar o A3”.

A3 que foi mostrado para os 5 novos integrantes da equipe. “Tá bom”, disse o coordenador, “mas cadê os requisitos?”. O analista falou que estava esperando a montagem da equipe e, principalmente, a contratação do coordenador para organizar as tarefas de ‘levantamento’. O mais jovem dos 3 desenvolvedores foi escolhido para ajudar o analista. Os dois mais experientes ficariam na empresa fazendo o ‘setup’ do ambiente e desenvolvendo um ‘framework’. O cronograma prometia a entrega dos módulos de cadastro para 30 dias. “Afinal”, justificou o analista, “os caras lá não têm sistema nenhum. Alguém vai ter que cadastrar tudo. Assim a gente ocupa o cliente e pode trabalhar em paz”. Um dos desenvolvedores falou que, “com o framework, a gente faz os CRUD tudo numa tarde”. Não fizeram.

{continua}