Clube do Livro VTEX: Colaborando com Gestão de Produto

Esse post faz parte de uma série de conteúdos produzidos pelo time de tech writers da VTEX em nosso projeto do clube do livro, em que discutimos o livro The Product is Docs. Neste post nós vamos discutir o pilar da colaboração com outros times no contexto de Technical Writing. Vamos abordar a relação entre tech writers e outros times em empresas de tecnologia, como o time de Experiência do Usuário, Design, Marketing, Gestão de Produto (Product Management) e Engenharia.

Technical writing é uma área chave em empresas de tecnologia. Nos relacionamos diariamente com outras áreas e até dependemos de outros profissionais para realizarmos nosso trabalho. Construir pontes e cultivar relacionamentos é um aspecto central do nosso dia a dia, que pode trazer oportunidades e desafios. Agrupamos alguns capítulos do livro que abordam a colaboração com outras áreas:

• Colaborando com UX e Design (Working with User Experience and Design)
• Colaborando com Marketing (Working with Marketing)
• Colaborando com Gestão de Produto (Working with Product Management)
• Colaborando com engenheiros (Working with engineers)

Parte da responsabilidade de um gestor de produto (Product Manager, ou PM) é compreender clientes e traduzir suas necessidades em objetivos do produto. Colaborar com esses profissionais faz toda a diferença para o sucesso da sua documentação.

Como gestão de produto pode ajudar a documentação

Confira abaixo alguns cenários onde gestão de produto e documentação podem trabalhar em conjunto.

Casos de uso, histórias de usuário e critérios de aceitação

Na maioria das empresas, PMs são os responsáveis por escrever casos de uso e histórias de usuário. Porém, o tech writer pode incentivar esse papel, ou seja, solicitar a escrita desses materiais e até rever os processos internos com a liderança de produto. É importante deixar clara a importância desses conteúdos não só para a área de documentação, mas para todo o time.

Casos de uso não mapeados e falta de clareza sobre o porquê da criação da funcionalidade são bons indicadores de quanto tempo e energia você deve utilizar para criar documentação para a funcionalidade nesta etapa. Talvez seja melhor trabalhar em outros projetos, enquanto essa ideia amadurece.

Prioridade de produto e documentação

Caso o time não tenha clareza, ou não concorde sobre suas prioridades de alto nível, você pode apoiar o PM em atualizá-las onde ficam registradas, pois essas prioridades ajudam a definir o escopo dos seus esforços.

É possível também que você tenha que equilibrar prioridades de documentação de times diferentes em que está alocado. Se os PMs de cada time não estiverem alinhados dentro da esfera mais ampla do produto, defina critérios claros para priorizar suas tarefas de documentação, comunique para todas as pessoas envolvidas e mantenha consistência perante sua decisão. Os seus critérios para priorização podem variar de acordo com o que é valorizado pela empresa, como feedback de usuário, objetivos estratégicos, prazos de lançamento, ou até quais histórias de usuário foram validadas primeiro. Idealmente, os PMs irão aprimorar a colaboração entre times e seus processos para que você possa focar sua energia em criar documentação.

Revisar e aprovar um plano de documentação

É importante captar feedbacks e apoio de PMs sobre seu plano de documentação e objetivos de aprendizado antes de começar a escrever. A chave para esse movimento é a comunicação.

Se você trabalha com vários PMs, identifique um deles como responsável por responder suas perguntas de documentação. Talvez você tenha sorte de que o gerente de produto identifique a melhor pessoa para esse papel, do contrário escolha a que pessoa que está mais disposta a colaborar com a documentação.

Para conseguir o que você precisa para a documentação, esteja atenta ao estilo de comunicação dos PMs. Se puder, considere ter uma conversa rápida com PM na primeira vez que escrever um plano de documentação, para que você possa introduzir seus objetivos de aprendizagem e explicar como eles se traduzirão na documentação. Dessa maneira, você ajuda os PMs a compreender e dar feedback sobre seus objetivos de aprendizagem para interações futuras ou nos próximos projetos sem precisar marcar reuniões.

Objetivos de aprendizagem são uma ferramenta excelente para refinar casos de usuários. Revisar e discutir documentação pode trazer esclarecimento para os PMs, por isso mostre esse valor à medida que você passa por esse processo de revisão.

Revisar e aprovar um conteúdo para publicação

Gerentes de produto devem validar e aprovar sua documentação antes de ser publicada, assim como fazem com qualquer outro aspecto do produto que vai ao ar. Silêncio implica consentimento, apesar de ser resultado de um processo mal formulado. É responsabilidade dos gerentes de produto arcar com desalinhamentos em relação aos diferentes aspectos do seu produto. Eles são, portanto, co-responsáveis pelas divergências entre documentação e entregas de produto. Em contrapartida, é responsabilidade do technical writer aliviar esse fardo, para garantir que será fácil para PMs revisarem e aprovarem documentações. Isso pode ser feito melhorando processos, indicando pontos específicos de revisão, criando um documento de pré-lançamento, ou contando com a relação construída com o time de produto para obter a revisão necessária.

Como documentações ajudam na gestão do produto

Validar a compreensão da gestão de produtos sobre o público-alvo

Valide suas suposições sobre o público com gerentes de produto durante seu plano inicial, para evitar frustrações, afinal, a documentação e o produto devem estar alinhados para um mesmo público. Uma forma prática de alinhamento é escrever um caso de uso ou documentação com base em cenários, e usar os objetivos de aprendizagem para refinar o que você está escrevendo.

Identifique trechos de documentação que precisam de mais revisão

Para tornar mais eficiente a revisão de sua documentação, não peça que os PMs revisem seu artigo inteiro, e nem faça as mesmas perguntas que desenvolvedores e designers já responderam, a menos que uma resposta colaborativa seja necessária. Deixe que sua validação prévia sobre público guie seu trabalho e solicite revisão de trechos específicos.

