De Agnóstico a Evangelista

Para contar esta história, eu vou ter que fazer uma contextualização da minha vida acadêmica e profissional. É bom ressaltar que são minhas experiências e opiniões pessoais e que respeito opiniões que sejam divergentes destas, inclusive grandes amigos meus discordam do que vou dizer.

Fiz graduação em Informática na UFRJ. Desde o início da graduação descobri na programação um grande prazer. Durante o ciclo básico, por vezes tomei bomba nas matérias matemáticas, devido às viradas de noite programando para as matérias que envolviam programação, ou por mero hobby.

Com o fim do “ciclo básico”, as matérias mais pesadas ligadas à matemática foram escasseando ou ficando mais atreladas às matérias de programação, o que eu gostava. Eu programava muito bem sozinho. Em trabalhos em grupo havíamos firmado o mesmo grupo desde o início da faculdade e optávamos sempre em dividir tarefas, ou trabalhos, cada um fazia o trabalho de uma matéria, o que não era lá muito correto. Quando tentávamos programar em conjunto, como uma equipe, não dava certo, não era produtivo. Comecei a ficar apreensivo, afinal de contas, quando eu chegasse ao mercado eu trabalharia em equipe e precisava saber como lidar com isso.

Eu estava ansioso pelas cadeiras que envolviam gestão de projetos, equipes e suas metodologias, principalmente para saber como colocar várias pessoas para programar juntas com produtividade. Nossa, foi uma das maiores decepções da minha vida! Quando comecei a escutar as aulas de Engenharia de Software, na mesma hora eu pensei: “Isso é charlatanismo!” É um comentário forte e passional, de fato.

Minha decepção aumentou quando em outra matéria vi a mágica do cálculo dos pontos de função, esta uma das práticas mais bizarras que já vi. Primeiro pela simplicidade (no sentido negativo) do método, afinal de contas eu havia até então trabalhado com integrais múltiplas, transformadas, etc. Ferramental matemático complexo que me permitia trabalhar com modelos complexos do mundo real. Quer dizer então que estimativa de desenvolvimento de software, um modelo super complexo, seria feito usando somente as quatro operações básicas? Soava-me como astrologia. Em segundo lugar por tratar a produtividade de pessoas envolvidas no desenvolvimento de maneira linear, era uma premissa muito rala. O terceiro lugar era o que mais me incomodava, a estimativa de pontuação para cada funcionalidade. Eu não sabia fazer isso direito, talvez não fosse um problema do método, mas meu, eu não sabia exatamente o que seria cada funcionalidade de antemão. Postulei então minha Primeira lição: Engenharia de Software é charlatanismo.

Naquela época, das linhas de pesquisas que existiam no nosso meio, duas mantinham mais contato com o mercado: Banco de Dados e Engenharia de Software. Teoricamente Engenharia de Software deveria agregar todas as pessoas interessadas em gestão de projetos e Banco de Dados deveria agregar as pessoas que estivessem interessadas nas implementações de SGBDs e técnicas que gravitassem em torno do armazenamento de dados em geral. Mas o que acontecia é que as pessoas descontentes com o que viram em Engenharia de Software acabavam indo para BD meio que por osmose; este, de certa forma, foi meu caso. Eu gostava das questões ligadas a implementação de um SGBD, mas eu não seria o cara a inventar a próxima árvore B+*.

Perto de me formar eu trabalhava em um projeto que chegou a ter uma equipe com mais de 30 pessoas entre gerentes, consultores, analistas e programadores. Até então eu havia assumido que tudo aquilo de Engenharia de Software era uma balela, que era uma historinha que contávamos para o cliente e um calhamaço de folhas que imprimíamos para justificar a complexidade de nosso trabalho. Nesta época eu já havia conhecido a UML, mas aquilo entrou na minha cabeça da seguinte maneira: “uma nova forma de dizer as velhas mentiras; ao invés de DFD , agora é Caso de Uso e assim por diante”. Foi então que tomei o segundo susto, vi algumas pessoas que eu considerava (e considero) levando aquilo a sério. Na verdade eu, como “homem-banco-de-dados” já levava a sério a confecção de ERs, mas não todos aqueles artefatos da UML. Eu não via benefício naquilo, mas enfim, se pessoas em que eu confiava estavam fazendo aquilo com seriedade e eu estava lá para aprender, resolvi dar crédito.

Pouco tempo depois me peguei gastando horas para acertar a posição de linhas ou bonequinhos nos diagramas nas ferramentas case já com o cérebro anestesiado. Um dia tive aquele clique. Opa! Não é para isso que estão me pagando, ou melhor, eu não quero receber para fazer isso. Reposicionei-me no projeto e comecei a trabalhar no desenvolvimento de componentes visuais e de acesso a Banco de Dados para o Delphi que seriam utilizados pelos outros desenvolvedores. Voltei a me divertir e infelizmente isso foi, durante muito tempo, o mais perto que cheguei de trabalhar desenvolvendo em conjunto com uma equipe. Mas a evolução da documentação no projeto continuou, como a documentação era feita conforme os requisitos iam sendo colhidos, elas estavam sempre atrasadas e sempre iam sendo modificadas.

