Алла Афанасенко

Привет! Я Аля — старший продакт-менеджер выделенных серверов 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. Они помогут со структурой, написанием и редактирование — это сэкономит ваше время. Заключение Документация продукта может стать полезным инструментом, если сделать ее простой, понятной и актуальной. Надеюсь, что мои рекомендации помогут вам сделать этот документ помощником, а не источником дополнительного стресса. Помните, что над документацией работают люди (много разных людей), поэтому документация никогда не будет идеальной – будут дублирования, разночтения, неактуальные страницы и другие недочеты. И это окей, главное, чтобы документация оставалась полезным инструментов.

Алла Афанасенко

Материалы автора

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

Как сделать встречи эффективными: заметки, фасилитатор и другие хаки

Когда A/B-тесты не подходят: 6 альтернативных способов тестирования продуктовых гипотез

Как мы перешли на Discovery-процесс в продукте и что из этого вышло