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
