Marco Mendes´s Blog

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.

Uma das maiores falhas de gerentes e líderes técnicos em projetos de software é ignorar os riscos técnicos inerentes em tecnologias como J2EE, .NET, Delphi, VB, SAP/R3, entre tantas outras. Exemplos destes riscos manifestados incluem:

• Sistemas Web ou de banco de dados que não escalam por ausência de testes de desempenho
• Erros em operações financeiras por falhas de precisão em representação numérica
• Alta taxa de erros em sistemas de atendimento (call center) e perda de clientes devido a falta de testes de usabilidade.

Muito dinheiro é perdido anualmente no Brasil devido a estas falhas. Pense por um instante quantas horas de projeto provavelmente voce já precisou gastar devido a falhas desta natureza…

Um forma de dar com este problema é realizar, no começo do projeto, a identificação dos requisitos não-funcionais ou suplementares de um produto. Um requisito não-funcional determina um critério de qualidade a ser observado, como por exemplo o tempo médio de resposta das telas de um sistema, a taxa de crescimento anual em registros de um banco de dados, a precisão numérica de operações financeiras ou os browsers suportados em uma aplicação Web.

Normalmente estes requisitos podem ser avaliados e medidos durante o ciclo de vida de um projeto, o que garante acordos minímos de qualidade do produto em construção. Uma boa equipe deve, portanto, criar um mecanismo de aferição destes requisitos não-funcionais ainda nas fases preliminares do projeto. Chamamos aqui este mecanismo de aferição de uma arquitetura executável, que consiste de código executável que viabilize a construção do sistema como um todo (requisitos funcionais) e sua operação em produção sem contratempos. Metaforicamente, a arquitetura executável é similar a fundação de um prédio de engenharia civil, que consiste de uma estrutura que garanta que todos os andares de prédio sejam montados posteriormente.

Criamos um roteiro abaixo que mostra como criar uma arquitetura executável, em três passos:

1. Identificação dos Requisitos Não-Funcionais
2. Criação de uma prova de conceito para cada requisito não-funcional que seja risco técnico alto.
3. Validação da arquitetura executável, que consiste do conjunto de provas de conceito realizadas no item 2.

O passo 1 deve ser realizado a partir de questionários e modelos disponíveis na literatura como a norma ISO 9126 ou o modelo FURPS+ (Usado para coletar requisitos não-funcionais no RUP).

O modelo FURPS+, por exemplo, trabalha os seguintes aspectos de qualidade:

• Funcionabilidade: Estética e consistência na interface com o usuário.
• Confiabilidade: Disponibilidade (a quantidade do sistema “funcionando apropriadamente”), exatidão dos cálculos do sistema e a capacidade de recuperação do sistema após falhas.
• Desempenho: Rendimento do processamento, tempo de resposta, tempo de recuperação, tempo de inicialização e tempo de encerramento.
• Suportabilidade: Possibilidade de teste, adaptabilidade, sustentabilidade, compatibilidade, configurabilidade, instalabilidade, escalabilidade e possibilidade de localização.

O problema primário destes modelos é que eles são áridos para iniciantes e pessoas sem background arquitetural. Para ajudar neste problema, colocamos abaixo uma versão mais leve, em formato de questionário, baseado na norma ISO 9126.

1. Precisão
   • O sistema realiza operações financeiras? Se sim, especifique o número de casas de precisão destes cálculos.
   • O sistema é de extração de dados/estatístico/ engenharia e realiza cálculos matemáticos complexos ? Se sim, especifique o número de casas de precisão das regras de transformação/cálculo.
   • O sistema manipula medicamentos, compostos quimícos ou elementos cuja dosagem possam causar danos a seres humanos?
2. Interoperabilidade
   • O sistema se comunica com outros sistemas, hardwares ou bases de dados? Se sim, especifique os sistemas de comunicação, hardwares ou bases de dados.
   • O sistema é de comércio eletrônico (B2C ou B2B)? Se sim, especifique os sistemas de comunicação do B2C ou B2C.
3. Segurança
   • O sistema deve realizar controle de acesso (autenticação e autorização)?
   • O sistema deve garantir o sigilo das informações trafegadas na rede interna ou internet (condidencialidade e integridade)?
   • O sistema deve realizar auditoria (log) das operações?
4. Maturidade
   • O sistema deve funcionar vinte e quatro horas por dia, sete dias por semana (missão crítica)? Se não, especificar o tempo máximo que o sistema pode ficar fora do ar (ou alternativamente porcentagem mínima de operação).
5. Tolerância a Falhas/Recuperação de Falhas
   • Em caso de falha do sistema, existirá algum plano de contingência ou de retomada de operação?
     Se não, especificar o tempo máximo que o sistema pode ficar fora do ar.
6. Facilidade de Entendimento
   • O sistema deve ter help-online ou manual?
   • Deve haver treinamento ou workshops para os usuários do sistema?
7. Operabilidade
   • O sistema usa hardwares específicos (canetas óticas, PDAs, URAs, telefones celulares, plotters ou outros)?
   • O sistema é de pronto atendimento (ex: call-centers)?
   • stema deve operar em browsers outros além do Internet Explorer?
8. Comportamento de Tempo
   • O sistema deve ter funcionalidades que rodem abaixo de seis segundos? (*) Seis segundos é um valor, medido em testes de usabilidade, onde usuários de sistemas computacionais começam a perceber a latência do sistema em uso. Como todo valor, ele deve ser contextualizado à sua realidade.
9. Comportamento de Recursos
   • O sistema irá rodar na Internet ou Intranets de grande porte? Se sim, especificar o número máximo de usuários esperado em horários de pico.
   • O sistema irá manipular bases de dados com muitos registros? Se sim, especificar o número máximo de registros e a taxa de crescimento anual.
