terça-feira, janeiro 31, 2006

Tirando agua de pedra

...ou como extrair informações de um cliente para fazer a especificação de um software.

Recebi esta tira do Dilbert hoje de manhã, e ela tem tudo a ver com alguns problemas de especificação de software que estou vivendo atualmente. Conseguir extrair informações sobre o negócio de um cliente é uma arte, que requer tempo, perícia e uma boa dose de calma. O grande problema é que pessoas normais (em oposição a desenvolvedores) não conseguem entender o mundo virtual que um software constrói, não entende implicações de decisões erradas de design, e sobretudo nem sempre consegue definir quais são as informações importantes para o design, e quais são totalmente superfluas. E são esses pequenos detalhes esquecidos que em geral irão causar redesign, refactoring, e portanto atraso.

Exemplo prático: ontem, por acaso, descobri que um atributo que eu acreditava estar ligado a uma entidade entidade na verdade era ligada a outra entidade. Detalhe: a questão das entidades foi discutida milhõs de vezes, e o cliente aprovou um documento que explicitava as entidades e seus atributos. Resultado: mudar o atributo de uma tabela de BD para outra é muito simples....o problema é modificar queries, objetos, e validar tudo de novo. No meu caso, 2 dias perdidos praticamente.

O fato é que não se pode esperar que o cliente vá falar sobre tudo sozinho, e de preferência, não se deve pedir pro cliente descrever o seu negócio com a ótica do software a ser produzido...inevitavelmente, ele irá colocar filtros nas informações que em geral não são desejáveis. Quem deve delimitar o escopo do software e as informações realmente relevantes é o desenvolvedor, obviamente com base nas informações do cliente.

5 Comments:

Anonymous Tereza Cristina said...

Esse e' um tema interessante. Na maioria das vezes o cliente sabe o que quer como produto final, mas nao consegue ver 'como' realmente o produto deve funcionar. O desenvolvedor, por sua vez, consegue ver como o produto pode ser feito, mas nao necessariamente consegue ver o problema do lado do cliente, vendo os aspectos operacionais e como sera' o dia-a-dia do cliente utilizando a nova ferramenta. Quando a situacao permite, acho interessante o empenho de uma pessoa que possa realizar a interface entre os dois mundos: uma pessoa que faca o advogado do diabo e defenda o ponto de vista do cliente e que tenha tambem conhecimento tecnico suficiente para conversar com a equipe de desenvolvimento e dar forma ao projeto.

2/01/2006 06:46:00 AM  
Blogger Miguel Galves said...

Eu diria que na maioria das vezes o cliente sabe o problema que quer resolver...isso é ligeiramente diferente de saber o que quer como produto final.

De fato, existe um buraco muito grande entre o mundo real do cliente e o mundo virtual do desenvolvedor, e ter alguem fazendo a ponte é essencial. Mas mesmo assim, quem tem que entender o mundo real eo problema para transpor para o mundo virtual é o desenvolvedor.

Fazendo uma analogia com médico...o paciente vai, deita no divã e começa a falar o que sente. O trabalho de separar o joio do trigo, definir o que é importante e forncecer um diagnóstico e uma solução é do médico. Em geral, qualquer tentativa do paciente de tentar definir ele mesmo o diagnóstico é desastrosa.

2/01/2006 11:14:00 AM  
Blogger Marcelo Bello said...

Acredito que boa parte disso é culpa dos desenvolvedores.
Em geral os desenvolvedores são apaixonados pelo próprio trabalho e se interessam pouco pelo negócio do cliente. Aliás, se interessam pouco por negócios em geral - e com isso perdem boas oportunidades. Quando você passa a entender do negócio do cliente coisas boas acontecem:

1. Você ganha confiança do cliente (parar de fazer perguntas idiotas é o primeiro passo);
2. O retrabalho diminui;
3. Você pode ser criativo no seu trabalho. Você pode usar sua inteligência não apenas para desenvolver o trabalho seguindo o melhor pattern que existe, mas para gerar valor ao negócio do cliente. Não há como repensar algo que você não entende;
4. Pode ter boas idéias a respeito do negócio que aprendeu e descobrir um nicho de mercado inexplorado (que pode não ter nada a ver com o trabalho atual);

As grandes consultorias em TI tem consultores que trabalham exatamente para fazer o meio campo negócio-desenvolvimento. Funciona? Minha experiência diz que sim, mas estas empresas pecam em outra coisa: contratam mão de obra barata para o desenvolvimento (apostando em design UML).

Minha experiência como programador e como consultor (de negócios - meu trabalho atual) me faz apostar no método Agile (http://www.agilemanifesto.org/).
Interação constante com o cliente e entregas contantes ("deliver often") são fundamentais em desenvolvimento de app.

2/01/2006 11:15:00 AM  
Blogger Ivan Sanchez said...

Marcelo, concordo contigo totalmente. Quando existe um canal de comunicação aberto entre cliente e desenvolvedor, além das iterações curtas para obter o feedback mais frequente possível, as coisas fluem sem muitos problemas.

Arrisco até a dizer que na maioria das vezes o problema não é nem o negócio do cliente. Já participei da experiência de ter uma equipe de programadores atuando como "clientes" na construção de um software que seria desenvolvido por outra equipe (todos da mesma empresa) e os problemas são os mesmos, apesar de todo mundo falar a mesma "língua".

Por isso que também sou mais um que aprova o manifesto ágil :-)

2/02/2006 10:07:00 PM  
Anonymous Anônimo said...

NSU - 4efer, 5210 - rulez

2/24/2007 08:48:00 PM  

Postar um comentário

Links to this post:

Criar um link

<< Home