Sem a documentação nada pode ou deve ser feito em TI, então quando estiver em um projeto, pensando ou mesmo tratando sobre uma demanda ou tarefa.
Existem procedimentos que devemos seguir para que minimizemos os problemas, mas não existem procedimentos para que os resultados de uma determinada rotina ou processo sejam avaliados de forma adequada pelos usuários.
Com este panorama tentamos através de assinaturas em documentos específicos, garantir de alguma forma que fizemos a nossa parte. Isso garante alguma coisa?
Bem, garante apenas que o Cliente concordou com o que fizemos. Mas e a parte dele?
Depois de um custo emocional e financeiro para se chegar num bom resultado implantado, o Cliente pode operar e gerir inadequadamente o sistema e dizer que deixamos lá uma “bomba relógio”? Afinal, nós e os Clientes estamos em busca de culpados, ou em busca de resultados?
Outro ponto: É tão enfadonho seguir uma metodologia, quanto gerar as documentações necessárias.
Consumimos muito tempo gerando um cronograma de atividades e no resultado final as atividades acabam sendo realizadas de acordo com a disponibilidade dos usuários, ou seja, sempre fora das datas definidas.
Este post era para ser sobre o gerenciamento de conteúdo. Mas como falar de gerenciamento, e de conteúdo, sem falar daqueles que teimam em criar obstáculos?
O gerenciamento de documentação, eu diria, é tão ou mais importante que a própria produção tecnológica em si. E quando eu digo documentação, eu incluo tudo – revisões de código, formulários de feedback de clientes, manuais, especificações técnicas, etc.
Como documentadora eu ouço muito a célebre frase “Pra quê? Ninguém lê o que vocês escrevem mesmo…”. Levo na brincadeira, dou risada junto. Mas é claro que eu sei que a realidade é essa mesmo – quase ninguém lê manual… até a hora que precisamos resolver um problema. E, nesse momento, eu faço questão de fazer a diferença para o meu cliente.
O processo de documentação em DITA é aquele em que a informação é dividida em pequenos tópicos que, por si mesmos, podem ser compreendidos.
Houve um tempo em que eu produzia por volta de 60-80 páginas de documentação por semana. Eram páginas e mais páginas que descreviam reuniões de levantamento de escopo de software com clientes.
O seu projeto de documentação baseia-se em (a) descrever todos os bits and bytes numa tela; (b) fazer com que todas as telas apareçam no manual; (c) ter um bom manual que ensina tudo, até como digitar o nome de usuário e senha?
Many times, how to do something is well documented. Instructions for recipes, for directions, for medicines – they are everywhere.
O SLA é um documento detalhado que define os padrões de um nível de serviço e a relação entre duas partes: solicitador e o executor.