Em algum tempo quem não gostava (ou não sabia) programar fazia e evoluía documentação e quem gostava se preocupava somente em programar. Esta separação contribuía para aumentar a distância entre uma coisa e outra. Uma das piores coisas que verifiquei foi quando uma das pessoas envolvidas no projeto, tida como uma das papas de engenharia de software no Brasil chegou com um calhamaço de folhas e anexou à documentação do projeto. Eu e nenhum dos outros desenvolvedores sequer leu e nem tomou ciência do que se tratava aquela documentação. Segunda lição: Documentação sempre fica desatualizada, defasada e é considerada boa quando consome uma boa quantidade de papel, principalmente se for dividida em volumes e encadernada com capa dura.

O projeto continuou, mas eu acabei saindo dele e dos meus planos de vida acadêmica. Acabei recebendo uma proposta tentadora de uma joint-venture suíço-brasileira e fui trabalhar numa área enxuta de TI desta empresa. Desta experiência eu fui ter um novo aprendizado. A equipe era eu e mais uma pessoa e tocávamos projetos sozinhos ou em dupla e fazíamos muito rápido. Por quê? Pela não necessidade de documentar, de ter que explicar para muitas pessoas o que foi feito. Para se ter uma idéia, em três meses fizemos todo nosso projeto de e-Banking. Nossa matriz, em Genebra, estava fazendo seu projeto de e-Banking há três anos e ainda não havia sido lançado. A complexidade não era a mesma, é verdade, mas nós éramos uma equipe de duas pessoas contra duzentas pessoas que existiam em Genebra.

Eles ficaram descrentes da segurança e da parrudez de nosso sistema, nos fizeram mudar a camada de autenticação, depois nos fizeram mudar nosso ambiente de Linux para Solaris, por fim, não satisfeitos, contrataram uma unidade de negócio de auditoria da HP para tentar achar alguma falha a ser explorada. Passamos por todos os testes. Quando fomos colocar o sistema em produção, o que eu fazia em alguns minutos no meu ambiente no Brasil, eu tive que falar com 5 pessoas em Genebra e ainda demorou algumas semanas. Terceira lição: se der para fazer sozinho, ou com pouca gente, é bem melhor e mais rápido.

Alguns anos depois me tornei gerente de TI do Grupo Santa Isabel, que possui unidades de negócios distintos: Construção / Incorporação Imobiliária, Administração Imobiliária e Hoteleira, Agro-negócio e é empreendedora de Shopping Centers. Deparei-me com um mar de questões a serem tratadas da gestão anterior, que não vale a pena citar aqui para não tornar este artigo mais extenso, mas levando em conta apenas a questão dos sistemas de informação, vi o seguinte: existiam muitos sistemas de informação desenvolvidos internamente para o porte da empresa. Estamos falando de cerca de 250 usuários e na época cerca de 30 sistemas de informação diferentes, com ferramentas de desenvolvimento diferentes e banco de dados distintos. Havia necessidade destes sistemas se intercomunicarem, mas as intercomunicações deles, devido aos problemas de arquiteturas distintas e requisitos mal mapeados, eram falhas. Não fazia sentido termos tantos sistemas tão falhos.

Na avaliação do desenvolvimento de novos sistemas verifiquei que o custo de desenvolvimento principalmente para unidade de negócio de construção e incorporação era muito elevado e já estávamos vivendo uma época de comoditização de software (menor do que apregoada pela mídia, mas de fato estava ocorrendo) e verificamos que existia um pacote ERP que atendia nossas principais necessidades, de forma que optamos por adquiri-lo. Outro fenômeno eram os projetos Open Source, que de certa maneira ajudavam neste movimento de comoditização. Em outras necessidades pontuais dentro da empresa, verificamos que alguns projetos Open Source com alguns ou as vezes nenhum ajuste nos eram adequados, como foi o caso do nosso sistema de helpdesk (HelpMeICT), de pesquisa (PHPSurveyor) e de eDMS (Owl). Quarta lição: Se o software que você quer fazer já existe, não o faça.

Infelizmente nem todos os softwares que precisávamos existiam prontos, pagos ou não, e ainda também deveríamos dar manutenção nos softwares existentes até serem substituídos. Como disse havíamos colocado um sistema de helpdesk para registro e controle de solicitações para nossa equipe de suporte e havia funcionado bem. Ingenuamente tentei colocar um sistema de gestão de projetos, seguindo o mesmo raciocínio, para minha equipe de desenvolvimento. Depois de testarmos alguns acabamos escolhendo o Tutos. Minha idéia era delegar as atividades através do Tutos e cada desenvolvedor estimar o tempo de desenvolvimento. Desta forma eu tinha uma ferramenta para criar as atividades, um controle das atividades pendentes, em execução, sendo executadas e de brinde, no final de tudo, eu ainda ganhava de graça, gerado através destes dados, um diagrama de Gantt, o que seria muito bonito para eu colar na parede, já que uma das unidades de negócio forte dentro do grupo é construção e incorporação e nada melhor do que um cronograma para dar visibilidade a todos do que estamos fazendo.

