Fiquei algum tempo sem escrever, pois estava (e ainda estou) por demais atarefado, mas a algum tempo tenho pensado nesse artigo, que trata a análise de processos de uma forma bem genérica, mas não deixa de ser pertinente ao objetivo desse blog.
Primeiramente, eu gostaria de colocar, que esse artigo se destina aos profissionais plenos de informática.
Mas o que eu quero dizer com "Profissional Pleno" ?
Não é o CMMxx / ISO99999 da vida, nem o programador de grandes empresas, que trabalha dentro de uma série de regras de qualidade e produtividade, e na maioria das vezes, engessado, inclusive o cérebro, mas sim ao programador padrão do Brasil, que normalmente se forjou no mercado, e obrigatoriamente precisa de um conhecimento multidisciplinar, que envolve análise de processos, programação, vendas e suporte, não necessáriamente executados por uma única pessoa, mas que devem ser dominados pelo dono, ou em conjunto pelos sócios do negócio.
Com exceção de algumas empresas de maior porte, a maioria das empresas desenvolvedoras de software, e desenvolvedores free lancer do Brasil se enquadram no perfil acima, e a maioria desses empreendedores (uns 99%), tem na cabeça, ou na gaveta, um projeto que vai fazer ele tirar o pé da lama, um verdadeiro mapa do tesouro.
E pela criatividade do brasileiro, tem sim, muitos projetos que realmente são inovadores, alguns nas idéias, outros na usabilidade, outros na exclusividade, mas infelizmente poucos se tornam realmente um produto comercial rentável.
Daí vem a pergunta, onde está o erro ? O que não deu certo ?
Dentre muitas causas, algumas são por falta de preparo, falta de conhecimento, falta de estrutura, mas em alguns casos, o resultado se torna pouco útil devido ao uso da POU, pelos profissionais envolvidos no projeto.
Mas como definir um projeto que utilize POU ???
Normalmente é um projeto que utiliza muitos recursos da linguagem, e também do programador, o código é um código "fodão", muito louco, o programador quase tem um orgasmo com a "excelência" de código concebida por ele, mas abre mão de coisas muito importantes, como legibilidade, trabalho em equipe, e principalmente, praticidade do projeto final, no objetivo a que se destina.
Isso faz com que o resultado comercial daquele projeto, que seria o "ovo de Colombo", seja pífio, frustando quem o idealizou, e dependendo do tamanho do ego do "dito cujo", ele às vezes acha que as pessoas não estão preparadas pra maravilha que ele criou.
Mas como identificar se estamos praticando a POU ?
A característica mais forte, é quando você valoriza mais os meios que os fins, ou seja, o brilhantismo do seu código se torna mais importante que o resultado prático e a confiabilidade das regras do produto.
Normalmente, nesses casos, o cumprimento de prazos nunca é obedecido, e a legibilidade do produto final, normalmente é prejudicada, além de o resultado prático do produto não ser nem de perto alcançado.
Mas o que podemos fazer para sair dessa situação ?
Tenho algumas sugestões que vou citar em ordem de importância.
- Aparar o ego
- Estudar sobre a área que o produto se propõe a controlar
- Questionar a praticidade de uso das rotinas
- Criar uma sequência lógica para as mesmas
- Concluir o produto
- Testar em campo
- Estudar novamente
- Ajustar após os teste
- Aprender a vender (Mesmo que você vá terceirizar a venda, terá que vender a idéia ao seu parceiro comercial)
Se nos atentarmos para o fato de que em todas as áreas, a maioria das pessoas tem idéias que vão enriquecê-las, mas um menoria alcança realmente esses objetivos, vamos mergulhar nas indagações e pesquisas, buscar um maior aprendizado, tentar entender a cabeça do usuário, tentar criar produtos que realmente sejam prático e úteis, e nesse caso, podemos realmente aumentar as nossas chances de sucesso, e quem sabe o Brasil começa a mostrar o quanto é criativo.
Wesley
5 comentários:
Parabéns pelo post, Weslei. Por muito tempo, acredito que parte do que produzi foi exatamente assim. Muito código e pouco recurso para o cliente. Hoje, depois de ter estudando muito a metodologia XP, minha forma de programar é totalmente diferente.
Antes de tudo, parabéns pelo blog, gostaria que não ficasse tanto tempo sem postar mas como nem tudo que a gente quer é possível...
Sobre o Post, essa é sua visão do mercado provavelmente vc escreveu isso baseado nas suas experiências, eu por exemplo tenho outra visão:
O Importante é o resultado mas não adianta ter um resultado satisfatório com um MEIO ruim.
Trabalhei em duas empresas onde os programadores se gabavam dos recursos que o sistema oferecia mas a cada manutenção que tinha que dar no código era um lamento só tanto que nas duas empresas sugeri reescrever o programa do zero e adotar algumas tecnicas básicas de trabalho em equipe como Padronização de Código Fonte e Auditoria no mesmo. Hoje ambos os sistemas estão rodando como rodavam antes mas as alterações (por conta de legislação) são realizadas em menos de 2/10 do tempo que levava antes.
Concordo com você, anônimo, que a manutenção do código é imprescindível para o sucesso de um projeto, mas o que eu quis salientar com esse artigo, é o fato de que muitas pessoas tentam colocar tanta eficácia e conhecimento dos recursos da linguagem, que a primeira consequência do código é ficar ininteligível, fora o não cumprimento de prazos, etc, etc.
Parabéns! Gostaria de saber se posso reproduzir no meu site? http://www.pedro-araujo.com/
Não concordo com o post não, se o cara se intitula >>pleno<<, significa que o cara tem conhecimento de boas práticas e de desenvolvimento de software, logo o cara sabe que o código deve ser legivel, comentado, documentado, acredito que é possível utilizar o máximo que uma linguagem oferece e manter o código legivel, em minha opnião o atrapalha um projeto, é a análise mal feita, visto que, deve-se analisar >>BEM<< para depois estimar, já pensando nas soluções inteligentes e utilizando o máximo do recurso que a linguagem oferece.
Agora o que acontece muito é, empresas contratarem desenvolvedores Junior e coloca-los para fazer manutenção de código, e como bem sabemos Júnior não tem o conhecimento de um pleno (óbvio), daí que surgem os problemas, já que o cara nem se preocupa em entender o todo para se livrar do problema dele.
Postar um comentário