terça-feira, 13 de novembro de 2007

Documentação

Eu já havia comentado anteriormente, mas volto a bater neste ponto. A necessidade da empresa em reter o seu bem mais valioso: a informação.

No mundo de TI, principalmente, a rotatividade do RH costuma ser grande. Muitos trabalham por projetos (como PJ) e, como consequencia disso, acabam permanecendo na empresa por 2 ou 3 anos, em média.

E se a empresa não reter toda informação gerada neste período? Podemos dizer que ou a empresa gosta de ter produtos "caixa-preta" (onde não se sabe ao certo como funciona tudo, pois os responsáveis foram embora), ou a empresa fica refém de seus funcionários (se eles forem embora, a informação vai junto).

Notem a importância de se ter uma documentação sobre tudo o que está sendo gerado. É importante, não acham?

Temos então um cenário que podemos chamar de "gestão da informação". E este cenário, no universo de TI, não é dos mais favoráveis. Abaixo, listo alguns problemas relativos a isto:

1) Como documentar? Um dos principais problemas em TI é a falta de uma padronização para a documentação. Existem modelos, mas falta capacidade para adaptar isto para a realidade da empresa. Pegue um documento de visão do RUP (Rational Unified Process) e use ele completo em um projeto pequeno de sua microempresa. Não dá! Você está fazendo um "gold plating" na sua documentação, preenchendo informações que não seriam relevantes.

2) Qual a granularidade do documento? Outro grande problema é a visão que cada um tem da documentação. Um desenvolvedor tem o cacoete de abstrair muita informação. Geralmente a justificativa é "mas isso é óbvio!". É um erro grande, pois ele está assumindo que quem irá ler o documento está a par de tudo. Por outro lado, um especialista irá encher de detalhes o documento. O meu chefe certa vez falou "escreva como se fosse um manual para sua mãe ler e montar todo o sistema". Também eu considero um erro, pois apesar da máxima de que "quanto mais informação, melhor", alguns níveis de detalhes não são relevantes.

3) Como documentar um sistema? A palavra sistema geralmente está atrelada a software. Mas a bem da verdade é que sistema indica o TODO que envolve o projeto. Um sistema pode ser um leitor de código de barras que envia os dados para o servidor, armazena no banco de dados e depois fornece informações através de um (aí sim) sistema de informação. Então temos um problema bem grande aí: como documentar um sistema desses? Fazer um documento geral? Dividir em hardware, software? Dividir por áreas como requisitos, arquitetura, desenvolvimento, testes?

4) Como documentar com os recursos umanos? Calma, o erro de português é proposital :) Um dos grandes problemas de TI é de fato encontrar pessoas técnicas que tenham uma boa redação. Ao menos uma redação razoável. No meu projeto, felizmente toda equipe tem uma redação razoável, daqueles que a gente lê o documento e, apesar de alguns pequenos erros e omissões de dados, entendemos o sentido e podemos delegar sem problemas. Em um outro projeto, o gerente amigo meu está enlouquecido com o que está lendo nos documentos. Ontem mesmo ele me mostrou uma frase escrita por uma das pessoas. Eu não consegui acreditar que um universitário havia escrito aquilo. Não tinha pé nem cabeça, começo nem fim. Em TI, se você sabe escrever, vale a pena colocar isso em seu currículo.

5) Como fazer a manutenção da documentação? Sabemos que documentar é uma das coisas mais detestáveis por qualquer pessoa ligada a TI (salvo exceções, como eu! hehe). Então geralmente a tarefa de documentação é feita OU antes OU depois do desenvolvimento. Por quê? Pois ninguém vai ter saco de atualizar esta documentação. Então se foi feito antes, eles vão atualizar só o que foi crítico (mudança de classes de projeto, por exemplo). Se foi depois, aquela será a versão "final" do documento, aconteça o que acontecer. No fundo, sabemos que isso é errado. A documentação tem que estar sempre atualizada, para garantir a informação correta. Bem como ela deve estar sempre bem armazenada, de fácil localização.

Volto a ressaltar que o gerente de projetos deve estar bem atento a essa questão. De nada vai adiantar o projeto gerar um super-mega-produto, sem que depois não se saiba como este produto foi feito. A informação é o bem mais precioso da empresa. Cabe a nós sermos responsáveis por isto.

E isso que eu nem falei sobre a gestão da informação gerada nos projetos...... mas acho que isso todos nós sabemos né? :)

Abraços

Um comentário:

Anônimo disse...

Olá, gostei da matéria. Vc indica algum software especifíco para auxiliar no processo de elaboração da documentação? Pretendo desenvolver a documentação na empresa onde trabalho, e tb, um manual para o Plone (dá para perder-se na navegação das opções facilmente).