Faça seu projeto falhar em 5 lições
No post de hoje veremos em 5 lições como você deve proceder para que seu projeto falhe completamente. Invariavelmente, se você não se empenhar na aplicação das dicas fornecidas aqui é bem provável que você não consiga fazer com que seu projeto falhe mas apenas que tenha um resultado medíocre que é o atraso do cronograma. Por isso, estude todos as lições para que você realmente consiga fazer com que seu projeto falhe.
Lição 1 – Analise, analise e depois analise
Isso mesmo. Seu projeto corre o risco de ser um sucesso se você não trabalhar bastante na análise do problema a ser resolvido. Já imaginou se no lugar de analisar você tivesse implementando algo?
Se o problema é simples e não demanda muita análise utilize a sua criatividade para aumentar o problema e tentando convencer o usuário (cliente) de que este problema que ele não tem é algo que ele deveria ter.
Lição 2 – Trate o projeto de software da mesma maneira que um engenheiro trata o projeto de uma ponte
Se você tratar o seu projeto como um projeto de software ele tem uma mínima chance de dar certo e isso é algo intolerável para a nossa missão. Faça diferente. Trate o seu projeto de software da mesma maneira que um engenheiro trata do projeto de uma ponte.
Para fazer isso com sucesso auto-denomine-se “Engenheiro de Software”, além de pomposo (já que você não tem um diploma de engenharia, não estudou Cálculo I/II/III/IV e não está registrado no CREA) representa melhor o trabalho que você fará no seu projeto. Isso implica que você terá que abandonar o título de “Desenvolvedor” ou “Programador” porque esses dois caras aí são caras que “desenvolvem” e “programam” e isso é algo que não devemos fazer.
Software como o nome diz é algo “soft” (maleável, leve, suave) se tratarmos ele dessa forma teremos sucesso no projeto e não é isso que a gente quer. Então trate o software como algo “hard” (estático, pesado, duro) e para nos certificarmos de que tudo dará certo (quer dizer, errado) trate ele como algo “hard” e “heavy” (pesado, grande). Para podermos ilustrar a nossa idéia:
Nada mais estático e pesado do que uma ponte (o caso da ponte da BR-116 é uma excessão à essa regra).
Engenheiros adoram usar coisas como PMI, Microsoft Project, Primavera, etc. Essas técnicas geram planilhas muito legais com cronogramas e tabelas cheias de informações facilmente geradas em uma planilha eletrônica convencional. Mas uma planilha eletrônica convencional não é reconhecida por PMIs e etc.
Adote a metodologia mais pesada que você conseguir adotar. Uma dica: RUP. Sugira a aquisição da caríssima Suite Rose para que você possa passar dias (ou meses) desenhando quadradinhos e setinhas. Assim vocês terão vários diagramas sexys para mostrar para o cliente em substituição à código implementado e funcionando. A metodologia RUP também adora documentações que é o assunto da próxima lição.
Lição 3 – Documente
Ao gerar documentação você estará dando uma importante contribuição para o insucesso de nosso projeto. Mas quando eu falo de documentação eu não estou falando apenas de um ou outro documento “levemente útil” como um resumo e/ou esboço de um diagrama de classes ou diagrama de ER. Eu estou falando de páginas e mais páginas de especificações, cartões, diagramas UML em sua plenitude (status, use cases, …), planilhas de todos os tipos, manuais e todo o resto que sua imaginação permitir. Lembre-se:
A documentação é uma boa técnica para que nosso projeto falhe porque além de você perder tempo fazendo ela no começo do projeto você vai ter que perder esse tempo todo novamente no término do projeto para “atualizar” a documentação (coloquei “atualizar” entre aspas porque o “atualizar” alí significa jogar tudo fora e fazer novamente).
Uma dica adicional nessa lição é: formato é muito mais importante que informação, portanto, deixe o designer que existe em você aflorar durante a confecção desta documentação.
Lição 4 – Fale “buzzwordês”
“O beans das business class precisam passar por um deploy” é uma frase que contribui muito mais que “As classes de negócio da camada model precisam ser entregues” para o insucesso do projeto, portanto, extenda seu buzzwordês. Alguns bons pontos de partida para isso é ir nos sites da IBM e Sun (principalmente a parte Java) e ler tudo que fizer referência à J2EE, e-business, etc. (dê uma olhada especial no produto Websphere da IBM… aquilo é um clássico do buzzwordês).
Essa lição aparentemente não apresenta nada prático que contribua para o não-andamento do nosso projeto mas acredite ela é fundamental para que nosso projeto fracasse.
Lição 5 – Adote o hype
Eu tenho uma paixão especial por essa lição. É a que eu tenho mais prazer em ensinar. A minha definição de hype é: tudo aquilo que não tem nada de inovador e mesmo assim promete resolver todos os tipos de problema. Os hypes são criados por pessoas de marketing e pessoas de marketing raramente sabem desenvolver software, logo, se você ‘comprar’ tudo o que eles te vendem é grande a chance de que nosso projeto fracasse e nossa tarefa se torne um sucesso.
Em alguns casos (raros) o hype pode até não ser a solução para todos os problemas, mas soluciona muito bem algum tipo muito específico de problema (mesmo que não tenha nada de inovador em sua idéia), portanto, cuidado com casos do tipo “vou usar XML para gravar uma informação estruturada num formato padrão texto” porque é exatamente pra isso que XML serve e nesse caso ele se torna útil (blerg!). Use XML em coisas para as quais ele não foi pensado: linguagem de query, linguagem de programação, arquivos pequenos de configuração, etc.
Prefira usar o “Enterprise jXML .NET” para fazer o seu trabalho do que usar algo que seja simples e funcional. Coisas como J2EE, EJB, JMS, etc são ricos em hypes, portanto, fique antenado à essas coisas.
Conclusão
É isso aí, com o passar do tempo eu vou passando algumas lições do “Curso de Projetos Fracassados” para que você sempre esteja por dentro das boas práticas para o insucesso de seu projeto.
*sigh*
Atualmente estou trabalhando pra uma consultoria e estou desenvolvendo uma aplicação Java (com Struts) que irá fornecer uma interface Web para usuários do ERP da empresa cliente.
O sistema usa Java/Struts porque o cliente escolheu assim e a consultoria que elaborou o projeto endossou a tecnologia que seria usada. Como eu precisava garantir o “leitinho da criança” e eu queria ver como funcionava esse tal de Struts e também dar uma ‘reciclada’ Javiana no meu cérebro topei o projeto e estou aqui.
Para fazer um mini-controle de segurança nesta aplicação resolvi desenvolver um “mini sistema de persistência de objetos em banco de dados relacional” para atender a uma demanda do sistema.
Eu havia escrito um “mini sistema de persistência de objetos em banco de dados relacional” para um projeto Python que eu tinha trabalhado a uns meses atrás. Ficou bem simples (porque senão eu usaria o SQLObjects que seria melhor) mas funcionava para o que eu precisava fazer. Levei 8 horas pra pensar e desenvolver ele inteiro.
Neste exato momento estou na minha 20ª hora de trabalho em Java e não tenho algo funcional. Vocês podem dizer “Ah! mas você conhece bem Python e não conhece bem Java!” mas eu retrucaria com um “Eu conheço Java e desenvolvi bastante em Java”. E ainda tem outros fatores que devem ser considerados:
- Eu já havia feito um sistema assim antes (em Python), portanto, não precisei elaborar nada dele porque já tinha a estrutura dele toda em mente.
- Estou usando uma ferramenta chamada jDeveloper da Oracle que disponibiliza um mooonte de facilidades como: suporte a Refactoring integrado (com funcionalidades que dificilmente existirão para Python pelo carater dinâmico da linguagem), integração com jUnit, sistema de ajuda integrado, etc. Ou seja, uma ferramenta com muito mais facilitadores do que o Vim que usei para desenvolver a minha versão pythoniana.
Ainda não mexi muito com o Struts para poder ‘avacalhar’ com ele da forma com que gostaria. Mas as primeiras impressões que ficaram é que é mais um daqueles frameworks onde você tem que saber mais XML do que Java para poder usá-lo.
Acho que no universo Java eles tentam fazer bastante coisa com XML para livrar o desenvolvedor da burocrática linguagem de programação que Java é.
PS. Não usei Hibernate, JDO, EJB, J2EE, etc… para persistir meus objetinhos porque levaria mais tempo pra eu configurar esses caras do que para desenvolver a solução toda. Além disso o cliente tem restrições com a utilização de determinadas bibliotecas / frameworks / tecnologias que ele não domina. Paciência, fica pra próxima vez a chance de conhecer mais uma coisa pra eu poder avacalhar (sim, porque eu não gosto de avacalhar com coisas que eu não conheço).
Python, Windows e exigências do ofício
Atualmente tenho trabalhado no desenvolvimento de um software de Webmail que será acessado via Wap (Wireless Application Protocol) e para que eu possa testar o funcionamento deste sistema precisei passar uma temporada usando Windows.
Alguns devem saber que eu simplesmente detesto o Windows (e acreditem, não é porque é um software da Microsoft, não gosto porque simplesmente é um péssimo software) e para que o sofrimento não fosse muito grande, tratei logo de instalar alguns softwares do universo Opensource em minha máquina. Além desses instalei também o Cygwin que trouxe um ‘sopro’ de felicidade ao meu trabalho.
Mas voltando ao assunto Python (que é sobre o que se trata esse Blog) eu acabei por instalar o Python 2.2 para essa tarefa (o servidor que rodará a aplicação de Wapmail usa um RHEL que disponibiliza a versão 2.2 do Python e instalar uma mais nova seria ‘politicamente complicado’) e instalei também o Python 2.4 para ter uma versão mais bleeding edge do Python.
Como fiquei sabendo somente um tempo depois que na máquina que rodaria a aplicação tinha apenas o Python 2.2 acabei por desenvolver uma quantidade considerável de código em Python 2.4 e quando fui rodar no Python 2.2… caos! desordem! fim dos tempos!… tá, não foi tudo isso, mas a aplicação quebrou em vários lugares e aí eu, pela primeira vez, comecei a notar que nem todas as mudanças de comportamento das bibliotecas do Python estão corretamente anotadas na documentação oficial da linguagem.
Trabalhar com versões diferentes de uma mesma linguagem sempre traz transtornos para o desenvolvedor (não importa a linguagem… já tive problemas do mesmo tipo com Java mas a solução demorou mais) e por isso fica registrada a dica aqui: verifiquem qual versão do Python e das bibliotecas que você vai usar antes de começar a desenvolver.
Antes desse projeto estava trabalhando em um outro que envolvia fazer integração de Python com o Internet Explorer e com o Microsoft Word. Para essa tarefa a única alternativa existente são os módulos para Win32 do Mark Hammond.
Vou dizer uma coisa pra vocês: É raríssimo encontrar um conjunto de módulos para Python que sejam tão completos quanto esse. Ele tem suporte a tudo o que você possa precisar para integrar sua aplicação com a plataforma Microsoft. A única coisa que é relativamente ‘sofrível’ é a documentação que basicamente é uma meia dúzia de arquivos e um acesso ao Microsoft Developers Network (que é tosco).
