Divagações sobre contratação / desenvolvimento de software

Os tempos de desenvolvimento não são comprimíveis a partir de um certo ponto
Nenhum sistema de qualidade fica pronto em menos de 3 meses (ou já estava pronto antes e foi cobrado um desenvolvimento que não ocorreu)
Pelo menos um terço do tempo de desenvolvimento deveria ser dedicado a testes

Um software deveria sempre ter - no mínimo - três ou quatro plataformas ou ambientes de trabalho:
- Um para desenvolvimento
- Um para teste(do pessoal do desenvolvimento)
- Um para homologação (para o contratante ou usuário usar o novo sistema em produção mas sem risco para a versão em produção - esta em algumas situações pode ser opcional)
- Um para produção (onde realmente está a operação do negócio que depende deste software ou do sistema do qual faz parte)
O banco de dados usado para desenvolvimento e para teste não pode ser o mesmo banco de dados de homologação / produção. É recomendável, conforme a situação, que a homologação tenha seu próprio banco de dados
É aconselhável que os bancos de dados não estejam nas mesmas plataformas/ambientes/servidores dos programas aplicativos. O que pode significar duas ou três plataformas/ambientes/servidores adicionais

Não há solução simples, mas sempre há uma solução simples e errada para um problema complexo
A qualidade do desenvolvimento é diretamente proporcional a média da competência da equipe e inversamente proporcional ao tamanho da equipe
Software ainda é uma atividade autoral e tão eficiente quanto mais clara é a visão do autor principal

A solução para a manutenção do sistema deve ser contratada ao mesmo tempo em que se contrata seu desenvolvimento
Todo software utilizado - isto é, bem utilizado - gerará solicitações de alteração dos seus usuários. Por outro lado. todo software não utilizado, sem valor, não terá manutenção
A qualidade da manutenção do software é inversamente proporcional a proximidade dos que são responsáveis por manter o código daqueles que foram os criadores do código. A provável um fracasso quanto se tem um fornecedor para desenvolver e outro para manter

Toda solução móvel é complexa
Nem toda a solução móvel precisa ser um app carregado no dispositivo móvel. Tendo uma conexão com a internet, o aplicativo móvel pode se reduzir a interface e/ou ao browser
Toda solução móvel complica a gestão de segurança

Conhecimento não se transfere
Pode ser transferida a informação
Somente uma equipe envolvida no esforço de desenvolvimento e manutenção pode receber a informação e transformar em conhecimento

Competência tem custo, há uma linha base de custo abaixo da qual ou a competência não existe ou há outros interesses no processo
Em desenvolvimento de software custos e horas de trabalho são forças apertando um mesmo balão inflável. Ao apertar custos (e competências) expandem-se as horas de trabalho
Custo pode ser reduzido com reduções de escopo - fazer somente o que é necessário e não todos os sonhos que os usuários ou planejadores possam antever

Software Livre não é gratuito, sempre há custos de suporte ou de manutenção externos ou de manter uma equipe interna com conhecimento para mantê-lo
Software Gratuito não é profissional
Os riscos de utilizar Software Livre sem acompanhamento adequado impactam fortemente aspectos de segurança

Segurança e Privacidade são os maiores desafio hoje em qualquer sistema, principalmente se este sistema tem componentes de software (e humanos).