quarta-feira, 14 de maio de 2008

Faltam programadores no Brasil

Há alguns meses, li um artigo do Plantão Info (http://info.abril.com.br/aberto/infonews/) sobre a carência de mão-de-obra no setor de software brasileiro (http://info.abril.com.br/aberto/infonews/122007/18122007-1.shl). É um artigo interessante que confirma algo que já suspeitava: faltam programadores no Brasil. Por isso, é comum encontrarmos profissionais de outras áreas trabalhando com software. Já vi de tudo nessa vida. Administradores, advogados, teólogos e até médicos foram parar na área de desenvolvimento de sistemas das grandes empresas. Qual é o resultado disso? O resultado é que as empresas brasileiras gastam horrores com treinamento, perdem em produtividade e em qualidade. Além disso, não conseguem concorrer com as empresas lá fora.

No artigo citado, encontrei vários comentários de supostos profissionais desacreditando o artigo. Alguns desses profissionais, aparentemente bem qualificados, já estavam desempregados há meses e, por isso, acreditavam que a demanda por programadores não era tão grande como o artigo colocava. Não sei exatamente qual a situação dessas pessoas, mas percebo realmente uma demanda crescente por programadores. Basta olhar as ofertas de empregos. Aqui em Brasília, onde moro, esses profissionais são disputadíssimos. Os salários não são lá essas coisas, é verdade. Mas isso é assunto para os economistas. Por tudo isso, aí vai uma dica para aqueles que querem investir em uma profissão: seja um bom programador!

Formação superior na área é desejável. Mas você pode provar que dá conta do recado se tirar algumas certificações. Bom raciocínio lógico e matemático e gostar de se atualizar e de ler são essenciais para quem quer ser bem sucedido no setor de software. Se você está começando agora, um bom ponto de partida é estudar modelagem de dados. Depois disso, pode começar a estudar programação propriamente dita, mas não deixe de ler um pouco sobre análise e projeto de sistemas. Escolha uma linguagem (Java e Python estão em alta) e um ambiente (existem boas opções que utilizam software livre). O próximo passo é se certificar. Futuramente vou publicar um roteiro mais detalhado para quem quer se tornar um programador. Também estou preparando outro artigo sobre o futuro do desenvolvimento de software e como isso afeta a vida dos programadores.

quinta-feira, 8 de maio de 2008

Documentação de software: vale a pena?

Hoje vou levantar um assunto polêmico: documentação de software. É incontestável a importância da documentação em quase todo processo de desenvolvimento de software. Documentar software traz diversos benefícios para a equipe de desenvolvimento. Mas não vou perder tempo aqui citando esses benefícios. Não faltam textos sobre esse tema. O que falta é bom senso na hora de decidir se um artefato de documentação deve ou não ser produzido.

Afinal de contas, para que a documentação serve? Serve para três propósitos principais: reduzir os riscos no início do desenvolvimento, facilitar a manutenção e, se for o caso, viabilizar a subcontratação. Na sua organização, talvez a documentação de software sirva a outros propósitos. Mas vamos nos concentrar nesses três, por enquanto. Vamos analisar cada um deles com um pouco mais de detalhe.

Reduzir os riscos no início do desenvolvimento

Quanto mais informação tiver sobre um sistema, menor é o grau de incerteza do desenvolvimento. Por exemplo, um levantamento de requisitos bem feito e com um razoável nível de detalhe vai evitar "surpresas" no meio do desenvolvimento. Mas a produção de artefatos de documentação tem um custo alto se comparada com outras abordagens para reduzir a incerteza de uma demanda de software. Cabe a cada equipe avaliar o seu custo de produção de alguns tipos de artefatos e decidir por aqueles que apresentam um menor custo e um benefício similar. Por exemplo, talvez uma lista de casos de uso seja suficiente e, ao invés de detalhar os fluxos de cada um deles, se possa adotar uma abordagem envolvendo técnicas de prototipação.

Facilitar a manutenção

Outro propósito da documentação é fornecer subsídios à pessoa responsável pela manutenção de um artefato de software. Ter em mãos um modelo de dados ou qualquer outro diagrama facilita a execução de qualquer alteração. Contudo, perceba que muitos artefatos de documentação são pouco ou sequer consultados diante da necessidade de uma alteração. Mesmo aqueles que poderiam ser consultados às vezes estão desatualizados – o custo de atualização é muitas vezes alto. E pode ser até que a documentação exista, esteja atualizada e seja útil para a manutenção. Mas neste último caso, a rastreabilidade dos artefatos de software pode não existir ou não ser confiável. O fato é: é alta a probabilidade de a sua documentação não servir simplesmente para NADA. Assim, vale a pena verificar com a sua equipe se a documentação está sendo atualizada e se ela é vista como útil pelos seus desenvolvedores.

Viabilizar a subcontratação

Subcontratação é um assunto delicado. Às vezes a empresa subcontratada estipula no contrato uma gama de artefatos de documentação que acabam por contribuir pouco para reduzir o grau de incerteza e aumentam o custo daquela que contrata. Às vezes é tão caro produzir a documentação exigida quanto desenvolver o software propriamente dito. Quer um conselho? Inclua no contrato um acordo de níveis de serviço e encontre uma forma de incluir a subcontratada desde o início do processo – de preferência já no levantamento de requisitos – e deixe que ela produza seus próprios artefatos.

Conclusão

É claro que falando assim tudo PARECE muito simples. Na prática você terá que ir substituindo seus artefatos de forma progressiva, sempre provendo o treinamento necessário para os membros da sua equipe. Sinceramente, acredito muito pouco em qualquer documentação. Na prática, as empresas acabam quase sempre dependendo das informações contidas na cabeça de cada pessoa. Mas não adianta ser tão radical – escrever sempre é bom para clarear as idéias. Pensando nisso, acho razoável considerar a produção dos seguintes artefatos de documentação:

- Lista de casos de uso.
- Modelo de dados.
- Protótipo de telas e/ou relatórios.
- Diagrama de componentes.
- Comentários de código (esse é o mais IMPORTANTE).

terça-feira, 6 de maio de 2008

Desenvolvendo software em uma grande empresa

Quero falar com você, programador, analista de sistema ou gerente de projetos. É bem provável que você, assim como eu, trabalhe em grande empresa onde os sistemas são críticos para os negócios da corporação. Em uma empresa assim, não é fácil manter a produção de software sob controle. É comum observarmos problemas de retrabalho, várias pessoas fazendo exatamente a mesma coisa, processos de desenvolvimento que não agregam valor e assim por diante. A lista de problemas parece não ter fim. E lá estamos nós no meio desse caos tecnológico. As vezes fico desanimado em ter que percorrer um emaranhado de soluções para resolver problemas tão simples. As vezes fico desesperado sem saber O QUÊ e COMO desembaraçar essa trama. E você? Também passa por isso no seu dia a dia?

Inauguro esse blog para publicar uma série de artigos sobre o CAOS que impera hoje nas áreas de tecnologia de grandes empresas. Espero contribuir para o pensamento crítico de todos os envolvidos, especialmente aqueles que tem o poder de mudar. Mas não me refiro apenas aos executivos e gerentes. Todo aquele que tem iniciativa também pode fazer algo para diminuir essa confusão. Boa leitura!