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.

Artigos relacionados:

1. Benefícios / Custos
2. Valorizando Projetos
3. Como Priorizar Projetos, Influenciar Decisões e não Fazer (muitos) Inimigos
4. Classificando e Priorizando Projetos
5. Prioridades 2: As Origens

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.

Artigos relacionados:

1. Priorizar
2. Valorizando Projetos
3. Classificando e Priorizando Projetos
4. Modelagem de Negócios: Os Diagramas
5. Como Priorizar Projetos, Influenciar Decisões e não Fazer (muitos) Inimigos

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.

Artigos relacionados:

1. Classificando e Priorizando Projetos
2. Benefícios / Custos
3. Priorizar
4. Como Priorizar Projetos, Influenciar Decisões e não Fazer (muitos) Inimigos
5. [SOA # 7] – Os Projetos SOA

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

Artigos relacionados:

1. Valorizando Projetos
2. Benefícios / Custos
3. Priorizar
4. Como Priorizar Projetos, Influenciar Decisões e não Fazer (muitos) Inimigos
5. Motivação, Parte 1

Priorização virou um tema recorrente aqui no finito. Pensando bem, deveria ser o *grande* tema de um site que pergunta no slogan “o que precisa ser feito?¹”. Mas minha pauta é sempre definida por debates e provocações correntes. Ao publicar o último artigo, senti necessidade de retomar o assunto. Desta vez, com a intenção de ser um tanto mais prático e direto. Vamos ver se consigo.

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.

Artigos relacionados:

1. Como montar Times e influenciar Projetos
2. Priorizar
3. Benefícios / Custos
4. Classificando e Priorizando Projetos
5. Valorizando Projetos

De todas as sugestões que apresento no FAN, a que causa mais espanto e suspiros é: um analista de negócios (AN) não deveria cuidar de mais de dois projetos ao mesmo tempo. Dois projetos pequenos! Invariavelmente a casa cai neste momento. E o burburinho parte, principalmente, de profissionais que atuam em médias e grandes empresas. Alguns deles são responsáveis por 10 ou mais projetos. Maluquice pura.

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.

Artigos relacionados:

1. Castelos de Areia…
2. Benefícios / Custos
3. Prioridades 2: As Origens
4. Classificando e Priorizando Projetos
5. Valorizando Projetos

Existem Times, times, timinhos e igrejinhas, como a Copa recém-encerrada bem mostrou. A formação de equipes, para projetos de qualquer natureza, é uma complexa mistura de ciência, bom senso, tato e intuição.

Ciência porque é preciso conhecer o projeto, as partes interessadas, as habilidades requeridas – tanto sociais quanto técnicas, e o desenho sócio-técnico mais adequado. O bom senso delineia fronteiras, particularmente em relação aos selecionáveis. O tato é exigido tanto na convocação quanto na exclusão de integrantes da equipe. Por fim, a intuição, subjetiva qualidade que permite perceber que aquele improvável jogador pode render bastante em determinado momento do projeto.

Este artigo trata exclusivamente o primeiro componente, a ciência. E, claro, não falará sobre seleções de futebol. Apesar de sua possível utilidade em outros tipos de iniciativas, o alvo aqui são os projetos para desenvolvimento de sistemas.

Até pouco tempo atrás eu me gabava de ter feito apenas uma pequena alteração em um metamodelo sócio-técnico que tinha uns 10 anos de idade. Vendia-o como um modelo para um Dream Team, ignorando alguns padrões emergentes que exigiam outro nível de abstração. A ficha só caiu depois de uns tabefes na cara, particularmente os proferidos por Jim Highsmith em “Agile Project Management – 2nd Edition” (Addison-Wesley, 2010). Roman Pichler, em seu “Agile Product Management with Scrum“ (Addison-Wesley, 2010), deu o bofetão de misericórdia.

O Líder do Projeto

O Movimento Ágil colocou o auto-gerenciamento no topo da agenda de todos que estavam formando times seguindo seus princípios. “Indivíduos e interações são mais importantes que processos e ferramentas”, é o que diz o primeiro verso do Manifesto Ágil. Dele derivaram os conceitos de auto-direção, auto-organização, auto-disciplina, respeito pelos indivíduos, igualitarismo e um bom ambiente de trabalho.

Highsmith diz com todas as letras que “times auto-organizados não se caracterizam pela falta de liderança, mas por um estilo de liderança”. Reforça a mensagem citando Larson e LaFasto (“Teamwork: What Must Go Right, What Can Go Wrong”. Sage Publications, 1989): “bons líderes são o principal ingrediente de projetos e organizações de sucesso”.

Highsmith ataca frontalmente,  resguardando os nomes dos santos, as propostas de auto-direção. Estas sim se caracterizariam pela ausência de um líder único. Os integrantes se revezariam nesta função dependendo de determinada situação em um projeto. Parece claro que ele dirige suas críticas para algumas práticas sugeridas em frameworks como o Scrum e a XP (Extreme Programming). Critica as práticas ou algumas interpretações delas, preciso dizer.

Déjà vu? Pois é, já falei um tanto sobre o líder aqui no finito, na seguinte série:

• O Novo Gerente de Projetos
• Fracasso 2.0
• O Mundo Mudou

O Time de Produto

Residem aqui todos os que ajudam a definir e priorizar o que precisa ser feito. Sim, é aqui que fica o Product Owner (PO – Dono do Produto) em um projeto guiado pelo Scrum. Uma coisa que precisa ser mais reconhecida e divulgada é que o PO, normalmente um usuário ou especialista no domínio, raramente terá disponibilidade para executar e entregar tudo o que está sob sua responsabilidade. Para muitos não fará sentido, por exemplo, a execução de várias tarefas operacionais para desenvolvimento e manutenção da Pauta (ou Product Backlog, como queiram).

Além do PO ou gerente do produto, o time de produto pode ser formado por: analistas de negócios, especialistas no produto / domínio e parte do pessoal de controle de qualidade (QA). Highsmith reconhece que “a formação deste time, com as pessoas mais adequadas e com tempo suficiente, pode ser um complicado desafio para muitas organizações porque o comprometimento exigido é bem maior do que em projetos tocados de maneira tradicional”.

É por isso que teimo tanto com a Formação de Analistas de Negócios. Por entender que os bons analistas podem compensar a indisponibilidade de usuários e clientes que mal têm tempo para cuidar de seus afazeres cotidianos. Que fique claro: eles compensam, mas não substituem nunca os usuários e especialistas.

O curioso é que até hoje vemos equipes sendo formadas sem um único representante disso que chamo (depois do Highsmith) de Time de Produto¹. Gerentes de projetos e analistas-programadores normalmente se revezam na posse dessas atribuições. O (imenso) problema com este enfoque é um só: gerentes e analistas-programadores não percebem o “levantamento de requisitos” (sic) como sua responsabilidade principal: “a gente não foi contratado pra isso”. Eles querem é gerenciar e programar. “Requisitos”, vejam só, é um tipo de impedimento para que eles executem seu trabalho real. Uma amolação.

O Time de Desenvolvimento

Gerentes de projetos, analistas-programadores (é melhor Desenvolvedores, não?) e afins moram aqui. Se o Time de Produto define o que precisa ser feito, este é o grupo responsável pelo como será feito e pela construção propriamente dita. Apesar de vivermos em tempos de massificação simplista e beócia – formando e contratando “analistas-programadores” como se tudo fosse a mesma coisa – não custa insistir que este time também é multidisciplinar. Que, dependendo do projeto, vários especialistas podem ser requeridos. Um profissional que saiba desenvolver para o Android ou iPhone, por exemplo.

Gosto de ver, de forma macro, uma estrutura com um mínimo de 4 células: interfaces, serviços, dados e infraestrutura. Isso não significa hierarquização nem divisão excessiva do trampo, mas sim a aceitação de que existem conhecimentos específicos. Não é “linha de montagem”, mas o reconhecimento do fator humano e da impossibilidade de contratar gente que saiba tudo sobre tudo. Estão distantes os tempos dos monoblocos cobolísticos.

Juntando Tudo

Se há um projeto então existe um objetivo ou conjunto de objetivos bem definido. Se o Líder, o Time de Produto e o Time de Desenvolvimento trabalham no sentido de alcançar o mesmo objetivo, então eles formam um único time. Este deveria ser o único critério para definir um time de verdade, não as eventuais divisões internas que só existem para organizar o conhecimento e as responsabilidades de cada um.

É muito sadia a divisão entre a turma do “que” e do “como”:

• Falando como um usuário: “Eu realmente participo do projeto, faço parte do time. E quando não posso participar de algum encontro, fico tranquilo porque tenho um representante que defende meu ponto de vista. Isso, mais as entregas regulares que um processo iterativo e incremental garante, torna o projeto um trabalho agradável e estimulante, ao contrário do calvário que caracterizava nossos projetos anteriores.”
• Falando como um desenvolvedor: “Finalmente inventamos uma maneira de ter o usuário bem perto da gente sem aquela sensação de ‘nós contra eles’, de dormir com o inimigo. Somos um time só e o que nos une são os objetivos do projeto.”

Divisão sadia, mas naturalmente conflituosa. Sempre foi, independente da arquitetura social ou processo de desenvolvimento utilizado. E sempre será. Os conflitos podem gerar uma tensão criativa, desejável ou até mesmo fundamental dependendo da natureza do projeto. Uma hora é um time que apresenta sua caixa – suas restrições e condições. Outra hora a outra divisão o faz. E todos trabalham, como diz Scott Berkun², “pensando dentro da caixa, debaixo dela, fora dela, quebrando-a e fazendo uma bela fogueira”. É nesta hora que a presença de um líder pode fazer diferença. Quando o “que” e o “como” demoram para atingir um consenso, transformando a caixa numa solução criativa, nada melhor que um olhar isento mas igualmente comprometido com os mesmos objetivos. E com 3 votos nunca teremos empates, certo?

.:.

Observações:

1. Já usei o termo “Time do Dono do Produto”, traduzindo literalmente Roman Pichler no livro já citado. “Time de Produto”, conforme sugerido por Jim Highsmith, é bem melhor. Mas confesso que não sei como ficará de forma definitiva em português. Aliás, nem sei se vingará como conceito!!
2. Em “A Arte do Gerenciamento de Projetos” (Bookman, 2008).
3. A ilustração utilizada neste artigo, “Chain of People”, foi legalmente surrupiada de HikingArtist.

Artigos relacionados:

1. O Novo Gerente de Projetos
2. O Mundo Ágil precisa de Analistas de Negócios?
3. Agile Project Management
4. Muita Areia no Caminhãozinho do AN
5. BABoK: Uma Leitura Crítica

Semana passada sugeri uma forma alternativa de apresentar e justificar a adoção de um ciclo de vida para projetos baseado no modelo Iterativo & Incremental. Deveríamos enfatizar a certeza de que todos cometerão erros em detrimento do destaque dado às inevitáveis mudanças.

Faltou dizer que muito do que chamamos de mudanças são na realidade erros. Usuários e clientes não são obrigados a aprovar o primeiro produto que recebem, por precisas e assinadas que sejam atas, especificações de casos de uso ou afins. Há mais mistérios entre requisitos e o produto final do que imagina nossa vã filosofia. E essa distância sempre exigirá, em alguma medida, um processo de tentativa e erro. Esse tipo de mudança é sim um erro. Muitos não gostam da palavrinha ou de admitir que erram. Mas deveríamos classificar melhor aquilo que chamamos de erros e mudanças. Papo para outra hora.

Porque hoje eu gostaria de destacar um segundo fator que justifica a adoção do modelo Iterativo & Incremental: as pequenas vitórias. Assim como é indiscutível que o ser humano erra, também é indissociável de nossa natureza a necessidade de motivação – de uma recarga quase diária de nossas baterias. Em projetos não bastam seus objetivos, por nobres e ambiciosos que sejam, nem eventuais compensações financeiras. Imagine um campeonato de futebol, curto como uma Copa do Mundo ou longo (e cansativo) como o Brasileirão. Os times e jogadores comemoram cada vitória e cada gol. No vôlei, um jogo definido após dezenas de pontos, cada um deles é comemorado. Cada gol ou ponto é uma pequena vitória. Elas são tão cruciais para uma equipe de projetos como são para os jogadores.

Em projetos tocados segundo moldes convencionais, particularmente no popular “cascata”, há pouco espaço para comemorações intermediárias. Por mais que equipe e coordenadores soltem foguetes para um documento de visão bem escrito ou uma coleção de especificações e modelos “nota 10″, o fato é que não há torcida nem usuários ou clientes compartilhando aquele momento e muito menos incentivando-o. É como uma vitória em treino, fechada e sem valor.

A vitória que conta, por menor que seja, tem participação direta do público externo – dos usuários e clientes. E eles sabem que documentos e modelos não valem como gols e pontos. Ou seja, não substituem o produto final.

Um projeto guiado pelo modelo Iterativo & Incremental supõe a comemoração de várias pequenas vitórias. Admite sim alguns revezes, como vimos no artigo anterior. Mas, exatamente por conta deste fator, torna a vitória final mais factível. Cada entrega, iteração ou gol é motivo para celebração. E isso ajuda a renovar o ânimo do time. No contexto de projetos há outros efeitos colaterais bastante benéficos, sendo o principal deles o aprendizado. O time tem a chance de rever seus erros e acertos, o que possibilita uma melhor preparação do próximo ataque, jogo ou iteração.

Imagine um zero a zero arrastado e chato. Pior ainda, decidido nos pênaltis. Compare com uma sonora goleada, um jogo aberto e bonito de se ver, com placar final de 5 a 3. Qual você prefere?

.:.

“Goal“, a foto utilizada neste artigo, é do Jonas B.

Artigos relacionados:

1. Iterativo & Incremental: Um Convite aos Erros
2. [SOA # 8] – Processo de Gestão e Desenvolvimento
3. Eventos: Os Novos e o Velho
4. O Novo Gerente de Projetos

Entre todos os mistérios que rondam nossa área há um difícil de explicar e justificar: qual a razão de tanta resistência na adoção de um ciclo de desenvolvimento que seja iterativo e incremental?

Nos últimos três anos, só por conta do FAN, pude falar com mais de dois mil profissionais e estive pessoalmente em dezenas de empresas. Sei que não tem valor de pesquisa, mas foi fácil concluir que pelo menos 95% deles ainda trabalham baseados em um modelo “cascata” (ou Waterfall) de desenvolvimento¹. Se considerarmos que já tem quase duas décadas que vários autores, metodologistas, empresas e consultores recomendam a adoção de outro modelo, qual a razão da incontestável predominância da “cascata”?

Não, este (pequeno) artigo não tem a menor intenção de reativar o debate ou destacar prós e contras de cada proposta. Aliás, se você quiser uma boa justificativa *econômica* para adoção do modelo iterativo & incremental, deveria ler este texto do José Paulo Papo. Minha preocupação aqui é outra.

Comumente apresentamos o modelo iterativo e incremental, independentemente do sabor (RUP, XP, Scrum, OpenUP…), como um remédio para as inevitáveis mudanças. Esse discurso costuma encontrar dois tipos de reflexos:

1. (Ainda) existem aqueles que acreditam que mudanças ocorrem exclusivamente porque o entendimento do problema não foi bem realizado. São os mesmos que, infelizmente, acreditam que a Análise de Negócios é a resposta definitiva para especificações (sic) mal feitas. O que vemos neste cenário é mais gente gastando mais tempo e dinheiro para escrever mais. Deveríamos escrever melhor, estruturar melhor as informações aprendidas e colaborar, conversar mais. E não escrever mais e de maneira mais detalhada².
2. “Os requisitos são estáveis e temos uma ótima compreensão do problema que iremos sanar. Podemos trabalhar em ‘cascata’”. É um reflexo parecido com o anterior mas com uma diferença: há realmente a sensação de que o solo pisado é de fato conhecido. Esta é uma das justificativas que encontro com maior frequência para a não adoção de um modelo iterativo e incremental.

Percebendo os dois reflexos alterei minha maneira de apresentar e “vender” o modelo iterativo e incremental. Transcrevo abaixo o que costumo falar nos treinamentos e consultorias:

O que é bonito no modelo iterativo & incremental é que ele reconhece um fato que nunca mudaremos: somos humanos. Ou seja, nós vamos cometer erros. Vários! Ao adotar este modelo estamos dizendo para nossos usuários e clientes: “Nós vamos errar, caríssimos, todos nós. Às vezes será um problema de interpretação de seus requisitos e histórias. Outras tantas vocês errarão, na explicação ou apresentação das próprias necessidades. E, precisamos admitir, muitas vezes as funcionalidades entregues não os atenderão pelos mais diversos motivos. Não importa. Aliás, não importa desde que o modelo de desenvolvimento adotado reconheça essa verdade: somos humanos e vamos errar”.

Esse discurso gera duas respostas muito positivas: i) desarma aqueles que ficam louquinhos por um debate; ii) facilita a compreensão por todos que nunca trabalharam de outra maneira que não seja a “cascata” ou o “caos absoluto”. São bastante perceptíveis também as carinhas de surpresa que surgem com a repetição de uma palavrinha: Erro.

