PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • {finito} 2010

    Resoluções retardatárias? Pois é, meu planejamento atrasou um pouco. O ano começou diferente dos anteriores, com turma fechada do FAN acontecendo em Sampa. E a maioria das minhas ideias para 2010 requer um tempo de maturação e até versões ‘beta’. Como de costume, vou escancarar aqui algumas delas. Para quê? Uai, o feedback antecipado de potenciais usuários e clientes é sempre bem-vindo, certo?

    O Blog

    Alguns costumes e manias não resistem a um bom teste unitário. Sei lá porque um dia decidi que publicaria aqui apenas artigos mais trabalhados que, invariavelmente, também são longos (quase sempre com mais de 1000 palavras). Artigos assim costumam demandar algo entre uma e quatro semanas de elaboração. Não de redação e edição, claro, mas de pesquisa e compilação. O problema com este enfoque é que deixo de falar sobre um monte de assuntos que, desconfio, também interessariam aos leitores fiéis ou ocasionais. Portanto, aguardem mais e menores blues, digo posts. O que não significará o fim daqueles verborrágicos, para tristeza dos apressados.

    Outro velho projeto que deve finalmente vingar é a criação de outras seções aqui no finito. Duas aparecem no topo do blog backlog: 1) Bibliografia Comentada, com dicas de leitura e trilhas de estudo; e 2) Bate-papo com profissonais da área e usuários. Penso na transcrição totalmente sem edição de prosas facilitadas por IM’s e afins. O primeiro convidado parece não ter gostado muito da ideia mas insistirei. As duas novas seções pretendem trazer vozes e pontos de vista distintos deste que aqui rabisca.

    Cursos e Palestras

    Não foi o que planejei 4 anos atrás, quando iniciei a carreira solo. Mas os Cursos e Palestras se transformaram em minha vaca leiteira – no Lucro e não no Troco¹. Ao invés de nadar contra a maré, é preferível que eu reforce minhas ofertas. Principalmente para tentar me distanciar do oceano vermelho de sangue que caracteriza esse mercado. Gosto do modelo utilizado no FAN – eventos curtos e práticos. Mas a estabilidade dos times que estão ganhando é uma perigosa ilusão. Está aqui o desafio que mais tem ocupado meu tempo nas últimas semanas.

    Devo lançar simultaneamente, ainda neste primeiro trimestre, dois novos eventos. Serão dirigidos para públicos diferentes mas vão compartilhar o mesmo formato e nome: “O Jogo dos 7 Erros“. Um será voltado para líderes de projetos e outro para meu público-xodó, os analistas de negócios. O formato é de um jogo realmente. Cada erro merecerá uma hora. Os exercícios tomarão metade do tempo. O restante será utilizado na apresentação do erro, casos e para o debate com a turma. Como o formato é muito novo os eventos serão lançados como ‘beta’ e terão preços especiais. Aliás, tudo será novo e o teste é mais que necessário. Inclusive ou principalmente do material didático. As primeiras turmas devem acontecer em São Paulo.

    As novas ofertas não significam que o FAN irá para escanteio, pelo contrário. Novas turmas serão abertas, a partir de abril, em São Paulo e Brasília.

    Serviços

    É curioso como meus “patinhos feios” atraem atenção quando apresentados de maneira menos formal. Particularmente o conjunto de serviços que identifico como Administração de Ativos. Ou seja: erro feio na mensagem que transmito aqui e no material de marketing que desenvolvi. Duas providências: 1) Alterar a apresentação “formal” dos serviços; e 2) Lançar, no segundo semestre, eventos que mostrem de maneira mais clara a importância de alguns temas, particularmente a Administração de Ativos e a Engenharia de Processos. Pacotes de treinamento + consultoria devem ser a melhor resposta. Mas eu tratei de deixar bem baixas minhas expectativas para 2010.

    E o livro, sai ou não sai?

    Transparência é jóia e dá retorno. Mas também pode te deixar assim, sem ter onde esconder a cara quando alguma coisa não vai bem. Hoje eu entendo porque Nicholas Negroponte e Louis Gerstner resolveram nunca mais escrever depois de lançarem seus primeiros livros. “É o Negócio, Beócio!” é de longe o pior projeto que já assumi em minha vida. E eu tratei de torná-lo cada vez pior, prometendo prazos mesmo quando não era cobrado por isso. Acabei por transformá-lo em um verdadeiro pesadelo quando deixei os alvos ficarem móveis. Justo eu, que insisto com os 4 ventos que um projeto não pode dar certo se não tem objetivos bem claros.

    Pois bem, o livro já foi escrito 4 vezes. Acho que já contei isso aqui. Duas versões não mereceram a luz do sol e foram direto para o lixo (shift+del mesmo). Alguns capítulos da última versão foram publicados. Mas, apesar do feedback relativamente favorável, alterei a estrutura e me perdi novamente. Tudo fica um tanto surreal quando me lembro que em apenas 4 meses, no longínquo 2007, eu escrevi uma versão quase completa. Hoje tenho a sensação de estar muito próximo da estaca zero.
    E olha que até capa(s) ele já tem²!

    Inicialmente o livro seria um “Guia para a Formação de Analistas de Negócios”. Quando comecei a aceitar que este deve ser também o meu último livro resolvi que ele podia ser um pouco mais abrangente. Ambiguidade é risco. E aquele “pouco” da penúltima frase virou um imenso problema. O lado bom do desabafo aqui é que, além de tirar um grande peso de meus ombros, dá ânimo para pegar no trampo de novo.

    Epílogo?

    Que nada! Prólogo para um 2010 que promete. Mas antes de começar eu preciso agradecer a todos que fizeram de 2009 um ano bem legal e produtivo: Leitores do finito, participantes do FAN e do grupo AN.br, clientes, parceiros e amigos. Espero que tenhamos boas desculpas para novos encontros.

    Observações

    1. Lucro | Troco | Truco é uma versão tropicalizada daquele esquema “70% 20% 10%” que seria utilizado pela Google. Dedico 70% do meu tempo em ofertas que representam meu negócio principal, o Lucro. O Troco, que ocupa 20%,  é aquela receita básica e normalmente pequena que serve para pagar despesas fixas. E o Truco é uma ideia maluca qualquer que só merecerá mais de 10% do tempo quando mostrar potencial para virar Lucro ou Troco. Junto com o esquema Conteúdo -> Conversas -> Transações, este conceito dá forma ao núcleo do modelo de negócios do finito.
      Pois é, formalizei lá em cima que Cursos e Palestras passam a merecer 70% do meu tempo. Pelo menos até o início do 2º semestre.
    2. As capas foram desenvolvidas pela Sabiá. Me apresentaram 6 sugestões e até hoje o máximo que consegui foi eliminar duas. É provável que o livro saia com 2 capas oficiais, uma para descolados e outra para… hmm… menos descolados, hehe…
    3. O finito ganhou chaves?!? {finito}
      Têm algum significado?

  • O Mundo Mudou

    Terceira parte da nossa conversa sobre “O Novo Gerente de Projetos”.

    O mundo mudou. E não me lembro qual foi a última vez que utilizei um título tão “fraquinho”. Como o antecipei nas duas partes anteriores, seguirei com ele.

    O mundo muda todo dia. Em negócios e TI a impressão que temos e deixamos é de uma dinâmica quase caótica. Uma volatilidade que, segundo experts, gera uma população repleta de pessoas inseguras, ansiosas e desconfiadas. Não raro, exageramos os possíveis impactos de determinado acontecimento. Outras tantas vezes subestimamos tendências. Como a imensa maioria das pessoas é desprovida de dons proféticos e bolas de cristal, é natural que seja assim. Como é normal que indivíduos apresentem reações muito diferentes quando defrontados com uma mesma mudança. Mas o papo aqui é ou deveria ser sobre projetos e seus gerentes.

    Projeto é mudança. Talvez esta seja a verdade absoluta mais ignorada ou desprezada. Quando uma organização dispara um projeto ela está implementando uma mudança. Aqueles que foram selecionados para o trabalho devem estar preparados para lidar com todos os reflexos gerados por ela. Esses reflexos, com maior ou menor intensidade, fazem com que os projetos sejam naturalmente instáveis. Ainda bem que eles têm data para acabar, não é mesmo?

    Porque é natural do ser humano o gosto ou necessidade de estabilidade. Mesmo aqueles viciados em adrenalina, como os praticantes de esportes radicais, valorizam muito os períodos de calmaria. O fato é que estabilidade perene apenas é possível em processos – em ações que repetimos ad infinitum. Projetos são únicos em seus objetivos e restrições. Eles sempre são inéditos de alguma maneira. Por isso é estranha uma certa obsessão por projetos estáveis. Surrupiando um dito de Michael Hammer¹, “projeto instável” é um oxímoro em vias de se tornar um pleonasmo. Por isso é equivocada a crença em planos. Ou, melhor dizendo, a crença na certeza dos planos. Mas, antes de “atacar” os planos (se é que vou fazê-lo), vamos falar sobre a crença. De onde ela vem? O que a alimenta?

    Durante muito tempo jogamos praticamente todas as nossas fichas em padrões e metodologias que, de uma forma ou de outra, prometem estabilidade e previsibilidade. Apesar das promessas raramente cumpridas, particularmente em projetos de TI, essas propostas se espalharam como notícia ruim. As falhas, quando reconhecidas, raramente eram atribuídas aos padrões e metodologias adotados. Quase sempre a culpa é de quem os implementou. Mercados foram criados em torno dessas propostas. E elas se solidificaram. No mau sentido.

    Temos hoje um imenso “sistema legado” de processos de gerenciamento e desenvolvimento. Usei o termo “sistema legado” exatamente porque ele nos remete aos nossos legados mais famosos – igualmente caros e não muito “simpáticos” a mudanças. O “sistema” que aqui trato é composto por treinamentos, certificações, ferramentas, corpos de conhecimento e, principalmente, cultura. Ou, para voltar ao termo utilizado anteriormente, crença.

    Em determinado momento da história alguns componentes do “sistema” se iludiram com sua pretensa estabilidade. Algumas palavrinhas que guiam os tempos modernos, como inovação e criatividade, são simplesmente ignoradas pelo “sistema”. O próprio sentido de mudança e o entendimento de que não se trata de algo indesejável, mas necessário e inevitável, não encontra respaldo real em algumas das peças mais relevantes do “sistema legado” de processos de gerenciamento e desenvolvimento.

    Seria então o caso de jogar todo o “sistema” no lixo? Claro que não. Sugestões assim são ingênuas (mas pouco inocentes). Ingênuas por não perceberem que o “legado” criado, assim como seus pares, é complexo e caro, mas não deixa de ter seu valor. Acredito que, de todos os seus componentes, o primeiro a ser questionado deveria ser a crença ou cultura. Questão de coerência: como um gerente de projetos – um profissional especializado na implementação de mudanças – pode resistir tanto em mudar?

    Ao questionar a crença, ao adotar um perfil mais cético, o profissional tomará os outros componentes do sistema com outros olhos. Ele tenderá a ser mais cuidadoso e desconfiado. Mas será também mais curioso.

    Não se iluda. Mudar cultura ou questionar a crença não é nada fácil. Também não é algo que possa ser implementado como um projeto. Mas é fácil apontar a trilha. Aliás, é até meio besta: 1) Aceitar que mudanças são inevitáveis; 2) Questionar certezas absolutas; e 3) Não ter medo do novo e muito menos de aprendê-lo.

    O Argumento Derradeiro

    Há poucos dias, Scott Berkun, autor de “A Arte do Gerenciamento de Projetos” (Bookman, 2008), retomou um tema que vou traduzir da seguinte maneira: Gerenciamento de projetos é chato? Berkun responde que “o gerenciamento de projetos é tão chato quanto a coisa que está sendo gerenciada”. Por favor, me desculpe a chatice, mas releia a frase negritada.

    Em um artigo anterior Berkun já havia comentado sua impressão de que o Gerenciamento de Projetos não é muito respeitado. E, em outras palavras, não é uma função ou profissão sexy, atraente. Você não vê nenhuma criança ou adolescente dizendo: “Quando eu crescer quero ser gerente de projetos”. Mas Berkun argumenta que diretores de cinema, técnicos de futebol, produtores de discos e várias outras profissões são variações de gerentes de projetos. A diferença é que eles usam outros termos. Nomes que tornam explícita a coisa que gerenciam. E fazem daquela função algo mais atraente, com certeza.

    Me lembro quando chegou a hora de definir minha profissão. Meu velho, como de costume, deu um conselho rápido e nada rasteiro: “Escolhe qualquer coisa, menos contabilidade”. Ele era contador. Dos bons, diga-se de passagem. Trabalhava 30 horas por semana e fazia de tudo para tornar sua rotina menos chata. Mas ele sabia que estava aprisionado em uma função que é, por natureza, 90% do tempo enfadonha.

    Gerenciamento de projetos pode ser tudo, menos chato. Mas, por incrível que pareça, conseguimos torná-la uma profissão dura e carrancuda. Quadrada mesmo. E me parece claro que os ângulos retos de todos os componentes do nosso “sistema legado” são os maiores responsáveis por isso.

    .:.

    Nome aos Bois e Pingos nos ‘is’

    Ao bom entendedor que por aqui navega ficou claro que dentre os componentes do “sistema legado” tratado acima figuram: PMBoK, CMMI, Prince2, MPS.br, ITIL, afins e derivados. Manada devidamente nomeada, resta agora esclarecer alguns pontos:

    • PMBoK e BABoK não tratam de nenhum tipo específico de projeto. Então, pode parecer equivocada uma crítica que considere apenas projetos de TI. Não na minha opinião. Ainda avalio se vale a pena um artigo sobre “O Problema com os BoK’s”. Vale a pena ou a espada?
    • Não estarei aqui para ver a aposentadoria do “sistema legado”. Ele resistirá e sobreviverá por um bom tempo. A torcida, de certa forma otimista, é para que ele encontre e beba de um tipo de fonte da juventude. O tipo de ‘service pack’ que o BABoK receberá, por exemplo², é uma de várias possibilidades de rejuvenescimento. Os únicos pré-requisitos são humildade e olhos e ouvidos abertos.
    • Por ser longevo, o “sistema legado” não pode ser ignorado por nenhum profissional razoavelmente sério. Há muito conhecimento ali.
      Mas é um pecado iniciar a profissão pelo lado quadrado da força. Quem quer iniciar uma carreira em gerenciamento de projetos deveria, antes de qualquer coisa, estudar alguns documentos que ainda são meio “apócrifos”. Eu iniciaria por “A Arte do Gerenciamento de Projetos” (Scott Berkun. Bookman, 2008) e “Agile Project Management – Second Edition” (Jim Highsmith. Addison-Wesley, 2010). Necessariamente nesta ordem. Eu não tive essa sorte. Mas também não virei contador³.

    .:.

    Observações

    1. Michael Hammer utilizou aquela frase para falar sobre mudanças corporativas. A original é: “Mudança corporativa é um oxímoro em vias de se tornar um pleonasmo“.
    2. Em dezembro fiquei sabendo que o IIBA está preparando uma “Extensão Ágil” para o BABoK. Quem viu a “Leitura Crítica” que fiz já sabia que era uma correção mais que necessária. Apesar da tentativa da versão 2.0 em atender os mundos “Plan-Driven” e “Change-Driven”. Mais do que qualquer coisa, devemos elogiar a humildade e iniciativa do IIBA.
    3. Por favor, prezados contadores, não me levem a mal. Além do meu velho, tenho vários outros parentes que assumiram e gostam desta honrosa profissão. Só não dá para discutir o fato dela ser  90% do tempo chatinha. Sabem o que meu velho fazia quando queria um pouco de diversão? Pegava a contabilidade de uma empresa pra lá de enrolada com fisco e afins. Ou então contratava o filho para desenvolver o sistema de contabilidade daquela empresa encrencada. Pois é, eu não estaria aqui se não fosse a contabilidade.
    4. O desenho utilizado neste artigo, flikr0675, é do flikr.

  • Fracasso 2.0

    Sequência do papo sobre “O Novo Gerente de Projetos“. Segunda parte de um total de três (ou quatro).

    Em todas as turmas do FAN, quando mostrando como todos os requisitos devem derivar dos objetivos do negócio, sempre comentei o seguinte: meu currículo apresenta projetos que tiveram problemas com prazos e orçamentos. Alguns maiores, outros nem tanto. Só me sentiria envergonhado se apresentasse ali algum projeto que tivesse falhado na realização dos objetivos do negócio.

    A comunidade de gerenciamento de projetos tem demonstrado maior preocupação com o Valor gerado para os negócios. Dentre vários artigos e outros trabalhos distingue-se, por exemplo, “Diferenciando os Alinhamentos Estratégicos de Projetos“, de Ana Helena Moreira e Fabio Medeiros, publicado na MundoPM de Abr/Mai de 2009. Eles demonstram como a Proposição de Valor de uma organização, da qual derivam as estratégias, deve direcionar “o foco e o conteúdo dos elementos do gerenciamento de projetos”. Aliás, o título do editorial da mesma edição, assinado por Zózimo, é “Valor“.

    O PMBoK¹ não dá margens para dúvidas quando registra que “projetos são meios para a realização de metas ou objetivos da organização”. Nem quando afirma que o gerente “entrega projetos balanceando requisitos de escopo, prazos, qualidade e custos”. Ele falha, em minha opinião, quando não explicita que tal “balanceamento” deveria ser orientado pelos objetivos do negócio. Na realidade, o grande problema do PMBoK é não fazer refletir em seus processos a devida preocupação com a satisfação das metas e objetivos da organização.

    Alinha-se ao PMBoK o Chaos Report, relatório publicado pelo Standish Group desde 1994. Alinha-se? Sim, ao considerar que um projeto *falha* quando atrasa e/ou estoura orçamento e/ou não entrega todo o escopo *planejado*. Ambos os trabalhos ainda apresentam em seu “espírito” uma preocupação exagerada com o plano. Contra desvios são recomendadas “ações corretivas”, o que deixa entender que o plano está sempre correto; Equivocada seria a execução.

    Apesar da qualidade aparecer entre itens que precisam ser “balanceados”, tanto PMBoK quanto o Chaos Report nos remetem ao velho “Triângulo de Ferro” do gerenciamento de projetos: Escopo, Prazos e Custo. Esses três itens configuram as principais preocupações de um gerente de projetos. E elas estão explicitamente refletidas nas várias práticas e processos sugeridos não só nos dois trabalhos mas em vários outros que tratam o gerenciamento de projetos.

    O primeiro dos 12 princípios do Manifesto Ágil diz que: “Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software valioso”. Valioso no sentido de que o produto entregue realmente representa um meio eficaz para a busca dos objetivos do negócio. Vários métodos, frameworks e práticas derivados do Manifesto Ágil atestam tal preocupação. Mas alguns parecem limitar a percepção de valor à medição do ROI (Retorno sobre o Investimento). É suficiente?

    O Novo Triângulo

    Um Novo Triângulo para o Gerenciamento de Projetos
    Um Novo Triângulo para o Gerenciamento de Projetos

    Jim Highsmith, em “Agile Project Management – Second Edition²“, sugere a adoção de um “novo triângulo”, de algo que de fato represente as principais preocupações de um novo gerente ou líder de projetos. Para ele, as três pontas deste novo triângulo são: Valor, Qualidade e Restrições. Segue uma breve explicação sobre cada uma:

    • Valor: representa diretamente a contribuição para a realização dos objetivos do negócio. Quando tratamos de um sistema para uso próprio, avaliamos e valorizamos a eficácia com a qual ele ajudará a empresa na busca pelos seus objetivos.
      Quando a principal saída de um projeto é um produto ou serviço para uso de terceiros, o Valor indica tanto a satisfação destes quanto a realização das estratégias comerciais.
      Aqui é importante destacar que o Valor também representa a Qualidade Extrínseca ou externa do produto ou serviço. Essa qualidade é imediatamente percebida pelo cliente e não é a mesma citada como segunda ponta do triângulo.
    • Qualidade: esta é a Qualidade Intrínseca ou interna do produto, e refere-se principalmente à sua confiabilidade e capacidade de adaptação. Por exemplo: um produto pode ser muito bem recebido por um cliente no primeiro momento – seu Valor foi percebido pelo cliente. No entanto, quando mudanças são necessárias mas de difícil e cara implementação, consideramos que a qualidade do produto é baixa, sofrível ou inexistente.
    • Restrições: e quem disse que o velho triângulo deveria ir para o lixo? Muito pelo contrário. É aqui, formando a terceira ponta do novo triângulo, que manifestamos nossa preocupação com Escopo, Prazos e Custos. Como reforça Jim, utilizando o mesmo padrão de apresentação dos valores do Manifesto Ágil, a colocação das restrições como apenas uma ponta do novo triângulo não significa dizer que elas não são importantes. Mas é considerável o impacto na crença de que a realização sem desvios do escopo, prazos e custos previstos seriam suficientes para determinar o sucesso de um projeto.
      E esta não é a única mudança. Além do livro de Jim, um outro trabalho a ser publicado em 2010, “Agile Product Management with Scrum³“, sugere um interessante tratamento das restrições. Das três – escopo, prazos e custos – uma é mais relevante para a realização dos objetivos do negócio. Apenas ela deveria ser fixada. As outras duas seriam tratadas com certa flexibilidade. Por exemplo: o prazo, o time-to-market, é considerado crucial para o sucesso de determinado produto. Sendo assim, tanto o escopo quanto os custos poderiam variar. É claro que não se trata de flexibilização total (e insana). Mas o cliente ou patrocinador aceitaria a flutuação dentro de uma faixa pré-estabelecida. Os custos ficariam entre $ 80 e $ 120, por exemplo. Também seria aceitável o possível corte de algumas funcionalidades opcionais (ou secundárias). Tudo para que o prazo, neste exemplo a restrição mais importante para o negócio, fosse atendido plenamente.

    .:.

    Me parece inevitável uma revisão da definição de fracasso pelo Standish Group. Assim como espero um PMBoK mais orientado para a adaptação do que para ações corretivas (que visam a colocação do trabalho nos “trilhos” de um plano). Como insiste Jim Highsmith em mais de um trecho do livro, “planos (e arquiteturas) devem funcionar como guias e não como camisas-de-força”.

    Do outro lado, do Mundo Ágil, espero a compreensão de que o ROI (Retorno sobre o Investimento) não é a única unidade de medida ou preocupação que deve nortear um projeto ou mesmo indicar seu sucesso ou fracasso.

    Mas… devo me segurar. Afinal, prometi uma série de artigos com provocações e questionamentos, não com conclusões. Portanto, deixo algumas questões: Como você mede o sucesso de seus projetos? E o fracasso? Você realmente acredita que um projeto cancelado significa um fracasso? Planos não realizados em sua plenitude são fracassos? Essas percepções são compartilhadas por todas as partes interessadas?

    O papo seguirá. O próximo artigo será “O Mundo Mudou“. Inté!

    .:.

    Referências

    1. Guide to the Project Management Body of Knowledge – PMBoK® Guide, Fourth Edition.
      PMI – Project Management Institute. 2009.
    2. Agile Project Management – Second Edition.
      Jim Highsmith. Addison-Wesley, 2010.
    3. Agile Product Management with Scrum
      Roman Pichler. Addison-Wesley, 2010.

    A figura utilizada no topo do artigo, flikr2298, é do Flikr e liberada como Creative Commons (by).

  • O Novo Gerente de Projetos

    Quase cometi um “O Mundo Ágil precisa de Gerentes de Projetos?“. Não o fiz porque, além de apelativo, o título remeteria ao artigo anterior, quando repeti a mesma pergunta para falar sobre analistas de negócios. Se naquele texto eu apresento uma conclusão, agora meu objetivo é apresentar alguns cenários e provocações. Na realidade, vou apenas compilar e repassar uma série de ‘achados’ que devem nos ajudar a debater e, se for o caso, definir um novo Gerente de Projetos. Soou pretencioso, né? Repare que a intenção é ajudar a definir, ok? São meus R$ 0,02.

    Antes de qualquer coisa: por que precisaríamos de um novo gerente de projetos? Algumas respostas: 1) O Mundo Mudou; 2) Os Fracassos são Constantes; e 3) Os Gerentes Vivem Sobrecarregados e Criticados. Se você não acredita nessas motivações ou acha que elas não são suficientes para justificar esse papo todo, então poupe seu tempo. Caso contrário, espero não chateá-lo com a série de 3 ou 4 partes que se inicia aqui. Sim, precisarei de uma série para desfilar alguns ‘achados’. Vamos lá.

    Gerentes de Projetos Vivem Sobrecarregados e Criticados

    E as causas são conhecidas. Em TI, insistimos em gerentes de projetos (GP’s) que também devem apresentar bons conhecimentos de determinadas tecnologias. Ou seja, muitos esperam que o GP seja também uma espécie de arquiteto. Ou, no mínimo, que ele consiga orientar ou validar o trabalho técnico desenvolvido. Isso sem isentá-lo de todas as tarefas administrativas. Não é a primeira vez que toco neste ponto e não pretendo explorá-lo em maiores detalhes. Me limitarei a citar Fred Brooks (“O Mítico Homem-Mês”, Campus, 2009): “Pensadores são raros. Executores são raros. Pensadores-executores são raríssimos”.

    Outra causa do excesso de trabalho é o microgerenciamento. Não importa se a “culpa” é do profissional ou do processo utilizado. Ou mesmo da falta de um. O fato é que, a partir de determinado porte, é simplesmente impossível microgerenciar um projeto. Claro, considerando uma jornada de trabalho de 8 horas por dia.

    Mas o efeito mais importante do microgerenciamento é outro: a insatisfação da equipe. Projetos de TI são tocados por “trabalhadores do conhecimento” – profissionais que gostam e precisam de espaço e autonomia para desempenhar bem suas funções. Temos aqui um típico exemplo de relação “perde – perde”.

    Aquilo que chamo de “Mundo Ágil”, o conjunto de propostas derivadas do Manifesto Ágil, endereça essas questões de diversas maneiras.  Tem poucos dias, por exemplo, Tobias Mayer escreveu em seu Twitter que: “Projetos ágeis não precisam ser ‘gerenciados’. Eu gostaria que este oxímoro fosse banido de nosso vocabulário”. Sua ‘revolta’ foi motivada por este anúncio, que fala de certificação em gerenciamento de projetos ágeis.  Só para clarear: oxímoro é uma figura de linguagem que coloca dois termos antagônicos, contrários, em uma mesma expressão. Tobias considera então que “gerenciamento” e “projetos ágeis” devem ser como água e óleo. Desconfio que ele quer dizer outra coisa: projetos ágeis não precisam de gerentes.

    A implementação mais comum deste conceito de “não-gerenciamento” é o “autogerenciamento”. A equipe se gerencia, sem nenhum tipo de interferência externa. Não há ingerência, já que todos podem falar sobre o trabalho de todos. Na realidade, em dada situação, algum membro da equipe pode assumir a responsabilidade por uma tomada de decisão. Mas o gerenciamento é uma responsabilidade de todos.

    Ainda no Mundo Ágil, mas em um pólo bem diferente de Tobias e outros, está Jim Highsmith. Na segunda edição de “Agile Project Management” (Addison-Wesley, 2010) ele quebra o termo “autogerenciamento” para clarear alguns pontos. Ele defende que uma equipe seja auto-organizada. Isso estaria no ‘core’ do APM (Agile Project Management) e a sua viabilização seria uma das principais responsabilidades de um Líder (ele não usa os termos gerente ou coordenador de projetos).

    Ainda segundo Jim, existem também os times “autodirigidos”, aqueles que independem de um líder. Em inglês ele usa o termo Leaderless. Para ele, esse tipo de estrutura “vai contra várias pesquisas que mostram que o sucesso em projetos e organizações dependem de bons líderes”. Algumas páginas adiante, mais precisamente na 60, Jim ‘desce o malho’: “Equipes auto-organizadas estão no núcleo do gerenciamento ágil, mas os conceitos estão corrompidos em setores da comunidade ágil. Apesar de ser um bom termo, ele tem sido, infelizmente, confundido com anarquia”. E prossegue: “É fácil combater os gerentes fracos e defender sua eliminação. Muito mais difícil é trabalhar com as organizações para que elas alterem seu estilo de liderança de forma a suportar um ambiente ágil”.

    Melhores líderes e um melhor estilo de liderança  não significam, na visão de Jim, que uma equipe não possa se auto-organizar e autogerenciar. Seria tudo uma questão de equilíbrio: “Auto-organização significa que, na medida do possível, a tomada de decisões é delegada para os times”. E explica: “Mesmo que líderes ágeis devam ser ‘light’ em termos de decisões ‘top-down’, eles devem ser ‘heavy’ na articulação de objetivos, facilitação de interações, melhoria da dinâmica da equipe, suporte a colaboração e incentivo da experimentação e inovação”.

    Não me parece uma coincidência o fato da lista acima guardar várias semelhanças com aquela apresentada no artigo anterior, que tratava das responsabilidades de um Dono do Produto em um projeto guiado pelo Scrum. Vale lembrar: o Scrum é uma metodologia que, em certo sentido, se propõe Leaderless. As responsabilidades sobre o gerenciamento são compartilhadas pelo ScrumMaster, Dono do Produto e Time.

    Acontece que, em vários trabalhos mais recentes (como “Product Management with Scrum”, de Roman Pichler – Addison-Wesley, 2010), a função do Dono do Produto está sendo apresentada de tal maneira que chega a ser estranho o fato dele não ser tratado como um Líder. De uma forma ou de outra, os autores são claros em um ponto: trata-se da função mais crítica e difícil em uma iniciativa guiada pelo Scrum.

    Por fim, gostaria de destacar algumas possibilidades apresentadas por Phillip “Shoes” Calçado no papo que tivemos sobre o último artigo: “Cada projeto tem necessidades específicas. Como analogia, em alguns projetos precisamos de alguém 100% do tempo atuando como gerente de projetos e ainda de um gerente de iteração. Em outros projetos apenas o gerente de iteração pode fazer PM e IM. E em outros um desenvolvedor ou BA sênior pode facilmente fazer o seu papel e ainda cuidar de gerência de projetos.”

    Queria apenas acrescentar que essa divisão entre gerenciamento de projetos e gerenciamento de iterações é totalmente compatível com o framework proposto por Jim Highsmith no livro citado acima. Aliás, “Agile Project Management – Second Edition” é uma compilação de práticas estruturada em torno de 3 das 4 “camadas” que formam o que Jim chama de “Agile Enterprise Framework”. As quatro “camadas” são: Governança do Portfolio, Gerenciamento de Projetos, Gerenciamento de Iterações e Práticas Técnicas. Apenas essa última camada, formada por práticas de engenharia, não está no escopo do livro.

    Como eu disse lá em cima, (ainda) não apresentarei conclusões. Na próxima parte da série falarei sobre “Fracassos”. Inté.

    .:.

    Observações

    A imagem utilizada, flikr0629, é de flikr e foi surrupiada no Flickr. Simples assim.

  • O Mundo Ágil precisa de Analistas de Negócios?

    Na realidade, a dúvida mais frequente em nossos papos e debates é: Como o Analista de Negócios (AN) se ‘encaixa’ em um projeto guiado por um método ágil? Acontece que possíveis respostas para essa questão obrigatoriamente nos levam para a pergunta do título: Projetos ágeis precisam de AN’s? Temo que não são poucos os que responderiam com um rápido e sonoro: Não!

    E não é muito difícil entender suas razões. Primeiro, como Roman Pichler lembra em “Agile Product Management with Scrum”¹, nenhum livro “clássico” derivado do Manifesto Ágil cobre aquelas etapas iniciais de um projeto que podem se beneficiar da atuação de um AN. Ken Schwaber, em “Agile Project Management with Scrum” (2004), Kent Beck, “Extreme Programming Explained” (1999) e “Crystal Clear” (2005) de Alistair Cockburn – todos partem de uma visão ou pauta* (Product Backlog) previamente definidos. Pouco ou nada falam sobre aquele momento em que equipe e organização definem ou, melhor dizendo, começam a definir o que precisa ser feito.

    Pichler não cita, mas “Agile Project Management – Second Edition” (2010) de Jim Highsmith e até “Utilizando UML e Padrões” (2008) de Craig Larman apresentam a mesma restrição. Este último não o faz de maneira explícita, como é comum em obras baseadas no Processo Unificado (PU). Mas isso é assunto para outro artigo. O que nos interessa aqui é a confirmação de que não só o AN, mas a própria Análise de Negócios é em parte ignorada por pessoas e obras que ajudaram a fundar, definir e consolidar o Movimento Ágil.

    Por favor, não entenda que a análise de negócios é apenas uma fase no início de um projeto. Utilizada corretamente em um modelo de ciclo de vida iterativo e incremental, ela existirá durante todo o projeto. E até depois dele. O que tento destacar aqui é que, nas fases iniciais de um projeto, a análise de negócios é caríssima. E o é porque é ela que ajuda a definir uma clara visão dos objetivos do negócio ou do produto. E, como diz Jim Highsmith², “na ausência desta clara visão, a natureza exploratória de um projeto ágil resultará numa espiral infinita de experimentações”. No popular: “para quem não sabe para onde vai, qualquer caminho serve”.

    Não é minha intenção tentar explicar essa grave omissão. Já ouvi muitas pessoas dizendo que a Análise de Negócios seria, por si só, um projeto específico. Não concordo. Todo projeto de software depende, mesmo que em graus diferentes, de um conjunto de métodos e práticas que: 1) ajudam a definir o que precisa ser feito; e 2) ajudam a garantir que o que está sendo feito realmente atende aos objetivos fixados (e respeita as restrições colocadas). A esse conjunto foi dado o nome “Análise de Negócios”. E eu não entendo como um projeto para a construção ou implantação de um sistema de informação poderia prescindir dele.

    Um segundo motivo pelo qual os AN’s parecem “ignorados” pelo Mundo Ágil é a forma como este, em seus vários sabores e formas, conclama e exige uma participação mais efetiva dos usuários e demais partes interessadas que não fazem parte do “time de construção”.

    Na proposta conhecida como eXtreme Programming (XP ou XisPê), por exemplo, uma prática requer o usuário literalmente sentado ao lado dos desenvolvedores. Costumo brincar que, quando um bom AN se deparar com um usuário que tenha total disponibilidade para ficar alimentando um projeto com seus requisitos, deveria recomendar sua sumária demissão. É brincadeira. Mas procura iluminar um ponto crítico: quem, nos dias de hoje, pode abandonar seus afazeres cotidianos durante todo um projeto? É claro que se trata de uma prática de difícil aplicação. Assim como deve ser óbvio que, quando possível e em determinados tipos de (pequenos) projetos, ela deve ser adotada. Não questiono sua eficácia. Apenas desconfio de sua viabilidade.

    O Scrum é outra proposta derivada do Mundo Ágil, que se caracteriza ultimamente pelos altíssimos índices de popularidade. Ele concentra suas sugestões nos aspectos gerenciais de um projeto. E define a existência de 3 “entidades” principais na comunidade de um projeto: o ScrumMaster, o Time e o Dono do Produto (Product Onwer). Este seria o representante de todos os usuários e teria, segundo Ken Schwaber (um de seus “criadores”), duas grandes responsabilidades: 1) Maximizar o ROI (Retorno sobre o Investimento); e 2) Gerenciar a Pauta (Product Backlog). Roman Pichler, no mesmo título citado anteriormente, sugere uma revisão das duas principais preocupações que devem guiar o Dono do Produto. Elas seriam: 1) Definir a Visão; e 2) Entregá-la!

    Repare como a sugestão de Pichler se encaixa perfeitamente na definição da análise de negócios que apresentei acima: 1) Ajudar a definir o que precisa ser feito; 2) Ajudar a garantir que a entrega realmente satisfaz os objetivos colocados. A mudança está apenas no tom, no tamanho da responsabilidade: o Dono do Produto realmente define a visão e é o principal responsável por entregá-la**. A análise de negócios ajuda.

    Então podemos dizer que o Dono do Produto (DP) elimina a necessidade de um Analista de Negócios (AN)? Em minha opinião, quase nunca! Citarei Pichler novamente, listando aquelas que seriam as responsabilidades de um DP:

    • Pesquisa de mercado;
    • Planejamento do Produto;
    • Análise de Negócios (!);
    • Gerenciamento da Pauta (Product Backlog);
    • Descoberta, Descrição e Priorização de Requisitos;
    • Gerenciamento de Versões (Releases);
    • Acompanhamento da evolução do projeto;
    • Gerenciamento do orçamento;
    • Relacionamento com clientes, usuários e outras partes interessadas; e
    • Participação nas Reuniões Scrum.

    Gerentes de projetos devem ficar um tanto “encafifados” com a listinha acima. Mas outro dia eu falo com eles. A questão aqui é: até que ponto é possível que apenas uma pessoa realize (bem!) todas as atividades listadas acima? Repare ainda como questões operacionais, táticas e estratégicas são misturadas, causando a falsa impressão de que seriam equivalentes. E lembre-se que existem pessoas que ainda cogitam a utilização de um DP que não tem 100% de disponibilidade de tempo para o projeto!

    Não é por acaso que vários trabalhos recentes – dentre eles o já citado Pichler e também “Scrum Product Ownership”³, de Bob Galen (2009) – afirmam que o trampo do DP é “o mais pesado em um projeto Scrum” (Galen). Portanto, não deve causar espanto nem revolta o fato de alguns autores começarem a sugerir uma Equipe do Dono do Produto. Pichler chega a citar um exemplo mostrando uma equipe formada por “dois analistas de negócios, um arquiteto chefe e um assistente de projeto”, além do próprio DP, é claro.

    É importantíssimo salientar que o DP continua sendo uma única pessoa. O que muda com a sugestão acima é a aceitação de que o DP não dá conta sozinho de tudo o que ele precisa fazer. Mesmo em projetos considerados pequenos. Sendo assim, ele sempre poderá montar um time próprio. Sinceramente, eu não entendi o que um “arquiteto chefe” fez naquele exemplo do Pichler. Mas, tendo em vista a lista de responsabilidades acima, é muito fácil supor a ajuda que AN’s podem dar para os DP’s. Sendo mais direto: todo o trabalho operacional listado (descoberta e descrição de requisitos; análise de negócios de uma maneira geral; pesquisas e parte do relacionamento com outras partes interessadas) pode ser atribuído exclusivamente para AN’s. Além, claro, do apoio na execução de atividades de caráter tático (como o gerenciamento da pauta).

    Eu entendo e até tento compartilhar o temor que muitos demonstram quando veem uma sugestão como essa. Mais pessoas, mais intermediários, podem comprometer a qualidade da comunicação. Nunca vou dizer que esta não é uma preocupação relevante. Acontece que os problemas causados por um DP sobrecarregado podem ser consideravelmente piores. Imagine, por exemplo, o início de uma iteração sem uma pauta fechada; ou então com uma pauta repleta de requisitos (ou histórias) incompletos, ambíguos ou mal estruturados e porcamente priorizados.

    Se ambos os cenários, comunicação e sobrecarga, são ruins e indesejáveis, mas devemos escolher um, qual seria melhor administrado? Qual representa menores riscos?

    Conclusões (?)

    Reparou nas datas de publicação das obras citadas? Pensou na base histórica que temos desde o dia 13 de fevereiro de 2001, data de ‘nascimento’ do Manifesto Ágil? Desconfiou que a consolidação de nossos métodos de experimentação (desenvolvimento) é também uma experiência? Por isso tasquei um ‘?’ ali no subtítulo. Porque conclusões, nesta altura do campeonato, ainda são muito perigosas. E relativamente frágeis. Daí a quantidade de debates e embates que vemos por todo canto. De um lado, ainda vemos muita resistência em mudar (o que configura uma boa piada). De outro, muitas vezes, a falta de humildade para admitir que ainda estamos todos aprendendo.

    Por isso, caros AN’s (e GP’s), não é preciso ter medo do ‘monstrinho’ Ágil. Todo projeto seguirá apresentando necessidades e consequentes atividades, independentemente do processo, metodologia ou ‘modinha’ utilizada. Todo projeto seguirá tendo uma etapa onde definimos o que precisa ser feito. Assim como todo projeto seguirá precisando de líderes.

    O que não pode significar, de forma alguma, que você AN (ou GP) possa baixar a guarda e ignorar tendências fortes, verdadeiras, viáveis e inevitáveis como o Movimento Ágil. E o SEMAT (?). E o Flu? E 2012?? E o Flamengo e a Terezinha???

    Desconfianças (!)

    Foi um bom mineiro, Guimarães Rosa, quem disse: “Sei de nada não… Mas desconfio de muita coisa”. Quem dera eu tivesse as desconfianças do Rosa. As minhas, no assunto em questão, são:

    • Não vejo mais com bons olhos a alocação de um AN para desempenhar o papel de Dono do Produto. Cheguei a sugerir isso algumas vezes. Peço desculpas e retiro minha sugestão. O DP deve ser de fato uma pessoa do negócio (ou, em algumas situações, o Gerente do Projeto).
    • Em projetos guiados pelo Scrum, o AN deve fazer parte do Time do Dono do Produto. Em muitos projetos, bastará 1 (um) AN. Seu par, na maioria das atividades, será o próprio DP ou um integrante do Time.
    • Corpos de conhecimentos vão incorporar cada vez mais práticas ágeis. Não adiantará muita coisa se seus espíritos (Princípios) não forem seriamente questionados.
    • AN’s (e GP’s) que já se deparam com projetos ágeis ou desconfiam (ou desejam!) que eles estejam em seu horizonte próximo, deveriam priorizar o estudo de obras como aquelas listadas abaixo, em detrimento até mesmo do BABoK (por razões já explicadas aqui).
    • Opa, quase me esqueci. A resposta é: Sim, o Mundo Ágil precisa de Analista de Negócios.

    Bibliografia

    1. Agile Product Management with Scrum
      Roman Pichler. Addison-Wesley (2010).
      Obs.: Tomei por base uma versão preliminar do livro, um Rough Cut. Seu lançamento está previsto para 5/mar/10.
    2. Agile Project Management – Second Edition
      Jim Highsmith. Addison-Wesley (2010).
      Obs.: Já disponível.
    3. Scrum Product Ownership
      Bob Galen. Draft v1.3 (2009).
      Obs.: A versão final, independente, já está disponível via Lulu.

    Observações:

    A foto utilizada neste artigo, “Danger: Keep Clear“, é do PSD, surrupiada legalmente no Flickr porque liberada como Creative Commons (by).

    * A sugestão do termo “Pauta” como alternativa para “Product Backlog” deve ser creditada para o colega Leandro Mendonça. Muito obrigado, meu caro. Tenho testado o termo com um surpreendente índice de aceitação.

    ** Antes que me batam: O DP é o principal responsável pela entrega no sentido de que ele deve ser accountable (aah! palavrinha maldita). No popular: é o dele que estará na reta em caso de problemas com a entrega do projeto. Ok? Então guardem as facas, please!

  • O Problema com Harry*

    Harry era um coordenador de projetos. Vivia para resolver problemas. O último foi insolúvel: Harry bateu as botas; foi dessa para uma melhor; tá mortinho da silva. Ninguém percebeu ainda. Ele está em seu cubículo, silencioso como quase sempre. Debruçado sobre o teclado, parece dormir. A tela do micro exibe o gráfico Gantt que ele atualizava quando morreu.

    Jenifer apareceu para confirmar a reunião das 10. Notou que algo estava errado só na quarta vez que chamou Harry, tocando seu ombro. Pela temperatura do pescoço sacou que o cara estava realmente morto. Lembrou-se imediatamente da rodinha que se formou em torno da máquina de café logo após a reunião do dia anterior. Sentiu um frio na espinha quando recordou a jura que fez para meia dúzia de testemunhas: “Ainda mato esse $%&”. Deixou o cubículo se certificando de que ninguém havia reparado sua presença ali.

    Jenifer é analista de negócios. Os 5 meses e 18 dias de convívio com Harry foram, segundo suas próprias palavras, “um inferno”. Se arrependeu de ter sugerido a adoção de um modelo iterativo e incremental para o desenvolvimento do projeto. “Melhor seria ter ficado aqui apenas um mês, escrito do jeito que desse todos os casos de uso e me mandado para outro projeto”. Harry lhe roubou a ideia e fez um curso de 8 horas de ScrumMaster. Voltou com o certificado e algumas conclusões: “A ideia do Scrum é muito boa. Só não curti muito esse papo de ScrumMaster, Product Owner e coisa e tal. Vamos adotá-lo, mas eu seguirei sendo GP. E tenho dito!”

    Harry fazia questão de participar de todas as reuniões com o cliente. Jenifer funcionava mais como sua secretária do que como analista de negócios.

    TheTroubleWithHarry

    Arnie é um dos três programadores plenos (pero no mucho) alocados no projeto. Com espinhas no rosto e bonequinhos japoneses em sua mesa, vivia irritado com Harry. Reclamava do “clima opressivo” do projeto. Não suportava mais as 4 horas extras diárias e as manhãs de sábado trabalhando, coisa que Harry chamava de “esforcinho extra”. Algo que ele compensaria, dependendo do sucesso do projeto, “com uma bela feijoada no Bar Brahma. Por minha conta!”, prometia o falecido.

    Arnie nunca manifestava suas opiniões para o coordenador – tremia de medo dele. Aos pares sempre acusava as sugestões “malucas” e o risível domínio técnico de Harry: “O cara sabe de Java tanto quanto eu manjo de culinária peruana”. As piadinhas de Arnie nunca mereciam uma risada espontânea, mas todos os programadores concordavam com suas críticas.

    Passou pelo cubículo do Harry para perguntar, pela terceira vez, se a data de encerramento da iteração realmente mudaria. Todo mundo achava aquilo uma loucura e Harry nunca era conclusivo. A verdade é que nenhuma iteração até aquele momento havia respeitado o plano original (que previa ciclos de 30 dias). Arnie tremeu muito quando percebeu que seu silencioso interlocutor estava mortinho. Agachou e elaborou 100 planos para escafeder-se sem ser notado. Saiu engatinhando e entrou no cubículo ao lado, da gata Jenifer, simulando a busca pela lente de contato que ele nunca usou. Nem notou as cruzadas pernas torneadas de tão nervoso que estava.

    Eis que chega o Capitão, bufando. É o gerente da área comercial e já avisou que não toleraria mais reclamações do cliente. Esperava desde a noite anterior por uma versão atualizada do arquivo do ‘project’. O cliente falou que não pagaria mais nenhuma parcela se não visse uma “evolução” do projeto. Harry e Capitão acordaram que o envio do ‘project’ talvez funcionasse como calmante. Não sem antes discutirem, por 3 horas e 17 minutos, sobre os problemas do projeto. Harry dizia que o cliente não sabia o que queria. E reclamava que sua equipe era muito “júnior”. Capitão, entre um tapa e um murro na mesa, lembrava que nunca vira, em 30 anos de carreira, um projeto de software sem problemas. No ápice do papo, lá pelas 8 da noite, gritou para quem quisesse ouvir: “Se esse projeto não der lucro eu te mato, safado!”

    Boa parte da remuneração do Capitão vinha de um naco do lucro de cada projeto comercializado. Ou seja, há tempos ele vivia com a corda no pescoço, contas penduradas e um salário mínimo. A empresa resolveu que comissões ‘normais’ estavam apenas contribuindo para o aumento do prejuízo dos projetos. E concluiu que a participação nos lucros incentivaria maior colaboração da área comercial nos projetos, “gerenciando relacionamentos. Afinal, esses técnicos são muito ruins de papo”. Capitão bufou, acatou e enviou o currículo atualizado para 47 empresas.

    Capitão gritou uma, duas, três vezes. “Não é possível que agora esse @#$ resolveu dormir aqui!”. Com um safanão fez a cadeira girar, o que mostrou meia face do pobre coitado e morto Harry. O olho esbugalhado dizia tudo.

    Jenifer e Arnie aproveitaram o escândalo para dar e livrar suas caras: “Capitão, você matou o Harry?” A pergunta saiu em uníssono e em volume suficiente para ser ouvida em todo o andar. Logo estavam todos ali, pescoços sobre as divisórias do cubículo, rostos de espanto e comentários inteligentes sem champanhe nem cicuta. “Jura? O Capitão matou o Harry?”

    Ninguém gostava do Harry. “Mas matar o cara! Meldels… onde vamos parar?” As meninas choravam um choro nervoso. Os rapazes, com seus modernos celulares, espalhavam a nova para toda a agenda de contatos. Ninguém sabia o que fazer. Capitão estava estático, catatônico, com cara de bobo. Jenifer e Arnie ainda o fitavam, acusadores e aliviados.

    O ramal do Harry tocou. Identificador de chamadas: “Amorzinho”. Todos que estavam próximos trocaram olhares, esperando que um herói tomasse a iniciativa de atender ao chamado. Ninguém teve coragem e depois do 13º toque o telefone silenciou. Para tocar de novo 30 segundos depois. Identificador de chamadas: “Esse cara não tem mãe”.

    “Xi… agora é o freguês”, disse alguém.

    Capitão atendeu, mandando bala: “Ô Xerife, você sabe que mora eu meu coração, não?”. Silêncio constrangedor de dois minutos e meio. Todos sacaram que o Xerife, o cliente, desfilava seu repertório de impropérios nos acostumados ouvidos do Capitão. Do nada, o gerente comercial resolveu mudar o rumo da conversa: “Querido, por favor, me diz uma coisa: você mandou matar o Harry? Porque, veja bem, se foi você, eu gostaria que você soubesse que todos aqui consideraram a decisão mais acertada para que finalmente a gente possa estar providenciando a otimização de nosso processo orientado ao…” tum, tum, tum…

    Epílogo

    Foi no velório que todos ficaram sabendo que Harry não foi assassinado. Sofreu uma parada cardíaca fulminante. “Também”, disse Jenifer, “o cara se alimentava mal e não fazia exercício nenhum! Não aguentava um lance de escadas”. Arnie lembrou que havia dois meses que Harry parou de fumar: “Não adiantou nada.” “Pudera, o cara tava mascando 60 chicletes de nicotina por dia!”, assuntou outro. Capitão consolava o Amorzinho dizendo que Harry era o melhor coordenador de projetos que ele conheceu em 30 anos de carreira. “Pena que não suportou a pressão”.

    E Harry não conseguiu o que queria quando veio para a “Top Down**”, com o diabo ter. Ele queria era falar pro Presidente pra montar um PMO e ajudar toda essa gente que só faz sofrer…

    .:.

    * O drama acima foi levemente inspirado num dos melhores filmes pouco conhecidos do Mestre Hitchcock, “The Trouble with Harry” (1955), que aqui em Pindorama é tratado como “O Terceiro Tiro”. As imagens utilizadas neste artigo foram indevidamente surrupiadas da Internet.

    ** A “Top Down” é uma software house de última geração fincada no meio do potencial vale do silício tupiniquim, leia-se Vale do Anhangabaú. Sediará outros dramas, com certeza. Infelizmente, sem nosso querido Harry.

    Atualização em 3/Fev/10: As três batidas na madeira, dadas abaixo, não adiantaram muito. Eu deveria ter verificado anteriormente a coincidência com nomes, principalmente com a empresa. É preciso dizer que a Top Down do artigo acima, agora definitivamente fechada, não tem nada a ver com a empresa homônima sediada no Rio de Janeiro. Foi uma infeliz coincidência mesmo. E pelo meu descuido peço desculpas. Agora vou ter que inventar um novo nome para as futuras aventuras da trupe desenvolvedora.

    Lembrete: salvo engano, ontem foi o Dia dos Gerentes de Projetos. Eu não ia homenagear-nos (ainda me considero um) com um artigo sobre as “maravilhas” da última versão do PMBoK, né? Fica para uma data mais propícia (ou menos perigosa).

    Aviso: a história acima é pura ficção e bobagem. Qualquer semelhança com fatos, empresas ou pessoas de verdade deve ser mera coincidência. (3 batidas na madeira)

  • Fred Brooks no Brasil

    Minha caixa postal amanheceu repleta de mensagens de amigos avisando: Brooks estará no Brasil na próxima quarta-feira, 21/out! A preocupação dos colegas tem uma única explicação: eles sabem que sou fanzaço do cara. Não só de sua obra prima, “O Mítico Homem-Mês” (lançada originalmente em 1975 e finalmente disponibilizada em PT-br), mas também de seus artigos que seguiram, particularmente “No Silver Bullet” (1987. Este e outros artigos aparecem na edição do livro lançada pela Elsevier-Campus).

    Seguem os convites:

    Se você quiser entender um pouquinho mais a importância do cara, veja a série de artigos que publiquei aqui no finito em 2006. Se gostar, não deixe de comprar o livro. Se comprar o livro, lembre-se de uma provocação do Brooks:

    Eles falam que o livro é a Bíblia da Engenharia de Software… é por isso que todo mundo o lê mas ninguém o usa!

    A gente se vê num dos dois eventos acima. Inté!

  • Estereotipinhos

    Existem usuários e usuários. Quem convive com eles sabe que cada um tem suas peculiaridades – suas necessidades e desejos, suas reclamações e chororôs, seus jeitos e manias, seus tiques e chiliques. Mas isso não nos impede de identificar e traçar alguns padrões, perfis, estereótipos e… Estereotipinhos!

    O analista de negócios mais esperto sabe que não pode colocar a mão no fogo por todos os requisitos que aprende. E as melhores pistas que ele tem para não se queimar são o jeitão e a postura dos usuários. Não, o analista não precisa virar o Doutor Cal Lightman (personagem de Tim Roth na série “Lie to Me”) – um cara que percebe mentiras e outras coisas simplesmente observando seus interlocutores.  Mas atenção e canja de galinha não matam projeto nenhum, certo?

    Este artigo não é (muito) sério. Ele pretende apenas apresentar alguns perfis de usuários que costumam criar probleminhas em projetos. E dar algumas sugestões para que os analistas evitem maiores acidentes.

    .:.

    Caetano

    CaetanoO usuário Caetano é carente. Passa eras esquecido em seu departamento Trancoso. A cada bimestre ele tenta receber um pouco de atenção, naquelas enfadonhas e inúteis reuniões com todo o escalão intermediário. Caetano só lida com processos de apoio (leia-se Despesas). Então só merece atenção quando a realização de seu backlog é uma obrigação. De vez em quando acontece. E lá vai o analista ouvir tudo o que o Caetano precisa.

    Caetano fala devagar, mas não para de falar. Parece que não precisa da pausa para respirar. E fala, fala e fala. Pede uma coisa, reclama de outras duas. Pede duas coisas, reclama de alguém genérico. Caetano adora abstrações e picuínhas. E mistura tudo em 45 minutos de um monólogo muito chato. Quando se aproxima dos ‘finalmentes’, Caetano desacelera: “Como vou saber o que estou pensando se não ouvir o que estou falando?” Suas frases ficam mais curtas e cada vez mais lentas. Até que há um intervalo que dura entre 5 e 10 segundos. Aí, num moroso (de) repente, Caetano condena toda a sessão de desenvolvimento de requisitos com apenas duas palavrinhas: “Ou não”.

    Ao analista resta: respirar fundo e ter muita paciência. Caetano é carente e acha que TI nunca lhe dá atenção (o que é a pura verdade). Suas demandas nunca são prioritárias. O analista deve evitar interromper o monólogo, para não correr o risco de ter um Caetano nervoso e irritado. E deve tentar entender o “ou não”, por impossível que isso pareça.

    Glória

    GloriaAh, a usuária Glória – uma novelista nata. Adora contar histórias (no meio de uma sessão de desenvolvimento de requisitos). Não, não o tipo de história que agradaria agilistas. Suas histórias são muito longas, verdadeiros épicos. E intrincadas demais. Glória normalmente comanda um departamento “global” – atinge todo mundo. RH, financeiro ou algo do tipo. Parece que todos na empresa gostam da Glória. Alguns por obrigação. Mas seu Ibope é alto: ela é realmente muito simpática. Calorosa até na hora de expressar seus requisitos.

    Glória complica demais e é voluntariosa. Aprendeu e ensina que tem mais valor aquele profissional que não se limita a reportar problemas. Ela adora apresentar soluções. Praticamente cada requisito que ela pede já vem acompanhado da solução ideal. Mas suas soluções, quando não são ingênuas demais (“Nossa, mas colocar esse campinho na tela é tão fácil!”), são nonsense de tão complexas  (“Então vamos colocar a Deborah numa caixa de papelão e entregá-la, como que por acidente, na casa do galã da novela”).

    Pobre analista: você deve ser muito sutil ao pedir para a Glória que ela se limite a dizer “o que ela precisa”. Explique, gentilmente, que o “como” é responsabilidade de outra patota, outra plateia. Diga que, se for o caso, ela pode até participar das sessões de brainstorming que definirão a melhor solução. A equipe técnica o odiará por isso. Ninguém se esquece que Glória já derrubou coordenadores, arquitetos e até diretores no passado.

    Azevedo

    AzevedoAzevedo é um usuário azedo. Para ele, tudo e todos estão sempre errados. E ai de quem discordar. Azevedo vive colado no alto escalão – tem “moral”.  Apesar de seu job description não formalizar e ninguém pedir, Azevedo sempre se mete nos temas estratégicos da empresa. E parece ter resposta para tudo. Ele é muito culto, um intelectual de chapéu panamá. E gosta de exibir a riqueza de seu vocabulário quando expressa seus requisitos.

    Azevedo detesta ser entrevistado – particularmente para o desenvolvimento de requisitos. Ele não fala, mas indica que os entrevistadores nunca estão a sua altura. Ele gostaria mesmo é de ser entrevistado pelo diretor de TI, CIO ou equivalentes. Como isso nunca é possível, ele prefere mandar os requisitos por escrito. O analista também ficaria satisfeito com isso, se ele não soubesse que nada substitui o contato cara a cara. Enfrentar o chato do Azevedo é inevitável.

    Ilustríssimo analista: acalente-se. Todo ofício tem seus ossos. E toda empresa tem seus azevedos. Evite o confronto porque ele só será resolvido em outra instância. Ou seja, *nunca* discorde do Azevedo. Mas também não precisa baixar a cabeça para ele. Registre com capricho os requisitos. Não pule nenhuma etapa da cerimônia que o Azevedo eventualmente exigir. E torça para que esses encontros sejam breves.

    Dunga

    DungaMuitos analistas gostariam que o usuário Dunga fosse aquele amiguinho da Branca de Neve – quietinho e muito bonzinho. Não é. Dunga é um ranheta – vive zangado e enfesado. Mas é diferente do Azevedo. Dunga é paranóico, tem mania de perseguição. Acha que todo mundo quer derrubá-lo (o que nem sempre é mentira). Mas Dunga é muito importante para a empresa. Como mostra resultados, não será fácil tirá-lo de lá. E Dunga sempre tem muitos requisitos para apresentar.

    Requisitos do tipo “desconfiado”. Dunga costuma pedir um monte de coisa que só sua paranóia justifica: dezenas de senhas, centenas de relatórios. E lê nas entrelinhas de cada pergunta do analista alguma crítica ou complô. Dunga não tem paciência nenhuma. Nem os modos educados do Azevedo. Dunga esbraveja e, em situações extremas, usa até palavras que não podem ser publicadas neste espaço. Dunga mete medo. Em seus adversários e, infelizmente…

    … nos tristes analistas: que ouvem desaforos que não merecem. É muito importante manter a calma e a compostura. Faça o Dunga entender que você, prezado analista, é apenas o mensageiro. E está ali só para entender as necessidades dele. Mas não tente ganhar o raivoso com elogios ou mimos. O paranóico verá indícios de conspiração até nisso. Demonstre isenção, imparcialidade. Mas sinta-se a vontade para interromper uma entrevista toda vez que o Dunga passar dos limites. Afinal, ninguém merece chilique de gente mal educada, né?

    Outras Figurinhas

    O espaço é curto e o elenco de estereotipinhos é quase infinito. Listo abaixo outras figurinhas relativamente comuns que, dependendo do projeto, podem ser tão ou mais perigosas que os colegas apresentados acima:

    • Mikaela: usuária um tanto lenta e sem um pingo de autonomia. Seu chefe, sem tempo para nada, sempre a joga nessa enrascada: passar os requisitos para o chato do analista. O problema é que ela não sabe nada e decide menos ainda. Analistas: peguem o chefe no corredor ou elevador. Rende mais.
    • Maikol: usuário que não acerta uma! 90% de seus requisitos são falsos. Os outros 10% não têm valor nenhum. Não é má vontade, pelo contrário: é excesso de vontade. E muita falta de conhecimento. Analistas: confirmem de alguma forma os pedidos do Maikol antes de passá-los adiante. Mas tentem não queimar o cara, ok? Ele é gente fina.
    • Maike: é um super-usuário, curioso e fuçador que nem te conto. É pior que a Glória na hora de propor soluções, porque ele realmente acha que sabe tudo sobre .Net, Java, SQL e o ângulo correto para colocação da rebimboca da parafuseta. Maike é um destruidor de soluções e um martírio para analistas de negócios. Analista: coloque seu melhor técnico para baixar a bola desse cara. Senão você está perdido.
    • Mikey: é o engraçadinho da turma, faz piada com tudo e todos. Requisito-piada? Pois é, existe. E é sempre de mau gosto. Mas esses caras têm sua utilidade quando um workshop de requisitos está carrancudo demais. Mas é bom não dar muita trela. Senão eles roubam a festa (e o seu precioso tempo).
    • Mixel: é uma figura, um fenômeno. Excelente funcionário e amigo de todo mundo. O problema é que ele vive se metendo em confusões. Em projetos, suas trapalhadas aparecem mais aos 45 do segundo tempo, quando apresentado para uma solução: “Nossa, eu pensei que não tivesse nada disso. Eu queria outra coisa!”

    .:.

    Observação: Os usuários serão vingados! Qualquer dia publico “Estereotipinhos (do outro lado)”. Garanto que eles são piores que o pior usuário que conhecemos.

  • Crise no Mundo Ágil. Que Crise?

    Sabe aquela sua colega que parece ser a única num raio de 500km que conhece e gosta de uma obscura banda de rock belga? Lembra-se como ela se revoltou e desgostou quando a banda assinou contrato com uma grande gravadora? É o mesmo caso daquele amigo que era fanzaço de um diretor de cinema chinês, mas desistiu da idolatria quando o cara resolveu fazer um filme em Hollywood: “O cara se vendeu”. Todos conhecemos gente assim, que gosta de coisas muito diferentes, distantes do universo pop(ular). Pessoas que se sentem traídas quando seus modelos ou ídolos tentam falar para um público maior, tentam atingir mais pessoas.

    Desconfio que algo muito parecido esteja acontecendo agora, naquele universo que surgiu após o big-bang do Manifesto Ágil. Dois excelentes artigos, de José Paulo Papo e Rodrigo Yoshima, ajudaram a alimentar minhas suspeitas. Além de um bate papo bem legal que rolou sobre a possível morte do RUP (Rational Unified Process) no grupo UML-BR.

    O Yoshima está certo: RUP e Agile compartilham hoje uma mesma tendência. Mas seria a de morrer? Márcio Tierno, o MT, fez um diagnóstico diferente ao falar especificamente sobre o estado atual do RUP:

    Acho que o RUP, pior do que estar morto, entrou para o mainstream. Hoje um cliente ou usa um processo waterfall ou usa um processo *pretensamente* baseado no RUP.

    E entrar para o mainstream significa ter sua evolução freada. Ninguém entendia direito o RUP. Poucos dos que o “adotaram” em suas empresas se deram ao trabalho de ler a última versão e entender. Os “metodologistas” das empresas sempre gostaram do RUP exclusivamente pelos artefatos, pela sensação de controle e pelo tamanho. Jamais pela iteratividade.

    Surrupiei do Google Trends alguns dados que de certa maneira confirmam as palavras do MT e solidificam minhas suspeitas. Veja os gráficos abaixo:

    Tendências para RUP, Agile e Scrum no mundo

    Tendências só no Brasil

    Azul = RUP | Vermelho = Agile | Laranja = Scrum

    O primeiro gráfico abrange o mundo todo. O segundo levou em consideração apenas as buscas e notícias realizadas no Brasil. O Google Trends faz exatamente isso: mostra a quantidade de buscas pelos termos. Não pode ser considerado ao pé da letra, afinal Scrum e Agile significam outras coisas para outras pessoas. O que não tira totalmente o valor do indicativo de tendências.

    E o que os gráficos nos mostram? Uma queda constante porém gradual no interesse pelo RUP e um crescimento vertiginoso nas buscas pelo termo “agile”, particularmente aqui no Brasil. Seria isso um indicativo de morte? Só para aqueles que, como os fãs de bandas e diretores obscuros, gostariam de permanecer num grupo pequeno e muito restrito.

    Eu entendo e compartilho o que acredito que sejam as principais preocupações do MT e do Yoshima. Ao se transformarem em artigos pop – ou “carne de vaca”, para usar um termo bem nosso – RUP e Agile saem do controle. Do nosso controle. E não serão poucos os que irão distorcer, desfigurar e desmontar os valores e princípios que caracterizam e definem essas propostas. Aliás, preciso confessar, eu sou um deles. Tanto que já fui criticado, aqui mesmo no finito, por chamar de “bullshitagenzinhas ágeis” algumas das práticas sugeridas. Falei de práticas, não de princípios e valores. Mas isso não importa. O que importa aqui é saber se é mesmo o caso de decretar a morte do RUP ou do Agile.

    Se o RUP é muito mal utilizado, e de fato é, boa parte da culpa é dos seus criadores e evangelistas. Já mostrei por aqui como o RUP foi uma verdadeira metamorfose ambulante desde o seu lançamento. Alteraram sem pudor seus princípios, causando confusão. O artigo do José Papo mostra que agora a versão 7.5 tem um “Agile Core”. Não estou dizendo que o RUP não deveria evoluir. Estou afirmando que a evolução foi mal conduzida (parece improviso) e muito mal comunicada. O que não isenta, claro, os cabeças de pamonha que fizeram dele uma cascata iluminada.

    O universo Agile pode e vai sofrer com problemas semelhantes. Cabeças de pamonha estão longe da extinção. Mas o caso aqui é diferente. Os valores e os princípios consolidados no Agile Manifesto permanecem os mesmos desde o dia 13 de fevereiro de 2001. E eles não sofrem com um dono nem com as pressões comerciais que este faria.

    Esqueçamos por alguns minutos os Pamonhas e suas cascatas e contratos a preço fechado. Cabe aqui uma autocrítica por todos aqueles que defendem o manifesto:

    • Será que estamos sendo didáticos o suficiente?
    • Não somos impacientes demais para explicar, por exemplo, por que uma iteração não é uma mini-cascata?
    • Será que, ao invés de explicar, não estamos detonando demais o “outro lado”. Vide meu termo acima: Pamonha!
    • Não estamos sendo religiosos e puristas demais?

    Meu maior temor é que os agilistas de hoje se comportem como os cascateiros de ontem. Não concordo com o MT quando ele diz que “mainstream significa evolução freada”. Oras, se no contexto de um projeto estimulamos (ou forçamos) a participação de todos, exatamente para gerar mais ideias e inovações, por que numa escala maior esta mesma prática seria nociva – por que ela geraria o efeito contrário?

    Se de fato nós acreditamos que RUP e Agile são as respostas para melhores projetos, não faz o menor sentido o medo de que essas propostas se transformem em suculentas “carnes de vaca”. Ou nós queremos seguir como os raros fãs de obras cult que ninguém conhece?

    .:.

    A foto utilizada neste artigo, “We Love Crisis”, é de Daquella Manera (Daniel Lobo), fotógrafo profissional que disponibiliza alguns de seus trabalhos como Domínio Público.

  • Pistas & Palpites – O Resultado da Pesquisa

    A pesquisa que disparei 15 dias atrás só permite concluir uma coisa: nosso povo não gosta muito desse tipo de coisa. Coloquei uma meta muito modesta: 150 participantes. Consegui apenas 131. Entendo que é uma amostra muito pequena, que não permite conclusões. Mas dá boas pistas. E possibilita a elaboração de alguns palpites.

    O pessoal que define “o que  precisa ser feito”, os analistas de negócios, empatou com a turma do “como será feito”, os analistas de sistemas. 22% de participação de cada um. Em segundo lugar vieram os coordenadores de projetos, com 15% das respostas. Desenvolvedores e analistas de processos aparecem com 10% e 9%, respectivamente. De curioso aqui nosso coringa, que disse ser analista de negócios, de sistemas, de requisitos, desenvolvedor e arquiteto! Será que o salário é compatível com tantas responsabilidades?

    Um participante cobrou, não perguntei sobre rendimentos. Falha minha. Não sei se por sorte ou azar, no mesmo período, a revista Você SA da Abril liberou uma pesquisa sobre o assunto. Cobre mais de 130 profissões, sendo 14 específicas da área de TI. Vou destacar aqui apenas um ponto: analistas de sistemas ou analistas-programadores (chamados naquela publicação de analistas de desenvolvimento) ganham praticamente a mesma coisa que analistas de negócios. Até os 5 anos de experiência. Depois disso, mostra a pesquisa, os analistas de negócios apresentam salários consideravelmente maiores. A diferença chegaria a R$ 5 mil entre profissionais com mais de 15 anos de experiência. Nesta faixa de tempo de estrada, o salário de analistas de negócios em pequenas e médias empresas seria maior até do que dos gerentes de projetos. Estranhei muito o número, mas não tenho como questioná-lo. A empresa que executou a pesquisa, a Robert Half, fez mais de 30 mil entrevistas. É uma pena que tenha se limitado aos mercados de São Paulo e Rio de Janeiro.

    São Paulo de fato concentra a grande maioria das vagas. Em minha pesquisa, 58% dos participantes são de lá. Rio, Santa Catarina e Minas aparecerem na sequência, com quase 10% cada um. Profissionais do sexo masculino também confirmam outro tipo de concentração: são 81%, contra 19% de mulheres. 70% dos participantes têm idade entre 23 e 34 anos. Com mais de 40 tivemos 11%. Curiosidades: 44% disseram se apresentar como “Sêniores”, contra 39% que são “plenos (ocasionalmente vendidos como sêniores)”; 5% estão “loucos(as) para mudar de profissão”.

    Mais da metade dos participantes, 57%, trabalha em empresas de TI. 30% em serviços de desenvolvimento e manutenção de sistemas. A maioria, 28%, conta com mais de 100 profissionais na área de TI. Mas, que espanto, 48% de todas as empresas contam apenas com algo entre 1 e 5 profissionais trabalhando com análise de negócios. Na questão eu ainda tive a preocupação de especificar que seria qualquer profissional que executasse: modelagem de negócios, modelagem de processos, desenvolvimento de requisitos etc. O desequilíbrio parece ser muito grande.

    Sobre Projetos

    Repetiu-se neste levantamento um número que tem cara de “default”: 62% dos projetos têm algum tipo de problema. 21% seriam “muito mal sucedidos (muito atrasados e gerando prejuízos)”. Para dizer a verdade, o número até que é um pouquinho melhor do que aqueles que vemos em outros lugares. Mas ainda é muito comprometedor.

    Nada de novo também no front dos principais problemas: mudanças de requisitos (18%), requisitos mal definidos (17%) e mudanças de regras de negócios (13%) são os principais. Pouco envolvimento de clientes e usuários, metodologia mal aplicada e equipe mal preparada respondem por 9% cada um.

    61% das empresas estão cientes dos problemas e tomando providências. As principais seriam: treinamento da equipe (31%), implantação de novas tecnologias e ferramentas (23%), implantação de nova metodologia (21%).

    E quais metodologias, processos ou padrões são utilizados? Algumas surpresas: PMBoK (23%), Scrum (18%), RUP (16%), CMMI (10%) e XisPê (8%) são os destaques. Fiquei com pulgas atrás do orelhão: com tanto Scrum, como ninguém se apresentou como ScrumMaster ou Product Owner? O número do RUP também surpreendeu.

    O que não surpreende é que 71% ainda utilizem editores de texto para tarefas de descoberta, descrição e gerenciamento de requisitos. E 61% depositem suas esperanças em planilhas eletrônicas. A relação não fica explícita, mas tenho certeza que essas ferramentas colaboram diretamente com os problemas listados acima.

    Mas 68% utilizam especificações de casos de uso. Parece um bom sinal. Mas o número não bate com os levantamentos informais que faço em meus eventos. Será que estão falando de casos de uso de verdade, ou daquelas extensas descrições de telas e de como a solução deve ser construída? Infelizmente seguirei sem resposta. Mas desconfiado de que estamos falando de casos diferentes.

    Perguntei se praticavam a modelagem de negócios. 38% disseram que sim, “e percebem o valor dela”. 35% disseram que praticam, mas “só um pouquinho”. 73% praticam a modelagem de negócios?!? Outro número que não bate de forma alguma com o que vejo nos eventos e empresas. Ainda mais com 59% dizendo utilizar a UML para tal. Para se ter uma ideia, são 23% aqueles que utilizam a BPMN. Pouco mais que os 20% que já estariam utilizando o método do “Pensamento Visual”.

    Uai cara pálida: você faz uma pesquisa para depois questionar os números obtidos? Entendam, por favor: a culpa é da pesquisa e do número de respostas. Minha críticas acima servem apenas para destacar pontos da pesquisa que parecem estar bastante distorcidos. E uma das causas das distorções é óbvia e também foi levantada: 55% de quem participou da pesquisa já participou de algum evento FAN.

    Mas, de qualquer maneira, pistas e palpites podem ser observados e colocados. Resta esperar que futuras iniciativas como esta sejam melhor elaboradas e mereçam um número bem maior de participantes. Aos que aceitaram meu convite e doaram preciosos minutos, registro aqui meu muito obrigado. E boa sorte no sorteio!

    .:.

    A foto utilizada acima, “Torcedor Solitário“, foi devidamente surrupiada do Rodrigo Moraes.