Foi um fracasso total! Era perfeito para mim, eu tinha um claro incentivo usando este sistema, mas por que não funcionou, se o mesmo, mantidas as proporções, havia funcionado para minha equipe de suporte? Eu só fui entender esta tempos depois. Eu tinha incentivo, mas a equipe de desenvolvimento não. Eu iria ter o meu controle, iria ter meu diagrama, mas a equipe de desenvolvimento só iria ter mais trabalho burocrático e não ia ganhar nada em troca. Para o helpdesk funcionou, porque as estatísticas de helpdesk ajudavam na tomada de decisão. Por exemplo, se estivesse tendo muito chamados relacionados à um departamento específico, certamente havia um problema localizado, além disso, era comum o usuário reclamar de um atendimento realizado e o registro do atendimento ajudava a dar visibilidade que o atendimento era tratado de maneira séria pela equipe de suporte e que o que estava registrado nem sempre batia com o que foi dito pelo usuário. Quinta lição: ferramentas e metodologias só funcionam se todos envolvidos no processo têm a sua parcela de incentivo.

Como disse, eu só fui descobrir porque não deu certo a utilização do sistema de gestão alguns meses depois. Quem já ficou até tarde zapeando os canais na TV já deve ter visto aqueles programas evangélicos onde as pessoas dão seu testemunho de como tinham uma vida turbulenta e, depois que encontraram o caminho da luz, como tudo mudou. Eu me sentia como a pessoa com a vida turbulenta que procurava uma solução, eu já tinha o livro do Vinícius há algum tempo, mas ainda não o tinha lido. Resolvi saber um pouco mais deste XP que não era o Windows e fui me surpreendendo. Li o livro mais ou menos na mesma época que li o livro Freakonomics e as semelhanças entre os dois eram incríveis. No fundo os dois abordavam como o senso comum pode estar errado, sendo que o livro do Vinícius tinha um foco específico, desenvolvimento de sistemas e apresentava uma solução para isso: XP.

Ok, estamos perto de eu dizer que XP é a solução para meus problemas, finalzinho previsível, mas é bom falar antes que eu sou na essência, intuitivamente, um cara anti-XP. Eu sou o tipo de cara que gosta de fazer a solução mais generalista possível, prevendo tudo que pode dar errado, tudo que o usuário pode pensar e, claro, sempre dando soluções overengineered. Exemplo? Que tal este programa cliente / servidor com uma placa acoplada na paralela e que a única coisa que ele faz é abrir a porta da minha sala? Então porque eu decidi optar pelo XP? Eu gostei das argumentações, mesmo sendo contra o que eu intuitivamente acreditava e como tudo mais não tinha funcionado, decidi apostar. E não é que a aposta está dando certo, esta semana termina o segundo release do Projeto Lucidus e mais uma vez estaremos dentro do prazo.

Errata da Quarta lição: Se o software que você quer fazer já existe, não o faça, a não ser que você tenha certeza que vai fazer melhor e que isso é um diferencial para seu cliente.

Sexta lição: XP funciona, mas além de coragem, você precisa controlar sua intuição, pois até hoje você se educou a pensar de uma maneira assumindo determinadas premissas e XP assume outras.

Chego ao fim deste artigo explicando o título. Um agnóstico, é diferente de um ateu que não acredita em nada, segunda a definição do Wikipedia, o autor do termo agnóstico foi o biólogo britânico Thomas Henry Huxley - avô paterno do escritor Aldous Huxley (autor do romance distópico Admirável Mundo Novo) - numa reunião da Sociedade Metafísica, em 1876. Ele definiu o agnóstico como alguém que acredita que a questão da existência ou não de um poder superior (deus) não foi nem nunca será resolvida. Da mesma forma eu era agnóstico quanto a Engenharia de Software (clássica). Eu sabia que deveria existir alguma maneira eficiente de se gerir projetos de desenvolvimento, mas o homem, na sua baixa capacidade intelectual, nunca conseguiria atingir a evolução necessária para desenvolver estas técnicas. Agora sou um evangelista entusiasmado, como o ex-drogado que dá seu testemunho no programa de TV. Eu acredito que podemos gerir projetos de software de maneira adequada. Basta assumirmos nossa humanidade e não querermos prever tudo que temos de fazer, que aí sim fugiria da nossa capacidade intelectual, mas trabalharmos com pequenos passos de bebê como apregoa o XP.

Alexandre Novello, Gerente de TI do Grupo Santa Isabel