Desenvolvimento

Ξ 6 comentários

Seja amigável, invista em documentação!

publicado por Sarah Siqueira

Se você é daqueles gerentes de TI que pensam que documentação é uma questão de produzir os manuais de usuário em tempo para o release do seu software, pense de novo. Se você, na sua equipe, nunca ouviu falar da figura do redator técnico ou, se ouviu falar, acredita que essa figura seja totalmente dispensável, pense novamente. Se a sua equipe possui aquele programador que “sabe bem inglês” ou que “é bom no português” e que por isso fica responsável por revisar e escrever as mensagens de erro do seu sistema, pare nesse instante.

Muito provavelmente você encara um acréscimo constante de gastos com os diferentes níveis de suporte ao usuário. Seu cliente não entende o produto, e você não sabe mais o que fazer para melhorar a performance do seu sistema e ganhar aquele filão de mercado no qual seu concorrente avança a passos largos.

Se você se encaixa neste perfil, não desespere. Se você tem um bom software, com uma boa base de clientes, e enfrenta esses desafios, muito provavelmente você deveria rever seus conceitos. Seu problema não é performance ou falta de funcionalidades – seu problema é documentação.

E quando eu digo documentação, eu não estou falando do manual de usuário de 500 páginas que sua empresa gasta alguns milhares para produzir e atualizar todos os anos. Documentação de software envolve desde os nomes dos campos na tela, passando pelas mensagens de erro, hover texts, help grids, online helps, até os manuais.

Se os nomes dos campos na tela são ruins, ambíguos, cheios de abreviações ou siglas, seu usuário procurará imediatamente ajuda no “F1”, ele não vai abrir o manual. E então, se o help daquele campo de nome estranho (por exemplo, uma abreviação do tipo “Dt.”) diz apenas “Include the Dt.”, seu usuário ficará frustrado.

E então ele vai tentar entrar com algum dado no campo. Imaginando que “Dt.” seja a abreviação de “Date”, ele vai simplesmente digitar uma data qualquer. E seu sistema então lhe enviará graciosamente uma mensagem de erro que diz “Database error. Please try again.”.

Tudo bem, nesse instante, seu usuário vai recorrer ao Google, ele não vai encarar 500 páginas de manual de usuário para entender o que significa “Dt.” e que tipo de informação o campo espera que ele digite. Aliás, você e eu, como usuários, faríamos a mesma coisa.

Então, antes de cortar gastos com documentação, achando que assim você vai incrementar sua receita, faça o oposto – contrate um bom redator técnico. Alguém que entenda sobre como redesenhar e melhorar sua interface com o usuário. Melhore a diagramação da tela, os nomes dos campos, a clareza de divisão das tarefas dentro de menus e telas.

A partir daí, invista no help online. Coloque a informação certa nas mensagens de erro – não adianta dizer ao seu usuário que ocorreu um erro; isso ele já sabe. Ao invés disso, inclua informações sobre porque o erro ocorreu e como ele poderá solucioná-lo. Se a explicação for grande demais, providencie um link para os detalhes da informação na web, ou pelo menos o número do capítulo e página do manual onde ele encontrará o detalhamento.

Quanto mais amigável, clara e concisa for sua interface com o usuário, melhor e maior será a penetração do seu produto no mercado. E tem mais: o gasto extra com o suporte de um bom redator técnico será suplantado pela redução de custos com suporte ao usuário.

E lembre-se: não importa o quão incríveis sejam as funcionalidades do seu sistema; se o usuário não consegue utilizá-lo com certa facilidade, ele procurará algo no mercado que seja mais simples e mais amigável. Portanto, não menospreze a documentação do seu produto – ela é a “cara”, o cartão de visitas, do seu software.

Autor

Sou pós-graduada pela FGV em Gerência de TI. Já fui programadora, tradutora, revisora, e atualmente sou redatora técnica há mais de 11 anos. Aprendi inglês muito nova, e descobri a redação técnica meio que por acaso, através de um anúncio de multinacional que precisava de alguém que escrevesse bem em português e inglês e tivesse disponibilidade para viagens. Lá trabalhei por 7 anos, viajei por todos os continentes, aprimorei técnicas, e entrei em contato mais profundo com o ciclo de vida do desenvolvimento de software no Brasil. Hoje sou líder de desenvolvimento de informações na IBM, onde planejo os projetos de documentação do produto sob minha responsabilidde, desenvolvo conteúdo, reviso materiais, dou treinamentos, mentorizo equipes mais novas e auxilio no processo de globalização e de teste da interface com os usuários finais. Espero trazer a vocês bons insights sobre o mundo da documentação em TI.

Sarah Siqueira

Comentários

6 Comments

  • Excelente articgo Sarah!

    Você trazer pontos muito bom para o valor de ter documentação. Depois de escrever o meu artigo sobre este assunto, as respostas eram esperados. Como consultor, sempre que uma empresa não tem uma boa documentação, gostaria de vê-los lutar cada vez que um funcionário valorizado seria saída para um novo emprego.

    Essencialmente, a empresa investiu seu dinheiro em alguém que acaba de sair pela porta para o que poderia ser um concorrente. Saber como funciona um sistema é apenas uma pequena parte do trabalho – geralmente há cusomizations que criam idiossincrasias do sistema. Sem a devida documentação, uma vez que a pessoa saiu de um novo emprego, então eveything precisa ser aprendida por alguém.

    Meu artigo é intitulado, “No Time To Document? You must have lots of money…” http://bit.ly/NoDocsNoROI

    • Oi Garret,

      First of all: how come you read and write in Portuguese? Or is this a trick the browser is playing on me? 🙂
      Anyway…

      Eu acredito que nossos artigos são complementares. Você fala sobre a documentação do processo de produção do software, enquanto eu falo mais sobre a documentação do software para o usuário final. Ambas são complementares e devem andar juntas.
      Não sou, no entanto, adepta da burocracia excessiva. Acredito que, se a empresa documenta bem o processo de design do software, e depois possui boas práticas de codificação — normas para a criação de campos, tabelas, funções, estruturação de código, inclusão de comentários em linha de código, etc. — ela estará muito bem munida de recursos se, no futuro, um ou mais de seus recursos experientes faltarem.
      Adicione-se a isso uma boa interação de seus recursos de desenvolvimento e teste com o time de redação técnica, e teremos grande chance de sucesso.

      Obrigada pela visita, e pelo comentário!

  • Muito bom o seu artigo. Reforçou ainda mais o meu conceito sobre documentação de software.
    Recentemente eu peguei um software CMS de uma empresa, para trabalhar em cima dele, quando adentrei no source code dele bateu-me logo uma tristeza. O software não tinha uma linha de código comentada, não tinha documentação, tinha muita repetição de código e não era orientado a objetos. Sofri o pão que o diabo amassou pra aprender como ele funcionava, lendo linhas de código e deduzindo o que faziam.
    Se tivesse uma documentação, ou pelomenos comentários do que os códigos estavam fazendo seria menos desgastante e bem mais produtivo.

    Enfim, parabéns elo seu artigo. Gostei muito!

    • Obrigada Jan Lucas!
      Como você, existem milhares de profissionais de TI passando por esse mesmo sufoco todo santo dia… infelizmente.

  • Olá Santa Sarah Siqueira!
    Você acaba de salvar minha vida. Muito bom seu artigo, comecei recentemente nessa área de redator técnico e sempre procuro referências, artigos para aumentar meu conhecimento e nunca acho nada. Que bom achar você!
    Tem algum blog que vc indica com dicas para elaborar uma boa documentação de software para usuários finais? Help me, please!
    Muito Obrigada!

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes