Написание документации

Question

Accepted Answer

Для кого: для отдела продукта в компании по разработке и для всех, кому нужно написать публичную документацию для своего продукта Документация, или руководство пользователя — подробное описание функций цифрового продукта, которое публикуется в открытом доступе для пользователей.  Ты как раз находишься в нашей документации — в разделе «Помощь». Расскажем, как выстроить процессы написания похожего раздела на своём примере.  Чем поможет гайд Объяснит, как разложить сложную структуру руководства пользователя. С помощью Канбан-доски и редактора FigJam составим верхнеуровневую структуру будущего руководства пользователя Поможет настроить повторяющиеся процессы, связанные с написанием документации, чтобы ничего не терялось Шаг 1. Визуализировать структуру документации в FigJam Перед написанием руководства стоит разложить продукт на основные составные части — допустим, главные сервисы, приложения, ключевые функции продукта. Это поможет определить основные разделы руководства — и статьи, которые расскажут про каждый из них. Эту информацию лучше визуализировать на схеме.  Удобнее всего собрать верхнеуровневую структуру в редакторе FigJam в виде дерева или ментальной карты — по нисходящей от главной части продукта к его составным частям. Так можно сформировать полный список статей, необходимых для руководства пользователя, — и ориентироваться, какие из них нужно обновить. 💡 При визуализации лучше дать каждому блоку свой цвет — так будет проще  ориентироваться в структуре и видеть картину целиком:  Шаг 2. Составить структуру документации на Канбан-доске  Следующая задача — начать писать статьи. Для этого нужно продублировать структуру схемы из FigJam на Канбан-доске. Так тексты превратятся в задачи и будет проще выстроить зависимости, назначить ответственных и соблюдать дедлайны. Для этого: Создай первую доску в проекте. Назовём её «Документация». Здесь будем делать структуру руководства пользователя.  Определи разделы документации. Отрази составные части своего продукта в колонках на доске. Например, Начало работы, Рабочие пространства, Задачи, База знаний и так далее. Можно и так: Мобильное приложение, Функции, Интеграции Создай большие задачи. Скажем, в колонке Начало работы будет большая задача — «Как начать пользоваться сервисом». Декомпозируй задачи на подзадачи. Большую задачу «Как начать пользоваться сервисом» декомпозируем, например, на такие задачи «Как зарегистрироваться в сервисе», «Основные элементы интерфейса» и так далее. Это статьи будут пошагово рассказывать, как освоиться в сервисе.  💡 Структура руководства пользователя готова. Это вид сверху на все процессы по написанию документации. Идеально, если она поместится на один экран, — так с ней удобнее работать. Шаг 3. Отстроить процессы по написанию документации Теперь организуем созданные задачи на первой доске, чтобы работать над каждой поэтапно. Для этого: Создай вторую доску в проекте. Назовём её — «Пишем документацию».  Определи этапы написания статей. Колонки на доске могут называться так: К работе, В работе, На проверке, К публикации, Выгружено на сайт и Архив статей. В дальнейшем статьи будут двигаться по этим этапам — от начала планирования до публикации или архивации. Это сделает процесс работы прозрачным.  Создай зависимости между задачами. На доске «Документация» зайди в большую задачу. Например, «Интеграции и API» — это задача-родитель. Она имеет несколько подзадач — «(HELP) Что такое API»,  «(HELP) Интеграции с Figma» и так далее. Проваливаясь в каждую подзадачу, настрой её путь к доске «Пишем документацию». Допустим, «(HELP) Что такое API» добавим в колонку К работе. Это будет означать, что статья готовится к написанию.  Назначь в карточках ответственных и дедлайны. Это поможет всем участникам команды быть в курсе текущих и будущих задач.   Что ещё почитать по этой теме: Как настроить повторяющиеся задачи в WEEEK Как создавать и использовать шаблоны в рабочих пространствах Как сделать календарь контента