Marco Mendes´s Blog

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.