Documentar Projetos de TI: Fardo ou Necessidade?

Esse caso acontece sempre de forma semelhante, com algumas peculiaridades de cada empresa ou projeto, mas em linhas gerais, é sempre o mesmo.

O Gerente Noçãoless™ (GN) ou <figura-que-não-entende-como-produzir-software-mas-acha-que-sabe> convoca os desenvolvedores para uma reunião onde um novo projetinho (calafrios nos desenvs) está se formando. Você já ouviu essa história antes, não é mesmo? Um projetinho, pequenino, baratinho, rapidinho de se fazer e manter. Tudo o que precisa ser feito já foi "levantado" em algumas atas de reunião e tudo são flores...

... até que a equipe de desenvolvimento começa a perguntar.

- Ahn, esse item aqui, "Criar um cadastro de clientes físicos e jurídicos.", o que exatamente o cliente quer?
- O GN™ volta com a resposta: são uns 20 campinhos, com pesquisa de CEP dinâmica, 18 campos de preenchimento, sendo dos quais 11 são obrigatórios e tem umas regrinhas de validação que eles querem também e... [mais algumas dúzias de requisitos entram].

Documentar é preciso, todos sabem disso, mas devido ao tamanho de alguns projetos, parece impraticável, um fardo burocrático e sem necessidade. Uma barreira para se chegar ao produto final, o conjunto de códigos que irá funcionar de forma coordenada e atender aos desejos do cliente.

De uma forma ou de outra, pessoas envolvidas com tecnologia entendem a necessidade de criar documentos, evidências, histórico e a indústria exige cada vez mais metodologias para gerar esse material de forma organizada. O maior problema atualmente enfrentado é justamente o custo da documentação.

Uma pessoa, ao encomedar o projeto de uma casa, entende perfeitamente os custos de um engenheiro ou arquiteto, ao projetar as plantas, calcular as quantidades de materiais, mão-de-obra, prestação dos serviços e obviamente, execução da obra. Tudo isso é documentado e o contratante paga por isso porque entende que sem esse plano e sem as plantas, nada irá sair do chão.

Agora o mesmo não é verdade para criar um aplicativo. Para reduzir custos, normalmente são cortados documentação e testes, justamente os dois pilares da qualidade. No final, ficamos, se muito, com um diagrama de base de dados mal feito. As atas de reunião dizem apenas linhas gerais como: quero uma casa de dois andares, com 3 quartos e cozinha ampla. A documentação verdadeira especifica quantos azulejos devem ser comprados para cobrir as paredes da cozinha, por exemplo. Em software, é isso que normalmente é cortado: a especificação, os casos de uso. Confia-se demais apenas em protótipos visuais e o cliente começa a mudar o escopo (scope creep, já falamos disso) porque ele disse na reunião que gostaria de uma interface divina.

Então, por falta de documentação, surgem falhas na comunicação entre as partes. O desenvolvedor pode criar algo formidável, mas que não era o foco do usuário: ele não precisava de um super cadastro, mas de um super relatório. Hoje em dia, testes de software ainda são propostos e projetados como um anexo ao desenvolvimento, como se fosse possível separar um do outro. Vejamos um exemplo simples abaixo:

Projeto XPTO

Planejamento e Documentação: Plano de Projeto, Casos de Uso, Diagramas de Classe, Base de Dados - 2000 horas
Desenvolvimento: Criar códigos, interface, montagem das telas, validações e toda a funcionalidade  e correções - 5000 horas
Testes: 3000 horas

É claro que estou simplificando enormemente a divisão de tarefas, mas normalmente cortam-se horas de testes e de documentação para economizar e no final, todos saem perdendo:

- O sistema possui funcionalidades demais, que serão pouco ou nunca usadas;
- Há um alto índice de defeitos e erros;
- Os prazos foram todos estourados;
- O cliente perde a confiança na empresa desenvolvedora;
- A equipe fica desmotivada com o retrabalho e horas extras (muitas vezes não remuneradas);
- O cliente fica sem um produto necessário ao seu crescimento.

Mesmo em metodologias ágeis, alguma documentação é necessária. A forma de se usar o tempo e nível de detalhamento mudam de acordo com cada projeto. Mesmo o Extreme Programming, Scrum e Iconix exigem algum planejamento, mas é bastante comum o desenvolvimento iniciar com rascunhos em papel, linhas gerais do que a pessoa quer e alguns links para websites com funcionalidades que o cliente deseja.

Para se ter uma idéia de como um projeto pode sair do controle se não houver uma boa dose de planejamento e boa comunicação, certa vez, eu estava ministrando o treinamento de uma ferramenta que havíamos desenvolvolvido. O Analista de Negócios/Requisitos acompanhava e anotava as observações dos usuários. O treinamento essencialmente transformou-se em 3 semanas de levantamento de requisitos com literalmente dezenas de pessoas. Um dos usuários abriu o GMail e disse: queria que o sistema funcionasse assim. Outro foi mais longe: bem que podia ter aquelas ferramentas de desenho e edição do Word.

O sistema era para Web e tínhamos 2 semanas para colocar em produção. No final, tudo deu certo e algumas funcionalidades do GMail foram criadas, como o autosave e a parte de edição também foi criada, usando um componente comercial. A empresa levou prejuízo porque não houve um planejamento prévio e a documentação era bastante escassa e quase inexistente. Melhorou quando começamos a congelar os requisitos e aplicamos princípios do Scrum, já que o RUP sairia 40% mais caro... ou não?

O fato é que com a experiência, percebe-se que documentação é chato de se fazer e atualizar. Não há sensação de conquista, mas quando um projeto começa a dar errado, é muito bom olhar para o cliente e dizer: olha aqui, você aprovou exatamente o que fizemos, está escrito. Podemos mudar, mas o novo prazo será xyz. E acredite, a visão que esse cliente terá não é de um chato mercenário, mas de uma pessoa altamente profissional, organizada e que sabe o que está fazendo, mesmo que ele tenha que pagar mais por isso.

Moral do Post

- Defenda o projeto com a palavra escrita.
- Acordos verbais e camaradagem só funcionam quando tudo vai bem. Quando o tempo fechar, aquele que possuir evidências é que sairá vencedor.
- O cliente sempre tem razão, exceto quando o que ele se contradiz com o que foi escrito e aprovado 2 meses antes.
- Cortar documentação é o mesmo que cortar qualidade. Lembre-se que mesmo a metodologia mais ágil ainda exige o mínimo, como um e-mail.
- O fardo de levantar requisitos detalhadamente e fazer protótipos antes de começar a construir telas é recompensado depois, com menos retrabalho e mais prazo para alterações que serão pedidas fora dos acordos iniciais.

Fonte: Bicalho's Memory About Fuck3d Projects