Documentação completa pode ser mais importante do que software funcionando?

Um pescador pode se encantar mais com a rede do que com o mar? Na bela poesia de Oswaldo Montenegro, pode sim. Um pescador pode se encantar pela beleza ou pela eficiência de sua rede de pesca. Há diversos tipos, com malhas diferentes, tamanhos diferentes, materiais diferentes e cores diferentes.

Mas se o pescador esquecer o motivo de sua existência, que é pescar, do que adianta ele ter os aparelhos de pesca mais eficientes, mais bonitos e mais modernos? O que define um pescador não são seus aparelhos, é sua habilidade, seu saber e sua capacidade de produzir.

Um analista de sistemas, um desenvolvedor ou um engenheiro de software também precisam ser muito habilidosos. E eles não podem, jamais, esquecer o motivo de suas existências: desenvolver software.

Contudo, percebo que muitas vezes (muitas vezes mesmo) esses profissionais atolam seus projetos em meio a um lamaçal de documentação inútil. Ficam tão encantados com os belos documentos que produzem, tão bonitinhos e organizados, que esquecem até de desenvolver o software. Se desenvolvem, é numa velocidaaaaaaaaaade… São modelitos os mais diversos de documentação, belamente chamados de “templates”, e outros nomes bem profissionais.

Ah, e não faltam referências também para eles. Os modelos de documento são geralmente “baseados” nos padrões intergalácticos dos excepcionais masters da documentação mega plus avançada e certificados pelo conselho universal das siglas mágicas de TI. Poxa, com tudo isso, pra que software? Uma documentação dessas já deve resolver todos os problemas do cliente.

Não me entenda mal, não é que eu não goste de documentação. É que eu gosto de documentação ÚTIL. Em outras palavras, de documentação que contribua significativamente para a construção do software. Para mim, é simplesmente absurda a ideia de que eu preciso construir um monte de documentos que não contribuem com a construção do software, gastando dezenas de horas e milhares de reais, só porque alguém escreveu em um livro ou sei lá aonde que eu tenho que fazer isso. Não tem lógica! (ou será que eu é que sou louco?)

Recentemente eu vi um projeto onde o software estava pronto e operando, o usuário feliz da vida, e o analista de sistemas me disse: “Agora vamos trabalhar na documentação”. What?!! A documentação não deveria ter sido insumo para a construção do software? Então, por que cargas d’água começar a construir a documentação depois que o software foi concluído? Ah, para uso a equipe de manutenção, entendi. Aquela equipe que certamente não vai nem chegar perto dessa documentação quando o sistema estiver com problemas e eles com 50 usuários pendurados no telefone. Pior ainda: essa documentação que é tão pesada e complexa, que em 3 meses vai estar absolutamente obsoleta e inútil.

Então, tá combinado, nada de documentação, certo? É claro que não! A documentação útil deve existir e é fundamental para o sucesso de um projeto de software. A diferença está na forma de construir software. Ao invés de construir aquela documentação extensa e pesada antes de começar a desenvolver ou, pior, depois de desenvolver, faça junto. Construa uma documentação leve, útil, com o objetivo concreto de ser utilizado para o desenvolvimento do software, e em seguida construa o software.

Isso pode ser feito em pequenas doses repetidas, e com a participação ativa do cliente/usuário. É mais ou menos assim: 1) saber como o usuário trabalha e conhecer seus processos, 2) especificar os requisitos, 3) construir os requisitos e testar, 4) validar com o usuário, e 5) implantar. Acabou essa dose. Comece outra.

De dose em dose o sistema fica pronto, atendendo a todas as expectativas do cliente, sem estressar desnecessariamente o time de desenvolvimento, e sem a necessidade de torrar uma fortuna em dinheiro e uma eternidade de horas com documentação que não agrega valor nenhum ao produto. Do ponto de vista de quem paga e de quem usa, o que interessa é o software funcionando do jeito ele eles precisam. E ponto.

Se a gente vai conhecer o trabalho do usuário ele já deve ter alguma documentação sobre isso. Se ele não tiver, uma opção seria construir algo leve, que no final documentasse as regras de negócio. Em seguida é preciso alguma documentação para conversar e contratualizar com o usuário os requisitos do sistema. De novo, algo leve e prático, talvez até desenhado a mão (mas pode usar ferramenta também, claro, se não for complicar a vida). Depois do Ok do usuário tem que ter um documento para passar para o desenvolvedor entender o que ele tem que codificar naquela “dose” (faz junto, colaborativamente). E pronto. Depois é só testar com base na documentação combinada com o desenvolvedor e homologar com base na documentação combinada com o usuário. Fazer os ajustes e implantar.

Então, no final das contas, documentação é importante? Mais do que importante, é fundamental. Mas não pode atrapalhar o verdadeiro o objetivo de todo mundo envolvido no projeto, que é o de construir software que atenda as necessidades dos usuários. Esse é o objetivo máximo, mais importante, e realmente encantador.

Tags:,

Envie um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *