Как вести внутреннюю документацию: с чего начать новичку

Привет! Я Аля — старший продакт-менеджер выделенных серверов Selectel. 

Совсем недавно я писала про одну из самых частых болей всех продакт- и проджект- менеджеров и тимлидов — бесконечные встречи. Тогда я рассказала, как мы повышаем эффективность обсуждений, при этом сокращая их количество. В этот же раз я сфокусируюсь на другой боли — документации продукта.

Почему создать документацию непросто

Когда-то давно я думала: «Что такого сложного во внутренней документации? Почему столько проблем с тем, чтобы она была актуальная, полезная и легко поддерживаемая? Делов-то». Но оказалось, что не все так просто. 

При работе с документацией я столкнулась с целым «букетом» сложностей.

• Как при запуске нового продукта или сервиса определить структуру так, чтобы начать с чего-то простого, а дальше можно было масштабировать? Как не погрязнуть в полотне ненужных разделов еще на старте?
• Как сделать структуру понятной не только тебе, но и другим членам команды? Иногда то, что понятно для тебя, для других максимально нелогично. 
• Как сделать документацию полезной не только для разработки, но и для продаж, маркетинга, саппорта и других команд? 
• Как держать документ в актуальном состоянии, при этом не посвящать этому все время?

В статье я расскажу, как справиться с этими сложностями. Я сфокусируюсь на легковесной структуре документации, дополню рассказ  комментариями вида «а еще пробовала вот это, но не сработало», а также приправлю рекомендациями по масштабированию по мере роста потребности. 

Легковесная базовая документация

Одна из больших сложностей, с которой я столкнулась в процессе, — как сделать документацию помощником, а не увязнуть в полотне ненужных разделов еще со старта. Я уверена, что продукт можно вполне успешно запустить и без документации. Так что задумайтесь, дает ли этот документ вам преимущества или тормозит вас.

Какие преимущества открывает документация

• Упрощается коммуникация внутри команды. Не все продукты создают два-три человека — иногда людей гораздо больше. А документация в этом случае выравнивает команду в том, каком направлении и зачем вы движетесь. 
• Снижается риск утраты знаний — ключевые сотрудники бывают недоступны: уходят в отпуск, берут больничный или вовсе покидают продукт. Если есть знания, которые важно сохранить, документация в этом поможет. 
• Можно проверить идею — точно ли она так хороша, как вы думаете? 
• Появляются инструменты для продаж, маркетинга и поддержки, которые позволят их значительно улучшить. Например, описание преимуществ продукта будет полезно для продаж и маркетинга, а основные вопросы и ответы по работе продукта — технической поддержке.
• Ускоряются будущие изменения — при дальнейшей доработке продукта команда может опираться на ранее зафиксированные решения.

Сейчас в открытом доступе можно найти сотни или даже тысячи шаблонов для документации (а с GenAI их можно сгенеририровать бесконечное множество). Однако многие из них слишком тяжеловесны. Это приводит к чрезмерному фокусу на документации вместо запуска и развития продукта, а также более сложному наполнению и поддержанию в будущем. 

Во всеобъемлющих сборниках накопленной мудрости нет ничего плохого, но на старте это может помешать и сделать хуже. Если уж и писать внутреннюю документацию, то начинать с чего-то простого, но при этом полезного. Например, с Press Release (PR) и Frequently Asked Questions (FAQ) от Amazon. Это ключевой документ, который используется для обеспечения общего понимания идеи всеми заинтересованными сторонами. PR/FAQ — отправная точка для всех последующих документов о продукте и макетов.

Другой пример простой документации —  различные канвасы, например, — Lean Canvas и The Value Proposition Canvas. Они помогают сосредоточиться на проблемах, решениях, ключевых метриках и конкурентных преимуществах, что особенно важно как на старте, так и дальнейшем развитии продукта. 

Вполне возможно, вам хватит этих артефактов на старте, а основная документация у вас будет вида «посмотри в коде».

Как может выглядеть структура документации

Если вам нужна более подробная внутренняя документация, предлагаю обратить внимание на базовую структуру, которая легко ложится в Confluence-подобные системы.

Пример структуры

1. О продукте — рассказываем кратко и емко: что это, для кого и зачем. Прочитав эту страницу, человек должен сразу понять, для чего и кого существует ваш продукт.

2. Customer & Value — клиентские сегменты, кейсы и контексты использования продукта: 

• В чем ценность для пользователей, чем продукт лучше альтернатив? 
• Какие сегменты целевой аудитории или пользователей — кто они, чем отличаются друг от друга. Опишите контексты, кейсы, задачи, проблемы и боли. 

• Какие есть ключевые преимущества для разных сегментов и кейсов.
• Сравнение с конкурентными решениями — чем мы лучше? 

Классный (но не единственный) формат — battle cards. Мне нравится тем, что он понятный и простой в использовании, а подход с «битвой» позволяет сделать процесс с подготовкой веселым и захватывающим. 

3. Запуск и продвижение:

• Какая стратегия выхода на рынок или go-to-market (GTM) strategy — план действий при запуске нового продукта. Он должен включать четкое описание целей запуска, позиционирование продукта на рынке, каналы и способы распространения, борьбу с конкурентами и другие аспекты, которые важны для успешного запуска.
• Описание планов и дальнейшее развитие.

4. FAQ & How-to — ответы на все вопросы.

