Monday, August 07, 2006

Esqueletos, apêndices e fantasmas

Então vocês finalmente conseguiram um cliente. Ele está muito empolgado e tem muitas expectativas para o projeto. Naturalmente, vocês também têm. Por onde começar?

Nesse início de projeto é óbvio que todo mundo está cheio de idéias, tanto vocês quanto o cliente. Todo mundo quer colocar todas as idéias em prática, mas há um limite para o que vocês conseguem entregar. A questão do que fazer primeiro é vital.

Uma idéia é levantar alguns requisitos iniciais com o cliente e escolher as funcionalidades mais representativas do ponto de vista técnico. Ainda não é preciso saber tudo que ele vai querer, somente o suficiente para ter uma idéia geral. Desse modo pode-se montar um esqueleto inicial do sistema sobre o qual as funcionalidades futuras se apoiarão.

Esta não é necessariamente uma boa idéia.

Pelo menos não é desse jeito que os esqueletos vêm tradicionalmente sendo desenvolvidos. Os esqueletos humanos, por exemplo, são produto de alguns milhares de anos de mutação e seleção natural. Não ganhamos este esqueleto que temos hoje de uma hora para a outra, foram necessárias várias gerações e muito refinamento do projeto inicial. Assim como na natureza, é melhor que a estrutura básica de uma aplicação evolua a partir de um conjunto mínimo ao longo do tempo ao invés de ser inventado tentando prever o futuro. Programadores não são muito bons em prever o futuro, então é melhor evitar projetar coisas que não precisaremos e deixar os apêndices evolucionários que ocasionalmente surgirão desaparecer naturalmente.

Mas há um argumento ainda mais forte. Quando levantamos prioridades observando apenas o mérito técnico, ignoramos o valor de negócio. Pode ser que as funções com maior representatividade técnica coincidam com as funções de maior valor para o cliente. Mas isto em geral não acontece. O resultado de priorizar inicialmente o desenvolvimento de um esqueleto normalmente são projetos que iniciam com uma grande fase de infra-estrutura e que, durante este tempo, não atendem a nenhuma necessidade do cliente.

O lado oposto desta idéia é deixar o cliente completamente livre para ordenar as funcionalidades como ele queira. Nesta abordagem tudo se inverte. Ao invés da aplicação se adaptar à infra-estrutura inicial, é a infra-estrutura que vai se adaptando às necessidades da aplicação. Os clientes podem então escolher em que investir.

São eles que estão pagando a conta, é natural deixá-los escolher em que investir. Claro que o papel dos programadores, especialistas em desenvolvimento de software, é mantê-los informados sobre suas opções. Eles podem oferecer seu conhecimento — devem fazer isso — mas a decisão final é dos clientes. Escolher uma funcionalidade ao invés de outra com base somente em quesitos técnicos é privá-los desta decisão.

1 Comments:

At 8/08/2006 06:17:00 AM, Blogger Felipe Costa said...

Sou formado em Desenvolvimento de Software mas faz tempo que não trabalho desenvolvendo, mas tempo ainda que não trabalho em equipe. Muito bom seu post. Me fez lembrar dos esqueletos inacabados que nunca chegaram a ser um produto final.

 

Post a Comment

<< Home