Translate this page now :



»Programação
»Programação.NET
»Banco de Dados
»Webdesign
»Office
» Certificações Microsoft 4
»Treinamentos4
»Programação 4
»Webdesign«
»Office & User Tips«
»Grupos de Usuários
»Células Acadêmicas«
intcontpiada : 118
Vá dormir
Você já está cadastrado e participa do grupo de usuários de sua cidade ? Se não, comente o porque.
 
 
Faça um pequeno teste com 10 questões de VB
.:.
Teste seus conhecimentos em Visual Basic, SQL Server e ASP 3.0 com nossas provas on-line
.:.
Aprimore seus conhecimentos em programação com nosso treinamento on-line de lógica de programação
.:.
Veja nosso calendário de treinamentos
Gostou da Página?
Então

para um amigo!
 





Por Dennes Torres
dennes@bufaloinfo.com.br
Dennes Torres possui as certificações MCAD, MCSD,MCSE, MCDBA e MCT. Atualmente atua Como diretor da Búfalo Informática, líder do grupo de usuários DevASPNet no Rio de Janeiro e membro da liderança dos grupos getWindows e devSQL, também do Rio de Janeiro, podendo sempre ser encontrado na lista de discussão do grupo DevASPNet (devaspnet-subscribe@yahoogrupos.com.br) bem como nas reuniões do grupo. Mantém dois blogs em http://cidadaocarioca.blogspot.com

O mercado de Software Brasileiro
(ou : o drama dos pacotes fechados)

Pesquisa personalizada
Pesquisar Dicas:






Em meio a era da terceirização, paises de 1o mundo buscam mão de obra no 3o mundo para suprir suas necessidades na área de tecnologia, especialmente por 2 motivos : Em alguns paises de 1o mundo (leia-se EUA) a especialização profissional é muito grande e esta característica cultural de especialização profissional vai diretamente contra a necessidade da área tecnologica de rápida atualização e que se conheça de tudo um pouco. Outro motivo é o valor da mão de obra, muito mais barata no 3o mundo.

Entre as diversas opções no 3o mundo, 2 paises se destacam pela abundancia de mão de obra barata e qualificada : Brasil e Índia.

Para ambos os paises é extremamente vantajoso estar recebendo este tipo de requisição de mão de obra. É dinheiro entrando no país e ajudando a manter um saldo positivo na balança comercial, o que é bom para todo o país. Portanto a disputa é acirrada. Os indianos tem alguns pontos a favor : Os indianos falam inglês fluente, enquanto que poucos brasileiros tem essa característica. Além disso a mão de obra indiana consegue ser mais barata que a nossa.

Um exemplo disso é o site http://www.rentacoder.com/RentACoder/default.asp . Uma proposta muito inovadora : Desenvolvedores de software e empresas encontram-se através do site, negociam propostas para desenvolvimento, o desenvolvimento é feito e o pagamento ocorre através do próprio RentACoder. Depois de pouco tempo de funcionamento o RentACoder foi dominado pelos desenvolvedores indianos, que ganham praticamente todas as propostas devido ao baixo valor solicitado.

Cabe então a nós, brasileiros, mostrarmos boa disposição para contornar o problema do idioma e compensarmos o preço da mão de obra oferecendo maior qualidade de desenvolvimento.

Mas infelizmente nós não estamos prontos para essa disputa. Nossa cultura de desenvolvimento de software não está apta a concorrer em um mercado internacional e nossos desenvolvedores de software não estão atentos ao belo cenário de oportunidades internacionais que é delineado em torno de nosso país.

Fico buscando justificativas para o cenário que temos hoje e a única justificativa que consigo encontrar é de que esta cultura tenha vindo da época do desenvolvimento Clipper e infelizmente esteja perdurando muito mais do que o desejável.

Na época do desenvolvimento Clipper desenvolviamos sistemas para locadoras de vídeo, farmácias, o barzinho da esquina, tendo como usuários pessoas que, muitas vezes, nunca tinham visto um computador. Então era fácil planejar o sistema, definir um preço fechado x e fazer o sistema por este preço, porque o sistema era uma grande revolução no trabalho do usuário e este interferia muito pouco no processo de sua criação, até por não saber exatamente o que opinar.

Mas os tempos mudaram. A era da internet chegou, o voto é eletrônico, o governo pede declaração de renda pela internet, o povo brinca com a tecnologia e as necessidades evoluem. Os sistemas não são mais simples sisteminhas que rodavam em uma máquina isolada, mas agora são grandes aplicações de rede para atender aos negócios de uma empresa e envolvem o trabalho com servidores de banco, internet, correio eletrônico, etc,etc, etc.

