Neste artigo eu gostaria de falar sobre os documentos que são utilizados no gerenciamento de projetos. Quais são os documentos e, para que servem cada um deles.
Os documentos que serão apresentados são os mais comuns na condução de um projeto. É claro que é possível a existência de outros que deixei de mencionar, mas normalmente são estes os que utilizo na condução de meus projetos tradicionais. Ressalto ainda que de acordo com seu projeto, não é necessário a utilização de todos os documentos, alguns podem não existir ou simplesmente ser absorvido por outro documento descrito, como exemplo o documento de descrição funcional pode estar contido no documento de descrição do escopo. O importante é que as informações do projeto não sejam perdidas e estejam documentadas.
Documentos que iremos abordar:
Todos os documentos citados neste artigo estão disponíveis para download, clicando aqui. Os modelos são guias para te ajudar na elaboração destes documentos.
Declaração de Escopo
Quando o projeto é iniciado a declaração do escopo é o primeiro documento que deve ser criado. Neste documento como o nome já diz, está todo o escopo do projeto, tudo que será desenvolvido ao logo do projeto está contemplado no documento de escopo.
Este documento normalmente é criado por um analista de negócios, que levanta as informações com a equipe ou usuário que solicitou o projeto/demanda. Não é preciso sempre ter um analista de negócios, caso os usuários tenham habilidades técnicas estes podem tranquilamente elaborar esse documento.
Importante deixar claro que este documento servirá para auxiliar na condução do projeto, pois expõe as necessidades do cliente e, será imprescindível para validação do projeto.
Em um projeto quando todo o escopo é conhecido este documento é bem especificado e algumas vezes não necessário a utilização de documento de apoio. Quando este documento é bem especificado todas as necessidades dos desenvolvedores por informação do projeto, podem ser sandas neste documento.
Agora, o que normalmente acontece é que este documento não está completamente detalhado, seja por inabilidade técnica do elaborador, por não conhecer o projeto como um todo ou simplesmente por mudanças habituais que normalmente acontece em tempo de projeto.
Particularmente utilizo a declaração de escopo como um documento macro do projeto, onde está o objetivo, funcionalidades e requisitos gerais e, posteriormente vou detalhando o documento com ajuda da equipe de funcional e de desenvolvimento. Faço isso para que o projeto possa ir avançando, enquanto detalho as solicitações menos prioritárias posteriormente.
Declaração Funcional
A declaração funcional pode ser entendida como um documento de funcionalidades do projeto, neste arquivo especificamos as funcionalidades através dos requisitos funcionais, não funcionais, regras de negócio e etc.
Em alguns projetos esta declaração não é desenvolvida pois como é um documento similar a declaração do escopo, fica a critério da equipe que está atuando no projeto. Normalmente esta declaração é criado quando precisamos detalhar ainda mais os requisitos especificados na DE (declaração de escopo)
Este documento pode ser utilizando com diversos tópicos de informações como, fluxos, processos, caso de uso entre outros. O objetivo é que este documento possa sanar qualquer tipo de dúvida da equipe de desenvolvimento.
Documentação Técnica
A documentação técnica é desenvolvida pela equipe técnica do projeto, nesta documentação aprofundamos as funcionalidades detalhadas nos documentos funcionais e de escopo a nível de desenvolvimento.
O intuito desta documentação é evidenciar o que deverá ser feito tecnicamente para que as funcionalidades apresentadas nos outros documentos possam ser desenvolvidas. Algumas informações que constam no documento são: digramas de classes, diagrama de banco de dados, linguagens de desenvolvimento de código, arquitetura adota para o projeto, configurações de servidores de aplicação e banco de dados entre outras.
Estas informações serão utilizadas pela equipe que irá construir o produto, e são informações vitais para o desenvolvimento do projeto. Este documento é um dos mais importantes do projeto, pois devem ser detalhados no último nível, o intuito é que com esse documento em mãos qualquer equipe técnica, possa dar prosseguimento ao projeto caso, a equipe ou profissional anterior venham a sair do projeto.
Este documento também serve de base para criação de documentos de handover/operacional.
Caderno de Testes
O caderno de teste é um documento desenvolvido para auxiliar os usuários que irão fazer os testes na ferramenta. O caderno de testes é preparado quando a equipe de desenvolvimento finaliza a atividade e coloca para testes. Normalmente os testadores são os criadores deste documento.
No documento deve ter o fluxo da funcionalidade que será testada, para facilitar o teste, faça uso de imagens, processos e detalhe cada clique que deve ser executado no sistema. O testador deve dar o seu “de acordo” (OK/NOK) na verificação da funcionalidade e criar uma opção para que o usuário final possa dar o seu “de acordo” também (OK/NOK), caso outras “pessoas” realizem o teste devem ser incluídas no documento. Esses “de acordo” validam que as funcionalidades foram testadas e quais foram as pessoas/área que foram responsáveis pelo teste.
Importante deixar claro, que caso haja uma inconsistência nas funcionalidades testadas as pessoas que fizeram os testes são as responsáveis. E após a validação para realizar uma alteração será necessário seguir o fluxo de novo desenvolvimento.
Manual do Usuário
Um dos documentos mais trabalhosos para equipe do projeto e o mais desvalorizado pelo usuário é, sem dúvidas o manual do usuário (qual foi a última vez, se teve, que lemos o manual de como usar o celular ou manual do carro).
Este deve ser um documento muito bem detalhado e tem o intuito de ensinar os usuários em como utilizar a ferramenta e, constantemente está sendo atualizado a cada nova funcionalidade. O manual normalmente é criado após os testes na ferramenta é um documento que irá auxiliar o usuário final.
O manual normalmente é criado com bastante imagens/prints para ajudar na visualização do usuário. Ultimamente e focando no ambiente de software o manual do usuário tem ganhado forma, os novos manuais do usuário estão ganhando “vida”, podemos observar isso em sites e aplicativos que a cada nova funcionalidade é criado um tutorial iterativo auxiliando os usuários em como utilizar a ferramenta. Esta prática é essencial para ganhar aderência e facilitar o ensino do usuário.
Mesmo sem a possibilidade de criar tutoriais programáticos, podemos utilizar nossa imaginação para criar manuais que consigam engajar o usuário uma das ferramentas que gosta muito é Power Point neste é possível criar manuais muito mais customizados e dinâmicos que podem facilitar para ganhar engajamento dos usuários.
Documento Operacional
A documentação operacional é desenvolvida com o objetivo de realizar uma passagem de conhecimento da equipe que desenvolveu o software para a equipe que irá operacionalizar. Este documento pode atender a equipe de suporte como os "admins" da ferramenta. Quando digo “admins” são os responsáveis por criar usuários, fazer o perfilhamento e realizar alterações de parâmetros suportadas na própria ferramenta. É comum termos um manual de usuário para os "admins", mas não vejo problema conter esse tipo de informação no documento operacional.
A equipe de suporte já é uma equipe voltada para problemas e incidentes que podem ocorrer na ferramenta. Este documento deve demonstrar a arquitetura da ferramenta e onde estão os arquivos fontes, informações de servidores, banco de dados e acessos (que pode ser enviado em arquivo separado ou armazenado em sistemas seguros). Após preenchimento do documento normalmente é necessária uma reunião com a equipe de suporte para passagem de conhecimento e retirar eventuais dúvidas.
Esse documento é aprovado pela equipe de suporte e pode sofrer alterações conforme solicitado pela equipe de suporte, com o intuito de termos um documento o mais transparente possível.
Comments