Всем привет!

Я Полина — старший системный аналитик на проекте разработки и развития решений по управления данными в компании "Цифровые сервисы". В целом мой опыт в аналитике более 10 лет на позициях, как бизнес , так и системного аналитика.

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

Скажу честно, ряд аббревиатур я увидела впервые.

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

В статье использованы следующие понятия:

• Заказчик — юридическое или физическое лицо, инициирующее разработку ПО и предоставляющее требования к функционалу, дизайну и другим характеристикам продукта.

• Исполнитель — сторона (компания или специалист), ответственная за создание программного обеспечения в соответствии с требованиями Заказчика

• Пользователь — лицо, которое непосредственно взаимодействует с разработанным ПО в процессе его эксплуатации.

Итак, Рассмотрим определенный бизнес-процесс и на его примере по каждой из методик разработаем тот или иной артефакт. Предположим, что к команде разработки приходит Заказчик  ООО «СпортСтиль» с запросом разработки интернет-магазина спортивных товаров.

Начнем с CustDev.

CustDev (или Customer development) — это тестирование идеи будущего продукта на целевой аудитории (пользователями) с помощью интервью. Простыми словами, это общение с потенциальными клиентами, выявление их запросов и пожеланий по конкретному продукту или услуге ещё до их разработки.

Customer development помогает снизить риск неудачи при запуске стартапов, новых продуктов или услуг. После проведения CustDev-исследования компания не ориентируется на свои догадки, а создаёт продукты и услуги, которые точно нужны рынку.

Рассмотрим этапы CustDev:

1 Этап. Выдвижение гипотез: определение проблемы, которую хотим решить с помощью своего продукта.
2 Этап. Определение целевой аудитории (ЦА). 
3 Этап. Подготовка вопросов для интервью: составление вопросов для CustDev, которые помогут получить нужную информацию от потенциальных представителей ЦА, чтобы подтвердить или опровергнуть гипотезу
4 Этап. Поиск респондентов: поиск можно сделать через социальные сети, личные знакомства, офлайн-мероприятия, форумы или специализированные платформы для проведения опросов
5 Этап. Проведение интервью: выделить 3-4 самых важных вопроса; на каждый вопрос 2-3 минуты; опросить как можно больше респондентов.

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

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

Что делать с результатами интервью:

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

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

На мой взгляд полезный подход, как на этапе зарождения идеи разработки ПО, так и на этапе MVP — пообщаться с ЦА и понять в правильном направлении двигается компания или нет. — Возьму на вооружение.

Пример CustDev-исследования

Основная проблема: просадка продаж, отсутствие новых пользователей

1. Выдвижение гипотез

— Основные покупатели (70%) — мужчины 25-40 лет, занимающиеся фитнесом/бегом

— Нехватка видеообзоров товаров — ключевая причина отказа от покупки

— Сложный фильтр по размерам/брендам увеличивает время поиска на 40%

      2. Определение ЦА

— Спортсмены-любители — Возраст 18-45 лет, занимаются фитнесом/бегом 2-3 раза в неделю 

— Профессиональные спортсмены  — Тренируются ежедневно, участвуют в соревнованиях

— Родители  — Покупают спортивные товары для детей 5-17 лет

— Фитнес-тренеры  — Закупают инвентарь для залов/секций

      3. Подготовка вопросов для интервью

· Общая информация о ЦА:

      —  Какой ваш возраст?

· Опыт покупок спортивных товаров:

     — Расскажите, как вы обычно выбираете и покупаете спортивные товары?

     — Смотрите ли вы видеообзоры на товары, которые вас заинтересовали?
     — Какой ваш лучший и худший опыт онлайн-покупки?

· Критерии выбора:

         — На что вы в первую очередь обращаете внимание при выборе товара?

         — Как проверяете качество товара перед покупкой?

         — Какой информации вам чаще всего не хватает?

· Процесс выбора:

         — Какие фильтры/параметры используете при поиске?

         — Как проверяете достоверность информации о товаре?

· Критерии выбора магазина:

     —  Рейтинг важности: цена, ассортимент, доставка, гарантии и т.д.

      — Что может заставить вас отказаться от покупки?

      4. Поиск респондентов

— Соцсети:Группы бегунов, фитнес-сообщества (например, «Чемпион» во ВКонтакте).

