Duas notícias recentes levantam críticas sobre o uso dos tradicionais e estabelecidos modelos de gerência de projetos, programas e portfólios do renomado instituto PMI.

1. O Gartner Group fez críticas duras à falta de aplicabilidade destes corpos de conhecimento para TI devido especialmente à sua superficilialidade em diversos pontos (sic). A notícia completa e uma análise desta polêmica esta aqui na portal da SearchCIO. Compilo aqui uma frase do diretor de pesquisa do Gartner Group, Michael Hanford - “Their portfolio management standard shows a solid understanding of a complex discipline, but I’d say it disappoints with an uneven level of explanations“.

2. O SCRUM tem sido adotado mundialmente em cada vez mais empresas no Brasil e no exterior. Uma interessante reportagem do uso do SCRUM em empresas fora do âmbito de TI está disponível aqui. Aparentemente, o SCRUM se adapta melhor a empresas com realidades dinâmicas e ágeis e segue a escola de gerenciamento ágil que também tem sido fomentada pela IBM em sua melhor prática denominada Two Level Planning.

Pensamento do dia: “It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.”, Charles Darwin

John Rambo é um veterano do exército americano. Inicialmente ignorado pela corporação, ele é sempre chamado para resolver situações fora de contorle. Com uma faca na mão e uma metralhadora na outra, ele mata facilmente todos os inimigos e volta com a missão cumprida para casa. No cinema, pelo menos, é assim.

João Nerd é um veterano Brasileiro em projetos de desenvolvimento de software. Os seus conselhos técnicos são ignorados pela gerência de projeto no começo do projeto. Quando o projeto foge ao controle, entretanto, ele é chamado. Com uma IDE na mão e a especificação de requisitos na outra, ele deve resolver todos os erros complexos, reorganizar a arquitetura interna do sistema, desenvolver os casos de uso atrasados, trabalhar como bombeiro, estar presente nos finais de semana e salvar o projeto. Na vida real de TI, infelizmente, é assim.

Nas empresas de TI, por incrível que pareça, vemos gerentes que tratam seus analistas desenvolvedores como hérois do cinema. Eles os chamam de “Guerreiros” e deles esperam atitudes heróicas para salvar projetos em crises. Exemplos de atitudes heróicas incluem:

• Execução sem planejamento. “Faça de qualquer jeito. Se não funcionar, jogamos o código fora e pensamos em outra forma de resolve o problema.”.
• Internalização dos problemas. Por falta de gestão de riscos e medo de negociar com os clientes, gerentes internalizam os problemas e os deixam a mercê da equipe técnica.
• Horas extras voluntárias.
• Horas extras não pagas. Também conhecidas como “horas bestas”.

O anti-padrão “Heroics” é catalogado como um dos “Classic Mistakes” (Erros Clássicos) no excelente livro Rapid Development”, de Steve McConnell. Em sua análise, McConnell destaca que este padrão é muitas vezes provocado pela atitude gerencial “Pode Fazer”, ao invés da atitude correta “Meça consistente o progresso da equipe através de relatórios de status”. Ao enfatizar demasiadamente a atitude “Pode fazer”, grandes problemas são mascarados até que se tornem desastres. Gerentes perdem, portanto, uma valiosa oportunidade de tomar ações corretivas nas fases iniciais de projeto devido à ênfase em heróismo das equipes de TI.

Outros erros clássicos de TI são enumerados no site de Steve McConneli. O livro citado acima e cuja imagem está abaixo traz excelentes dicas de como evitá-los e bater cronogramas complexos de projetos. Leitura indispensável para líderes técnicos e gerentes de projeto.

Li recentemente um artigo que propõe um tema interessante ao discutir a personalidade de arquitetos de software e gerentes de projeto e a sua relação (normalmente tensa) em projetos de software. (The Tense Relation between Architect and Manager, Gerrit Muller).

Arquitetos e gerentes são peças fundamentais para o sucesso de um projeto e devem interagir fortemente em sinergia, como já apontado por Grady Booch em seu excelente livro Object Solutions, de 1995.

Um aspecto que Gerrit Muller endereça são os comportamentos associados a cada papel. Um resumo destas características é colocado abaixo:

