Software corporativo, estamos fazendo errado

Português   |   Source

Triciclo

Eu trabalho numa grande empresa do país. Apesar de não ser uma empresa de software, a área de TI é enorme e devemos ter pelo menos umas 6 mil aplicações desenvolvidas (sem exagero!) ao longo do tempo para atender às demandas da empresa, não estou contando aqui as aplicações que foram compradas, apenas as desenvolvidas mesmo. A fila de espera de aplicações a serem desenvolvidas é enorme, e depois de conviver nesse ambiente por quase 5 anos, eu posso afirmar categoricamente: estamos fazendo a coisa errada, estamos desenvolvendo software de um jeito completamente equivocado.

Errado, por quê?

Primeiro, preciso deixar claro que isso não é exclusividade da empresa onde trabalho, mas pelo que eu tenho conversado com outras pessoas e tenho lido por aí, a maioria absoluta das empresas no Brasil ou no mundo estão fazendo software do jeito errado.

Uma coisa que comprova isso é o Chaos Report, um relatório lançado a cada 2 anos com dados estatísticos sobre como anda o desenvolvimento de software nas empresas ao redor do mundo. Vamos dar uma olhada no gráfico relativo a 2009.

Chaos Report 2009

Apenas 32% dos projetos são bem sucedidos, no passado a situação era bem pior, em 1994 apenas 16% dos projetos eram bem sucedidos. Mas ainda assim, eu considero esses números alarmantes. Com toda a dita "maturidade" em desenvolvimento que adquirimos nos últimos anos, com todas as metodologias, processos, certificações e toda a evolução da indústria de software para isso? Sem contar o fato que eu acho que esses números são extremamente otimistas em relação à realidade que eu observo.

Tim Bray, empregado da Oracle, escreveu um artigo sobre isso e não poderia ter colocado o problema de forma melhor: > The community of developers whose work you see on the Web, who probably don’t know what ADO or UML or JPA even > stand for, deploy better systems at less cost in less time at lower risk than we see in the Enterprise.

Quem conhece pelo menos um pouco das comunidades de software livre ou das empresas da era web 2.0 sabe que isso é uma tremenda verdade. Os desenvolvedores dessas comunidades, em geral, produzem sistemas melhores, mais baratos, em menos tempo e com um custo menor do que a maioria absoluta das grandes empresas que conhecemos atualmente. Tim Bray vai ainda mais fundo na sua crítica: > This is unacceptable. The Fortune 1,000 are bleeding money and missing huge opportunities to excel and compete. > I’m not going to say that these are low-hanging fruit, because if it were easy to bridge this gap, it’d have been > bridged. But the gap is so big, the rewards are so huge, that it’s time for some serious bridge-building investment.

O que precisamos nos perguntar nesse momento é: por que as coisas estão tão erradas assim com o desenvolvimento de software no meio corporativo? Por que as empresas que possuem todo o capital, todo o "suporte" dos grandes fornecedores não conseguem atingir a excelência no desenvolvimento de software? O momento não é apenas de fazer perguntas, mas sim de buscar as respostas.

Onde está a solução?

Uma das sugestões do Tim Bray, e que deveria ser óbvio pois é um conselho antigo da engenharia de software, é comprar sistemas ao invés de construí-los, sempre que isso for possível, mas isso ainda é uma controvérsia. E muitas vezes a coisa realmente é mais complexa do que imaginamos. Se um software atende a 70% das suas necessidades, o que será melhor, construir um para atender completamente ou solicitar ao fornecedor uma customização? Qual a melhor opção para futuras manutenções nesse software? Isso nem sempre é uma pergunta fácil de responder.

Mas ainda assim. Eu tenho algumas outras sugestões que podem nos ajudar a suceder mais no que tange ao software que desenvolvemos, ou pelo menos, poderemos falhar menos, por assim dizer.

**1) Evite desenvolver sistemas repetidos.*0 Falando pela experiência que eu tenho aqui na empresa, acho que temos pelo menos uns 12 sistemas desenvolvidos com o objetivo de reservar salas de reuniões, sim, isso mesmo, reuniões são abundantes no meio corporativo. Mas por que raios eu preciso de 12 sistemas distintos que fazem a mesma coisa, talvez com customizações mínimas aqui ou ali, mas se fazem a mesma coisa é totalmente factível que esses 12 sistemas sejam reduzidos para 1 somente. Esse é apenas um exemplo, entre tantos outros que eu já vi.

2) Fuja das certificações. A não ser que exista uma razão extremamente primordial, pela qual a sua empresa precise de certificações, fuja extremamente delas. Elas vão engessar o seu trabalho, vão proliferar as políticas e padrões dentro da sua empresa, e é quase certo que elas farão a sua empresa gastar desnecessariamente, muito mais dinheiro do que deveria. Então, se aparecer algum consultor mirabolante, falando que a sua empresa de TI ou o seu setor de TI precisa de uma certificação CMMI, ISO 9000 ou qualquer outra, fuja completamente!

3) Esqueça a analogia de fábrica de software. Comparar a construção de um software, um produto abstrato com qualquer outro produto industrial tangível em que você consegue automatizar ou criar uma linha de montagem é a pior comparação possível nos tempos de hoje. Tratar o seu desenvolvedor como o trabalhador de uma fábrica é pior ainda, isso vai apenas desmotivá-lo e fazer com que o trabalho dele fique cada vez mais burocrático e mais lento.

4) Responda rapidamente à mudanças. A natureza do software é ser um produto volátil, os requisitos do software são volatéis, mudam muito rápido. Não tem como mudar isso. O cenário de tecnologia muda muito rápido, as coisas avançam numa velocidade incrível. Aceitar isso e moldar o seu setor de TI ou a sua empresa para responder a essas mudanças é a melhor coisa a se fazer. A não ser que você queira se fechar no seu mundinho pequeno e começar a se debater quando os seus projetos começarem a fracassar.

5) Olhe com atenção e, se possível, copie os bons exemplos das comunidades de software livre e das empresas web. Será que o Google se preocupa em usar UML nos seus projetos? Consegue imaginar o Twitter sendo feito através de um processo em cascata? Existem vários e vários exemplos de sistemas de grande sucesso nessas comunidades, e geralmente essas empresas conseguem a excelência no desenvolvimento de software. É claro que, num ambiente corporativo, muitas vezes você não conseguirá o nível de liberdade que essas empresas ou comunidades conseguem, mas ainda assim, conseguimos aproveitar alguma metodologia, alguma ferramenta, ou alguma outra forma de organização que lhe permita ter mais agilidade, mais responsividade para o produto que entregamos para nossos clientes.

Tim Bray, no final do seu artigo até propõe um experimento interessante. Tente imaginar na sua empresa que você vai solicitar à sua área de desenvolvimento de software que eles desenvolvam uma ferramenta semelhante ao Twitter, ou ao Basecamp, ou ao YouTube com todas as formalidades e processos que a sua empresa prega. Provavelmente chegará à conclusão que não será possível fazer, seria um tremendo fracasso.

Conclusão

A situação no mundo do software corporativo é alarmante. É como aquele paciente que está no CTI respirando por aparelhos, porém existe a perspectiva de melhoras. E cada um de nós, que faz parte desse ambiente, pode fazer algo para mudar, ou pelo menos tentar mudar. Mesmo que não tenhamos poder de decisão, podemos tentar convencer as pessoas que tem para que possamos promover melhorias significativas nesse quadro caótico.

Comments powered by Disqus
Share