O desenvolvimento de software está em constante evolução. Plataformas como Zoho ou Salesforce oferecem soluções SaaS (Software as a Service) e disponibilizam, sem qualquer impacto para o software e dados dos clientes finais, novas funcionalidades, várias vezes por ano. Toda esta mudança constante origina uma necessidade crucial de criar documentação bem definida e corretamente estruturada durante o desenvolvimento de um projeto de software.
Uma das principais características de um projeto é ser único, o que faz com que não seja possível considerar e criar soluções standard de implementação. Por muito idênticos que sejam os requisitos, há sempre uma particularidade que obriga a uma análise e a um plano de ação de implementação.
Com uma documentação bem organizada, os fluxos a implementar começam a ganhar performance e qualidade. Ao existir uma adequada planificação de fluxos, estamos não só a investir numa diminuição de cronograma de implementação, mas também a garantir uma maior confiança no trabalho a ser entregue. Tudo isto faz com que a comunicação entre o Gestor de Projeto e o Cliente ganhe qualidade e o trabalho entregue apresente melhores resultados.
Por outro lado, a não documentação dos requisitos, no início do projeto, bem como a falha na anotação de todos os pedidos de alteração, durante o seu desenvolvimento, podem levar a várias interpretações do mesmo requisito, o que, consequentemente, leva a um desalinhamento de expectativas (como ilustra o exemplo da fig. 1) e à falta de mitigação de problemas mais complexos (gestão de riscos) que advêm do desenvolvimento de um software.
Fig. 1 – Diferentes interpretações dos stakeholders de um requisito.
Na LOBA, consideramos que a documentação é um fator chave para a eficiência de um projeto. Por este motivo, tentamos sempre que a documentação sirva de arranque do projeto, âncora durante o desenvolvimento e suporte para o restante tempo de vida do produto (fase da manutenção). Documentos como o Caderno de encargos, Lista de Requisitos, Dicionário de Dados, Documento Funcional, Documento de Integrações ou Documento de Testes Funcionais são criados para que se consiga abranger as três vertentes do desafio:
- Contextualização do problema: relata todas as necessidades que levam ao desenvolvimento do projeto;
- Detalhes da solução: explica a toda a equipa como será a implementação do projeto (quer a nível de Base de Dados que a nível de fluxos dos principais User Cases identificados);
- Definições técnicas: regista todas as especificações definidas durante a implementação da solução do projeto; dá a garantia de que o mesmo passou por um rigoroso plano de teste de forma a certificar a qualidade do produto.
Aplicando uma visão temporal, a documentação acompanha todas as fases de desenvolvimento do software (definição, desenho, implementação, integração e manutenção). Na figura seguinte, tentamos replicar usando o modelo RUP, que demonstra em que fases do projeto são criados os documentos mencionados.
Fig.2 – Modo RUP ajustado à documentação
Casos práticos:
- Aplicação de Gestão Clínica: A definição de funcionais e mockups ao longo do projeto resulta numa total confiança por parte do cliente no trabalho realizado, bem como num desenvolvimento à medida capaz de colmatar todos os problemas inerentes ao software antigo.
- Aplicação de Gestão de Projetos e custos associados: Através da apresentação da estrutura funcional de todo o projeto, o Cliente começou a perceber a forma de atuação do sistema, o que facilitou a identificação de exceções que deveriam ser contempladas. Após a aprovação, a implementação demorou 3 semanas.
- CRM + Aplicação comercial e de Merchandising : Toda a grandeza e complexidade deste projeto foi devidamente documentada, resultando numa implementação de qualidade e numa total confiança e satisfação por parte do cliente.
Em suma, na LOBA, mais do que um mero preciosismo, a documentação é uma forma de enaltecer um projeto, protegendo o resultado final e garantindo o envolvimento total da equipa em todo o trabalho efetuado.