• Arquitetos tem um escopo amplo em projeto e pouca autoridade formal. Gerentes, por sua vez, tem um escopo de atuação mais limitado e possuem muita autoridade formal.
• Arquitetos são independentes, criativos e curiosos. Gerentes são pragmáticos e focados em controles.
• Arquitetos encaram mudanças; vindas dos stakeholders, pressões de tempo e análise de problemas; como fatos da vida. Gerentes encaram mudanças como possíveis fontes de problemas e desvios financeiros.
• Arquitetos são motivados pela busca das melhores soluções. Gerentes são motivados por hierarquias e salários.

O autor coloca, finalmente, que arquitetos e gerentes devem buscar, conjuntamente, as seguintes técnicas para a melhoria do relacionamento e resolução destes problemas:

• Maior delegação de tarefas.
• Liderança ao invés de gerenciamento baseado em tarefas.
• Trabalho em time.
• Respeito mútuo.
• Reconhecimento da diversidade.
• Feedbacks contínuos.
• Estímulo à uma comunicação aberta e franca.

Recentemente, escrevi uma compilação de características de liderança de arquitetos de software, inspirados nos comportamentos de liderança descritos por Stephen Covey. Acredito que estas características podem ajudar a resolver este problema e promover como conseqüência maior sucesso aos projetos.

Creio que o maior valor do interessante artigo do Gerrit Muller é tornar claro que arquitetos e gerentes possuem sistemas de crenças e visões de mundo diferentes. Arquitetos e gerentes não podem cometer o erro de assumir que a outra parte irá pensar e agir como ele. Ao invés, gerentes e arquitetos devem conhecer a natureza da outra parte e desenvolver mecanismos pró-ativos para melhorar a comunicação e alinhamento nos projetos.

Toda a nossa escola de gerência de projetos tradicional vêm da escolha de gerência de projetos da engenharia. Como exemplo, cito o PMI, talvez a escola mais difundida e aceita de gerenciamento de projetos de TI no Brasil e EUA. O PMI foi criado ainda no final dos anos 60 e seus membros iniciais eram pessoas de engenharia civil. Na escola de engenharia, o paradigma de planejamento detalhado e acompanhamento minuncioso deste planejamento é o modelo mental ainda usado no nosso seculo XXI.

Na área de TI, copiamos este modelo e também as ferramentas (como o Project ou o Primavera). Entretanto, algo parece errado. Quantos projetos eu já acompanhei (como participante, observador ou como executor do cronograma) onde a nossa inabilidade de montar e seguir um plano detalhado foi tornada aparente (e frustante). Várias vezes me questionei - “Algo está errado, mas não sei muito bem o quê”.

Felizmente, parecem existir evidências fortes que estamos usando o modelo errado para atacar um problema comum em TI, que é como gerenciar projetos e obter sucesso.

Gostaria de compartilhar um artigo que li na IEEE, de um autor de renome (Walker Royce) na área de gerenciamento de projetos e que lança luz neste tema - Successful software management style: Steering and balance. Embora controverso, devemos realizar algumas análises sobre a essência de projetos de software. Projetos de software, de forma geral, possuem as seguintes características (identificadas por Walker Royce):

• Não existem leis físicas ou de propriedades de materiais para restringir as soluções aos seus problemas. A restrição está na imaginação humana, restrições econômicas e desempenho da plataforma física que hospedará o software. Sistemas embutidos, obviamente, são excecões.
• Tudo pode ser mudado em um projeto de software - planos, pessoas, financiamentos, marcos, requisitos, desenhos e testes. Praticamente tudo é negociável.
• Métricas e medidas para produtos de software normalmente são melhor avaliadas através de modelo de valor percebido pelo usuário do que modelos clássicos de engenharia como custo e produção. Aspectos de qualidade são muitas vezes subjetivos como por exemplo manutenabilidade, confiabilidade e usabilidade.