Com toda essa evolução os sistemas agora exigem um planejamento muito maior do que o planejamento existente na era Clipper. A cada passo da evolução o planejamento se tornou mais e mais fundamental, se tornando mais e mais certo de que sem o planejamento o desenvolvimento do sistema irá naufragar.

Porém, infelizmente, ainda reina a cultura do desenvolvimento Clipper. Quando um empresário busca um desenvolvedor e diz : Quero um sistema ! O desenvolvedor passa um ou dois dias obtendo informações sobre como é o sistema, monta uma proposta com um preço x. O empresário discute, pechincha, mas acaba aceitando o preço x e o desenvolvedor começa o sistema.

Se você não viu nada de errado na relação empresário-desenvolvedor ocorrida acima, então CUIDADO ! Você é mais uma das vítimas contaminadas com o vírus da cultura Clipper !

A complexidade dos atuais sistemas de informação faz com que nem o empresário nem o desenvolvedor possam delinear em tão pouco tempo as complexidades de um sistema. Quando o desenvolvedor do exemplo acima começar a fazer o sistema ele vai descobrir que para atender as necessidades que o empresário possui o sistema precisará ter duas vezes maior complexidade do que inicialmente estava previsto.

Como resultado entra-se em um empasse : O empresário não deseja pagar mais, ele contratou o desenvolvedor para resolver o problema xpto e quer o problema xpto resolvido, não considera problema dele o fato de que xpto é duas vezes maior do que parecia ser. Já o desenvolvedor fica em um mato sem cachorro, sem saber como fazer para não ter que trabalhar de graça.

A conclusão é previsivel : prazos não cumpridos, sistemas com má qualidade, empresários acreditando estarem sendo lesados e, por fim, o mercado de desenvolvimento de software caindo em total descrédito por parte dos empresários.

O desenvolvimento de um sistema não pode ser tratado como um produto ou serviço fechado para o qual possa ser dado um preço fixo, X, e esse preço possa ser mantido. Os empresários que insistirem em ter essa abordagem por parte dos profissionais que contratam só terão um de 2 possíveis resultados : Se o profissional é inexperiente, o preço cobrado será razoável, mas o projeto irá fracassar, pois o desenvolvedor desanimará ao descobrir que subvalorizou o projeto (e isso sempre acontece). Por outro lado, se o desenvolvedor for experiente, cobrará 10 vezes mais do que o projeto aparentemente vale, pois sabe que quando os detalhes começarem a aparecer ainda assim o projeto estará dentro de um valor razoável para o desenvolvedor.

Nenhuma das duas opções é agradável para o empresário. Aceitar o fracasso ou pagar 10 vezes mais do que o projeto vale, tudo isso é muito desagradável e faz com que um investidor internacional prefira investir na Índia (lá, pelo menos, os softwares funcionam). Então como resolver o problema ?

O desenvolvedor precisa expor claramente ao empresário que é necessária uma análise do problema existente para que possa ser realizada uma definição do sistema. Neste ponto entra a técnica da análise estruturada ou UML, a critério do desenvolvedor. Como resultado da análise são gerados documentos descrevendo a arquitetura do sistema, é gerado o banco de dados e o cronograma do sistema. A análise não tem tempo previsto de duração, então a única forma justa de contrato é que o desenvolvedor receba por hora trabalhada.

Mas a análise não é algo estático. O trabalho de análise perdura durante todo o desenvolvimento do sistema, gerando mudanças na arquitetura do sistema. Novas descobertas são feitas a cada instante e quanto mais descobertas melhor para o empresário, que terá um sistema de maior qualidade.

Porém se neste ponto o desenvolvedor e o empresário acordarem um valor fixo X pela execução do cronograma definido na análise, mais uma vez haverão problemas. Por mais que a análise tenha sido bem realizada, sempre existem mudanças, a análise é algo vivo durante o desenvolvimento. Quando essas mudanças ocorrerem o desenvolvedor terá a desagradável tarefa de se dirigir ao empresário para negociar uma alteração contratual. O empresário culpará o desenvolvedor por não haver previsto essas características na análise, haverá então a tendencia a obrigar o desenvolvedor a assumir responsabilidade e culpa por algo que faz parte do processo natural do desenvolvimento de um sistema !

Mesmo que os atritos sejam poucos e razoavelmente bem resolvidos, ainda assim não é uma boa tática para o empresário usar a opção de contrato fechado. Isso porque, tendo conhecimento dos possíveis atritos que serão gerados, o desenvolvedor estará pré-disposto a não levantar debates com relação a novas descobertas de análise. Como resultado características que poderiam ser importantes para o bom funcionamento do sistema poderão ser deixadas de lado, afetando a qualidade do produto final.

