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”.

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.

Encerrei a última parte da série afirmando que um analista normalmente precisa de apenas 30 minutos para entender os objetivos do negócio. Provocação fracassada: ninguém questionou?!? Acreditam demais neste escriba, duvidam de tudo aqui escrito ou não sabem do que estou falando?

Quando falamos de projetos, qualquer dica que se pretenda universal deve ser recebida com desconfiança. E qualquer estimativa com números absolutos (30 minutos!) deve ser vista como trabalho de um ingênuo ou otimista ou inexperiente ou safado ou tudo isso misturado. Existem projetos complexos e muito grandes. Invariavelmente eles apresentam um conjunto de objetivos de negócio igualmente complexo e extenso. Por isso, acreditar que meia horinha seria suficiente para seu entendimento é acreditar em mágica. Por outro lado, seguirei afirmando que o entendimento dos objetivos do negócio, particularmente daqueles que motivam um projeto, deve ser algo simples e rápido. Ou deveria.

Mas, antes de seguir, um breve esclarecimento sobre os termos aqui utilizados:

• Motivação = Conjunto de Objetivos do Negócio
• Objetivo do Negócio = Requisito do Negócio
• Valor = Requisitos do Negócio devidamente atendidos
• Fracasso 2.0 = Valor não entregue

Vamos dividir os projetos de software em duas categorias, também para facilitar o entendimento do que vem abaixo. Vou chamar de “Pacote” aqueles projetos que visam a criação de um produto ou serviço que pretende ter vários clientes. E de “Custom” (perdão, bem que tentei achar um nome melhor) o projeto que atenderá demandas específicas de uma organização. A distinção é necessária porque as motivações para esses dois tipos de projetos podem ser consideravelmente diferentes. Assim como o processo para o seu entendimento.

Pacotes nascem de uma ideia brilhante e/ou de uma necessidade percebida. Ok, vários pacotes também nascem como cópias de cópias, tristes demonstrações de muita falta de imaginação. Mas aceitemos que a cópia também possa ser uma ideia razoavelmente brilhante. Não custa. E, às vezes, realmente são. A identificação e entendimento da motivação, em teoria, deveria ser muito mais simples nestes casos. Qual é a ideia? Qual é a oportunidade ou necessidade percebida? Se o autor ou vendedor da ideia não conseguir explicá-la de forma breve, desconfie. Ou produto ou seu “vendedor” não são tão bons assim.

Jim Highsmith – depois de Bill Shackelford – recomenda em “Agile Project Management” (2ª Edição. Addison-Wesley, 2010) que seja desenvolvida uma caixa para o produto ou serviço. Sim, uma caixa – uma embalagem para o pacote. Desconheço documento de visão mais direto e, preciso dizer, *Visual*. A caixa obriga a criação de uma mensagem ‘marqueteira’ (no melhor sentido da palavra). Nela destacamos as principais funcionalidades do produto ou serviço, de maneira suscinta na frente e de forma um pouco mais detalhada no verso. Restrições de uso, como plataformas ou sistemas operacionais por exemplo, seriam apresentadas no verso ou nas laterais. Enfim, a equipe deveria criar uma embalagem de verdade, com todas as informações fundamentais sobre o pacote. Um documento de 2 páginas seria uma alternativa para a caixa. A limitação de espaço é arbitrária sim. Exatamente para que os autores se limitem a informar aquilo que é fundamental. O poder de concisão, habilidade tão desejável em analistas e líderes de projetos, é crucial na apresentação da visão de um produto.

Um pacote é bem apresentado quando ele descreve:

1. O público-alvo;
2. Seu benefício-chave (o valor que estamos prometendo para o cliente/usuário); e
3. Os diferenciais competitivos.

“Banhistas de Ipanema , refresquem-se com nosso côco geladinho . E não se preocupem com o lixo , porque o Zezinho aqui vai passar recolhendo tudo. É que a gente também faz uma graninha reciclando .”

Os três pontos explicam a motivação para o pacote. O seu desenvolvimento pode tomar um certo tempo. O que afirmei acima e reitero é: o entendimento dessa motivação deve ser rápido. Seja por uma analista de negócios ou por qualquer outra pessoa.

Requisitos ou histórias serão extraídos dessa definição. E devem ser priorizados. Pois é, o tema central desta série é priorização. Mas ainda vou demorar um pouquinho até chegar lá. Na próxima parte tratarei do entendimento da motivação em projetos “custom”. Inté!

.:.

Créditos

• Playground é uma foto da artista Tanakawho, e
• Software Box é do Vectorportal.