— Родительские чаты (спортивные секции для детей)

— Посетители спортивных магазинов

       5. Проведение интервью

 Выделяем основные вопросы, которые будут заданы респондентам:
— Какой ваш возраст?

— Какие фильтры/параметры используете при поиске?

— На что вы в первую очередь обращаете внимание при выборе?

— Что может заставить вас отказаться от покупки?

— Какой ваш лучший и худший опыт онлайн-покупки?

 Итоги:

· Все гипотезы из п. 1 подтвердились

Бриф

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

Бриф нужен как Исполнителю, так и Заказчику.

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

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

Выделяют следующие виды брифов:

• Анкетный. Содержит общие сведения о заказчике, вопросы о целях и задачах компании.

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

• Обобщенный. Универсальный бриф с набором стандартных вопросов, который подходит для разных пользователей.

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

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

Какого-то единого шаблона Брифа нет, но есть обязательные разделы, которые он должен включать:

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

2. Целевая аудитория.Попросите Заказчика при заполнении брифа рассказать о том, каким он видит потенциального представителя ЦА: его пол, возраст, семейное и социальное положение, увлечения, боли. Если есть составленный портрет ЦА и иные результаты аналитики, можно их приложить.

3. Общие вопросы. Вид, объем и структура работы. Сколько нужно написать текста, нарисовать иллюстраций, разработать страниц сайта? Есть ли примеры конкурентов, которые нравятся: дизайн и юзабилити сайта, содержание блога, оформление розничной упаковки и прочее?

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

Бриф можно и нужно дополнять другими блоками и вопросами. 

Пример результата проведения Брифа

1. Общая информация

—  Название компании: ООО "СпортСтиль"

—  Сфера деятельности: Продажа спортивных товаров (одежда, обувь, инвентарь, аксессуары)

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

 2. Целевая аудитория

—  Основные группы:

- Спортсмены-любители и профессионалы

- Фитнес-тренеры и клубы

- Родители, покупающие товары для детей

- Корпоративные клиенты (спортивные школы, секции)

—  Возраст: 18 – 55 лет

—  География: Россия (с возможностью расширения на страны СНГ)

      3. Общие вопросы

—  Сроки разработки: 3 – 6 месяцев (в зависимости от сложности)

—  Бюджет: от 500 000 ₽ (уточняется после ТЗ)

      4. Требования к функционалу

—  Основные функции:

- Каталог товаров с фильтрами (категории, бренды, цена, размеры, цвет и т. д.)

- Корзина и оформление заказа

- Личный кабинет (история заказов, избранное, подписки)

- Оплата: онлайн (карты, СБП, PayPal), наложенный платеж, рассрочка

- Доставка: интеграция с СДЭК, Boxberry, Почтой России, самовывоз

- Поиск по сайту с умными подсказками

—  Дополнительные функции:

- Система лояльности (бонусы, скидки)

- Подписка на новости и акции

- Чат / онлайн-консультант

- Сравнение товаров

         5. Интеграции

—  Платежные системы (ЮKassa, Сбербанк Эквайринг, Tinkoff)

—  Службы доставки (СДЭК, Boxberry, Почта России)

—  Маркетплейсы (Wildberries, Ozon – опционально)

          6. Дополнительные пожелания

Разработка мобильного приложения (в будущем)

          7. Контакты

—  Контактное лицо: Иванов Иван Иванович

—  Телефон / Email: +79041234577

— Дата заполнения: 09.04.2025

BRD (или Business Requirement Document)

В Документе бизнес-требований (или Business Requirement Document) объясняется, почему Заказчику необходимо создать новое программное обеспечение или бизнес-решение. Он служит основой для дальнейшей разработки проекта, обеспечивая понимание бизнес-задач и ожидаемых результатов со стороны Заказчика и Исполнителей. Другими словами, этот документ используется для установления и документирования функциональных и нефункциональных требований, целей и ожиданий Заказчика.

Структура и наполнение BRD меняются в зависимости от проекта, но обычно он включает следующие обязательные пункты:

• Информация о компании, отрасли, целевой аудитории и конкурентах.

• Определение целей проекта и конкретных задач, которые необходимо выполнить.

• Функциональные требования (функции продукта, необходимые для достижения целей).

• Нефункциональные требования (к производительности, безопасности, надежности и другим характеристикам продукта).