Concordo em linhas gerais como esta análise. Uma outra força neste aspecto é o tempo de vida de uma arquitetura de software. Em um recente artigo na InfoQ, Sadek Drobi conjectura que uma arquitetura expira em dez anos - “Architecture Life Span:Implications on Business and how to build more Long-lasting Architecture“. Após este período, as manutenções se tornam cada vez mais caras e o sistema deve ser refatorado em uma nova arquitetura, sob o risco de gerar cada vez mais prejuízos para o negócio. Esta força mostra como a inventidade humana e inovações dificultam a aplicação de leis comuns em engenharia civil como por exemplo “Fazer para durar”.

A conclusão, que eu concordo, é que a melhor metáfora para a construção de softwares é a concepção de um filme. Precisamos, como apontado por Walker Royce, de arquitetos qualificados (diretores), analistas (roteiristas), engenheiros de software (equipe de produção, atores, editores, dublês) e gerentes de projeto (produtores). Entretanto, a metáfora técnica é que a disciplina de gerência de projetos é regida pela disciplina software economics ao invés da disciplina de software engineering. As decisões diárias de gerentes de projetos de software são dominadas por julgamentos de valor, relações de custo benefício, fatores humanos, tendências macro-econômicas, forças de mercado e pressões gigantescas de tempo. A escola de Software Economics, que tem como um de seus mentores Barry Boehm, pode ser definida como a escola científica de desenho de software fundamentada em modelos formais de valores e criação de valores em condições de incerteza, informações incompletas e competição.

O planejamento iterativo (ou planejamento em duas fases) no processo unificado é um escolha de gerência de projetos muito mais adaptável a esta realidade. O planejamento iterativo define planos em alto nível para as etapas de um projeto e somente realiza o planejamento detalhado para a etapa atual. Neste contexto, podemos incluir o SCRUM aqui também. O SCRUM nos ajuda a organizar a dinâmica de eventos variáveis e lidar com as exceções (impedimentos) que vivemos (enquanto gerentes de projetos) em uma iteração (etapa) específica de um projeto. Coloco, então, o SCRUM como um complemento natural ao planejamento iterativo do RUP.

A escola de metologias ágeis de gerenciamento de projeto Extreme Project Management (XPM), embora sem menção explícita a metáfora de filmes, usa princípios similares para o planejamento e acompanhamento de tarefas.

Começamos a observar o nascimento de ferramentas mais adequadas a este paradigma. Apesar de considerar ferramentas como o Primavera ou o MS Project excelentes, não as considero adequadas para o gerenciamento de projetos de TI. Estamos usando um martelo para bater em algo que não é um prego!

Uma versão mais leve do artigo do Walker Royce está disponível aqui no portal da DeveloperWorks da IBM. Recomendo fortemente a leitura deste artigo. São idéias valiosas (embora polêmicas), mas que me parecem descrever melhor a nossa realidade de projetos de TI.

Artigos mais detalhados e referências para os interessados nas escolas alternativas de gerência de projeto estão abaixo:

• Planejamento Iterativo - Planning an Iterative Project.
• SCRUM - Scrum it Now na Prática
• XPM - Extreme Project Management

Finalmente, deixo também uma coleção de publicações sobre a escolha chamada Software Economics, referenciada por Walker Royce em seu artigo.

Observo, com cada vez maior frequência e mais preocupação, a baixa importância dada a gerência de riscos em projetos de TI. A gerência de riscos é um dos princípios chave do RUP e de vários outros processos de software. Apesar disso, observo riscos de toda sorte que surgem, crescem, tomam proporções gigantescas e levam a equipe a níveis de stress e desespero.

A gerência de riscos pode parecer assustadora, mas pode ser realizada em passos simples. Considere um projeto de TI qualquer. Podemos dividí-lo em quatro marcos, associados a zonas de riscos.

• Riscos de Viabilidade - Devem ser mitigados até 10% do prazo de um projeto.
• Riscos de Colapso Arquitetural - Devem ser mitigados até 30% do prazo de um projeto.
• Riscos Logísticos - Devem ser mitigados até 50% do prazo de um projeto.
• Riscos de Entrega - - Devem ser mitigados até 70% do prazo de um projeto.

Os riscos de viabilidade surgem quando o gerente ignora leis fundamentais de estimativas na organização do escopo, prazo, custo, qualidade e riscos na iniciação de um projeto. Diversos projetos são fechados com escopos não realizáveis nos prazos, custos e qualidade acordados. A consequência é na maior parte das vezes a qualidade, dado que alguma variável tem que ceder. Por exemplo, observações exaustivas de Barry Boehm mostram que comprimir um cronograma em mais que 25% do seu cronograma nominal é estatisticamente inviável. Diversas outras observações de Frederik Brooks, em seu clássico livro “The Mythical Man-Month”, mostram que adicionar pessoas a um projeto já atrasado também não funciona. Uma excelente fonte de consulta e aprendizado sobre este tema e o livro “Software Estimation - Demystifying the Black Art“, do autor Steve McConnel. Um artigo rápido sobre este tema é Something’s Gotta Give, do autor Scott Ambler. O resumo aqui é: Se um projeto mostra-se inviável em suas variáveis básicas (qualidade, riscos, escopo, prazo e custo), nao o traga para casa. Dizer NÃO ao final da iniciação de um projeto não deveria ser uma vergonha. Muito pior é perceber dez meses depois que o projeto foi cancelado pelo cliente depois de milhares ou centenas de milhares reais gastos.

Dado que um projeto seja viável, temos que torná-lo livre de riscos técnicos. Para isso, gerentes não podem ignorar que todo projeto merece uma arquitetura executável. Para isso, devemos priorizar os requisitos mais importantes do usuário e de maior dificuldade técnica e gerar códigos que os realizem, em conjunto com todos os requisitos não-funcionais críticos de um sistema. Nunca devemos começar por cadastroa CRUD, dado que isso apenas adia os riscos dos riscos de integração, desempenho, usabilidade, segurança e especialmente de mudanças de escopo. Concentrar a energia central no mais crítico antecipa riscos e promove um mecanismos saudável de mitigação dos mesmos. Nesta fase, o projeto ainda deve ter poucas pessoas, dado que o ambiente está instável. Recomendo, em particular, um excelente artigo de um dos pais do RUP (Phillippe Kruchten) — Common Misconceptions about Software Architecture para removermos mal-entedidos sobre a palavra arquitetura. Exemplos de colapsos arquiteturais são banco de dados ou servidores Web que não escalam ou descobertas tardias que a aplicação não opera em um browser não identificado. Em resumo, para evitarmos um colapso arquitetural devemos implementar e testar entre 5 e 20% dos requisitos mais críticos para termos um arquitetura executável (fundação) que sustente os vintes andares de código que nos aguardam.

Dado que a base técnica do projeto tenha sido criada, é hora da economia de escala. Neste ponto, podemos ter vários desenvolvedores operando em paralelo (como uma linha de montagem) para implementar os diversos casos de uso de um sistema. Entretanto, antes devemos preparar a logística de operação do time. Temos já um líder técnico de desenvolvimento para suporte imediato às dúvidas do time? Temos um processo de micro-gerência nas mãos? Temos um criterioso processo de controle de mudanças definido? Temos ferramentas de micro-gerência como o Mylin para controle fino do tempo gasto por cada desenvolvedor? O ambiente e políticas de gerência de configuração está estável? Conheci (e conheço) gerentes ingênuos que fizeram (e ainda fazem) a alocação de várias pessoas ao projeto sem ter respondido a estas questões. O resultado é ….caótico. Tarefas redudantes, re-trabalho, conflitos no versionamento do código, equipes estressadas e outros sintomas se manifestam.

Finalmente, se o gerente conseguiu chegar até aqui, ele deve se preparar para os riscos de entrega do produto. Um plano de implantação foi definido? Os usuários chaves foram envolvidos? Os ambientes de teste integrado, homologação e produção foram corretamente desenhados e testados? Critérios claros de aceite como percentual mínimo de cobertura de código em testes integrado, curvas de tendência de defeitos ou mecanismos de operação da aplicação da produção foram pensados? Novamente o gerente deve estar atento a estes detalhes para evitar a morte do projeto quase na sua entrega. Uma leitura chave para este processo é o excelente livro do autor Scott Ambler chamado The Unified Process Transition and Production Phases : Best Practices in Implementing the UP.

Afinal, matar um elefante é fácil, mas….

Projetos de TI (Tecnologia de Informação) impõe desafios únicos, muitas vezes não observáveis em projetos de engenharia, tais como requisitos extremamente variáveis, pressões de tempo muitas vezes não realistas e dificuldades de aferir e medir a qualidade do produto entregue. Neste cenário já conturbado, infelizmente presenciamos mais uma força negativa, que vou apelidar aqui de Gerente: E Aí?.

O que é o Gerente: E Aí?.

É fácil reconhecê-lo pelas seguintes características:

• Possui pouco domínio do contexto e das tecnologias usadas.
• Possui extrema dificuldade de expressar, seja pessoalmente ou por falta de apoio de um líder técnico competente, os entregáveis do projeto em uma lista detalhada de atividades técnicas necessárias para realizar aquele entregável.
• Usa mecanismos de pressão com o time. O paradigma do século XIX “Cenoura e chicote” é bastante usado.
• Não consegue criar um isolamento e ambiente saudável de trabalho para o time.
• Não se comunica com a equipe, a não ser por emails e reuniões formais e impessoais. Fica quase todo o dia na frente do seu computador, em uma sala especial com mobiliário de padrão melhor que seu time. Afinal, precisa demonstrar que é o chefe.
• Abusa da manipulação gerencial. Frases como “Precisamos de mais empenho!”, “Vamos trabalhar este final de semana para o bem do projeto.” e “Vocês precisam ter mais compromisso.” são comuns no vocabulário deste tipo de gerente.
• Abusa das perguntas “E aí, tá pronto?”; “Já terminou?”, “Fica pronto para hoje, ok?”.

Infelizmente, o Gerente: E Aí? o não consegue obter o respeito do time. Normalmente ele é alvo de piadas de todo o time. Um dos maiores malefícios deste tipo de gerente é afetar o moral e motivação do time. Steve McConnell (em seu excelente livro Rapid Development) e Tom de Marco (em seu excelente livro Peopleware) mostram a correlação negativa da taxa de sucesso de projetos e gerentes manipuladores.

Capers Jones, outro excelente estudioso de fatores de sucesso e fracasso de projetos de TI, observa também que times sob pressào extrema introduzem até 40% a mais de defeitos que times similares em um ambiente saudável. Um excelente texto sobre ambientes saudáveis em TI pode ser achado na seção “Hygienic factors”, do livro supra-citado do Steve McConnell.

O novo milênio e os novos paradigmas pedem novos tipos de gerentes. Projetos de complexidade como observados em TI pedem um novo tipo de gerência. Vamos chamar este gerente de Como posso te ajudar.

O Gerente Como posso te ajudar? pode ser reconhecido pelas seguintes características:

• Possui bons ou excelentes conhecimentos do domínio em que atua. Este tipo de gerente não precisa ser certificado Java ou .NET, mas deve conseguir manter um diálogo técnico mínimo com a sua equipe. Por exemplo, você já viu um projeto de um prédio de vinte andares que não tenha sido gerenciado por um Engenheiro?
• Consegue expressar claramente os entregáveis de um projeto em uma lista de atividades precisa, com o apoio de processos como o RUP, EUP ou metodologias ágeis. Conhece bem processos de software.
• Isola, a todo custo, o time das pressões comerciais dos clientes e da alta gerência das empresas do time. Este tipo de gerente sabe que o que não ajuda, pode atrapalhar.
• Usa mecanismos de motivação para fazer o time trabalhar bastante. Como Barry Boehm observa do alto de sua experiência de quase 50 anos em TI e mais de 80 de idade, a motivação é o fator que mais contribui isoladamente para diferenciar times de projeto de mesma capacidade técnica em tecnologias similares.
• Está em constante circulação, fisicamente ou virtualmente, com suas equipes exercendo um papel pró-ativo e removendo os empecilhos encontrados pelo time. Este gerente é um “coach”, na melhor definição do termo.
• Conhece profundamente técnicas de negociação “Ganha Ganha ou Nada feito”. Com isso, consegue um profundo respeito do time e portanto um sentimento de compromisso de toda a equipe para bater as metas de projeto.
• Acima de tudo, reconhece que ele não é chefe, mas um mero servidor. Um gerente “servidor” existe para o bem único e exclusivo de apoiar o time a cumprir as metas do projeto.
  

Um excelente livro que discute este novo paradigma gerencial é o livro “O Oitavo Hábito, do autor Steven Covey”. As claras diferenças entre o gerente clássico e o líder são discutidas à exaustão neste livro. Em resumo, o gerente Como posso te ajudar comunica valores corretos às pessoas e com isso libera o potencial das mesmas.

Um aspecto fundamental nesta diferenciação dos gerentes é a autoridade formal vs autoridade moral. A autoridade formal é imposta através de hierarquias. A autoridade moral é conseguida através de liderança.

Como analistas, arquitetos e desenvolvedores, devemos buscar cada vez mais gerentes líderes para nossos projetos e educar gerentes do século XIX a uma profunda mudança de atitude e comportamento.

Finalmente, como gerentes devemos entender como desenvolver nossas habilidades de liderança. Uma fonte de inspiração e conhecimento é o autor Warren Bennis, que possui excelentes livros e tratados sobre liderança de times.

Recentemente escrevemos um artigo para a Rational Buzz (revista on-line da IBM Rational no Brasil), sobre aspectos motivacionais para o desenvolvimento de recursos humanos na área de software. O artigo apresenta também ferramentas para suporte a este desenvolvimento como o IBM Rational Portfolio Manager e o IBM Rational Unified Process.

O resumo do artigo está aqui:

A volatilidade dos negócios, a globalização e a necessidade de contínuas inovações tecnológicas nas empresas tornam a TI uma peça fundamental para o correto alinhamento estratégico dessas empresas às suas visões. Esses novos paradigmas tornam ainda mais desafiante a implementação de projetos, que dependem, para o seu sucesso, do uso adequado de pessoas competentes e motivadas, processos ágeis e ferramentas integradas. Nesse contexto, este artigo apresenta como a questão do capital intelectual é crítica para a execução de projetos e propõe um pequeno conjunto de práticas-chave ancoradas em ferramentas de produtividade como o IBM RPM e o IBM RUP para promover uma maior previsibilidade nos resultados de projetos e a gestão de competências e desenvolvimento de recursos humanos em organizações.

O artigo completo pode ser encontrado aqui.

Terminou ontem (28 de novembro), o segundo congresso anual do capítulo mineiro do PMI. Apresentamos neste evento uma palestra sobre a importância das pessoas no desenvolvimento de projetos, com a discussão de:

• práticas e anti-práticas de gerência de pessoas;
• gerência vs. Liderança;
• planejamento de capacidade pool de recursos para a execução de portifólios dinâmicos de projetos.

A apresentação está disponível aqui para download.

Nos próximos dias 27 e 28 de Novembro haverá o segundo encontro anual de Gerenciamento de Projetos do capítulo PMI MG. Neste evento teremos a oportunidade de realizar uma apresentação sobre a importância da gestão do pool de recursos humanos para a execução de múltiplas demandas. A grade completa do evento e mais informações podem ser encontradas aqui.

O mercado Brasileiro ainda é carente de boas pesquisas da maturidade da indústria de TI, engenharia de software e gestão de projetos. Na contra-mão desta realidade, os professores Darci Prado e Russel Archibald apresentam anualmente os resultados da sua pesquisa em maturidade de gestão de projetos, a partir do feedback de centenas de participantes de empresas do mercado Brasileiro, americano e europeu. A maturidade, neste contexto, é definida de acordo com o modelo desenvolvido por Darci Prado, chamado de MMGP

A rodada de pesquisa de 2006 está disponível para preenchimento por gerentes de projetos, gerentes de escritórios de projetos ou pessoas em outras funções gerenciais a partir do seguinte link: www.maturityresearch.com. Caso você, leitor, não ocupe posição gerencial, divulgue este blog a seu gerente e incentive a participação na pesquisa.

Para quem deseja apenas obter dados de maturidade para comparação e análise, os resultados de 2005 estão disponíveis em formato PDF aqui.