Documentação boa melhora o produto
Desde que comecei a gravar episódios para meu podcast, no ano passado, tive a chance de conversar com algumas pessoas de conteúdo bastante incríveis, como Tom Johnson, Mark Baker e Christopher Gales.
Claro, cada um deles tem pensamentos diferentes sobre muitos aspectos do trabalho de escrita, mas um pensamento surgiu em cada uma dessas conversas (sim, provavelmente devido ao meu próprio interesse nisso, admito). Pode ser resumido assim:
Olhar para o desenvolvimento de produtos através de uma lente que prioriza o conteúdo não melhora apenas a documentação; melhora também o próprio produto.
Então vamos conversar um pouco sobre isso. Pense em uma equipe de produto se reunindo em uma sala de reuniões para discutir as primeiras etapas de um projeto que levará a um novo produto ou feature. Quem são as pessoas dentro da sala? Você provavelmente vê um gerente de produto; talvez o CEO, se o produto for realmente importante ou a empresa for uma startup pequena; designers; desenvolvedores; alguém do suporte a clientes? Talvez alguém do controle de qualidade? Se você tiver muita sorte, pode ser que encontre até mesmo um UX Writer.
Você sabe aonde quero chegar com isso: a pessoa que você provavelmente não verá na sala é a technical writer. E não é porque ninguém gosta dela, mas porque a documentação técnica geralmente não é vista como parte do produto em si. Na maioria das vezes, é vista como um apêndice. E quando se desenha a linha do tempo de um projeto no quadro branco e se pergunta às pessoas onde o apêndice entra, a resposta óbvia é “no final”, depois que tudo o que é essencial e importante tiver sido descoberto e criado.
E o que é curioso é que frequentemente as questões que realmente são apêndices serão incluídas primeiro na conversa, simplesmente porque é fácil pensar sobre elas. O material do bicicletário antes do projeto da usina nuclear.
E o que acontece quando o technical writer é finalmente chamado é uma série de tropeços desnecessários. Afinal, o produto está supostamente pronto, então agora a equipe precisa decidir se:
- Ele será lançado sem documentação – “a gente faz depois”;
- Vamos segurar o deploy enquanto os technical writers correm para produzir um arremedo de documentação (o que é uma maneira ruim de trabalhar e, a propósito, mostra pouco respeito pelo trabalho do technical writer);
- Simplesmente não haverá documentação – “problema do usuário”.
Além disso, vamos pensar numa coisa a mais: se ela não estava trabalhando na documentação do produto, o que aquela tech writer preguiçosa estava fazendo enquanto a equipe de produto trabalhava duro no desenvolvimento? Bem, ela estava tentando cobrir as inconsistências nas features lançadas anteriormente e que também foram construídas sem um trabalho síncrono de documentação. Prque – justamente por não terem sido construídas com trabalho síncrono de documentação – elas nasceram repletas de lacunas.
Agora você deve estar pensando que garantir boa usabilidade é tarefa dos designers – e eles estavam na sala durante a primeira reunião. Minha resposta é que você está, mais uma vez, subestimando o impacto do trabalho do technical writer no desenvolvimento do produto. Designers são definitivamente essenciais, mas estão tão próximos do produto que não conseguem assumir a posição do usuário com o distanciamento ideal. Os engenheiros de controle de qualidade também são essenciais, mas estão lá para garantir que nada vai quebrar. Também não pretendem assumir o lugar do usuário.
A technical writer, por outro lado, está em posição de assumir o lugar do usuário. Na verdade, ela geralmente é a primeira usuária entre todos. Só ela pode olhar para o produto com a ignorância e a curiosidade que levam às questões necessárias para gerar um conhecimento que corresponda ao modelo mental do usuário – e, portanto, um conhecimento super valioso. Porque ela não é a estrategista, nem a construtora, nem a testadora. Ela é a aprendiz e depois a professora. E para ensinar, ela precisa usar o produto, não com o olhar de quem o criou, mas como os usuários o experimentariam.
Então o que acontece quando a technical writer está na sala é que ela aprende a usar o produto enquanto a equipe do produto o constrói. E, ao fazer isso, vai te ensinando o que você só poderia aprender muito mais tarde, depois que o produto fosse lançado, por meio de tickets enviados ao suporte por usuários irritados.
“Technical writer” ou “documentarista” são nomes enganosos quando se trata de avaliar o real impacto dessa posição (se bem usada). Coloque o tech writer na sala e você terá um grande aliado para fazer um produto melhor.