Agora não é o momento para documentar e pensar em usabilidade para o usuário ?

As vezes vamos deixando para depois sempre com a desculpa de dizer que agora não é o momento, se agora não é o momento, quando vai ser? Este artigo surgiu depois da experiência vivída com alguns casos em que o desenvolvimento de software foi tratado como um objeto, ou algo mecânico desenvolvido especificamente para melhorar o ego dos presidentes das empresas, e não no usuário final que utiliza o sistema todos os dias e o sistema é inutilizável (de díficil uso).

O desenvolvimento de sistemas em pequenas empresas sem uma linha de produção definida, é bastante complicado pois um funcionário depende do outro e em muitos casos um funcionário exerce mais de 3 atividades dentro da empresa, como por exemplo a pessoa pode ser designer, programador, analista de sistemas entre outras funções.

As pequenas empresas sofrem grandes percas com a saída de funcionários do alto escalão, pois, estes funcionários desenvolvem muitos cargos e como nada é documentado, ou só a atividade de programador que ele exerce com maior frequência que ele documenta.

Na maior parte do tempo, definir uma linha de produção ou seguir um processo específico, algo único como por exemplo o processo unificado, para alguns gerentes são perca de tempo e atrapalham a produtividade da equipe.

Só depois do sistema estar com 2500 tabelas e estar praticamente impossível “produzir” é que vão pensar na adoção de um processo unificado, adotar padrões de projeto no desenvolvimento é uma prática extemamente aconselhável, mas, só adotar padrôes de projeto não é o suficiente, é preciso definir prazos coerentes, verificar se os pontos de marcações definidos estão todos seguindo os prazos pré estabelecidos, se não estão, verificar qual o tipo de problema que está ocorrendo.

Outro ponto importante que sempre ocorre é não documentar os testes efetuados, e entregar uma versão para o cliente testar, o principal problema que ocorre nesse caso é que o programador definiu um caminho ideal que deve ser seguido pelo cliente, porém não é o que ocorre na maioria dos casos, pois na especificação se é que há uma especificação não foi definido que poderia ocorrer uma situação em que há um caminho alternativo. Como nem sequer sabiam que existiam um caminho alternativo com certeza sera um produto que incomodará muito o cliente e funcionários. Pois haverá muitas falhas pois o processo de desenvolvimento apesar de ser um código que segue padrôes de projeto e web standards não foi um projeto elaborado para o cliente, um projeto que foque a experiência do usuário e que defina a principal prioridade “Pessoas”.

Bom, por enquanto vou encerrar este artigo por aqui, mas a idéia é que não basta ter um projeto que seja válido pelo W3C ou que utilize “Design Patterns”. É preciso ter um sistema que seja fácil de utilizar, escalável, portável, seja acessível para deficientes físicos, e que as pessoas possam aprender a utilizar o sistema facilmente, se o sistema não for assim, ou se não tiver um foco na experiência do usuário, já começou errado, achar que agora não é o momento para desenvolver software para pessoas, que as pessoas que vão utilizar o sistema não tem que ter aquelas janelinhas “bonitinhas” e aquelas “frescuras” que facilitam a vida do usuário pode ter certeza que tem algo errado no projeto.

Um abraço.