Com isso a melhor opção para ambos os lados é o trabalho por homem/hora. Para o empresário, surge a certeza de pagar um preço justo pelo desenvolvimento, um cronograma cada vez mais próximo da realidade e um verdadeiro acompanhamento de progressos, pois o desenvolvedor não terá problemas em informar imprevistos com o cronograma. Para o desenvolvedor, um trabalho tranquilo sem que preocupações contratuais e financeiras afetem a qualidade do produto desenvolvido.

Então cabe aos empresários e desenvolvedores nacionais a tarefa de mudar a mentalidade nacional de desenvolvimento de software e preparar nosso país para tomar seu devido lugar no cenário tecnológico internacional. Cabe aos empresários e desenvolvedores nacionais abrir mais esse caminho para o crescimento de nosso país no cenário internacional. Vocês vão deixar essa oportunidade escapar ?



Envie seus comentários sobre este artigo

Nome :

E-mail :

Comentários :


Avise-me quando houverem novos comentários nesta página

Veja abaixo os comentários já enviados :

Nome : Fabiano Silva E-Mail : fabiano_silva@click21.com.br
Nao ha como discordar da abordagem realizada. Entretanto é perceptível o desejo do empresário de ter conhecimento do valor a ser investido para poder efetuar sua análise de custo x benefício.

A relação homem/hora fere esta premissa, sendo assim o que acontece é que os desenvolvedores - mesmo tendo conhecimento da inevitável mudança de escopo - terminam fechando preço x e preferindo renegociar ao longo do projeto.

O atrito e descontentamento de ambas as partes tambem é inevitável, mas antes gerenciar estes problemas do que perder o negócio.

O que voce acha?

Um abraço.
Nome : Dennes Torres E-Mail : dennes@bufaloinfo.com.br

É um problema muito difícil de resolver. Em minha opinião a solução começa na conscientização dos empresários. Mas como fazer isso ?
Nome : Luiz Guilherme E-Mail : sem@email.com
É. Já passei por todos esses problemas, não só no desenvolvimento de software como no suporte técnico também. Ainda pior, mesmo sem haver problemas orçamentais, um sistema difícilmente sai em sua primeira versão exatamente como se gostaria que fosse. Geralmente a melhor prática é colocar um protótipo rudimentar dos principais módulos a informatizar para rodar no cliente e, depois disso, fazer uma reavaliação das necessidades. Isso porque o usuário nunca sabe o que realmente quer ou precisa e o desenvolvedor não necessariamente conhece a especialidade do cliente (ex: desenvolvedor não é analista de investimentos). Assim, a única solução que vejo é conversar abertamente com o cliente e fechar um contrato de valor fixo mensal com reuniões mensais, quinzenais ou semanais para fechar metas do mês, acompanhá-las e rediscutí-las sempre que necessário. É preciso convencer o cliente de que software não é produto, é serviço. Um valor fixo mensal é algo mensurável, logo passível de ser gerenciado, orçado. A negociação do preço deve ficar atrelada à urgência do cliente na execução do projeto. Mais rápido = mais desenvolvedores = + caro.

Sei que muitas vezes é difícil fazer o cliente se convenser a assumir um "custo eterno", mas só funciona assim. Para o desenvolvedor, por outro lado, não vale a pena assumir um compromisso com alguém que não se compromente. Certo?

Obs: Considero que disponibilizar ao cliente os fontes do sistema é uma forma de demonstrar confiança no seu próprio trabalho, pois você mostra estar seguro de que ele não vai te trocar por outro, além de ser um ótimo argumento para eliminar outro tabú: a dependência direta de você.

Nome : Jair E-Mail : jair.romagnoli@gmail.com
Como sou desenvoledor Clipper há 20 anos, me sinto na obrigação de defender esta ferramenta.
Sou funcionário de uma metalúrgica que trabalha com corte laser, oxicorte, usinagem, correntes agrícolas e produtos sob encomenda. A empresa possui cerca de 200 funcionários e tem certificação ISO.
O sistema de informática que a atende é feito em Clipper e neste mes de agosto/2005, completou 18 anos de uso. Atende Compras, Vendas, Produção, Escrita fiscal e até pouco tempo atrás, também atendia Contas a Pagar e a Receber.
Estes 2 últimos já foram portados para Visual Basic com SQL.
Discordo do conceito de que Clipper é somente para "sisteminhas de locadora".
Meu sistema é multi-usuário e atende mais de 50 pontos de rede. Possui apontamento de produção em tempo real via código de barras.
Para a empresa não houve choque de implantação, pois o crecimento foi gradativo. E continua a ser aprimorado até que seu porte para nova plataforma esteja concluído.
Nome : geovanne E-Mail : geovanne.jorge@huthilservicedesk.com.br
Avise-me quando houverem novos coment?rios nesta p?gina