• Показатели, по которым будет оцениваться успех проекта.

• Описание потенциальных рисков и способов их минимизации

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

Пример BRD

Business Requirements Document (BRD) для разработки интернет-магазина ООО "СпортСтиль"

1. Введение

    1.1. Цель документа
Определить бизнес-требования, функционал и ключевые характеристики интернет-магазина спортивных товаров для ООО "СпортСтиль".

2. Бизнес-требования

    2.1. Цели проекта

—  Увеличить продажи на 30%за год.

—  Обеспечить удобный и быстрый процесс покупки.

    2.2. Целевая аудитория
См. раздел 2 из брифа.

   2.3. Ключевые метрики успеха

—  Конверсия в покупку: ≥ 3%.

—  Среднее время загрузки страницы: < 2 сек

—  Уменьшение процента отказа на этапе оплаты: < 15%.

3.Функциональные требования

Функция	Описание
Каталог товаров		Древовидная структура категорий, фильтры (цена, бренд, размер), сортировка
Корзина		Возможность редактирования, сохранение на 24 часа, промокоды
Оформление заказа		Покупка, выбор доставки и оплаты
Личный кабинет		История заказов, избранное, подписки, бонусы
Поиск		Умный поиск с автодополнением и исправлением опечаток

4. Нефункциональные требования

   4.1. Производительность

Одновременная работа ≥ 1000 пользователей.

Загрузка страниц за < 2 сек

   4.2. Безопасность

Сертификат SSL.

Защита от SQL-инъекций и DDoS.

   4.3. Масштабируемость

Возможность добавить новые регионы доставки.

Расширение каталога товаров.

5. Потенциальные риски и способы их минимизации

Риск	Воздействие	Способ минимизации
Уязвимости безопасности (взлом, утечка данных)	Финансовые и репутационные потери	- Регулярные обновления плагинов - Шифрование данных (SSL, HTTPS)
Низкая производительность сайта при высокой нагрузке	Увеличение времени загрузки, потеря клиентов	- Использование кэширования - Оптимизация БД - Нагрузочное тестирование перед запуском

CJM

CJM (Customer Journey Map) — это визуализация взаимодействий Заказчика с вашим продуктом или услугой при выполнении какого-то сценария. Путь Пользователя от возникшей у пользователя потребности до пользования продуктом.

Основные элементы карты пользовательского пути:

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

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

3. Каналы взаимодействия. Здесь нужно определить каналы, которые Пользователи используют для взаимодействия с брендом: сайт, социальные сети, мобильные приложения, мессенджеры, магазины, колл-центры и другие.

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

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

6. Персонажи — типичные представители целевой аудитории с учетом их характеристик, соцдем параметров, мотиваций и поведения.

Карта может быть создана и представлена в виде таблицы, схемы или инфографики.

Пример CJM

Этап	Действия пользователя	Канал взаимодействия	Эмоции	Проблема	Возможность улучшения
1. Осведомленность	- Видит рекламу в Instagram - Ищет в Google "кроссовки для бега"	Соцсети, контекстная реклама	"Где купить качественные кроссовки?" "Какие бренды лучше?"	Нет узнаваемости бренда	Запустить таргетированную рекламу
2. Исследование	- Смотрит каталог - Читает отзывы - Сравнивает товары	Сайт, моб. версия, отзовики	"Фото некачественные"	Сложная навигация, мало информации, в том числе визуальной	- Добавить 3D-превью товаров - Внедрить чат с экспертом
3. Принятие решения	- Добавляет товар в корзину - Проверяет условия доставки	Корзина, pop-up с промокодами	"Доставят ли завтра?	Нет прозрачности по срокам доставки	- Калькулятор доставки на этапе корзины - Уведомление о наличии в реальном времени
4. Покупка	- Оформляет заказ - Выбирает оплату картой	Оформление заказа, платежный шлюз	"Сайт безопасен для платежей?" "Почему нет Apple Pay?"	Ограниченный перечень вариантов оплаты	Поддержка Apple Pay/Google Pay
5. Постпродажное обслуживание	- Получает SMS о статусе заказа - Оставляет отзыв	Email/SMS, соцсети, сайт	"Почему нет трек-номера?" "Как вернуть товар?"		- Автоматические трек-номера - Программа лояльности после первой покупки

Impact Map