Почему я объединила вопросы и ответы с инструкциями — по моему опыту они почти всегда идут рука об руку. Если человек ищет ответ на вопрос, как что-то создать, то он хочет узнать, как это сделать. А значит, ему нужна инструкция. Например, вопрос «Как мне заказать сервер клиенту через админскую панель управления» хочется сопроводить инструкцией (how-to) — как это сделать. 

FAQ иногда полезно поделить по направлениям — скорее всего, техническая поддержка и продажи будут приходить с разными вопросами. 

5. Решение:

• Техническая архитектура продукта — структура системы, способы взаимодействия ее компонентов и технические решения, используемые для реализации продукта. Этот раздел помогает всем участникам команды разработки понимать, как устроен продукт на уровне технологий и инфраструктуры.
• Функциональность продукта — что доступно для пользователей, как это работает, какие есть особенности и ограничения.

6. Product Discovery:

• Раздел, в котором собираются все ваши исследования — исследования пользователей (интервью, опросы и анкеты, полевые исследования и другие исследования вокруг ваших пользователей), юзабилити-тестирования, продуктовая аналитика и другие исследования.

7. Опциональные разделы, которые зависят от особенностей вашего продукта, но могут быть важны уже на этапе запуска: 

• поддержка продаж — особенно актуально для В2В. В этом разделе могут лежать полезные материалы для продаж; 
• руководства для пользователей;
• скидки и спецпредложения; 
• обновления в продукте или релиз-ноутсы;
• команды и процессы — описание команд продукта, зон ответственности, процессов и процедур;
• онбординг в продукт;
• meeting notes. Почему этого раздела нет в основной структуре — обсуждения обычно бывают в каком-то контексте, поэтому заметки лежат в разделе контекста. Например, если вы обсуждаете конкретное юзабилити-тестирование, то заметки по нему логичней положить в раздел этого исследования, а не в какой-то отдельный. 

Рекомендации: как работать с документацией, когда продукт и команда растут

С ростом продукта внутренняя документация также должна масштабироваться, чтобы поддерживать команду разработки, сотрудников и другие заинтересованные стороны в процессе работы. 

На мой взгляд, основная сложность с ведением внутренней документацией продукта, когда продукт большой и сложный — сохранение актуальности и полезности. Но есть несколько советов, которые помогут с этой проблемой.

Централизируйте «хранение». Возможно, в этот момент вы удивитесь, сейчас все говорят про децентрализацию, а тут наоборот. 

Децентрализация — это нормально. Скорее всего, у вас будет много разных источников. Я же говорю про единый инструмент, в котором хранится основная документация и ссылки на документацию, хранящуюся в других местах. Например, для документации исследований мы используем Confluence, но для расчетов применяем таблицы в онлайн-офисе, а для прототипов — Figma или Pruffme-доски. И так еще целый ряд инструментов под разные задачи. В Confluence в этом случае мы даем ссылки на другие источники. 

Вовлекайте команду в формирование и поддержание документации в актуальном состоянии. Конечно, можно выделить ответственную роль за обновление всей документации — техписа. Но когда у вас большая команда и изменений в продукте много, такой подход плохо масштабируется.

Вовлечение команды в написание и актуализацию документации — решение, которое лучше масштабируется. Только работает оно хорошо, когда часть с документацией встроена в цикл разработки, а также есть стандарты и шаблоны (об этом ниже). Как альтернатива или промежуточное решение — назначение владельцев разделов. 

Используйте шаблоны. Большинство инструментов для документации позволяет формировать шаблоны — они значительно ускоряют работу над документацией, а также позволяют упростить ее восприятие. Примеры, когда будут особенно полезны шаблоны: FAQ, meeting notes, страница исследования, документация интервью и т.д. 

Встраивайте документацию в процесс разработки в процесс разработки. Значительно проще помнить про необходимость вести документацию, когда это встроено в процесс работы над задачей. Например, у нас написание и обновление документа — часть работы над задачей, еще точнее — acceptance criteria. 

Определите стандарты по формированию документации. Тут важно не переусердствовать. Возможно, небольшого документа с самыми важными правилами и рекомендациями будет достаточно. 

Переиспользуйте документацию или сформируйте «строительные блоки». Возможно, одна и та же информация встречается в разных разделах документации. Например, про целевую аудиторию и преимущества продукта особенно важно знать маркетингу и продажам. Если такое происходит, напишите информацию в одном месте, а в других переиспользуйте. Например, в Confluence это можно сделать через макросы «A Shared Blocks» + «Include A Shared Blocks» (подробнее про использование макросов рассказывали в статье). Очень удобно: если вы измените информацию в одном разделе, в другом она автоматически обновится. 

Автоматизируйте формирование и обновление документации. Можете формировать release notes, беря resolution comment из Jira-задач — обязательно воспользуйтесь этим.

Используйте AI writing assistants. Они помогут со структурой, написанием и редактирование — это сэкономит ваше время. 

Заключение

Документация продукта может стать полезным инструментом, если сделать ее простой, понятной и актуальной. Надеюсь, что мои рекомендации помогут вам сделать этот документ  помощником, а не источником дополнительного стресса. 

Помните, что над документацией работают люди (много разных людей), поэтому документация никогда не будет идеальной – будут дублирования, разночтения, неактуальные страницы и другие недочеты. И это окей, главное, чтобы документация оставалась полезным инструментов.