Всем привет! Я — Ира Саблина, системный аналитик в Creonit. Мы разрабатываем цифровые продукты на заказ. Большая часть моей работы — это создание сервисов с нуля. На чужих проектах я часто вижу, как результатом проектирования становится сотня артефактов, в которых заказчик не может разобраться. Потом на их основе пишут техническое задание на кучу страниц, которое тяжело воспринимать. Расскажу, как избегать всего этого с помощью пользовательских историй.

Введение

Когда к нам приходит заказчик с идеей продукта, необходимо понять: 

• какую задачу решает продукт; 

• какие нужны функции; 

• в чём его ценность для аудитории; 

• какие бизнес-цели мы закрываем разработкой. 

Словом, сформировать чёткое видение сервиса и требования к нему. Для этого существует этап аналитики и проектирования. 

Мы проектируем продукты и пишем ТЗ с помощью User Stories — это позволяет вовлекать в процесс заказчика и продакшн-команду. Как итог — все стороны разработки без труда ориентируются в проектной документации. Расскажу поэтапно, как мы выстраиваем процесс.

В статье разберём:

1. Что такое User Stories.

2. Как подготовиться к их написанию.

2.1. Бриф с заказчиком

2.2. Приоритизация функций.

3. Как писать User Stories.

4. Что с ними делать дальше.

Что такое User Story

User Story (US) — это краткая формулировка, которая отражает, что пользователь хочет сделать в системе, и как она должна отвечать на его действия.

Шаблон: 

Пример:

Формулировки User Stories — короткие и доступные. Их понимают все: лица со стороны бизнеса, менеджеры проектов, дизайнеры, разработчики и тестировщики. Заказчик сам может подключаться к проектированию и участвовать в создании User Stories. Всем участникам проще ориентироваться на достижение пользователем цели. Такой подход хорош для развития продукта и синхронизации всех команд.

Ещё один пример:

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

Если мы даём человеку User Stories, ему сразу станет понятна логика взаимодействия с его продуктом. Заказчик может предложить свои варианты. 

Если дать ему техническое задание на 300 листов — он не осилит столько сухого текста. И, скорее всего, даже не станет читать.

Как подготовиться к написанию User Stories

Чтобы написать User Stories, нужно зафиксировать список функций будущего продукта и согласовать их с заказчиком. Для этого проводят аналитику: изучают специфику бизнеса, рынок и пользователей. 

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

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

Как проводить бриф с заказчиком

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

Выделить цели встречи

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

Примеры целей для брифа

1. Зафиксировать, как работает система заказчика сейчас.

2. Выяснить, какие есть недостатки у системы.

3. Зафиксировать, какие функции должен включать будущий продукт, чтобы закрыть текущие недостатки.

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

Частый кейс: руководитель уверен, что он «знает всё», но на деле оказывается, что у его сотрудников совершенно другие боли и потребности. Лучше позвать на созвон sales-менеджера, который каждый день общается с клиентами, составляет сметы и собирает коммерческие предложения, чтобы он рассказал, с какими неудобствами сталкивается в работе. На основе этих данных будет понятно, какая функциональность решит его проблемы.

Как подготовиться к брифу: 5 шагов

1. Изучить материалы от заказчика. Его существующие продукты и внутренние системы, если есть доступ. Если уже была какая-то аналитика, изучить её итоги — записи звонков с руководителями, метрики, данные исследований, конкурентного анализа.

2. Изучить материалы по проекту: что уже сделано, какие встречи проведены, на каком этапе разработка продукта сейчас, есть ли макеты и так далее.

3. Узнать, есть ли аналоги на рынке и какую функциональность включают в себя продукты конкурентов.

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

5. Ко встрече подготовить список вопросов: отталкиваться от цели и обсуждать, что нужно для её достижения. 

Как проводить бриф

Плохой пример: расскажите, что вы хотите видеть в своей системе.

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

Какую-то базу нужно подготовить заранее. Заказчику проще дополнить или опровергнуть информацию, чем придумывать её с нуля. Подготовительная работа сократит количество звонков и время на них.

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

На примере ERP-системы:

1. С чего должна начинаться работа пользователя с вашей системой? Пользователь открывает сервис и… 

2. Уточним, какие у вас есть процессы в работе сейчас…

3. С какими программами сейчас работают ваши сотрудники? Какие цели они решают с их помощью?

4. Сколько всего департаментов и чем они занимаются?

5. Чем сотрудники чаще всего заняты в работе? (обработка жалоб, поиск заказа)

6. На что вы и сотрудники тратите больше всего времени в работе? 

7. Какие неудобства есть сейчас в работе? С какими проблемами вы сталкиваетесь? Что могло бы эти проблемы решить? Что по вашему мнению можно улучшить?

8. Расскажите, что пользователь должен делать в вашей системе/на вашем сайте?

Единого универсального списка не существует, как и не существует брифа, который идёт чётко по плану.

Фиксируйте все данные, которые получили. Обязательно записывайте встречу, но не забудьте сообщить об этом заказчику. Голосом в конце встречи проговорите пункты, о которых договорились. После созвона зафиксируйте всё письменно и отправьте на уточнение собеседникам. У вас должно быть подтверждение договорённостей, к которому можно будет вернуться в любой момент.

Приоритизация функций

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

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

В большинстве случаев всё сводится к определению:

Из ответов на эти вопросы получаем список:

1. Обязательных функций.

2. Функций, которые «хорошо бы сделать, но можно и без них запуститься». 

3. Совсем необязательных функций.

4. Функции, которые нужны для развития продукта, но их стоит отложить до следующих итераций.

Дальше можно брать функции, которые выделили в первый этап работы, и наконец-то писать пользовательские истории.

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

Также приоритизированные функции нужны, чтобы:

1. Понять, каким будет MVP. Выделить только необходимую функциональность и запуститься без лишних трат на разработку.

2. Скорректировать сроки разработки, чтобы быстрее запустить продукт на рынок.

3. Составить смету — без неё не одобрят ни один проект.

Пишем User Stories

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

Аналитик детализирует каждую функцию из сформированного этапа и расписывает в формате пользовательских историй, задавая вопросы:

1. Кто?

2. Что?

3. Зачем?

Почти «Что? Где? Когда?». Из этих трёх вопросов вырастают роли системы и понимание, что и зачем мы делаем.

Выделить роли пользователей

Чтобы учесть интересы всех пользователей в сервисе, нужно разбить их на роли. 

Например, в продукте есть функция авторизации. Что может авторизованный пользователь и что недоступно неавторизованному?

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

При этом в сервисе есть отдельная роль — «Работодатель». Только он может публиковать вакансии и изучать профили соискателей.

Примеры User Stories по ролям

Пример функций, расписанных с помощью User Stories

На примере того же сервиса по поиску работы и сотрудников.

Первый пример:

Функция: изучить отзывы о компании

User Story: я как соискатель и неавторизованный пользователь, хочу посмотреть отзывы о компании, чтобы понять условия работы.

Второй пример:

Функция: оставить отзыв или поставить оценку компании

User Story: я как соискатель, хочу оставить отзыв о компании, чтобы другие пользователи видели моё мнение.

Третий пример:

Функция: оставить запрос «Хочу работать в вашей компании».

User Story: я как соискатель, хочу оставить работодателю своё резюме, независимо от опубликованных вакансий, чтобы получить возможность работать в выбранной компании.

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

Что делать дальше с User Stories

Далее пользовательские истории проходят через все этапы проекта:

• На их основе дизайнеры создают прототипы и дизайн-макеты.

• К User Stories пишут критерии приёмки — подробные пункты с требованиями к создаваемой функциональности. Пользовательская история описывает основную цель новой функции — как она поможет пользователям. Критерии приёмки отражают принцип работы фичи с технической точки зрения.

• На основе пользовательских историй, прототипов и критериев приёмки пишем техническое задание.

• QA-инженеры с помощью технического задания пишут тест-кейсы.

• Разработчики при выполнении технических задач тоже опираются на User Stories и могут предлагать более подходящее решение. Но обо всех этих этапах подробно — в следующей части.

Выводы

Аналитика и проектирование — важные этапы проекта, от них зависит успех всех следующих шагов в разработке продукта.

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

Формулировки User Stories — простые и понятные. С ними могут работать все — и продакшн-команда, и заинтересованные лица со стороны бизнеса. С помощью этого инструмента легче вовлекать заказчика в проект и согласовывать с ним функциональность. Разработка становится прозрачнее.

В следующей части расскажу, как мы делаем прототипы, техническое задание и ведём разработку с помощью пользовательских историй.

А пока буду рада почитать ваши мысли в комментариях :)