Criamos uma cultura que combate e pune erros. Mesmo em ambientes que se dizem “inovadores” o erro ainda é mal visto. As pessoas vivem com medo de errar. Imagine então o desafio de dizer, antes mesmo do início de um projeto, que erros acontecerão. Mas é fato: erramos. Pra caramba!

Clientes e usuários costumam gostar muito dessa transparência, dessa sinceridade. Estranham porque ela não é muito comum em nosso mercado. Mas aceitam o modelo e o consequente desafio com mais facilidade³. Daqui para a adoção de outras práticas mais modernas é “um tirinho”.

.:.

Observações:

1. Num belo dia um cliente pediu que eu pulasse essa parte do curso: “A gente já desenvolve assim”. Obedeci. Mas depois o treinamento caminhou na base de soluços. Descobri o problema e o susto que curou o soluço: “É que nossas iterações duram algo entre 3 e 4 meses”. Ou seja, eles não desenvolviam de forma iterativa e incremental. Era outra coisa.
   Um outro freguês, agora numa turma aberta, disse que usa Scrum mas que tem que levantar todos os requisitos no início do projeto. Ou seja, não era Scrum. Também era outra coisa qualquer que nem merece nome.
2. Era uma vez uma empresa que terceirizava todo o trampo de codificação para “fábricas de software” (sic). Eu apresentava para eles os 5 ícones recomendados pelo Cockburn (“Escrevendo Casos de Uso Eficazes”, Bookman. 2006) para indicar o nível de detalhamento de uma especificação de caso de uso. Eles disseram que, para trabalhar com fábricas, os 5 não seriam suficientes. Pediram a criação de outro, abaixo da “ostra”. Sugeriram a colocação da logomarca da Petrobras. E explicaram: “É o nível ‘pré-sal’, sete mil metros abaixo do nível do mar! Só assim o pessoal da fábrica entende.” Repito: não é escrever mais. Não deveria ser…
3. Era outra vez, lá pelos idos de 2001 ou 2002, eu tocava um projetão. ÃO mesmo, em porte e complexidade. Sabe-se lá porque ($$$) topamos que o cliente “espelhasse” toda nossa estrutura gerencial. Para cada líder de nosso lado, eles colocavam um líder do lado de lá. Um mês de lua-de-mel. Um mês de “briguinhas”. E no terceiro mês a pérola: “Para com esse negócio de iterativo e incremental – queremos que seja cascata”.
   Juro, não é cascata não. Contei a história aqui só para dizer que a palavra “facilidade”, escrita ali no último parágrafo, deve ser interpretada com a devida precaução.
