PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • O Clube da Esquina Globalizada

    Esta é a primeira das três partes da palestra que apresentei no último sábado, “O Futuro não é mais como era Antigamente“. Publicarei todas aqui, antes que voltem para o segundo plano de minha gaveta. Hoje escrevo sobre pessoas e equipes. O artigo foi bem contaminado por um tema que ganha espaço até em agenda de candidato, o “apagão” de mão de obra qualificada.

    .:.

    Nossa história se inicia com um grande apagão. Lá nos idos de 1950 e início da década de 1960, quando agências do governo dos EUA e algumas pouquíssimas empresas começaram a apostar no potencial do “cérebro eletrônico”, aconteceu a Crise do Software 1.0: milhões foram gastos naquelas engenhocas mastodônticas antes que sentissem falta de um componente essencial: gente. Particularmente daquele tipo que depois receberia a genérica alcunha “programador¹”. Qualquer projetinho de meia tigela demandava dezenas e até centenas de profissionais. Acontece que poucos projetos daquela época eram pouco ambiciosos. Só o SAGE (Semi Automatic Ground Environment), da Força Aérea, contou com 700 programadores e 1400 profissionais de suporte. Época legal, em que cada linha de código chegava a custar assombrosos US$ 50.

    A grana, melhor dizendo, o potencial de faturamento chamou a atenção de muita gente. Começaram a brotar as “software houses” independentes. O desenvolvimento de sistemas deixava de ser uma exclusividade dos produtores de ferro (IBM, Burroughs, RCA etc). Mas como faltava gente. Os dois anúncios que você vê ao lado se preocupavam só com isso: atrair talentos. O simpático Dr. Bauer, da Informatics Inc., cravou a sua “segunda lei” no clássico reclame²: “o talento vai para onde está a ação“.

    Mas os anúncios não eram suficientes. E as empresas lançaram mão das estratégias mais agressivas para encontrar “talentos”. Montavam escritórios e quiosques em grandes cidades só para achar pessoas que poderiam ser “convertidas” em programadores. Os recrutadores eram orientados a dedicar especial atenção para: professores de matemática e, olha que jóia, professores de música!

    A estratégia funcionou. Em paralelo, universidades e escolas nasceram ou criaram cursos para formar gente que deveria atender toda aquela demanda pós-moderna.

    Até que, num belo dia, o mundo ficou chato (no sentido de ter uma superfície plana). E dos lugares mais improváveis surgiam programadores que prometiam executar o mesmo trampo de seus similares ocidentais por 1/10 do preço ou menos. Quem já teve o prazer de ler “O Mundo é Plano“, de Thomas L. Friedman (Objetiva, 2005), aprendeu que a Globalização 3.0 não afetou apenas os desenvolvedores de sistemas. Ninguém está isento do achatamento do mundo. E todo mundo pode aproveitá-lo. Acontece que a pancada no mercado do software, além de ter sido a primeira, foi também a mais sentida. “The New Face of the Silicon Age”, artigo publicado na Wired em fevereiro de 2004, mostra bem o tamanho do estrago.

    Os Pecados do Lado de Baixo do Equador

    O alegre povo de Pindorama, com um certo atraso, sacou: “tem bagulho bom aí!” (e João de Santo Cristo ficou rico a acabou com todos desenvolvedores da Índia). Bem, não foi bem assim. Poderia ter sido, não fôssemos tão viciados no auto-engano. A edição da EXAME aí ao lado, de 25/jun/2003, cravava na capa: “Descobrimos um segredo: o Brasil produz tanto software quanto a Índia.” Pouco tempo depois, em 17/mar/2004, a mesma revista jogou uma ducha d’água fria: “A Índia dá aula ao Brasil” (negrito e vermelho da versão original). Segredinho sem vergonha esse, hem?

    Jogamos tantas fichas em apostas bobinhas (CMMI, MPS.br e cartórios afin$) que agora assistimos bondes a nos ultrapassar. EXAME, em 30/jun/2010: “Rivais Além do Futebol – No setor de tecnologia, os empreendedores da Argentina estão melhor que os brasileiros na corrida da globalização.”

    Vou poupá-los do chororô sobre uma estratégia para o software tupiniquim. Quem se interessar pelos meus R$ 0,02 sobre o tema pode ler uma pequena série que publiquei em dezembro de 2007 no abandonado Graffiti. O ponto aqui é outro.

    É a Educação, Estúpido!

    O que Índia, China, Coréia do Sul e outros emergentes da indústria digital têm em comum é a preocupação com educação. O tema sempre aparece na pauta de nossos políticos. Mas aparece assim, como um tópico em um slide que apresenta suas “prioridades”. Até hoje não vi ninguém ir além do óbvio (mais escolas, professores melhor preparados e mais bem pagos etc etc). Como sou um dos menos indicados a tratar o tema com a profundidade e seriedade que ele merece, me limitarei a propor dois ou três novos “slides”, com questões mais específicas:

    • No último dia 12/ago a FGV assustou um tanto de gente com um número: “Até 2014, haverá um déficit de 800 mil vagas no setor“. Como não tem muito tempo que esse número era 200 mil, minha desconfiança é alta. Tanto que na palestra perguntei: “Será que estão confundindo a gente com atendentes de telemarketing de novo?” Não importa (muito). O fato é que há sim um “apagão”. E como suprir tamanha demanda de forma rápida? Com cursos técnicos! Em 2 anos é possível formar um batalhão de bons desenvolvedores. Repito o que disse o mineiro Adail Retamal em um seminário há 3 anos: “Programação se aprende em curso técnico, não na faculdade“.
    • Não tenho números oficiais, mas há tempos sabemos que cerca de metade da patota que inicia um curso (técnico ou superior) não o conclui. Alguém já se ocupou em descobrir as razões de tanta desilusão? Será que a distância entre nosso instigante cotidiano digital e os ângulos retos e empoeirados de nossas escolas não é uma boa explicação?
    • Se eu tivesse grana montaria uma escola com uma grade antenada. Uma base comum, formada por mínimas certezas e teorias fortes, seria obrigatória para todos. Depois, um cardápio multidisciplinar estaria à disposição de designers, engenheiros, líderes, analistas etc. Não me preocuparia em ter o crivo do MEC, PMI, IIBA nem nada do tipo. Uma escola de pensamento independente. Acho que seria uma revolução.
    • A formação de mão de obra qualificada é responsabilidade exclusiva de governos? É estranho o pensamento de alguns de nossos capitalistas de TI. Aqueles que têm real consciência da criticidade das pessoas para seu negócio devem se mexer. Quem quer talento hoje deve se preocupar em formá-lo. Duas dicas: i) Faça com que 4 ou 8 horas da jornada semanal seja utilizada exclusivamente em atividades de aprendizado; ii) Incorpore a segunda lei do Dr. Bauer: “O talento vai para onde a ação está“. Ação, pra quem não entendeu, é projeto que dá tesão.

    Observações:

    1. É preciso dizer que naquela época a tarefa de programação era dividida entre diversas funções, do pensador de algoritmos ao perfurador de cartões.
    2. Sorte nossa que o anúncio, lá no rodapé (p.s.), mata a curiosidade. A “primeira lei” do Dr. Bauer é a seguinte: “se o programa tem um bug, o computador o encontrará”. Grande Dr. Bauer. Mal sabia que sua primeira lei viraria mantra-desculpa de tester preguiçoso…
    3. A parte pré-histórica aqui narrada foi surrupiada do grande livro “From Airline Reservations to Sonic the Hedgehog – A History of the Software Industry”, de Martin Campbell-Kelly (The MIT Press, 2003).
    4. O cartoon, “Fitting into the system“, foi surrupiado de HikingArtist.com. Os dois anúncios que ilustram este artigo foram publicados no livro citado acima. E as capas da EXAME e da Wired são propriedade de suas editoras.
    5. O “Clube da Esquina” é do Milton e de todos os Mineiros; “O Pecado ao Sul do Equador” é do Chico; e o “Bom Bagulho”, do Renato Russo.

  • A Economia da Informação

    Original: Information Rules (Harvard Business School Press, 1999).

    Autores: Carl Shapiro é professor de Estratégia de Negócios na Haas Scholl of Business e do Depto. de Economia da Universidade da Califórnia, em Berkeley. Hal R. Varian é professor da School of Information Management da Universidade da Califórnia e colega de Shapiro na Haas.

    Editora: Campus, 1999. Tradução de Ricardo Inojosa.

    Do que se trata: defesa consistente e bem amparada de uma tese: “A tecnologia muda. As leis da economia não“.

    É um belo presente para:

    • Executivos de qualquer negócio baseado em informações;
    • Gente que vende software;
    • Profissionais que precificam produtos ou serviços de informação.

    Recomendações:

    “A Economia da Informação é o primeiro livro a explicar a economia em rede, a nova economia de nossas vidas. Shapiro e Varian explicam as loucuras que ocorrem todos os dias no Vale do Silício e em outras partes do mundo. Este livro é leitura obrigatória para toda pessoa de negócios do novo milênio.”
    – Eric Schmidt, quando ainda era CEO da Novell.

    “Excelente livro! Ao combinar uma linguagem clara e sem jargões, com exemplos bem definidos e específicos do mundo real, A Economia da Informação mostra como os princípios econômicos aplicam-se à era da Internet.”
    – Andrew Grove, presidente do conselho da Intel.

    Prós:

    • Leitura fácil, clara e objetiva.
    • Repleto de exemplos reais.
    • Bem estruturado em seus 10 capítulos e 400 páginas.

    Contra:

    • A tradução, pra variar, peca. Ver commodity aparecendo como “mercadoria” o tempo todo irrita. Se estava tão preocupado em trazer tudo para o português, por que manteve inalterado o termo “feedback”, que aparece até em título de capítulo?

    Trechos:

    “Ao gerir sua propriedade intelectual, você deve ter por objetivo escolher os termos e as condições que maximizem o valor de sua propriedade intelectual, não os termos e condições que maximizem a proteção.” (pág. 18)

    “A infraestrutura está para a informação assim como a garrafa está para o vinho: a tecnologia é a embalagem que permite entregar a informação aos consumidores finais.” (pág. 21)

    “O que há de novo é nossa habilidade de manipular informação, não a quantidade total de informação disponível.” (pág. 22)

    “Não deixe que seu produto de informação se transforme em mercadoria .” (pág. 42)

    Acompanhamentos:

    • A Vida Digital
      Nicholas Negroponte. Companhia das Letras (1995).
    • Wikinomics – Como a Colaboração em Massa pode Mudar o seu Negócio
      Dan Tapscott & Anthony D. Williams. Nova Fronteira (2007).
    • Cultura da Convergência
      Henry Jenkins. Editora Aleph (2008).

  • Priorizar

    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.

  • Benefícios / Custos

    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.

  • Valorizando Projetos

    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.

  • Classificando e Priorizando Projetos

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

  • Como Priorizar Projetos, Influenciar Decisões e não Fazer (muitos) Inimigos

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

  • Muita Areia no Caminhãozinho do AN

    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.

  • Agile Project Management

    Autor: Jim Highsmith é um consultor e escritor, especialista em engenharia de software e gerenciamento de projetos. Além do livro apresentado aqui, escreveu também “Adaptive Software Development” (Addison-Wesley, 2000), dentre outros. Foi co-autor do Manifesto Ágil.

    Editora: Addison-Wesley | The Agile Software Development Series. Primeira edição de 2004. Esta entrada é sobre a segunda edição, publicada em 2010.

    Do que se trata: Criação de produtos inovadores através do APM – Agile Project Management, ou Gerenciamento Ágil de Projetos. Apesar da intenção de atender um público mais amplo, é claro que Highsmith concentra-se no desenvolvimento de software.

    O autor sugere um Agile Enterprise Framework composto por 4 camadas:

    • Governança do Portfólio
    • Gerenciamento de Projetos
    • Gerenciamento de Iterações
    • Práticas Técnicas

    O livro só não cobre a última camada, que pode ser composta por práticas sugeridas em frameworks como XP (eXtreme Programming), OpenUP etc.  Highsmith defende que a estrutura proposta “facilita a construção de métodos ágeis híbridos que atenderiam necessidades específicas de uma organização”.

    O destaque para o Gerenciamento de Iterações não é novo, mas Highsmith coloca o tema em um novo patamar. O Planejamento Avançado de Releases é uma das principais atualizações desta segunda edição. As outras são: Valores Ágeis; Escalando Projetos Ágeis; Governança de Projetos; e Medição de Performance.

    A quem se destina: Líderes de projetos.

    Mas também pode ser muito útil para:

    • Gerentes de projetos insatisfeitos com sua situação atual;
    • Gerentes de produtos cobrados por inovação, qualidade, valor, agilidade…
    • Qualquer um que queira conhecer o Mundo Ágil de maneira ampla e sem dogmas ou extremismos. É particularmente indicado para executivos e gerentes.

    Prós:

    • Isenção. Highsmith não defende nada específico como Scrum, XP ou FDD, por exemplo. E justifica sua posição lembrando que um dos princípios  do desenvolvimento ágil é a adaptação para diferentes situações.
    • É esta isenção que possibilita que Highsmith critique alguns caminhos e descaminhos do Mundo Ágil.
    • O livro é muito bem estruturado e ilustrado. O que torna a leitura das 370+ páginas um estudo agradável.

    Contras:

    • As alterações em relação à primeira edição são muito grandes. Desconfio que o “segunda edição”, apresentado em letras garrafais na capa, faça com que muitos que conheceram a primeira edição ignorem este lançamento. Não deveriam.
    • Aliás, que capinha mais feia, hem?

    Destaques Aleatórios:

    • “Qualquer um que pratique o desenvolvimento ad hoc sob o disfarce ‘ágil’ é um impostor.” (pág. 9)
    • “Olhando de fora, um time gerenciado e um time liderado podem parecer a mesma coisa. Dentro eles são muito diferentes.” (pág. 48)
    • “Princípios guiam práticas. Práticas instanciam princípios. Não dá para separá-los”. (pág. 86)
    • “Todo projeto deve ter um time de desenvolvimento e um time de produto. O grupo de desenvolvimento deve ser liderado pelo líder do projeto e o grupo de produto pelo gerente do produto (que no Scrum é chamado Dono do Produto).” (pág. 119)
    • “O reconhecimento de que a iteração 0 (zero) não entrega valor para o cliente pressiona o time a mantê-la breve”. (pág. 147)
    • “… ‘Como você consegue estimar o desconhecido?’ A resposta é: ‘Você não consegue’. Quando há o desconhecido você está chutando, não estimando – e isso é o melhor que podemos fazer. É por isso que tempo e custo são vistos como restrições, e não estimativas, em projetos ágeis.” (pág. 153)
    • “A falta de um bom planejamento de releases é endêmico em partes da comunidade ágil”. (pág. 157)
    • “Existem duas estratégias fundamentais para o gerenciamento de mudanças – antecipação e adaptação – e o bom design leva ambas em consideração.” (pág. 218)
    • “Muita gente, inclusive algumas da comunidade ágil, pensa que o gerenciamento ágil de projetos significa menos gerenciamento. Em minha experiência, o gerenciamento ágil pode ser diferente, mas com certeza não demanda menos tempo.” (pág. 225)
    • “O intercâmbio de pessoas é muito mais eficaz que o intercâmbio de papelada.” (pág. 283)
    • “Os relatórios do Standish Group NÃO são bons indicadores da pobre performance do desenvolvimento de software, eles SÃO bons indicadores das sistêmicas falhas de nossos métodos de planejamento e medição.” (pág. 334)
    • “Quem nunca cancela projetos nunca corre riscos. Quem não corre riscos não sobrevive. não é fracasso, é bom gerenciamento.” (pág. 334)
    • “Previsibilidade ou agilidade: escolha uma.” (pág. 336)

    Trilha de Estudo:

    • Como prometido, uma trilha curta (em número de títulos). Esta entrada completa a anterior, “Agile Product Management with Scrum“, de Roman Pichler. Diz aí, você precisa de 2 dias, 2 semanas ou 2 meses para estudar ‘isso tudo’? Inté!

  • Times

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