Continuo aqui o assunto do artigo anterior sobre Performance de Aplicações. São três as principais fontes de demanda por melhorias de performance: Infraestrutura, Clientes e Colaboradores.
Apesar de tudo, a lentidão dos sistemas também tem seu lado positivo: teoricamente, alto volume de dados para processar indica que houve mais faturamento. E se for um sistema de Compras? Ora, também teoricamente, quanto mais compras, mais produção, motivada por mais vendas.
A lista de demandas é encaminhada de alguma forma para a equipe de Performance de Aplicações. Com esses dados em mãos o Gestor vai agora priorizar as atividades de análise de performance, geralmente classificando as demandas em ordem decrescente de consumo. Em seguida vai estabelecer metas, prazos, fazer os devidos alinhamentos com as áreas impactadas, e comandar o ciclo de análise, desenvolvimento, testes, homologação e implantação.
Esta é uma boa discussão, que deve ser analisada no contexto da Corporação, através de um amplo debate à luz da avaliação tradicional de custos versus benefícios. A implementação pode ser feita tanto pela própria equipe de desenvolvimento, quanto por uma equipe dedicada, conforme a análise das áreas envolvidas.
Se a análise e implementação for feita pela equipe de desenvolvimento, isto pode impactar projetos já em andamento. Por outro lado, é fato que o desenvolvedor conhece melhor os módulos que foram apontados como grandes consumidores de recursos, e por isso pode ter mais facilidade em revisar o acesso a dados, ou melhorar rotinas internas.
Por outro lado uma equipe dedicada a análise de performance de aplicações tem uma visão global da arquitetura dos sistemas corporativos. Esta forma uma base de conhecimentos específica, como:
Então, está definido o objetivo principal a ser atingido: redução de custos de processamento, melhoria da qualidade de software, melhoria no atendimento aos clientes, melhoria no suporte aos colaboradores em todos os níveis, desde o nível operacional até os níveis gerenciais.
Todo este trabalho, porém, depende de outros fatores: o software é desenvolvido “in-house” ou é um pacote fechado? A Corporação tem restrição de escalabilidade ou pode adquirir mais servidores (ou mais MIPS para o Mainframe)? Existe pessoal suficiente para criar a área exclusiva de melhorias, ou serão alocados recursos das equipes temporariamente no projeto? Essas perguntas serão respondidas na fase de planejamento, e documentadas no projeto.
A abertura de projeto específico de melhoria de performance permite o envolvimento dos gestores das áreas impactadas, como: negócios, tenologia, e atendimento a clientes. Determina prazos, metas, alocação de pessoas, pontos de controle, os entregáveis, enfim, o projeto passa a ser conduzido de forma transparente. E no final, os números importantes aparecem: sabe-se qual o percentual obtido em economia de consumo de recursos, podendo traduzir em resultado financeiro alcançado – ou, Retorno do Investimento – ROI.
Nos próximos artigos irei começar a descrever melhorias técnicas. Já me abstraí muito na parte teórica: vamos à prática? Vou começar falando de Mainframe, mas em algum momento vou falar por exemplo de Android, de Java, Linguagem C e talvez até do Visual C#. Aguardo você nos próximos artigos.
[Crédito da Imagem: Performance – ShutterStock]
You must be logged in to post a comment.