4. “Funny“, a foto utilizada acima, é da Tanakawho. Sempre ela!

Artigos relacionados:

1. Iterativo & Incremental: O Segundo Fator
2. [SOA # 8] – Processo de Gestão e Desenvolvimento
3. O Mundo Ágil precisa de Analistas de Negócios?
4. O Novo Gerente de Projetos

“Certo perdeste o senso!”

Perdão Bilac, mas não resisti. Não é a primeira vez que surrupio belas obras com fins questionáveis. Certo não será a última. A espoleta da vez não veio de TI, mas de um mundo tão distante quanto Pandora está da Terra: veio da bola, do pé na bola, do futebol. É a Copa que se aproxima. Mas não deveria ser. O futebol é algo tão rico de ensinamentos que merecia outro status e mais presença. Pena, ele segue em outra direção. E acaba de perder um de seus melhores tradutores, Sr. Armando Nogueira. Pena. Mas voltemos ao princípio: “Ora (direis) Gerir Estrelas!”

“Certo perdeste o senso!” Porque, se há algo difícil de gerenciar, é a tal da estrela. Dá de mil e um no pior dos piores projetos. Dá de mil e dois no pior dos piores fregueses. Estrela, como o Flamengo está aprendendo da pior maneira, está sempre acima da gerência. Não apenas na grana depositada mensalmente, mas em praticamente tudo.

É certo que estrelas de verdade brilham. Adriano foi o artilheiro do último campeonato brasileiro. Sem ele provavelmente o Hexacampeonato não teria acontecido. Em outra nação, a Corinthiana, Ronaldo decidiu, no primeiro semestre de 2009, uma série de partidas importantes. Sem ele o Timão não teria conquistado dois campeonatos. Benefícios assim costumam fazer com que os custos sejam tratados como pequenos detalhes, bobeirinhas. Perdão, mas são pouquíssimos no mundo que podem tratar um milhão de qualquer coisa por mês como um pequeno detalhe. No Brasil, talvez o Batista e mais dois. E olhe lá!

O custo (exorbitante) de uma estrela é fixo. Seus resultados variam mais que bolsa de valores em tempos de crise. O que permite concluir que, em médio e longo prazos, uma estrela nunca se paga. Ok, “nunca diga nunca”. Então fechamos com “quase nunca se paga”.

Defina “Estrela”

Estrela é o craque, o expert, o bambambam em determinada área do conhecimento. Domina como poucos sua arte. Quando brilha, o faz de forma tão intensa que cega, maravilha e entorpece.

Se a definição se limitasse ao que foi escrito acima este artigo não teria razão de existir. Acontece que uma estrela é apaixonada pelo próprio umbigo. Se acha tão acima dos normais que acaba criando um universo só seu. Heliocêntrico, é claro. Tem seus próprios processos e regras. Seus próprios horários e calendários. E ai de quem discordar.

Talvez só o futebol rivalize com TI no número de pessoas que recebem, de forma pejorativa ou não, apelidos como “deus”, “rei”, “gênio”, “monstro”, “fenômeno” etc. Mas há ESTRELAS e estrelas. Existem as anãs e as pagãs, as supernovas e os buracos negros. Supernovas, por exemplo, berram por “autogerenciamento” mas não conseguem botar ordem na própria mesa. Já os buracos negros sugam toda a energia (e recursos) ao seu redor – são mal humorados de nascença – e costumam sumir antes que algum resultado seja entregue.

Em comum todos os (nossos) tipos de estrelas só apresentam dois fatores: i) normalmente são realmente bons no que fazem;  mas, ii) são difíceis, chatos, desagradáveis etc etc etc.

