Concluindo

Concluíndo o pensamento do post anterior, refere-se ainda que:

• Permite adaptar gradualmente a implementação de processos com a mudança gradual das mentalidades, evitando o stress gerado pela incerteza.
• Deve efectuar-se um cronograma de resultados suficientemente flexível para que um atraso numa etapa não invalide o objectivo da próxima.
• Sem a definição dos resultados a obter, não se sabe o que se deve implementar, nem a prioridade dos mesmos. A implementação fica sem rumo, e os resultados obtidos são sempre inesperados...
• Efectuando a implementação por etapas, começa-se a obter pequenos resultados desde o inicio, motivando quer os quadros envolvidos, quer as chefias / direcção. Quando o resultado obtido diverge do pretendido, foi motivado por um erro numa etapa anterior, ainda suficientemente recente para ser corrigido. Se não existir a preocupação da obtenção de resultados em cada etapa, os erros poderão só ser detectados no fim, quando já é demasiado tarde.
• Todos os pequenos ajustes que sejam necessários, são feitos ao longo de cada etapa, atempadamente, com esforço mínimo. Se o sistema só for avaliado no fim, pode ser tarde demais...
• Os utilizadores automotivam-se com os resultados do esforço despendido. Se motivados, colaboram. Se não, são um travão do processo. E depende da força com que carregam no pedal, podem mesmo fazê-lo parar...
• A direcção começa a ver os resultados da mudança, ou seja, o retorno do investimento feito, ficando mais aberta a outros investimentos que complementem o projecto.

• Quando um processo não consegue ser integralmente implementado no sistema, deve tentar-se até ao limite a remodelação do mesmo, afim de evitar alterações ao sistema standard, e só no caso de não ser mesmo possível e se ter consciência das consequências, é que se deve partir para a construção de um módulo específico, e desde que não interfira com o normal funcionamento e desenvolvimento do sistema.
• Muitas vezes o processo só existe porque já existia manualmente ou no sistema antigo, sem nunca ter sido questionada a sua utilidade.
• Um desenvolvimento à medida não pode comprometer os princípios da engenharia de software. (Integridade e não redundância de dados, modularidade, etc.). Se isso acontecer, ir-se-á acarretar com todas as consequências da sua violação, não visíveis a curto prazo, mas que podem inviabilizar a continuação da solução de futuro.
• Não pode comprometer o desenvolvimento / actualização do sistema em si, senão, na primeira actualização que for feita, o módulo específico pode deixar de funcionar. Pior ainda seria não poder efectuar a actualização, porque no desenvolvimento do módulo específico foi necessário alterar o modelo de dados...
• Não deve ser mais caro no desenvolvimento que o retorno de investimento que produz. Não se deve partir para o desenvolvimento de um módulo que automatize determinado processo, só porque é possível, mas raramente utilizado. Os custos da sua concepção e manutenção não justificam os resultados obtidos.
• Existem custos ocultos envolvidos no desenvolvimento à medida. Um sistema standard já foi testado quer pela empresa produtora, quer por muitos clientes. No específico, só o cliente poderá efectuar os testes da especificação de requisitos, ou seja, a verificação de que o mesmo cumpre com o que se foi pedido, e para tal, é necessário disponibilizar recursos humanos para esses testes.
• Há que ter consciência de que, quando a aplicação é actualizada em funcionalidades, plataformas ou de carácter legal, o custo dessa actualização é dividido por muitas empresas, enquanto que, se esse módulo específico necessitar de manutenção originada por essa actualização, este custo, normalmente elevado, é integralmente suportado por uma empresa.

Créditos: FG