Прилипухова Алина

Ведущий аналитик

Всем привет! На связи снова Алина — аналитик продукта Тил Эйчар. 

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

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

Введение

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

1. Большой поток однотипных вопросов от пользователей;

2. Передача функций технической поддержки в стороннее подразделение;

3. Сокращение временных затрат на поддержку пользователей внутри команды;

4. Обязательное требование к наличию документа при подаче заявки на конкурсы, в реестры и т.д.

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

Главный вопрос, который возникает на начальном этапе: «Кто займётся написанием инструкции в команде?»

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

Какие возникли проблемы и почему они возникли?

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

После первого подхода на этапе ревью выявились следующие проблемы:

1. Не соблюдалось разграничение функциональности согласно ролевой модели. То есть в части инструкции, которая относилась к обычному пользователю, было описание сценариев, доступных другим ролям;

2. Инструкция была плохо структурирована:

   1. Разделы в ней не соотносились с разделением функциональности по бизнес-смыслу внутри приложения. Было сложно понять, куда в приложении нужно зайти, чтобы воспроизвести описанный сценарий до конца;

   2. Отсутствовали перекрёстные ссылки на главы или хотя бы наименования разделов, где были описаны взаимозависимые сценарии;

3. Частично были приложены скриншоты не с демо-кабинета, а с тестового стенда;

4. Не хватало описания альтернативных сценариев и/или сложной бизнес-логики.

После ревью в ходе обсуждения выяснилось, что сотруднику, который находился вне команды, было тяжело сориентироваться среди всех требований, чтобы корректно структурировать информацию. 

Скриншоты с демо-кабинета для части функциональности сделать было нельзя, поскольку в процессе написания инструкции никто не останавливал релизы. Как следствие, интерфейс менялся: в нём появлялись новые компоненты, которые не предполагалось описывать в текущей версии. 

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

Что было решено сделать и какой получился результат

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

Работа со скриншотами поделилась на 2 части:

1. Те скриншоты, которые можно было сделать с демо-кабинета, нужно было заменить;

2. Те скриншоты, которые уже нельзя было сделать с демо-кабинета, решили сделать с тестового стенда, подобрав для них релевантные данные.

Правки вносились специалистом технической поддержки, а затем аналитик снова проводил ревью.

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

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

Как можно было предотвратить эти проблемы?

На этот вопрос напрашивается очевидный ответ — не отдавать инструкцию сотруднику вне команды разработки. Аналогичная ситуация могла бы сложиться, если бы эту задачу передали новичку. Поэтому корректный тезис будет звучать так: «Отдавать для подготовки инструкцию сотруднику, который в достаточной степени знаком с функциональностью продукта». «Здорово, Алина, — скажете мне вы, — А что делать, если у нас нет такой возможности?»

На это я отвечу, что если вы всё-таки принимаете решение отдать написание инструкции новичку или кому-то вне команды разработки, то будьте готовы — кому-то всё равно придётся потратить время и обсудить, а также зафиксировать договорённости по следующим вопросам: 

1. Как инструкция делится по ролевой модели: у вас будет общая инструкция для всех ролей или отдельные для каждой роли? Есть проекты, где помимо ролей используются ещё и пермиссии (от англ. permissions — разрешения), и одна и та же пермиссия может быть присвоена разным ролям. Если нужно скрывать от пользователей, которые не имеют соответствующей роли и/или пермиссии недоступную им функциональность, то стоит об этом сказать сразу.

2. В каком виде и где вы будете хранить инструкцию и как планируете её актуализировать.
   Во-первых, нужно обеспечить доступ к инструкции для всех заинтересованных лиц: техническая поддержка, продажи, внедрение и т.д. Во-вторых, нужно продумать, в каком виде будет храниться инструкция (в том числе её текущая версия, пока вы готовите новую). Например, это может быть файл с текущей версией инструкции, прикреплённый на странице в Confluence / Notion / (ваш вариант), где вы готовите новую версию. Если вы хотите делать это на отдельных страницах и давать на них ссылки, то я бы советовала копировать страницы и оставлять копию как предыдущую версию инструкции, а в изначальной странице проводить актуализацию. Таким образом, один раз передав ссылку коллегам, не будет необходимости её обновлять.

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

4. Какая структура будет у инструкции.
   Вы разделите её по бизнес-смыслу, пользовательским сценариям, разделам в вашем приложении и т.д. 

5. Что с внешним видом.
   Важно ли вам, чтобы скриншоты не содержали сущности с наименованием «Тест1234_проверка»? Чтобы они были в едином стиле? Для функциональности, которая сейчас дорабатывается, стоит подготовить скриншоты до очередного обновления, чтобы они сходились с инструкцией.

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

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

Заключение

Написание инструкции, на первый взгляд, несложная задача. Приступив к делу, можно обнаружить подводные камни. Чтобы не потратить на неё больше времени, чем планировалось, нужно оценить, кому рациональнее передать задачу по написанию и актуализации инструкции. Если решение будет в пользу сотрудника, который мало знаком с функциональностью, то обязательно поставить ему задачу с конкретными вводными и полным описанием того, что от него ожидается, в каком виде, в какие сроки. 

А какой у вас был опыт, связанный с инструкциями для пользователей?