Objetivos do Negócio – finito https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br o que precisa ser feito? Wed, 20 Apr 2011 12:02:04 +0000 pt-BR hourly 1 https://wordpress.org/?v=7.0 https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/wp-content/uploads/2021/01/head_512x512-150x150.png Objetivos do Negócio – finito https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br 32 32 Por que Precisa ser Feito? https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2011/04/20/por-que-precisa-ser-feito/ https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2011/04/20/por-que-precisa-ser-feito/#comments Wed, 20 Apr 2011 12:02:04 +0000 http://www.pfvasconcellos.eti.br/blog/?p=1823 Este será um post diferente¹.

Há algumas semanas participei de uma pequena reunião com especialistas de diversas áreas. Mistura de comunidade de prática com think tank – sem frescuras, pura troca de experiências e dicas. Distribuí meu risque & rabisque e, de bate pronto, recebi a pergunta: por que a questão “o que precisa ser feito?” mereceu tanto destaque? Contei rapidamente a história: Drucker disse, lá no final do século passado, que era a pergunta mais importante que um executivo poderia fazer. Meu interlocutor completou: “Pode ter sido. Hoje, a questão mais importante e difícil é: por que precisa ser feito?

Não preciso ir muito longe para descobrir inúmeras evidências que provam que meu colega está certo. A amiga Thais, trabalhando na administração pública, não sabe o que fazer para priorizar as demandas de dezenas de secretarias. Um cliente, que é uma SA, também não sabe o que fazer com seu backlog volumoso, amorfo e desordenado. Buscamos pistas no topo do topo da pirâmide – o que estariam dizendo o plano diretor daquela cidade ou a área de relação com investidores daquela empresa? – e seguimos perdidos. Para onde quer que eu olhe é quase sempre o mesmo: tudo é prioritário. Sendo assim, nada é prioritário.

Não é de hoje que a questão me incomoda. No ano passado escrevi alguns artigos sobre estratégia e priorização {1, 2}. Sugestões inúteis se não temos as diretrizes iniciais. Cada vez mais parece que o buraco “está mais em cima”!?!

Caramba, se o Capitão não sabe dizer para onde dirige seu barco, quem saberá? E o que dizer dos efeitos imediatos de tamanha falta de sentido? Primeiro, tem um monte de gente correndo adoidado para entregar ou se livrar de tudo o que aparece pela frente. Segundo, esse monte de gente trabalha no automático, sem objetivos. Como saber se um trabalho é bem feito se não conhecemos sua razão? Como acordar de manhã e ir trabalhar se não entendemos a motivação?

O que a turma lá de cima tanto faz que esqueceu de sua principal atribuição? Será que estão todos presos nos mesmos problemas cotidianos? Se toda a pirâmide de uma organização está concentrada no presente, detonando a única justificativa plausível para uma estrutura hierárquica, quem sobrou para projetar o amanhã e o depois de amanhã?

Enfim, encerrando a irritante sequência de interrogações, o que poderia ter criado esse mundo repleto de barcos sem mapas nem bússolas?

?

Observações:

  1. Sei lá quando criei a restrição (mania) de publicar apenas artigos longos e (teoricamente) mais elaborados. O fato é que, com a agenda meio insana que assumi, corria o risco de deixar o {finito} às moscas por um longo período. Por isso vou tentar ser menos chato e publicar posts como este, mais curtos. É uma forma de dar sinal de vida, certo?
  2. Experts at Sea“, cartoon que ilustra este post, é um trabalho do HikingArtist.com disponibilizado via Flickr.
]]>
https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2011/04/20/por-que-precisa-ser-feito/feed/ 6
Priorizar https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2010/08/18/priorizar/ https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2010/08/18/priorizar/#comments Wed, 18 Aug 2010 19:06:08 +0000 http://www.pfvasconcellos.eti.br/blog/?p=1295 Priorizar v. {mod. 1} t.d. tratar de (algo) em primeiro lugar e com mais empenho (Houaiss).

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.
]]>
https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2010/08/18/priorizar/feed/ 4
Benefícios / Custos https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2010/08/10/beneficios-custos/ https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2010/08/10/beneficios-custos/#comments Tue, 10 Aug 2010 17:15:45 +0000 http://www.pfvasconcellos.eti.br/blog/?p=1268 No capítulo anterior vimos como atribuir valor para projetos. Aprendemos que as possíveis iniciativas devem ser avaliadas como um conjunto e nunca de forma isolada. Nosso foco até agora esteve no peso, na contribuição de cada iniciativa para que a empresa alcance seu objetivo maior. Neste quarto artigo da série vamos olhar para o outro lado da moeda, aquele formado pelos custos.

.:.

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.
]]>
https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2010/08/10/beneficios-custos/feed/ 2
Valorizando Projetos https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2010/08/04/valorizando-projetos/ https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2010/08/04/valorizando-projetos/#comments Wed, 04 Aug 2010 18:53:17 +0000 http://www.pfvasconcellos.eti.br/blog/?p=1253 Previously on Lost (e bota ‘lost’ nisso): uma empresa fictícia que tem como proposta de valor a excelência operacional – ela “vende baratinho” – apresenta um grande objetivo para o próximo ano: o aumento de 30% da margem (rentabilidade) das vendas. Quatro metas, que serão reapresentadas abaixo, explicam como se dará a realização da visão, do grande objetivo. Cada meta pode significar a necessidade de um ou mais projetos. A questão que ficou aberta no último capítulo foi: como priorizá-los? Mistério que tentaremos desvendar neste terceiro artigo.

.:.

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.
]]>
https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2010/08/04/valorizando-projetos/feed/ 6
Classificando e Priorizando Projetos https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2010/08/02/classificando-e-priorizando-projetos/ https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2010/08/02/classificando-e-priorizando-projetos/#comments Mon, 02 Aug 2010 20:52:44 +0000 http://www.pfvasconcellos.eti.br/blog/?p=1235 Continuação de “Como Priorizar Projetos, Influenciar Decisões e Não fazer (muitos) Inimigos“.

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 ano4. 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”.
]]>
https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2010/08/02/classificando-e-priorizando-projetos/feed/ 2