Seu Projeto depende de uma Estrela?

Meus pêsames. Ops… perdão. Não são raros, particularmente numa área tão nova, dinâmica e mal formada como TI, projetos que dependam muito da atuação de um craque. E é importante notar que nem todo craque é estrela. É claro que existem os humildes e mortais – que se caracterizam principalmente pelo tanto que são cientes de suas próprias limitações. Traduzindo: craques sabem dizer “NÃO”, “NÃO SEI” e também nunca apresentam estimativas absolutas. Mas você não deu a sorte de contratar um craque. Tens uma estrela em suas mãos. E agora?

Só tenho duas dicas:

1. Não crie a ilusão de um relacionamento duradouro. Contrate a estrela especificamente para um projeto. E faça girar em torno dela um ou dois planetas (funcionários de sua confiança) que tenham: i) estômago forte; ii) vontade de aprender.
2. Vincule todo e qualquer pagamento à entrega de resultados. Faça com que a estrela se comprometa realmente com o sucesso do projeto. Desconheço outra maneira que não seja através do zelo extremo com os desembolsos e reembolsos.

Seu Gerente é a Estrela?

Hmmm… Mas que situação, hem? Não prestou atenção na hora da entrevista não? Ok, pode não ser o fim do mundo. Considere uma das alternativas abaixo:

1. Trocar de emprego;
2. Tomar o lugar do gerente;
3. Ajudar alguém (gente boa) a tomar o lugar do gerente;
4. Convencer o gerente que ele será mais importante, mais bem visto, mais sexy e bem sucedido se começar a trabalhar para a equipe, esquecendo o comportamento “comando & controle” e aprendendo que a “delegação de poderes” o fortalece e não o contrário. Pode garantir que, se ele aceitar tudo isso, será convidado para todos os happy-hours e churrascos da turma.

Você é a Estrela?

Desculpa aí. Não é nada pessoal não, viu gente fina?

Inté!

.:.

Slinky Abstract, a foto utilizada este artigo, é de Paul Stevenson.

No related posts.