Muito se fala dos documentos relacionados à gestão do projeto, plano de risco, plano de custos e por ai vai. Mas, existe um documento tão importante quanto, que na verdade é um entregável. Se trata do documento do produto do projeto.

Já ouviram aquele velho jargão “Projeto Caracu. Seu chefe entrou com a cara, e você com o …”. Para bom entendedor meia palavra basta né?

Pois é. O que não falta por ai são projetos caracu. Trazendo para minha realidade, tive problemas com um deles semana passada. Tudo começou com um sonoro “DEU PAU NO BI (business intelligence)”!

Opa vamos lá atrás da fulano que foi o responsável pela implementação desse projeto. “Fulano, deu pau no BI. A carga de dados travou. Preciso do documento do produto onde estão descritas as integrações entre os sistemas que alimentam ele, bem como os servidores onde ele grava as informações, qual o nome do JOB que executa os pacotes do SQL, o mapa de processos etc. Onde está?”

É … a resposta foi esta mesmo … NÃO EXISTE DOCUMENTAÇÃO DO PRODUTO. Ebaaaa ótimo né. E ai começa aquela correria atrás de pingos de informação, algumas “meio-certas” outras erradas. Liga para o programador que desenvolveu, fala com o fornecedor do banco de dados, conversa com os analistas que trabalharam no projeto, abre os fontes dos programas para entender o que eles fazem. É uma maratona, sem contar a meia dúzia de seres desesperados com notebooks e nextel na mão te precionando e fungando no seu cangote esperando uma reposta.

Passadas umas 4 horas, aliás horas queimadas, jogadas no lixo, se tivessemos a documentação do produto, em no máximo 20 minutos teriamos conseguido compreender como o processo funcionava e assim detectar onde deu problema. Então, após aproximadamente 4 horas, acham que a coisa melhorou? Não, piorou. Descobrimos (Sim, descobrimos. Nada estava documentado realmente.) que o programa que envia informações para o BI, também alimentava o sistema de captação de pedidos via celular. Conclusão: problema no BI, problema para os vendedores que não conseguiam vender  e ninguém, nenhuma alva viva dentro da TI conhecia aquele processo completamente.

Pessoal, isso é muito sério. TODO projeto deve ter o documento do produto com detalhes e disponível em um diretório acessível por todos que necessitam.

O conhecimento não pode ser tácito, não pode estar somente na cabeça das pessoas que neste caso que relatei, de forma fragmentada, cada um conhecendo um micro pedaço e mesmo assim, juntando o que todos sabiam, não chegamos a 20% de tudo que o produto realmente era e fazia.

Se ainda não ficou claro porque deve-se documentar o produto, vou citar mais alguns exemplos:
- Agilidade para atender incidentes
- Menor tempo de indisponibilidade quando o sistema sair do ar
- Menos horas de análise, poupando os analistas para destinarem suas horas em atividades mais produtivas
- Ajuda em futuras implementações e customizações, auxiliando o time de desenvolvimento
- Conhecimento a respeito do produto disponível para todos
- E todos esses motivos, e outros mais, nos levam a um objetivo maior que é a redução de custos. Todos estes itens custam, e muito caro.

Mas, o que deve conter em um documento do produto? Simples (nem tanto vai …)! Todos os detalhes a respeito do produto!

No caso de um sistema, eu surgiro conter pelo menos as seguintes informações:

- Mapa de processos
- Se tiver integrações, layout das integrações, caminho físico onde os arquivos são salvos em caso de troca de arquivos, IPs de bancos de dados, bem como tabelas, indices.
- Descrição de cada uma das telas, explicando o que cada uma faz.
- Quem são os contatos que devem ser acionados caso o produto gere algum incidente

A medida é simples. A economia é IMENSA.

Abraço!