Artigo .net Magazine 66 - Submarinos Voadores

Quando Janio Quadros tentou seu “autogolpe” em 1961, o então deputado Tancredo Neves imortalizou o seguinte ditado popular mineiro “quando a esperteza é demais, ela vira bicho e engole o dono”. O desenvolvimento de software não está imune ao problema de “excesso de esperteza”. Eu diria até que o desenvolvimento de software é mais vulnerável a este problema do que a média das atividades humanas, por ocorrer essencialmente “no cyberespaço”, com menores vínculos com a realidade física do que outras atividades.

Veja uma situação: eu tenho um problema que pode ser resolvido pela criação de um novo software. Até aí tudo bem. Mas como o problema envolve outras áreas da empresa, começam a aparecer outros “interessados” apresentando “sugestões”. Como no desenvolvimento de software qualquer sugestão pode ser implementada “com apenas algumas linhas de código”, tudo parece fácil, especialmente se quem vai ter que criar as tais poucas linhas de código são os outros. O projeto então vai “evoluindo” até que fica irreconhecível e possivelmente nem fazendo mais direito a função original, sobrecarregado pelas “novas ideias”.

Isso é mais difícil de acontecer no mundo real, onde as restrições físicas são mais óbvias. Por exemplo, digamos que estou desenvolvendo um mini-submarino de pesquisas oceânicas e alguém chega e diz que “seria muito útil se o submarino pudesse voar”. Esta pessoa passa então a descrever os múltiplos benefícios de um submarino voador, quem sabe até inspirado em algum episódio do antigo seriado de TV “Viajem ao Fundo do Mar”. No entanto, esta é uma ideia evidentemente impraticável. Qualquer coisa voadora tem que ser leve, o que significa possuir uma densidade total baixa. Já um submarino é algo que, por definição, afunda na água. Tem que ser ligeiramente mais denso que a água. Na verdade, seu material de construção tem que ser bem mais denso, para compensar o ar que ele inevitavelmente carregará de forma a poupar a vida dos seus ocupantes. A ideia do submarino voador é descartada na hora, a realidade física rapidamente se impõe.

Já no desenvolvimento de software, ideias disparatadas não são tão fáceis de descartar. Pelo contrário, é comum que as sugestões se acumulem de forma a termos no final um verdadeiro submarino voador, que além de ser um péssimo avião, é um submarino medíocre. Isso é particularmente comum quando o produto é projetado “por comitê”, onde cada pessoa remotamente interessada é convidada a participar do processo. Pior: como o processo é assim vulnerável, pessoas que tenham motivos inconfessáveis para que o projeto não se realize podem até se aproveitar para injetar necessidades espúrias, de forma a sabotar o projeto.

Evidentemente esse não é um problema técnico e sim de gestão. Existem algumas maneiras de combater esse problema. Uma delas é ter no projeto um “gerente de produto” que decide o que será feito e quando. Essa pessoa não só deve conhecer o negócio como também ter tempo para usar o software e discutir com todos os envolvidos. Por causa disso, ela usualmente não é a pessoa com o cargo mais alto – chefe nunca tem tempo livre. Outra boa saída é entregar versões consistentes e funcionais com frequência – mesmo que incompletas. A entrega frequente traz vários benefícios:

• Os usuários podem utilizar o software antes, usufruindo de seu valor;
• Ajuda a definir melhor que funcionalidade é realmente importante por ter base na realidade;
• Pune os maus desenvolvedores – que terão dificuldades em fazer entregas antes do fim do projeto, sem o famoso “período de graça” inicial, onde mesmo que pouco seja feito é difícil perceber;
• Tira pressões injustas de bons desenvolvedores, que têm seu trabalho reconhecido cedo.

O gerente de produto também ajuda a manter uma visão coesa e consistente do software, algo muito importante ao longo de sua vida, facilitando e barateando futuras manutenções e evoluções.

Mauro Sant’Anna acredita no princípio “KISS”: Keep It Simple, Stupid.