Impact mapping — это современная методика облегчённого совместного стратегического планирования для Заказчиков (компаний) и Исполнителей (проектных команд ).

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

Impact Mapping применяется:

• Для формирования бэклога;

• Для определения рисков;

• Для выявления конфликтов интересов заинтересованных лиц;

• Для генерации гипотез по развитию продукта.

Рассмотрим каждый элемент Impact mapping:

Зачем мы это делаем?
Центральный элемент нашей карты, который отвечает на ключевой вопрос: Зачем мы это делаем? Это цель, которую Заказчик пытается достичь.

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

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

Что делаем?
После ответа на основные вопросы можно обсудить конкретные задачи. Третий уровень отвечает на вопросы: Что мы можем сделать как организация или команда разработки, чтобы создать необходимые воздействия? Здесь будет описан конечный результат нашей работы. На последнем этапе обрисуйте конкретные задачи, которые необходимо выполнить для воплощения идей в жизнь. Выставляйте задачи по приоритету, распределяя ответственность за их выполнение.

USM

Каждый аналитик знает эту аббревиатуру и скорее всего использует на практике. 

User Story Mapping — это методика визуализации пользовательских историй, которая помогает Исполнителям лучше понять пользовательский опыт и определить приоритеты для разработки функциональности продукта.

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

Обычно создание User Story Mapping занимает 2–3 часа. Этого достаточно, чтобы выполнить основные этапы — устроить короткий мозговой штурм, сгруппировать действия Пользователей и найти в них пробелы, приоритизировать бэклог продукта и начать использовать его на практике.

Этапы в User Story Mapping:

1) Подготовка. Выберите, где и как вы будете работать над User Story Mapping. Используйте традиционные инструменты визуализации — цветные стикеры или специальные инструменты вроде Miro, Trello или Cardboardit.

2) Мозговой штурм. Начните с вопроса: «Что пользователь сделал бы с продуктом?». Выделите 2–3 минуты на индивидуальный мозговой штурм, а затем начинайте совместное обсуждение. Представьте, что вы пользователь, заинтересованный в продукте. Отталкивайтесь от того, какие действия необходимо совершить, чтобы закрыть свои потребности. Результатом мозгового штурма должна стать история Пользователя по шагам — что он делает, когда использует продукт.

3) Группировка действий. Когда у вас есть набор основных действий Пользователя, переходите к их упорядочиванию — группировке. Допустим, вы выделили 10 – 15 шагов, которые совершает пользователь. Работать над каждым отдельно может быть неэффективно, поэтому разделите их на тематические категории.

4) Заполнение пробелов. Теперь перед Исполнителем история Пользователя. Она поделена на разделы, а разделы — на отдельные шаги. Когда действия Пользователя упорядочены, сразу заметны пробелы — шаги, которые Исполнитель упустил. Подумайте, чего не хватает для удобства Пользователя и как можно упростить взаимодействие с продуктом.

5) Расстановка приоритетов. Решите, что нужно сделать обязательно, что — желательно, а что — можно оставить на будущее и реализовать по возможности. Не забывайте: вы смотрите на продукт со стороны Пользователей, а не разработчиков и дизайнеров (Исполнителя).

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

US+AC

Acceptance Criteria (AC) — критерий того, что задача не просто готова, а еще и работает так, как надо Заказчику.

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

Пример AC:

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

Acceptance Criteria:

• Пользователь может отправить форму регистрации только после того, как заполнены все обязательные поля;

• Email должен быть уникальным;

• Пользователь получает уведомление по email после успешной регистрации.

Почему используются вместе User Story и Acceptance Criteria. User Story задаёт контекст, а Acceptance Criteria — конкретные технические и бизнес-условия.

Использование чётких критериев приёмки приносит команде и продукту несколько важных преимуществ:

1) Общее понимание задач и требований. Все члены проекта говорят на одном языке, что снижает количество ошибок и разночтений.

2) Минимизация переделок. Когда критерии чётко прописаны, команда знает, когда задача считается выполненной.

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

4) Контроль прогресса. Для менеджеров каждый выполненный критерий — явный показатель продвижения работ.

5) Повышение качества готового продукта. Продукт лучше соответствует ожиданиям и требованиям конечных пользователей.

Схемы в BPMN/ EPC

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

—  BPMN

—  UML

—  EPC