10. Conformidade e Facilidade de Troca
    • O sistema deverá rodar em quais sistemas operacionais?
    • O sistema deverá rodar em outros hardwares além dos PCs? Se sim, especificar quais hardwares.
11. Padronização
    • O sistema deve obedecer a alguma lei, norma, regulamentação ou portaria governamental? Se sim, especifique.
    • O sistema deve obedecer a algum padrão definido na organização alvo onde o sistema irá funcionar. Se sim, especifique o padrão.
12. Facilidade de Instalação
    • O sistema deve possuir instalador para usuários finais?

O questionário acima não é completo. Remova, altere e adicione itens ao mesmo, mas não deixe de ter o seu roteiro para entrevistar os seus usuários e coletar estes requisitos suplementares. Temporalmente, você deve terminar esta coleta na fase de iniciação do projeto pois estes requisitos são críticos e normalmente de alto risco. Por exemplo, se o seu projeto tem vinte semanas de duração, você deve ter extraído os requisitos não-funcionais e riscos associados nas duas primeiras semanas do projeto.

Ao terminar este processo, iremos partir para o item 2, que consiste em montar provas de conceito que mitiguem os potenciais riscos destes requisitos. Para isso, iremos trabalhar um exemplo simples. Suponha que coletemos um requisito de desempenho que nos peça para suportar 4.000.000 transações por dia e um máximo de 200 usuários concorrentes no sistema. Um requisito desta natureza impõe um alto risco no produto pois existe uma alta chance de não ser suportado em uma típica configuração PC Intel + windows + Servidor Web. Se existe o risco, devemos mitigá-lo. A mitigação deve ser feita com código executável e não com modelos UML apenas. Criamos então uma primeira versão do produto, que chamamos de Alfa 1, que consiste de um requisito funcional implementado sujeito as condições do requisito não-funcional em análise. Por exemplo, podemos implementar um versão simplificada de um relatório ou página sendo consumida simultaneamente por 200 usuários. A versão Alfa não possui compromissos reais de funcionalidade como por exemplo possuir todos os campos ou realizar todas as consistências de negócio, mas deve ser suficientemente real para mitigar o risco. No nosso exemplo poderíamos ter descoberto que precisaremos de duas máquinas em um cluster para operar com tal carga. O risco foi mitigado e a topologia física agora se baseia em uma decisão técnica e não em uma especulação ou estimativa.

O procedimento exemplificado acima é repetido para cada risco identificado e novas versões (Alfa 2, 3, N) são geradas ao longo de alguns dias ou algumas semanas para projetos de maior porte. Temporalmente, o primeiro terço da vida do projeto deve conseguir gerar uma arquitetura executável que mitigue todos os riscos destes requisitos suplementares. Em um projeto de vinte semanas, este processo deve ser encerrado até a sexta ou sétima semana. O passo 2 (Criação das provas de conceito) se encerra aqui.

Finalmente, temos um conjunto de códigos evolutivos que compreendem alguns requisitos funcionais (normalmente entre 5 e 20% do escopo do sistema), que atendem a todos os requisitos não-funcionais que impõe riscos técnicos alto no sistema. Chamamos isso de uma arquitetura executável, que deve ser então testada e validada por um audiência maior. Eventualmente, ajustes devem ser feitos e novos alfas serão produzidos até que a arquitetura se estabilize. Este produto é chamado de arquitetura executável e serve como linha de base arquitetural do sistema. O passo 3 se encerra aqui.

Quais as vantagens desta abordagem, pode perguntar o leitor mais cético?

• A grande maioria dos riscos técnicos do sistema foram mitigados. As surpresas técnicas em produção nao existem mais, pois foram detectadas, analisadas, implementadas, testadas e homologadas previamente.
• O tempo investido em arquitetura permite agora a paralelização dos recursos o que fornece economia de escala em médio prazo.
• O retrabalho de projeto é reduzido drasticamente. Por exemplo, cito o caso de uma empresa de Belo Horizonte que detectou tardiamente em um projeto que o browser Mozilla precisava ser suportado em sua aplicação Web (Veja novamente o item Operabilidade no item 1 do nosso processo). Após mais de 50 requisitos incorretos, isso gerou um retrabalho de mais de 1000 horas e um custo extra de mais de 50.000 reais!

  A pergunta que pode ficar é: Quem cria uma arquitetura executável? O arquiteto de sistemas é o papel responsável pela criação de uma arquitetura executável. O arquiteto, entretanto, nào é um super-homem. Ele é muitas vezes composto de um comitê de pessoas que em um trabalho conjunto irão identificar e mitigar riscos técnicos e então criar a arquitetura executável de um sistema.

  Se você está começando um novo projeto agora, pare por cinco minutos e pense. Você quer gastar horas e horas intermináveis em sessões de depuração de código à noite. viver a pressão de atrasos, falta de qualidade no código e ter noites mal dormidas? Se não, invista agora em criar a sua arquitetura executável do seu sistema. O trabalho é desafiante, mas o benefício é garantido!

  1 comentário »

O autor Scott Adams, criador do excelente quadrinho Dilbert, usa exemplos da vida corporativa para seus roteiros e histórias - A arte imita a vida.

Estranhamente, a comunidade J2EE parece copiar as histórias do Dilbert - A vida imita a arte?, com seus erros constantes em garantir compromissos básicos de projetos como custos, qualidade, escopo e prazos. No artigo que apresentamos no ultimo SUN TechDays em Abril deste ano em Belo Horizonte, ressaltamos alguns exemplos de como não gerir projetos J2EE e também um conjunto de boas práticas para evitá-las.

Gerência de Riscos J2EE:Gerência de Riscos J2EE