Seguindo naquele nosso papo sobre seguros. Se eu tiver que dar um chute ("de bico*" mesmo), o desenvolvimento daquele projeto que citei no 'episódio' anterior custaria algo entre US$ 1,5 milhão e US$ 2 milhões. Considerando não só aqueles orçamentos que comentei na última semana, mas também algumas "informações privilegiadas", tenho que admitir que muito dificilmente uma seguradora bancaria o desenvolvimento do InsHub. Por óbvio e necessário que ele seja. Acontece que as seguradoras têm outras prioridades. Gerenciamento de riscos, Business Intelligence (BI) e combate a fraudes - não necessariamente nessa ordem - são as mais visíveis.

Não vou me repetir. Em novembro do ano passado comecei a escrever alguns artigos sobre o tema. Ficaram escondidos até hoje porque eu não sabia o que fazer com o projeto. Aliás, ainda não sei, mas creio que passou da hora de discutí-lo de uma forma mais aberta. Por enquanto, tenho apenas 3 artigos - um tipo de Business Case. Para quem se interessar, estão aqui:

• Breve Análise do Mercado de Seguros
• Barrando o Crescimento
• TI e o Setor de Seguros

O projeto recebeu o singelo pseudônimo "InsHub" (Insurance Hub). Eu sei, meio feinho. Mas acho que consegue passar a idéia.

Depois de muito martelar (posso dizer que são mais de 4 anos de marteladas ocasionais/acidentais), creio que existem apenas duas formas de viabilização do projeto: i) como Software Livre; ou ii) como um Projeto Cooperativo.

No primeiro caso seria necessário reunir algo entre 10 e 20 desenvolvedores dispostos a encarar um trampo de aproximadamente 1 ano. Seria bem mais fácil de viabilizar se pintassem dois ou três patrocinadores, seguradoras interessadas no produto final ou investidores. Entidades como a SUSEP, Fenaseg, Fenacor ou similares também poderiam se interessar. Mas trariam uma complexidade "política" pouco comum no mundo do Software Livre.

Complexidade bastante semelhante à de um projeto cooperativo. Neste caso, algo entre 5 e 10 seguradoras bancariam o projeto. Ou algo entre 10 e 20 corretoras. Coisa complexa que só seria possível com a formação ou nomeação de uma empresa para tocar o projeto. Como um projeto de software livre, seria de difícil gerenciamento. Afinal, teríamos algo entre 5 e 20 fontes de requisitos. Muitos interesses conflitantes e o eterno (e infundado) medo da concorrência. Sobre o "infundado" eu falo em outra oportunidade, provavelmente no próprio blog do InsHub.

Bom, agora me resta falar um pouco sobre a solução. Durante esta semana vou descrevê-la, em 3 ou 4 partes, no blog do InsHub. Mostrarei como o projeto pode atender uma seguradora ou um conjunto delas. Ou, sabendo posicioná-lo, como ele atenderia um grupo de corretoras. Destacarei todos os negócios "periféricos" que ele pode gerar: rastreamento de veículos, planos de saúde, melhores soluções de CRM e BI etc. Lógico, não entrarei em detalhes técnicos. Neste ponto do projeto eles não se justificam. Mas, dependendo do papo, quem sabe?

Minha única certeza é que não ficarei mais com esse peso na minha gaveta de "projetos em stand-by" ou de "projetos órfãos", como um dia eu disse para o Bob Wollheim. Tenho mais o que fazer.



* Um chute "de bico" é, no jargão dos boleiros, um chute pouco técnico - feio, principalmente se realizado por um "perna de pau". Raros craques, como Romário e Ronaldo, sabem fazer do chute "de bico" uma finalização perfeita. No contexto deste artigo, o termo foi utilizado para enfatizar a grosseria do chute dado.