JSM

Jira Service Management (JSM) — это инструмент от Atlassian для эффективного управления услугами. Он предназначен для ИТ-отделов и служб поддержки клиентов. Благодаря гибким службам поддержки и автоматизации он помогает операторам оперативно решать проблемы. С помощью Jira Service Management команды могут следить за тем, как они выполняют соглашения об уровне обслуживания. Это помогает обеспечить своевременную доставку услуг.

Jira Service Management предлагает ряд мощных функций, разработанных для оптимизации доставки услуг и операционного совершенства. Ключевые функции включают:

• Управление инцидентами: Быстро устраняйте и решайте инциденты, чтобы минимизировать сбои в обслуживании.

• Управление запросами на услуги: Упрощайте и эффективно управляйте запросами сотрудников и клиентов.

• Управление проблемами: Определяйте и управляйте коренными причинами инцидентов, чтобы предотвратить их повторение.

• Управление изменениями: Планируйте, отслеживайте и управляйте изменениями, чтобы минимизировать риски и обеспечить успешное развертывание.

• Управление конфигурацией: Поддерживайте всеобъемлющий обзор IT-активов и конфигураций.

• Управление знаниями: Централизуйте и делитесь знаниями, чтобы наделить команды полномочиями и улучшить процесс предоставления услуг.

• Управление уровнем обслуживания: Определяйте, отслеживайте и выполняйте соглашения об уровне обслуживания (SLA), чтобы соответствовать целям организации.

• Управление активами: Отслеживайте и управляйте аппаратными и программными активами, чтобы оптимизировать использование ресурсов.

• Отчетность и аналитика: Получите информацию о производительности сервиса и определите области для улучшения.

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

JS +AC

При работе над статьей я столкнулась с необходимостью уточнить значения некоторых специализированных аббревиатур. Несмотря на обращение к поисковым системам и нейросетям, включая DeepSeek, точные определения найти не удалось.

Единственным решением стало обращение к первоисточнику — спикеру доклада, на основе которого готовился материал. Я связалась с Дмитрием Неверовым (X5 Tech), и он любезно предоставил развернутые пояснения, за что выражаю ему искреннюю признательность. Его экспертиза значительно дополнила статью и помогла избежать неточностей.

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

Итак, 

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

Шпаргалка для составления JS: 

Когда [контекст/ситуация], то [мотивация], чтобы [результат]

 Job Story на русском языке составляется от первого лица (местоимения Я, Меня).

JS применяют, когда хотят:

• усовершенствовать продукт, который уже есть;

• понять, как должен выглядеть новый продукт;

• выйти на новые рынки, привлечь других потенциальных клиентов;

• передавать информацию о потребностях клиента команде, которая работает над продуктом;

• найти ориентир в рекламных посылах, маркетинговой стратегии.

Различия User Story и Job Story

Job Story. Помогает понять проблему пользователя и его мотивацию. Формула JS: «Когда (контекст), я хочу (мотив), чтобы (цель)»

User Story. Помогает изучить пользователя. Формула US: «Я, как (роль человека), хочу (основное желание), чтобы (результат и выгода)»

Примеры : 

а) Поиск и выбор товаров

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

б) Оформление заказа

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

в) Обратная связь и поддержка

Когда у меня как у клиента возникает вопрос или проблема с заказом,
то мне нужна быстрая связь с поддержкой (чат, телефон, email),
чтобы оперативно получить помощь и не прерывать покупку.

Зачем комбинировать Job Story и Acceptance Criteria?

Преимущества такого подхода

• Уменьшает недопонимание между разработчиками, тестировщиками и продукт-менеджерами.

• Позволяет проверить реализацию не только по функционалу, но и по ценности для пользователя.

Пример в связке:

Job Story:
"Когда я как клиент добавляю товар в корзину, я хочу видеть его количество и стоимость, чтобы контролировать бюджет."

Acceptance Criteria:

• В корзине отображается список товаров с их количеством и ценой за единицу.

• Показывается общая сумма заказа.

• При изменении количества товара сумма пересчитывается автоматически.

Таким образом, Job Story задает контекст и ценность, а Acceptance Criteria — четкие требования к реализации. Вместе они делают задачи более понятными и измеримыми

Выводы

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

Должен ли аналитик уметь всё? Однозначно — нет.

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

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

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