Documentar um software é importante?
Documentação de Software – basta citar esse assunto em meio a uma equipe de desenvolvimento de sistemas para instalar uma polêmica. Isso não é necessário! Não temos tempo para isso! Documentar o sistema aumentará muito o custo do projeto!!! Essas e outras frases logo são ditas e lá está a tal da documentação mais uma vez esquecida. Porém será mesmo que podemos deixar de lado essa parte do projeto por achar que estamos jogando tempo e dinheiro fora? Quem nunca sentiu falta de uma especificação funcional ou daquele modelo de dados que ajudaria tanto a entender melhor o que precisava ser desenvolvido?
Muitas empresas hoje, não possuem um padrão definido para desenvolvimento de sistemas ou criam processos muito morosos com a exigência de uma extensa e complexa documentação. É o famoso 8 ou 80. Esses dois extremos certamente não são favoráveis ao bom andamento de um projeto, pois o primeiro nos leva a um produto desenvolvido “no escuro” e o segundo, se não houver um rígido controle e um alto grau de amadurecimento organizacional, nos leva a um cenário de caos com muitas normas e regras a serem seguidas o que estimula o abandono da documentação para que se possa cuidar de outros “fatores mais importantes” visando o cumprimento das metas de prazo e custo do projeto.
Quando não documentamos um sistema, na grande maioria das vezes, a análise do que deve ser desenvolvido é extremamente prejudicada.
Analisar corretamente o que está sendo pedido é parte fundamental para a entrega de um produto de qualidade e que atenda as expectativas do solicitante. É a análise, realizada interativamente com o cliente, que dará as diretivas do projeto, que esclarecerá as expectativas sob o que se espera receber.
Um escopo bem definido, documentado e entendido entre as partes certamente irá diminuir a frequência das alterações no decorrer do projeto e o retrabalho para acerto de erros por falta de entendimento inicial. Afinal de contas o combinado não sai caro, não é mesmo!!!
Então, qual seria a melhor maneira de lidar com a documentação de software? A resposta para essa pergunta não é única. Ela depende de cada organização. Cada empresa tem uma rotina diferente e precisa estar disposta a avaliar o seu dia a dia para entender qual é a melhor maneira de lidar com isso. Mas uma coisa é fato, a ausência total de documentação em um projeto para desenvolvimento de um sistema aumenta as falhas, as alterações de escopo, o retrabalho sem contar que, sem documentação, não é criada uma base histórica que poderia ser extremamente útil no entendimento do sistema por novos integrantes da equipe e nas manutenções futuras. A base histórica gerada pela documentação economiza tempo de treinamento e consequentemente dinheiro. A empresa que opta por não ter documentação, mesmo que básica, assume muitos riscos, principalmente o de ver aumentar o custo e o tempo do projeto, aquilo que achou que economizaria.
Sendo assim, talvez um “meio termo”, algo entre a inexistência de documentação e os processos morosos citados anteriormente possa ser uma saída viável, um início. Implantar um processo aderente ao dia a dia da empresa com uma documentação mínima, mas eficaz ao desenvolvimento pode trazer benefícios claros. Esse processo pode e deve ser evoluído à medida que a organização amadurece e com essa evolução as necessidades de documentação serão revistas e recriadas sempre conforme a necessidade da empresa. Uma documentação que traga informações úteis para os envolvidos no projeto e que seja de fácil atualização não precisa ser complexa. Se for básica, mas útil, todos os envolvidos conseguirão enxergar os benefícios brevemente (veja, brevemente pode não ser imediatamente) e com certeza o cliente será o maior beneficiado ao receber um produto final com a qualidade que ele esperava.
Em uma rotina cada vez mais corrida, pensamos sempre no que podemos eliminar para ganhar tempo. Porém, eliminar a documentação e análise de um projeto de sistema em nome da produtividade pode, além de não trazer o benefício esperado, ainda ser um complicador para o bom andamento do projeto.
Referências: