[#MetodologiasÁgeis] Traduzindo negócio para um sistema automatizado

Por Giovanni Bassi, Em Lambda 3

Normalmente quando somos chamados para automatizar com um software um processo manual nosso primeiro instinto é traduzir para o software o processo da empresa.

Por exemplo, este é o formulário do departamento do trabalho da Nova Zelândia que permite soldagem, por motivos de segurança no trabalho (outros formulários aqui):

Se tivéssemos que automatizar o processo de autorização, muitas vezes o que faríamos seria algo assim, inicialmente;

Isso traduz o começo do formulário, que continuaria até o final, embaixo.

Não há um enorme problema em começar desta forma. A pergunta que quero trazer é se realmente nosso trabalho é traduzir formulários de papel para seu exato formato eletrônico.

Sem precisar pensar muito, vou adicionar um componente a mais nesse formulário eletrônico:

Ok, agora temos um botão, e em vez de ser um formulário gigantesco. Isso já ajudaria na visualização da tela.

Que tal melhorar mais?

Talvez agora fique mais fácil enxergar o formulário em aplicações mobile.

O que mais poderíamos fazer?

Olha lá, um botão para buscar pelo nome das pessoas, sem precisar ficar digitando.

Outro exemplo clássico é o grid:

Porque ainda fazemos grids? Isso não é um relatório, porque estamos enchendo a tela de informações inúteis? Vocês podem imaginar outras formas de apresentar essa informação? Pensem nas aplicações para tablets: quantos grids vocês veem nelas?

O que estou propondo são apenas modificações simples no layout original. Na prática, eu convido vocês a repensar totalmente a necessidade que o formulário atende, sua razão de negócio, qual o ROI que ele proporciona. E a partir daí, modelar uma interface gráfica totalmente nova.

Nosso trabalho não é traduzir formulários. Lembre-se disso.