Introdução
Aqui, forneceremos algumas diretrizes sobre como padronizar a documentação para uso dos departamentos responsáveis na edição das “Notas de versão”, bem como “Manuais” e outros documentos que possam ser editados para uso interno/externo. |
|---|
Índice
🖥️ Prints de tela
Nas documentações não podem haver prints de vídeo, desta forma devemos ter dentro dos documentos feitos pelos testers/desenvolvedores prints de telas com boa definição.
Incorreto: A imagem não pode ficar desfocada, com o nome de tela e nem a logo da empresa (Guarani) cortada.
Correto: Imagem com boa definição, apresentando logo da empresa sem cortes e a tela completa para melhor entendimento.
🟥 Grifos de tela
As imagens inseridas nos documentos devem ser grifadas com formas geométricas retangular ou quadrada no tom vermelho e na espessura 2px ou 3px. Não podem haver setas nas imagens para destacar nenhum campo específico.
Incorreto: Destaques em tela, não podem ser selecionados de outra cor e nem setados.
Correto: Os pontos destacados estão na cor padrão e não há setas na imagem.
📸 Imagens com conteúdos esmaecidos
Para ocultarmos as informações dos clientes é necessário que isso seja feito de uma forma que esteticamente não fique fora do padrão.
Incorreto: Documento com as informações ocultadas, não pode ficar com aparência de borrão.
Correto: Ocultando as iformações dos clientes para que nenhum dado fique visível e apresentável.
Incorreto: Não podem sumir as informações contidas nos campos, pois é necessário saber do seu preenchimento.
Correto: Nesta imagem, vemos como devem os ocultamentos dos dados dos clientes.
💬 Textos dentro das imagens
Não colocar indicações, textos ou explicações por escrito dentro da imagem selecionada para a documentação.
Incorreto: Colocar observações e ou apontamentos dentro dos prints.
Correto: Manter as imagens com boa resolução e sem poluição visual.
?? - Sistema print
Quando houverem telas de duas situações lado a lado, não colar uma sobre a outra, fazer separadamente as imagens.
Incorreto:
Correto:
Informações necessárias para documentar
Para fazermos uma boa documentação, quando o ticket é de uma “Solicitação” ele deve conter sempre o relato da ocorrência e a solução, para descrevermos para o cliente.
Primeiro exemplo:
 Incorreto: Uma documentação onde não há o relato da ocorrência e na solução não ficou explicado o que foi ajustado para descrevermos para o cliente. |
 Correto: O resultado na nota de versão, depois de buscar dentro dos tickets atrelados as possíveis soluções. |
Segundo exemplo:
 Incorreto: Na documentação (testers) não haviam informações suficientes para elaboração da nota de versão. |
 Documento do desenvolvedor  Correto: Foi utilizada a documentação do desenvolvedor para a solução, mas foi uma publicação com a limitação de informações |
Exemplo Ideal de Nota de versão
  Documentação exemplar contendo a Solução Simples e Solução Técnica |
 Nota de versão ideal |
