Certa vez, em aula, um grande mestre – Prof. Vinícius Gadis Ribeiro, durante uma explicação sobre desenvolvimento de sistema, fez uma observação que até hoje ecoa quando preciso desenvolver qualquer aplicação. Na imagem ao lado, o retângulo representa o problema que o software deveria atender e a bolha o que o sistema realmente executa.
Poderia passar horas filosofando sobre as diferentes interpretações que pelos anos a fora fico imaginando. Detenho-me no que, para o momento, é relevante. A zona de intersecção é muito pequena.
O problema que o cliente tinha foi pouco atingido e, o esforço na produção do software gerou rotinas desnecessárias.
Lembro de uma máxima que se aplica muito bem ao momento: A informática veio para solucionar problemas que não tínhamos sem ela.
Chocante, mas é essa a característica que é atribuídas aos profissionais de TI. Para livrar-se destas amarras, algumas dicas são relevantes:
• Codifique aquilo que soluciona o problema do cliente, não o que você acredita que precisa ser codificado;
• Ouça o cliente, mas realmente ouça. Depois de ouvir descreva tudo o que vai e não vai ser produzido e, só ai parta para desenhos de modelagem do sistema;
• Como o produto não é pra você, teste a funcionalidade das rotinas junto com o cliente;
• E finalmente, a cada momento – antes de iniciar e terminar uma rotina – pergunte-se: O que é essa parte do sistema? Para que ela serve? A quem ela atende? Quanto de esforço/custo ela gera/economiza?
Não custa tentar...
Poderia passar horas filosofando sobre as diferentes interpretações que pelos anos a fora fico imaginando. Detenho-me no que, para o momento, é relevante. A zona de intersecção é muito pequena.
O problema que o cliente tinha foi pouco atingido e, o esforço na produção do software gerou rotinas desnecessárias.
Lembro de uma máxima que se aplica muito bem ao momento: A informática veio para solucionar problemas que não tínhamos sem ela.
Chocante, mas é essa a característica que é atribuídas aos profissionais de TI. Para livrar-se destas amarras, algumas dicas são relevantes:
• Codifique aquilo que soluciona o problema do cliente, não o que você acredita que precisa ser codificado;
• Ouça o cliente, mas realmente ouça. Depois de ouvir descreva tudo o que vai e não vai ser produzido e, só ai parta para desenhos de modelagem do sistema;
• Como o produto não é pra você, teste a funcionalidade das rotinas junto com o cliente;
• E finalmente, a cada momento – antes de iniciar e terminar uma rotina – pergunte-se: O que é essa parte do sistema? Para que ela serve? A quem ela atende? Quanto de esforço/custo ela gera/economiza?
Não custa tentar...
Nenhum comentário:
Postar um comentário