Pergunte-se: que áreas da documentação mais se beneficiariam da revisão de gerentes de produto? É provável que PMs estejam mais próximos de outros tipos de documentação como notas de versões de um produto (release notes), lançamento de novas funcionalidades, problemas conhecidos (known issues) e listas de problemas resolvidos.

Facilite o processo de feedback

Adapte seu processo e estilo de revisão para o que funciona melhor com seu gerente de produto. Pergunte ao PM sobre sua forma preferida de revisar documentação e teste dinâmicas diferentes até chegar na melhor opção. Utilizar ferramentas que incluem comentários na linha desejada do texto, como o Google Docs ou o próprio Github, torna o processo mais rápido.

Utilizar o fluxo de revisão pelo Git, ou a abertura de tickets de documentação pelo pelo sistema de tickets que o time de produto utiliza também pode funcionar bem. Se revisão digital não é uma opção, é possível marcar um encontro para que você faça anotações enquanto os PMs revisam a documentação ao vivo, poupando-os de escreverem formalmente suas considerações sobre o texto.

Não desanime se não receber feedback. Revise seus métodos, esclareça suas necessidades e tente novamente. Aponte os benefícios mútuos de colaborar na documentação e compartilhe feedbacks de usuários. (p.245)

Envolva-se no início do processo de desenvolvimento

Documentações e gestão de produto trabalham juntas com mais efetividade quando o tech writer se envolve cedo no ciclo de desenvolvimento de um produto. Dessa forma, você compreende como a funcionalidade funciona desde o início e, sobretudo, entende o porquê da sua criação e a quais casos de uso ela se aplicará.

Participar no início do desenvolvimento do produto também permite:

• Contribuir com texto dentro do próprio produto, como descrições e mensagens de erro.
• Sugerir melhorias no fluxo a partir de testes iniciais.
• Manter uma compreensão compartilhada do produto com os PMs.
• Manter-se informado(a) sobre detalhes do produto.

Levante questionamentos

Ao levantar questionamentos sobre o design e a definição de produtos, confie na sua experiência sobre o que os usuários podem achar confuso. É claro que são os gerentes de produto que vão decidir qual dos problemas percebidos vale a pena resolver e quais não. De qualquer forma, você é mais uma voz na equipe que está acostumada a articular a perspectiva e as necessidades do usuário.

Seja proativo em solicitar a alteração de pequenos problemas de experiência do usuário, em vez de assumir que alguém os resolverá espontaneamente ou que alguém vai pedir sua sugestão. Não restrinja sua atenção apenas à escrita e às mensagens de erro da interface do produto, atente-se também a questões como consistência em styling, terminologia de produtos e recursos, pontuação e cores.

Os gerentes de produto muitas vezes não têm tempo para atender a um alto nível de detalhes, especialmente nos primeiros estágios de desenvolvimento ou Design de um produto ou funcionalidade, mas, ao priorizar isso durante todo o processo de desenvolvimento, você pode evitar que erros ou problemas de estilo sejam incorporados na construção final.

Alcance eficiência

Crie padrões, processos e templates para seu time sempre que isso aumentar a eficiência. Se notar que o time está tendo dificuldades similares repetidamente, trabalhe com PMs para investigar a questão, definir uma boa prática e registrá-la. Atualize os processos se a solução não atender as necessidades do time integralmente.

Busque formas de aplicar feedbacks, objetivos e preferências de PMs em todos os materiais em que estiver trabalhando, não só em um caso específico em que perguntou sobre sua opinião. Como a maioria das pessoas, os PMs acham irritante ter que repetir o que já disseram. Seja cuidadoso com o tempo deles!

Compartilhe feedbacks de clientes

PMs buscam basear suas decisões na visão mais precisa possível sobre a opinião dos usuários. Se você tiver um método robusto para obter feedbacks por meio de um portal de documentação, compartilhe as descobertas oriundas de feedbacks com o time de PMs para que eles utilizem esses insumos juntamente com outros métodos para captar a opinião de clientes. Porém, fique atento para o fato de que os feedbacks enviados em seu portal de documentação não necessariamente representam a maioria dos usuários. É possível que usuários novos deixem mais comentários que usuários já habituados com o produto, por exemplo. Ainda assim, os dados coletados podem trazer insights úteis sobre mudanças no perfil dos usuários.

Citações

Traduzimos livremente alguns trechos do livro que mais chamaram nossa atenção:

Citação	Página
Você pode demonstrar como uma funcionalidade específica não foi para frente devido à falta de compreensão compartilhada sobre o que estavam construindo e por quê. Como escritor, você está bem posicionado para levantar essa mensagem para que todos do time entendam seu impacto e sejam motivados para incentivar melhorias.	240
Para um time funcionar bem, gerentes de produto devem definir prioridades e garantir que o time inteiro as compreenda. Ninguém discordaria dessa frase num time saudável de produto. Porém, demandas do dia a dia podem superar essa compreensão compartilhada e as pessoas podem esquecer de focar na clareza e acessibilidade dessas prioridades.	241
A documentação — seja ela uma seção de ajuda dentro do produto ou um conteúdo externo — é parte integral do produto e, portanto, também faz parte da responsabilidade geral do gerente de produto.	172
Observe enquanto PMs articulam o “porquê” para o time, e veja como o time de desenvolvimento responde com o “como”.	246
Não espere atingir o mesmo nível de sinergia com PMs se você só trabalha ativamente em documentação ao final do ciclo de desenvolvimento.	246
Preserve o tempo de PMs, para que possam te dar feedback sobre o próximo item que precisar - e não sobre algo que já trataram com você antes.	247