Основы системной аналитики

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Аналитику Архитектору Руководителю Техническому писателю

---

Виды аналитиков

Аналитиками называют несколько профессий:

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

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

Бизнес-аналитик

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

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

Системный аналитик

СА получает от бизнес-аналитика (или напрямую от заказчика) описание того, что нужно сделать, и превращает это в техническое задание для разработчиков, описывая как именно это должно работать.

• он детально прорабатывает функциональность, проектирует архитектуру системы, описывает сценарии работы пользователей (Use Case), продумывает, как система будет обмениваться данными с другими (API, интеграции), и ставит задачи разработчикам (фронтенд и бэкенд).
• он готовит технически проработанные задачи для разработчиков, схемы баз данных, описание API, техническая документация.
• для него важно глубокое знание технологий, архитектуры ПО, баз данных (SQL), UML-диаграмм, понимание жизненного цикла разработки (SDLC).

Аналитик данных

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

• он собирает данные из разных источников, очищает их и преобразует, ищет закономерности и тренды, строит прогнозы, визуализирует результаты в виде дашбордов и отчетов (например, в Power BI или Tableau).
• он готовит отчёты, дашборды, графики, аналитические выводы и рекомендации для бизнеса.
• для него важно владение SQL, Python/R, статистика, умение визуализировать данные, знание BI-инструментов.

Другие виды аналитиков

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

• Продуктовый аналитик, который анализирует метрики продукта (Retention, LTV, ARPU) и дает рекомендации по его развитию на основе данных.
• BI-аналитик (Business Intelligence Analyst), специализируется на создании систем отчетности, дашбордов и витрин данных для поддержки бизнес-решений. Его работа очень близка к работе аналитика данных, но с большим уклоном в бизнес-показатели.
• Маркетинговый аналитик, анализирует эффективность рекламных кампаний, строит воронки продаж, считает CAC (Customer Acquisition Cost) и ROMI (Return on Marketing Investment).
• UX-аналитик, изучает поведение пользователей на сайте или в приложении, чтобы улучшить их опыт и удобство интерфейса.

Главное различие между ними кроется в их объекте работы.

---

Порядок действий системного аналитика

В отличие от хаотичного «реактивного» подхода, работа строится как четкий технологический конвейер. В индустрии стандартом де-факто является последовательность, описываемая SWEBOK (свод знаний по программной инженерии) и гибкими методологиями, но адаптированная под реальные проекты.

Этап 0. Входящий контекст (Pre-Analysis)

Прежде чем что-то делать, вы получаете «вход»:

• Что вы получаете: Сырое бизнес-требование (от заказчика, продакта или бизнес-аналитика). Часто это просто фраза: «Сделайте, чтобы пользователь мог оплатить заказ в два клика».
• Действие: Вы оцениваете техническую осуществимость (Feasibility study). Можно ли это сделать на текущем стеке? Нет ли архитектурных ограничений?

Этап 1. Декомпозиция и погружение (Анализ требований)

Здесь вы превращаете «хотелку» в структурированную логику.

• Действие 1.1. Формализация: Вы разбиваете задачу на атомарные куски. Что именно делает система до, во время и после оплаты?
• Действие 1.2. Выявление сущностей: Определяете, какие объекты (данные) участвуют. (Заказ, Платеж, Статус, Пользователь).
• Действие 1.3. Анализ ограничений: Ищете «не сказанное»: какая максимальная сумма платежа? Сколько раз можно пытаться оплатить? Какое время ответа допустимо?

Этап 2. Описание логики и сценариев (Моделирование)

Вы переходите от мыслей к чертежам. На этом этапе создаются 3 ключевые модели.

• Действие 2.1. Сценарии (Use Cases): Пишете позитивный (все работает) и негативные (карта отклонена, сеть упала, сессия истекла) сценарии.
• Действие 2.2. Диаграммы состояний: Рисуете State Machine — как меняется статус заказа (Черновик → Ожидает оплаты → Оплачен → Отгружен → Возврат).
• Действие 2.3. Диаграммы последовательности (Sequence Diagram): Это самый важный шаг. Вы чертите стрелочки, показывающие, кто с кем общается: Клиент → Фронт → Бэкенд → Платежный шлюз → База данных. Без этой диаграммы разработчики не поймут очередность вызовов.

Этап 3. Проектирование интеграций и данных (API & DB)

Теперь вы спускаетесь на уровень конкретных протоколов и форматов.

• Действие 3.1. Контракты API: Вы описываете, какие поля (в формате JSON/XML) приходят в запросе, а какие возвращаются в ответе. Прописываете HTTP-методы (POST /payment), коды ошибок (400, 500) и заголовки.
• Действие 3.2. Работа с БД (Data Modeling): Выясняете, какие таблицы нужно создать или изменить. Пишете схему: Таблица Orders — добавить колонку payment_id. Если данных много — продумываете индексы для скорости.
• Действие 3.3. Интеграционные сценарии: Если система стучится во внешний сервис, вы описываете поведение при таймауте (повтор запроса? Идемпотентность?).

Этап 4. Написание артефактов (Документирование)

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

• Действие: Вы пишете Техническое задание (ТЗ) или User Story с критериями приемки. В него входят:
• AS-IS (как было) и TO-BE (как станет).
• Формулы расчетов (если есть математика).
• Граничные условия (Edge cases): что, если пользователь ввел отрицательное число? Что, если дата окончания оплаты меньше сегодняшней?

Этап 5. Передача в разработку (Refinement / Estimation)

Ваше решение должно быть понято разработчиками и оценено в деньгах/времени.

• Действие 5.1. Презентация решения: Собираете команду (Dev, QA, DevOps) и проводите Demand-сессию (или Grooming). Рассказываете, как вы решили задачу.
• Действие 5.2. Оценка (Estimation): Вместе с тимлидом дробите работу на подзадачи (Backend Task, Frontend Task, DB Migration) и прикидываете трудозатраты в story points или часах.
• Действие 5.3. Снятие вопросов: Разработчики начнут задавать каверзные вопросы, которых вы не учли. На этом этапе вы правите свое решение (это нормально).

Этап 6. Сопровождение разработки и тестирования (Support)

Аналитик не бросает задачу после передачи.

• Действие 6.1. Review кода: Проверяете, реализовал ли разработчик логику так, как вы задумали.
• Действие 6.2. Тест-кейсы: Вместе с QA (тестировщиками) помогаете написать чек-листы. Вы знаете все пограничные сценарии лучше всех — подсказываете, где могут быть «баги».
• Действие 6.3. Приемка (Acceptance): После того как код написан, вы первыми (или вместе с заказчиком) проверяете стенд, подтверждая, что поведение системы полностью соответствует вашей документации.

Этап 7. Финал (Демо и Архивация)

Действие: Показываете рабочую фичу заказчику (на демо-встрече). Обновляете главную вики/конфлюенс проекта, чтобы новые аналитики в будущем знали, почему вы приняли именно такое архитектурное решение.

EARS

Во время этих 7 этапов вы непрерывно задаете 4 главных вопроса (правило EARS или аналоги):

• Когда? (Триггер)
• Если? (Условие)
• То что? (Действие системы)
• А если нет? (Альтернативный поток)

---

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

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

Давайте разложим бизнес-требования по полочкам. Согласно стандартам (IIBA, BABOK), они делятся на уровни, типы и категории качества.

Уровень 1. Бизнес-требования (Самые верхние)

Это цели и задачи компании на самом высоком уровне. Они не про IT, они про деньги, выживание и развитие.

Что это: Формулировка проблемы или возможности, которую хочет решить топ-менеджмент.

Примеры:

• «Увеличить долю рынка в регионе на 5%».
• «Снизить операционные расходы на поддержку клиентов на 20%».
• «Выйти на международный рынок (Европа)».

Важно для СА: Вы не проектируете это, но вы должны знать эту цель. Без нее вы не сможете отказаться от лишней фичи, сказав: "Это требование не ведет к цели снижения расходов".

Уровень 2. Требования стейкхолдеров (Пользовательские требования)

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

Что это: Описание задач, которые пользователь должен выполнить в системе.

Примеры:

• «Менеджер по продажам должен видеть историю заказов клиента за 1 секунду».
• «Оператор колл-центра должен иметь возможность заблокировать карту клиента в один клик».

Важно для СА: Здесь появляются роли (Actor) и сценарии использования (Use Cases). Вы начинаете понимать, кому что нужно.

Уровень 3. Функциональные требования (Это уже про систему)

А вот здесь начинается ваша работа. Это конкретные действия, которые система ОБЯЗАНА выполнять, чтобы удовлетворить бизнес-цели и пользователей.

Именно функциональные требования делятся на классические типы:

• Создание (Create). Система должна позволять вводить / создавать новую сущность. «Система должна создать заказ после нажатия кнопки "Оформить"».
• Чтение (Read). Система должна отображать информацию. «Система должна показывать текущий статус заказа на дашборде».
• Обновление (Update). Система должна изменять существующие данные. «Система должна обновлять остатки товара на складе после оплаты».
• Удаление (Delete). Система должна удалять данные (или делать их неактивными). «Система должна удалять товар из корзины, если его больше нет в наличии».
• Бизнес-правила. Условия, по которым работает логика (алгоритмы). «При сумме заказа > 1000 руб. доставка должна быть бесплатной» (здесь вы уже пишете формулу).
• Интеграционные. Связь с другими системами. «Система должна отправить запрос в платежный шлюз и получить код авторизации».

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

Они же «качественные характеристики». Система может делать всё, что написано выше, но если она тормозит или падает — бизнес-требование не выполнено.

Типы NFR:

• Производительность: «Время ответа API не должно превышать 200 мс при 1000 RPS».
• Надежность: «Система должна восстанавливаться после сбоя за 5 минут (RTO)».
• Безопасность: «Все пароли должны храниться в захэшированном виде (bcrypt)».
• Удобство использования (Usability): «Новый пользователь должен оформить заказ не более чем за 3 шага».
• Масштабируемость: «Система должна выдерживать пиковые нагрузки в Черную пятницу (x10 от обычных)».

Ограничения (Constraints)

Это не совсем требования, это рамки, за которые вы не можете выйти.

• Технологические: «Мы используем только PostgreSQL, никаких MongoDB» или «Бэкенд только на Java».
• Регуляторные (Юридические): «Данные российских граждан должны храниться на серверах в РФ (152-ФЗ)».
• Временные: «Фича должна быть готова к 1 декабря (дедлайн)».

MoSCoW

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

• Must have (S — критические): Если этого нет — систему нельзя релизить. (Например, кнопка «Оплатить»).
• Should have (H — важные): Очень нужно, но если не успеем, можно поставить костыль или сделать позже. (Например, отправка СМС-уведомления об оплате).
• Could have (L — желательные): Приятные мелочи, если останется время. (Тёмная тема для личного кабинета).
• Won't have (в этом релизе не делаем): Внесено в бэклог, чтобы не спорить. (Интеграция с криптовалютой).

Как отличить бизнес-требование от функционального?

Ко мне часто приходит заказчик и говорит: «Нам нужно, чтобы в профиле у пользователя был аватар».

• Для него это Бизнес-требование (чтобы повысить доверие к продавцам).
• Но для системного аналитика это становится ворохом Функциональных и Нефункциональных задач:

1. Система должна принимать файлы формата JPG/PNG (ФТ).
2. Максимальный размер файла — 5 Мб (ФТ).
3. Система должна сжимать (ресайзить) картинку до 200x200 px, чтобы не тормозить страницу (НФТ производительности).
4. Аватар должен отображаться через 1 секунду после загрузки (НФТ).

Ваша суперсила как аналитика — разбить расплывчатую бизнес-идею на эти жесткие, четкие, измеримые пункты.

---

Стейкхолдеры

Стейкхолдеры (заинтересованные стороны) — это физические лица, группы или организации, которые оказывают влияние на проект/продукт или испытывают на себе его последствия. В IT-разработке и управлении проектами этот термин шире, чем просто «заказчик» или «клиент».

Классификация стейкхолдеров

Наиболее устойчивая классификация делит их по отношению к организации или проекту:

1. Внутренние стейкхолдеры

Находятся внутри компании или проектной команды. Их интересы напрямую связаны с операционной деятельностью.

• Команда разработки: разработчики, тестировщики, дизайнеры, DevOps. Заинтересованы в технической реализуемости, качестве кода, адекватных сроках и инструментарии.
• Менеджмент проекта / Продукта: PM, PO, Team Lead. Отвечают за результат, бюджет, сроки и соответствие требованиям.
• Руководство компании: C-level, директора департаментов. Интересуются стратегическим соответствием, ROI, рисками и репутацией.
• Смежные отделы: маркетинг, продажи, поддержка, HR, юридический отдел, безопасность. Могут быть затронуты изменениями в продукте или процессах.

2. Внешние стейкхолдеры

Находятся за пределами организации, но взаимодействуют с ней или зависят от неё.

• Клиенты / Пользователи: конечные потребители продукта. Ключевая группа для валидации ценности.
• Заказчики / Инвесторы: финансируют проект. Ожидают возврата инвестиций или решения бизнес-задачи.
• Партнёры и поставщики: интеграторы, облачные провайдеры, вендоры ПО, аутсорс-команды. Зависят от контрактов и API.
• Регуляторы и государство: органы, устанавливающие стандарты, законы (например, 152-ФЗ, GDPR), лицензионные требования.
• Конкуренты: косвенные стейкхолдеры; их действия влияют на приоритеты и стратегию продукта.
• Общество и СМИ: могут формировать общественное мнение, особенно для публичных сервисов.

Типология по уровню влияния и заинтересованности

Для практической работы (приоритезации коммуникации) используется матрица Менделова:

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

---

End-to-End Pipeline

Процесс трансформации абстрактной бизнес-цели в детальное техническое задание (ТЗ) представляет собой последовательную декомпозицию. В индустрии этот процесс называется Requirements Engineering (инженерия требований).

Ниже приведена каноническая цепочка этапов. Названия артефактов могут варьироваться в зависимости от методологии (Waterfall, Agile, RUP), но логика перехода от «Зачем» к «Как именно» остаётся неизменной.

1. Выявление бизнес-потребности (Business Need)

• Вход: Абстрактная цель, проблема, идея или регуляторное требование.
• Действия: Интервью со стейкхолдерами, анализ рынка, изучение стратегии, проблемный анализ (Root Cause Analysis).
• Результат: Problem Statement или Business Case. Фиксация того, зачем это нужно и какую ценность создаёт.
• Пример: «Клиенты уходят к конкурентам из-за долгого оформления заказа».

2. Формализация бизнес-требований (Business Requirements)

• Вход: Problem Statement.
• Действия: Определение границ проекта, целевых метрик (KPI/OKR), ограничений бюджета и сроков. Согласование со спонсорами.
• Результат: BRD (Business Requirements Document) или Vision & Scope. Документ отвечает на вопрос «Что должно измениться в бизнесе?».
• Пример: «Сократить среднее время оформления заказа с 5 до 2 минут; увеличить конверсию чекаута на 15% к Q4».

3. Сбор пользовательских требований (User/Stakeholder Requirements)

• Вход: BRD.
• Действия: Анализ ролей, Customer Journey Map, User Stories, Use Cases, Jobs To Be Done. Описание сценариев взаимодействия без привязки к реализации.
• Результат: SRS (Software Requirements Specification), часть 1, или Backlog Epics/User Stories. Отвечает на вопрос «Что пользователи должны мочь делать?».
• Пример: «Как покупатель, я хочу сохранить данные карты, чтобы не вводить их повторно при повторной покупке».

4. Определение системных требований (System/Solution Requirements)

Этот этап делится на два подэтапа:

4а. Функциональные требования (Functional Requirements)

• Действия: Декомпозиция пользовательских сценариев на поведение системы. Описание входных данных, логики обработки, выходных данных, состояний.
• Результат: Детальные спецификации функций, диаграммы состояний, sequence diagrams.
• Пример: «При нажатии "Сохранить карту" система должна токенизировать PAN через шлюз X и сохранить токен в профиле пользователя».

4б. Нефункциональные требования (Non-functional / Quality Attributes)

• Действия: Определение атрибутов качества по стандартам (ISO 25010): производительность, безопасность, доступность, масштабируемость, совместимость.
• Результат: SLA, критерии приёмки по качеству, архитектурные ограничения.
• Пример: «95-й перцентиль времени ответа API сохранения карты < 200 мс при нагрузке 1000 RPS».

5. Составление детального ТЗ (Detailed Technical Specification)

• Вход: Полностью определённые системные требования.
• Действия: Привязка требований к конкретной архитектуре, стеку, интеграциям. Описание структур БД, контрактов API, алгоритмов, конфигураций. Верификация на реализуемость.
• Результат: ТЗ на разработку (или Design Doc / Tech Spec). Отвечает на вопрос «Как именно это будет реализовано?». Это прямой контракт между аналитиком/архитектором и разработчиком.
• Пример: Схема таблицы user_payment_tokens, OpenAPI-спецификация эндпоинта POST /api/v1/tokens, описание обработки ошибок шлюза.

6. Валидация и верификация (Validation & Verification)

Не является этапом создания, но обязателен перед передачей в работу.

• Верификация: «Мы сделали ТЗ правильно?» (проверка на полноту, непротиворечивость, однозначность). Рецензирование, инспекции.
• Валидация: «Мы сделали правильное ТЗ?» (соответствует ли оно исходной бизнес-цели). UAT-критерии, трассировочная матрица (RTM).

---

Как собирать требования?

Сбор требований (Requirements Elicitation) — это активный исследовательский процесс выявления скрытых, противоречивых и неосознанных потребностей. Заказчики часто формулируют решения, а не проблемы, или упускают критические детали.

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

1. Техники работы с людьми (Коммуникативные)

Интервью (Interviews)

• Суть: Прямой диалог со стейкхолдером по подготовленному плану.
• Когда применять: Для получения глубокого понимания контекста, мотивации, скрытых проблем. На старте проекта и для уточнения деталей.
• Нюанс: Разделяйте факты («процесс занимает 3 дня») и мнения («процесс неудобный»). Всегда просите привести конкретные примеры из прошлого опыта. Избегайте наводящих вопросов.

Фокус-группы и воркшопы (Workshops / JAD)

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

Наблюдение (Observation / Job Shadowing)

• Суть: Аналитик наблюдает за работой пользователя в естественной среде, не вмешиваясь (пассивное) или выполняя работу вместе с ним (активное).
• Когда применять: Когда пользователи не могут вербализовать процесс, делают много неочевидных действий «на автомате», или когда заявленные процессы расходятся с реальными.
• Нюанс: Люди меняют поведение, когда за ними наблюдают (эффект Хоторна). Пассивное наблюдение даёт более достоверную картину рутины.

2. Техники работы с артефактами и данными

Анализ документов (Document Analysis)

• Суть: Изучение существующей документации, регламентов, отчётов, логов, тикетов поддержки, кода legacy-системы.
• Когда применять: На самом старте, до интервью. Позволяет прийти на встречу подготовленным и не задавать вопросы, ответы на которые уже есть в документации.
• Нюанс: Документация часто устаревшая. Это отправная точка, а не истина в последней инстанции.

Анализ интерфейсов и систем (Interface / System Analysis)

• Суть: Исследование API, БД, UI текущей системы для понимания того, что уже реализовано.
• Когда применять: При модернизации, интеграции или замене legacy-систем.
• Нюанс: Код отражает как сделано, но не всегда зачем. Требуется сопоставление с бизнес-контекстом.

3. Техники моделирования и прототипирования

Прототипирование (Prototyping / Wireframing)

• Суть: Создание визуальной модели (от наброска на бумаге до кликабельного макета) для получения обратной связи.
• Когда применять: Когда требования к UI/UX неясны, стейкхолдерам сложно мыслить абстрактно, нужно валидировать понимание.
• Нюанс: Прототип — это вопрос, а не ответ. Фиксируйте обратную связь, а не сам макет как требование. Чрезмерная детализация раннего прототипа создаёт ложное ощущение завершённости.

Моделирование процессов (Process Modeling)

• Суть: Визуализация текущего (As-Is) и целевого (To-Be) процесса в нотациях BPMN, UML Activity Diagram.
• Когда применять: Для выявления узких мест, дублирования функций, точек передачи ответственности.
• Нюанс: Модель должна быть верифицирована исполнителями процесса. Аналитик не может нарисовать процесс правильно без подтверждения тех, кто его выполняет.

4. Техники выявления скрытых требований

Анализ корневых причин (Root Cause Analysis / 5 Whys)

• Суть: Последовательное задавание вопроса «почему» для перехода от симптома к реальной проблеме.
• Когда применять: Когда стейкхолдер настаивает на конкретном решении, но не может объяснить зачем.

Brainstorming и Mind Mapping

• Суть: Генерация идей без критики с последующей структуризацией.
• Когда применять: Для расширения границ поиска решений, выявления нефункциональных требований, которые забывают упомянуть.

Принципы эффективного сбора

1. Подготовка обязательна. Нельзя приходить на интервью с чистым листом. Гипотезы, список вопросов, изученные документы — база качественной сессии.
2. Разделение фактов и интерпретаций. Записывайте цитаты и наблюдаемые действия отдельно от своих выводов.
3. Немедленная фиксация. Память ненадёжна. Заметки, запись (с согласия), фото досок — сразу после сессии.
4. Верификация «по горячим следам». Резюме встречи отправляется участникам в течение 24 часов для подтверждения. «Правильно ли я понял, что...» — обязательная практика.
5. Контекст важнее слов. Слова «быстро», «удобно», «надёжно» бессмысленны без количественных критериев и примеров. Всегда уточняйте: «Что конкретно означает "быстро" в этом случае?».
6. Ищите негативные сценарии. Стейкхолдеры описывают «счастливый путь». Ваша задача — спрашивать: «А что если?», «А когда это сломается?», «Кто ещё может это сделать?».

---

Какие виды сбора требований выбирать?

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

1. По стадии проекта

Стадия	Рекомендуемые техники	Обоснование
Инициация / Discovery	Анализ документов, Интервью (стратегические), Наблюдение (As-Is)	Нужно понять контекст, реальное положение дел и бизнес-цели до того, как предлагать решения. Прототипы на этом этапе преждевременны.
Элаборация / Детализация	Воркшопы, Прототипирование, Моделирование процессов, Интервью (тактические)	Требуется согласование противоречий, уточнение сценариев, валидация понимания. Визуализация критически важна.
Валидация / Уточнение	Прототипирование (кликабельные), Review-сессии, Анализ интерфейсов	Проверка корректности зафиксированных требований. Выявление пропусков через конкретные артефакты.
Поддержка / Эволюция	Анализ тикетов/логов, Интервью с поддержкой, Анализ данных	Требования приходят из эксплуатации. Стейкхолдеры могут не помнить первоначальный контекст.

2. По типу стейкхолдеров

Характеристика стейкхолдера	Эффективные техники	Неэффективные / Рискованные
Высокоуровневые (C-level, спонсоры)	Короткие интервью, Анализ стратегических документов, Воркшопы по приоритизации	Детальное моделирование процессов, прототипы UI (если не обсуждается UX-стратегия). Они мыслят целями, а не функциями.
Эксперты предметной области (SME)	Наблюдение, Глубинные интервью, Моделирование As-Is	Опросники (теряется нюанс), фокус-группы (могут доминировать или замыкаться). Знают «как есть», но могут не видеть альтернатив.
Конечные пользователи (массовые)	Опросы, Анализ данных использования, Юзабилити-тестирование прототипов	Индивидуальные интервью (нерепрезентативно), воркшопы (сложно собрать репрезентативную группу).
Технические специалисты	Анализ кода/API/БД, Совместное моделирование, Интервью по интеграциям	Бизнес-воркшопы без подготовки (говорят на разных языках). Требуют конкретики и артефактов.
Недоступные / Распределённые	Асинхронные опросы, Анализ документации/тикетов, Запись сессий	Синхронные воркшопы, наблюдение. Коммуникационные барьеры требуют адаптации формата.
Конфликтующие группы	Фасилитируемые воркшопы, Joint Application Design (JAD)	Раздельные интервью (усиливают silos), опросы (не выявляют корни конфликта). Нужна модерация для достижения консенсуса.

3. По типу требований

Тип требования	Первичные техники	Вспомогательные техники
Бизнес-цели и метрики	Интервью со спонсорами, Анализ стратегии, Brainstorming	Бенчмаркинг, анализ конкурентов
Бизнес-процессы	Наблюдение, Моделирование (BPMN/UML), Интервью с исполнителями	Анализ регламентов (как база, не как истина)
Функциональные (UI/UX)	Прототипирование, User Stories, Воркшопы	Анализ аналогов, юзабилити-тестирование
Интеграционные / Системные	Анализ API/контрактов, Интервью с техспециалистами, Sequence Diagrams	Анализ логов, нагрузочное тестирование существующей системы
Нефункциональные (NFR)	Интервью с архитекторами/DevOps, Анализ SLA, Бенчмаркинг	Опросы пользователей (для субъективных атрибутов типа «удобства»)
Данные и отчётность	Анализ БД, Интервью с потребителями отчётов, Data Profiling	Прототипы дашбордов, анализ запросов к БД

4. По ограничениям проекта

Ограничение	Адаптация техник
Жёсткий дедлайн	Приоритет: анализ документов + короткие целевые интервью. Отказ от масштабных воркшопов и глубокого наблюдения. Фокус на MVP-требованиях.
Ограниченный бюджет	Минимизация синхронных сессий. Максимум асинхронного анализа (документы, данные, тикеты). Прототипы низкой точности (paper/wireframe).
Legacy-система без документации	Наблюдение и анализ кода/БД становятся основными, а не вспомогательными. Интервью с давними сотрудниками. Реверс-инжиниринг.
Высокие риски / Регуляторика	Обязательное сочетание: документальный анализ (нормативы) + формальные воркшопы с верификацией + трассировка. Недопустимо полагаться только на устные источники.
Инновационный продукт (нет аналогов)	Прототипирование и эксперименты (Lean Startup подход) первичны. Интервью и опросы вторичны (пользователи не знают, чего хотят). Наблюдение за аналогичными потребностями в других доменах.

Критерии выбора: чек-лист перед планированием

Перед выбором техники ответьте на вопросы:

1. Что мы не знаем? (Контекст → документы/наблюдение; Противоречия → воркшоп; Детали UI → прототип; Скрытые проблемы → 5 Whys).
2. Кто обладает знанием? (Доступность, articulateness, мотивация).
3. Какова цена ошибки? (Высокая → формальные техники + верификация; Низкая → лёгкие техники + быстрая валидация).
4. Есть ли существующие артефакты? (Да → начать с анализа; Нет → начинать с людей).
5. Каковы временные и ресурсные ограничения? (Реалистично оценивайте стоимость каждой техники).

Важное предостережение

Никогда не используйте одну технику изолированно. Треугольная верификация (triangulation) — золотой стандарт: каждое ключевое требование должно быть подтверждено минимум двумя независимыми источниками (например, интервью + наблюдение, или документ + прототип). Единственный источник = высокий риск искажения.

---

Алгоритм сбора требований

Сбор требований — это не хаотичный набор встреч, а структурированный инженерный процесс. Ниже представлен универсальный алгоритм, применимый как в Waterfall, так и в Agile (где он выполняется итеративно для каждого инкремента).

Алгоритм сбора требований

Этап 0: Подготовка (Planning)

Цель: Определить границы исследования и подготовить инструменты.

1. Определите контекст проекта. Изучите устав проекта, бизнес-кейс, стратегические документы. Поймите, зачем проект существует.
2. Идентифицируйте стейкхолдеров. Составьте список всех заинтересованных сторон. Классифицируйте их по влиянию/заинтересованности (матрица Менделова). Определите, кто является источником каких требований.
3. Оцените доступные артефакты. Найдите существующую документацию, код, тикеты, регламенты. Это база для формирования гипотез.
4. Выберите техники. На основе матрицы из предыдущего ответа определите набор методов для каждой группы стейкхолдеров и типа требований.
5. Составьте план элиситации. Запланируйте сессии, подготовьте вопросы, создайте шаблоны для фиксации. Согласуйте график с участниками.

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

Этап 1: Первичное выявление (Elicitation)

Цель: Получить максимально полную «сырую» информацию.

6. Начните с анализа артефактов. Изучите документы и систему до общения с людьми. Сформируйте список вопросов и гипотез. Это экономит время стейкхолдеров.
7. Проведите сессии сбора. Интервью, наблюдение, воркшопы — согласно плану.
   • Фиксируйте факты отдельно от мнений.
   • Записывайте цитаты и конкретные примеры.
   • Ищите расхождения между словами и реальными действиями.
8. Зафиксируйте результаты немедленно. Заметки, записи, фото досок должны быть обработаны в течение 24 часов. Память ненадёжна.

Критерий завершения этапа: Собран достаточный объём первичной информации для формирования черновика требований. Не стремитесь к полноте на этом шаге — стремитесь к покрытию ключевых областей.

Этап 2: Анализ и синтез (Analysis & Synthesis)

Цель: Превратить «сырые» данные в структурированные требования.

9. Структурируйте информацию. Группируйте по функциям, процессам, ролям. Выделяйте бизнес-, пользовательские и системные требования.
10. Выявите пробелы и противоречия. Сравните информацию из разных источников. Где есть расхождения? Что не описано? Сформируйте список уточняющих вопросов.
11. Смоделируйте. Создайте диаграммы процессов, прототипы, схемы данных. Визуализация выявляет проблемы, невидимые в тексте.
12. Вернитесь к стейкхолдерам (цикл). Проведите уточняющие сессии только по выявленным пробелам и противоречиям. Не повторяйте уже пройденное.
13. Повторяйте пп. 10–12 до достижения согласованности. Это итеративный цикл, а не линейный проход.

Критерий завершения этапа: Требования непротиворечивы, полны в рамках границ проекта, подтверждены стейкхолдерами. Модели и прототипы верифицированы.

Этап 3: Документирование и спецификация (Specification)

Цель: Зафиксировать требования в формате, пригодном для разработки и тестирования.

14. Оформите требования по стандарту. Используйте принятый в проекте формат (SRS, User Stories + AC, BRD). Каждое требование должно быть: однозначным, проверяемым, трассируемым, приоритизированным.
15. Установите трассировку. Свяжите каждое требование с бизнес-целью (вверх) и с элементами реализации/тестами (вниз). Матрица трассировки (RTM) обязательна для контроля покрытия.
16. Определите критерии приёмки. Для каждого требования чётко зафиксируйте, как будет проверяться его реализация. Без критериев приёмки требование неполно.

Критерий завершения этапа: Документ/бэклог готов к ревью. Трассировка построена. Критерии приёмки определены.

Этап 4: Верификация и валидация (Verification & Validation)

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

17. Проведите формальное ревью (верификация). Инспекция требованиями с участием разработчиков, тестировщиков, архитектора. Чек-лист качества требований (однозначность, полнота, реализуемость).
18. Подтвердите соответствие бизнес-целям (валидация). Покажите стейкхолдерам итоговый артефакт. Вопрос: «Если мы реализуем именно это, решится ли ваша проблема?»
19. Устраните замечания. Внесите правки, полученные на ревью и валидации. Повторите проверку при значительных изменениях.
20. Базелините требования. Официально утвердите версию. Дальнейшие изменения — только через процесс управления изменениями (Change Request / Backlog Refinement).

Критерий завершения этапа: Требования базелинированы. Команда разработки принимает их в работу. RTM актуальна.

---

Адаптация алгоритма под методологии

Элемент алгоритма	Waterfall / ГОСТ	Agile / Scrum
Гранулярность прохода	Один полный проход для всего проекта	Проход повторяется каждый спринт/инкремент для набора историй
Этап 0 (Подготовка)	Детальное планирование всего объёма	Лёгкое планирование + постоянный Product Discovery параллельно с доставкой
Этап 3 (Документирование)	Формальный SRS, ГОСТ 34	User Stories + Acceptance Criteria в бэклоге; документация just-in-time
Этап 4 (Верификация)	Формальная инспекция, подпись заказчика	Grooming/Refinement, Sprint Planning, Demo как встроенная валидация
Управление изменениями	Change Request, CCBS	Приоритизация бэклога, замена историй без бюрократии

Типичные антипаттерны (чего избегать)

1. «Собрать и забыть». Сбор без последующего анализа и верификации = сбор мусора.
2. Бесконечный сбор. Отсутствие критериев завершения этапа 1 ведёт к параличу анализа. Определите timebox или критерий достаточности.
3. Документирование вместо понимания. Красивый SRS, который никто не читает и который не отражает реальность, хуже отсутствующего SRS.
4. Игнорирование этапа 0. Приход на интервью без подготовки = неуважение к времени стейкхолдера и низкое качество данных.
5. Линейность в итеративном контексте. Попытка пройти все этапы последовательно в Agile убивает гибкость. Циклы анализа (пп. 10–12) должны быть короткими и частыми.

---

Как общаться с бизнесом?

Общение с бизнес-стейкхолдерами — это не бытовая беседа, а структурированная инженерная активность. Цель коммуникации — не «поговорить», а получить верифицируемое знание и достичь согласованного понимания.

Ниже представлен алгоритм, построенный на принципах бизнес-анализа (BABOK) и практическом опыте IT-проектов.

---

Алгоритм коммуникации с бизнесом

Фаза 1: Подготовка (до встречи)

80% успеха коммуникации определяется до неё.

1. Сформулируйте цель встречи. Не «обсудить требования», а конкретно: «Подтвердить список полей для формы заявки» или «Разрешить противоречие между отделом продаж и логистикой по приоритету обработки заказов». Если цель нельзя сформулировать — встреча не нужна.
2. Изучите контекст. Прочитайте доступные документы, предыдущие протоколы, тикеты. Подготовьте гипотезы. Приходите с вопросами, а не за ответами на вопросы, которые уже есть в документации.
3. Определите формат и состав. Кто необходим для достижения цели? Лишние участники снижают эффективность. Выберите формат: интервью, воркшоп, демо, асинхронное согласование.
4. Подготовьте артефакты-провокаторы. Люди плохо реагируют на абстрактные вопросы («Что вам нужно?»), но хорошо — на конкретику («Правильно ли я понял, что здесь должно быть так?»). Подготовьте схему, прототип, список вопросов, таблицу сравнения.
5. Согласуйте повестку заранее. Отправьте участникам цель, вопросы/материалы и ожидаемый результат минимум за 24 часа. Это фильтр: если стейкхолдер не готов — перенесите встречу, а не проводите её впустую.

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

Фаза 2: Проведение (во время встречи)

Управление диалогом, а не пассивная запись.

6. Откройте встречу контрактом. Озвучьте цель, тайминг, правила (например, «фиксируем решения, а не только обсуждения»). Получите устное согласие. Это задаёт рамку.
7. Задавайте правильные вопросы.
   • Начинайте с открытых («Как сейчас выглядит процесс...?»).
   • Уточняйте закрытыми («Верно ли, что лимит составляет 100 тыс.?»).
   • Используйте технику 5 Whys для перехода от решений к проблемам.
   • Просите конкретные примеры («Приведите случай, когда это сломалось»).
   • Избегайте наводящих и составных вопросов.
8. Активно слушайте и переформулируйте. Периодически резюмируйте услышанное своими словами: «Правильно ли я понимаю, что...». Это выявляет расхождения в понимании в моменте, а не через неделю.
9. Визуализируйте в реальном времени. Рисуйте схемы на доске/экране, показывайте прототип. Визуальный артефакт фокусирует обсуждение и снижает двусмысленность слов.
10. Управляйте дивергенцией. Если обсуждение уходит в сторону — фиксируйте тему в «парковке» (parking lot) и возвращайтесь к цели. Не позволяйте встрече превратиться в мозговой штурм без модерации (если это не заявленная цель).
11. Фиксируйте решения, а не дискуссии. Записывайте: что решено, кто отвечает, какие открытые вопросы остались. Мнения и эмоции — вторичны.

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

Фаза 3: Закрепление (после встречи)

Коммуникация не закончена, пока понимание не верифицировано.

12. Отправьте резюме в течение 24 часов. Структура: решения, открытые вопросы (с владельцами и сроками), следующие шаги. Не транскрипт встречи, а выжимка результатов.
13. Запросите явное подтверждение. «Пожалуйста, подтвердите корректность резюме или укажите расхождения до [дата]». Молчание ≠ согласие. Если нет ответа — эскалируйте или повторите запрос.
14. Интегрируйте результаты в артефакты требований. Обновите SRS, бэклог, модели. Трассируйте новые знания к существующим требованиям.
15. Проверьте понимание на следующем контакте. Начните следующую встречу с краткого подтверждения предыдущих решений. Контекст теряется быстро.

Критерий завершения цикла: Резюме подтверждено. Артефакты обновлены. Следующие шаги назначены.

---

Специфические сценарии коммуникации

Ситуация	Адаптация алгоритма
Стейкхолдер говорит «хочу кнопку»	Не спорьте. Спросите: «Какую задачу эта кнопка решает?», «Что произойдёт, если кнопки не будет?», «Какой результат вы ожидаете после нажатия?». Переводите решение → потребность.
Конфликт между стейкхолдерами	Не принимайте сторону. Фасилитируйте: визуализируйте оба варианта, определите критерии выбора (бизнес-цели, метрики), эскалируйте на уровень выше, если консенсус невозможен. Ваша роль — нейтральный модератор, не судья.
Стейкхолдер недоступен / игнорирует	Переключитесь на асинхронные техники: анализ документов, наблюдение, опросы. Эскалируйте через спонсора проекта. Не блокируйте работу из-за одного человека.
Стейкхолдер меняет мнение	Вернитесь к фазе 1: уточните причину изменения. Зафиксируйте изменение через формальный процесс (Change Request / Backlog Refinement). Не обвиняйте, но требуйте обоснования.
Вы не понимаете предметную область	Честно признайтесь. Попросите объяснить «как для новичка». Используйте наблюдение и shadowing. Подготовьтесь к следующей встрече глубже. Притворство эксперта разрушает доверие.
Эмоциональная реакция / сопротивление	Не отвечайте эмоциями. Валидируйте чувство («Я вижу, что это вызывает беспокойство»), затем вернитесь к фактам и целям. Часто за сопротивлением стоит невысказанный риск или потеря контроля.

---

Принципы эффективной коммуникации с бизнесом

1. Говорите на языке бизнеса, не IT. «Рефакторинг базы данных» → «Снижение риска потери заказов при пиковой нагрузке». «API-интеграция» → «Автоматическая передача данных из бухгалтерии в склад, исключая ручной ввод».
2. Вы — переводчик, не стенографист. Ваша ценность не в записи сказанного, а в трансформации неструктурированных потребностей в проверяемые требования.
3. Доверяйте, но верифицируйте. Слова стейкхолдера — гипотеза. Подтверждайте через второй источник, наблюдение, данные, прототип.
4. Управляйте ожиданиями. Никогда не обещайте того, в чём не уверены. Лучше сказать «мне нужно уточнить», чем дать необдуманное обещание.
5. Фокус на ценности, не на процессе. Бизнес не интересует, как вы собираете требования. Их интересует, что их проблема будет решена. Коммуникация должна быть направлена на этот результат.
6. Профессиональная дистанция. Вы партнёр, не подчинённый и не друг. Уважайте экспертизу стейкхолдера, но сохраняйте ответственность за качество анализа.

---

Антипаттерны коммуникации

• «Запишу всё, потом разберусь». Ведёт к накоплению мусора и потере контекста. Разбирайтесь в моменте.
• Технический жаргон. Создаёт иллюзию понимания у стейкхолдера и реальные пробелы в требованиях.
• Обещания без полномочий. «Да, мы это сделаем» без подтверждения команды = будущий конфликт.
• Избегание сложных тем. Замалчивание конфликтов или неясностей не делает их исчезнувшими. Они всплывут на этапе разработки дороже.
• Монолог вместо диалога. Презентация без обратной связи — не коммуникация, а информирование. Разделяйте эти форматы.

---

Общение с разной аудиторией

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

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

---

Универсальный каркас адаптации

Для любого типа стейкхолдера перед коммуникацией пройдите три шага:

1. Определите профиль: К какой группе относится? Каковы их KPI/боли? Какой уровень детализации им нужен?
2. Выберите формат и язык: Синхронный/асинхронный? Визуальный/текстовый/табличный? Бизнес-метрики/процессы/технические детали?
3. Определите контракт взаимодействия: Как часто? В каком формате отчётность? Как принимаются решения? Как эскалируются проблемы?

Далее — специфические алгоритмы для каждой ключевой группы.

---

1. Спонсоры и высшее руководство (C-level)

Профиль: Мыслят стратегией, ROI, рисками. Время крайне ограничено. Не интересуются деталями реализации. Принимают решения о финансировании и приоритетах.

Алгоритм коммуникации:

1. Подготовка: Сведите информацию до 1–2 страниц / 5 минут. Подготовьте executive summary: статус, риски, требуемые решения, влияние на бизнес-цели.
2. Формат: Короткие синхронные встречи (15–30 мин) строго по расписанию. Асинхронные дайджесты между встречами. Никаких воркшопов по деталям.
3. Язык: Деньги, сроки, риски, стратегическое соответствие. Не «рефакторинг», а «снижение операционных расходов на 15%». Не «баг в API», а «риск остановки продаж на 4 часа».
4. Цель встречи: Получить решение или подтверждение направления. Не информировать ради информирования.
5. Эскалация: Только когда проблема влияет на бизнес-цели и не решается на нижних уровнях. Всегда с вариантами решений и рекомендацией.
6. Верификация понимания: «Правильно ли я понимаю, что приоритет X выше Y, потому что...?» Резюме с решениями — в течение 2 часов.

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

---

2. Эксперты предметной области (SME / Business Users)

Профиль: Знают «как есть» до мельчайших деталей. Могут не видеть альтернатив. Часто мыслят процессами, а не системами. Могут сопротивляться изменениям.

Алгоритм коммуникации:

1. Подготовка: Изучите текущие процессы/документы до встречи. Подготовьте модели As-Is для верификации. Сформулируйте гипотезы.
2. Формат: Наблюдение (shadowing) + глубинные интервью + воркшопы по моделированию To-Be. Прототипы для валидации. Регулярные, но не ежедневные сессии.
3. Язык: Процессы, роли, данные, исключения, бизнес-правила. Используйте их терминологию, не навязывайте IT-жаргон. Просите конкретные примеры и артефакты (скриншоты, выгрузки, регламенты).
4. Техники: 5 Whys для перехода от «хочу кнопку» к проблеме. Моделирование в реальном времени. Прототипирование как вопрос, а не ответ.
5. Работа с сопротивлением: Валидируйте опыт («Вы лучше знаете этот процесс»). Объясняйте выгоды для них, не для компании. Вовлекайте в проектирование, а не только в согласование.
6. Верификация: Покажите смоделированный процесс/прототип и попросите «пройти» по нему реальный сценарий. Письменное подтверждение резюме обязательно.

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

---

3. Конечные пользователи (Mass Users)

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

Алгоритм коммуникации:

1. Подготовка: Определите сегменты пользователей. Подготовьте инструменты сбора (опросы, аналитика, юзабилити-тесты).
2. Формат: Преимущественно асинхронный и масштабируемый: опросы, анализ данных использования, A/B-тесты, юзабилити-тестирование прототипов. Фокус-группы — только для качественных инсайтов, не для статистики.
3. Язык: Простой, без жаргона. Вопросы о задачах и боли, не о функциях. «Что вы пытаетесь сделать?» вместо «Какая функция нужна?».
4. Валидация: Через поведение, не через слова. Юзабилити-метрики, конверсия, время выполнения задачи. Слова пользователей — гипотеза, поведение — факт.
5. Обратная связь: Закрывайте цикл. Сообщайте, что их фидбек учтён (или почему нет). Иначе перестанут давать обратную связь.

Антипаттерны: Принятие решений на основе 3–5 интервью, вопросы о будущих функциях («Будете ли вы использовать...?»), игнорирование количественных данных.

---

4. Техническая команда (Разработчики, Архитекторы, QA)

Профиль: Мыслят реализацией, ограничениями, качеством кода. Нуждаются в однозначности и полноте. Ценят контекст «зачем», но требуют конкретики «что именно».

Алгоритм коммуникации:

1. Подготовка: Требования должны быть структурированы, трассируемы, с критериями приёмки. Без этого разговор бессмысленен.
2. Формат: Grooming/Refinement сессии, совместное моделирование (sequence diagrams, ERD), code review требований. Асинхронные комментарии в тикетах.
3. Язык: Точный, однозначный. Диаграммы > текст. Критерии приёмки в формате Given/When/Then. Обсуждение edge cases и ошибок — обязательно.
4. Роль аналитика: Переводчик бизнес-потребностей в технически проверяемую форму. Не диктуйте решение, но чётко опишите ограничение и ожидаемое поведение.
5. Обратная связь: Слушайте технические риски и ограничения. Если требование нереализуемо в заданных рамках — совместно ищите альтернативу, не продавливайте.
6. Верификация: Техническое ревью требований до начала разработки. Вопрос разработчика «А что если...?» = пробел в требованиях.

Антипаттерны: Расплывчатые требования («должно работать быстро»), отсутствие критериев приёмки, игнорирование технических ограничений, передача требований «через забор».

---

5. Регуляторы и внешние партнёры

Профиль: Формальны. Требования обязательны, не подлежат приоритизации. Коммуникация документирована и юридически значима.

Алгоритм коммуникации:

1. Подготовка: Изучите нормативные акты, контракты, SLA. Подготовьте формальные запросы/отчёты по установленному шаблону.
2. Формат: Официальная переписка, формальные встречи с протоколами, аудиты. Соблюдение регламентов взаимодействия.
3. Язык: Юридически точный, соответствующий нормативной базе. Никакой двусмысленности. Ссылки на конкретные пункты документов.
4. Верификация: Письменное подтверждение обязательно. Устные договорённости не имеют силы. Храните всю переписку.
5. Эскалация: Через официальные каналы, с соблюдением иерархии.

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

---

Матрица быстрого выбора формата

Тип стейкхолдера	Частота	Формат	Уровень детализации	Ключевой артефакт
Спонсор	Редко, по расписанию	Executive summary, короткие встречи	Стратегический	Дашборд статуса, BRD
SME	Регулярно	Интервью, наблюдение, воркшопы	Процессный, детальный	Модели процессов, прототипы
Mass Users	По необходимости	Опросы, аналитика, юзабилити-тесты	Поведенческий	Отчёты UX, метрики
Tech Team	Ежедневно/еженедельно	Refinement, совместное моделирование	Системный, точный	SRS, AC, диаграммы
Регуляторы	По регламенту	Официальная переписка, протоколы	Нормативный	Соответствие стандартам

---

Общие принципы адаптивной коммуникации

1. Эмпатия ≠ согласие. Понимать позицию стейкхолдера не значит принимать её без критики. Ваша задача — понять почему они так думают, и затем верифицировать это знание.
2. Гибкость внутри сессии. Если подготовленный формат не работает (SME молчит, спонсор уходит в детали) — переключайтесь в реальном времени. Алгоритм — руководство, не догма.
3. Документирование адаптации. Фиксируйте в плане коммуникации, почему выбран именно этот подход для каждой группы. Это помогает онбордить новых участников и корректировать стратегию.
4. Регулярная калибровка. Профили стейкхолдеров меняются. То, что работало месяц назад, может не работать сейчас. Периодически переоценивайте эффективность коммуникации.
5. Культурный и организационный контекст. Алгоритмы выше — базовые. В конкретной организации могут быть свои нормы (формальность, иерархия, скорость принятия решений). Наблюдайте и адаптируйтесь.

---

Use Case и User Story

Use Case и User Story — это два разных инструмента с разной областью применения. Use Case описывает полное взаимодействие системы с актором для достижения цели (формально, полно, с альтернативами). User Story описывает потребность пользователя в формате, пригодном для планирования и обсуждения (компактно, ориентировано на ценность).

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

---

Алгоритм составления Use Case

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

Структура Use Case (по Алистэру Кобёрну)

1. Идентификатор и название. UC-XXX + глагол + объект. Название отражает цель актора, не действие системы.

   • ✅ «Оформить заказ»
   • ❌ «Нажать кнопку "Заказать"», «Обработка заказа»

2. Акторы. Кто инициирует? Кто участвует? Разделяйте primary (инициатор) и secondary (вспомогательные системы/роли).

3. Предусловия (Preconditions). Что должно быть истинно до начала use case. Не путайте с триггером.

   • ✅ «Пользователь авторизован», «Товар есть в наличии»
   • ❌ «Пользователь открыл страницу» (это триггер)

4. Постусловия (Postconditions). Гарантированное состояние системы после успешного завершения.

   • ✅ «Заказ создан со статусом "Новый"», «Списание средств подтверждено»
   • ❌ «Пользователь увидел сообщение об успехе» (это UI, не состояние системы)

5. Основной поток (Main Success Scenario). Пошаговое описание счастливого пути. Каждый шаг:

   • Нумерован.
   • Описывает действие актора ИЛИ реакцию системы (не оба одновременно в одном шаге).
   • На уровне абстракции, независимом от UI.
   • Ведёт к постусловию.

6. Альтернативные потоки (Extensions). Отклонения от основного потока. Формат:

   • Указание точки ветвления (номер шага основного потока).
   • Условие перехода.
   • Шаги альтернативного потока.
   • Точка возврата к основному потоку ИЛИ завершение с ошибкой.

7. Исключения (Exceptions). Сбои, которые не являются бизнес-альтернативами (технические ошибки, таймауты). Описываются аналогично альтернативам, но ведут к аварийному завершению.

8. Бизнес-правила. Инварианты, которые истинны независимо от потока. Выносятся отдельно, не встраиваются в шаги.

9. Нефункциональные требования (опционально). Специфичные для данного use case: время отклика, требования к безопасности данных.

Чек-лист качества Use Case

• Название = цель актора (глагол + объект)
• Предусловия ≠ триггеры
• Постусловия проверяемы и описывают состояние системы
• Основной поток ведёт к постусловию без ветвлений
• Каждый шаг — одно действие (актор ИЛИ система)
• Нет UI-деталей («кнопка», «поле ввода», «цвет»)
• Альтернативы имеют точку возврата или явное завершение
• Бизнес-правила вынесены отдельно
• Уровень абстракции консистентен по всему документу

---

Алгоритм составления User Story

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

Формат User Story

Как <роль>,
Я хочу <действие/возможность>,
Чтобы <ценность/результат>.

Критически важно: третья часть («чтобы») обязательна. Без неё история теряет смысл и становится замаскированным техническим заданием.

Алгоритм написания

1. Определите роль. Конкретная, не абстрактная.

   • ✅ «Менеджер по продажам», «Зарегистрированный покупатель»
   • ❌ «Пользователь», «Система»

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

   • ✅ «сохранить данные карты для будущих покупок»
   • ❌ «система должна хранить токены в БД»

3. Артикулируйте ценность. Зачем это нужно? Какая боль снимается или какая выгода получается?

   • ✅ «чтобы не вводить реквизиты повторно и сократить время оформления»
   • ❌ «чтобы была такая функция», «чтобы соответствовать ТЗ»

4. Определите критерии приёмки (Acceptance Criteria). Без них user story неполна. Формат Given/When/Then (Gherkin) или маркированный список.

   • AC должны быть проверяемыми.
   • Покрывать основной сценарий + ключевые альтернативы + граничные условия.
   • Не дублировать текст истории.

5. Проверьте по INVEST:

   • Independent — независима от других историй
   • Negotiable — допускает обсуждение реализации
   • Valuable — несёт ценность для пользователя/бизнеса
   • Estimable — оценима командой
   • Small — помещается в спринт
   • Testable — имеет проверяемые критерии приёмки

6. Дополните контекстом (опционально):

   • Ссылки на макеты/прототипы
   • Технические заметки (API, ограничения)
   • Зависимости от других историй
   • Приоритет / оценка

Чек-лист качества User Story

• Есть все три части: роль, действие, ценность
• Ценность осмысленна и специфична
• Критерии приёмки определены и проверяемы
• Соответствует INVEST
• Не содержит решения реализации (если это не spike/enabler)
• Понятна команде без дополнительных объяснений
• Имеет приоритет и оценку (или помечена для оценки)

---

Когда использовать что

Критерий	Use Case	User Story
Сложность процесса	Высокая, много ветвлений	Низкая/средняя, линейная
Требуемая полнота	Формальная, исчерпывающая	Достаточная для обсуждения
Методология	Waterfall, RUP, гибридная	Scrum, Kanban, Agile
Аудитория	Аналитики, тестировщики, аудиторы	Команда разработки, PO
Стадия	Детальное проектирование	Планирование, backlog refinement
Регуляторика	Часто обязательна	Обычно недостаточно
Интеграции	Предпочтительно	Только если просты
UI/UX-ориентированность	Вторична	Первична

Гибридный подход

В реальных проектах часто комбинируют:

• User Stories как единицы планирования и доставки в бэклоге.
• Use Cases как детальную спецификацию для сложных историй (прикладывается к story как attachment или ссылка).
• User Story Mapping для структурирования бэклога и выявления пробелов.

Не пытайтесь писать use case для каждой user story. Это избыточно. Используйте use case только там, где сложность оправдывает формализацию.

---

Типичные ошибки

Для Use Case:

• Описание UI вместо поведения системы.
• Смешивание бизнес-правил и шагов потока.
• Отсутствие альтернативных потоков (описан только happy path).
• Предусловия = триггеры.
• Слишком низкий уровень абстракции (псевдокод вместо поведения).

Для User Story:

• Отсутствие «чтобы» (ценности).
• Критерии приёмки отсутствуют или непроверяемы.
• История слишком большая (не Small).
• История описывает техническую задачу без пользовательской ценности (замаскированный task).
• Роль = «пользователь» (слишком абстрактно).

Общие:

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

---

Use Case: Шаблон

ID:              UC-XXX
Название:        [Глагол несовершенного вида] + [Объект]
Версия:          X.X
Автор:           [ФИО]
Дата:            YYYY-MM-DD
Статус:          Черновик / На ревью / Утверждён

Акторы:
  Primary:       [Роль, инициирующая use case]
  Secondary:     [Вспомогательные системы/роли]

Описание:        [1–2 предложения: что делает use case и зачем]

Предусловия:
  1. [Условие, истинное ДО начала]
  2. ...

Постусловия (успех):
  1. [Гарантированное состояние системы ПОСЛЕ успеха]
  2. ...

Основной поток:
  1. [Действие актора]
  2. [Реакция системы]
  3. ...
  N. [Финальный шаг, ведущий к постусловию]

Альтернативные потоки:
  A1. [Название альтернативы]
      Точка ветвления: Шаг X основного потока
      Условие: [Когда возникает]
      1. [Шаг альтернативы]
      2. ...
      Возврат: Шаг Y основного потока / Завершение с ошибкой

  A2. ...

Исключения:
  E1. [Название исключения]
      Точка возникновения: Шаг X
      Условие: [Технический сбой / нарушение инварианта]
      1. [Действия по обработке]
      Завершение: Аварийное / Частичный успех

Бизнес-правила:
  BR-001: [Инвариант, истинный независимо от потока]
  BR-002: ...

Нефункциональные требования:
  NFR-001: [Специфичное для данного UC требование качества]

Приоритет:       Высокий / Средний / Низкий
Частота использования: [Раз в день / 1000 раз в час / ...]

Пример: UC-042 «Оформить заказ»

ID:              UC-042
Название:        Оформить заказ
Версия:          1.2
Автор:           И. Петров
Дата:            2026-07-15
Статус:          Утверждён

Акторы:
  Primary:       Зарегистрированный покупатель
  Secondary:     Платёжный шлюз, Система управления складом (WMS)

Описание:        Покупатель формирует и подтверждает заказ на товары
                 из корзины с выбором способа доставки и оплаты.

Предусловия:
  1. Покупатель авторизован в системе.
  2. Корзина содержит хотя бы один товар.
  3. Все товары в корзине доступны для заказа (не заблокированы).

Постусловия (успех):
  1. Заказ создан в системе со статусом «Ожидает оплаты».
  2. Резервация товаров на складе подтверждена WMS.
  3. Покупателю отправлено письмо-подтверждение с номером заказа.

Основной поток:
  1. Покупатель переходит к оформлению из корзины.
  2. Система отображает форму оформления с предзаполненными данными профиля.
  3. Покупатель подтверждает/изменяет адрес доставки и выбирает способ доставки.
  4. Система рассчитывает стоимость доставки и итоговую сумму.
  5. Покупатель выбирает способ оплаты.
  6. Покупатель подтверждает заказ.
  7. Система отправляет запрос резервации в WMS.
  8. WMS подтверждает резервацию.
  9. Система перенаправляет покупателя на страницу платёжного шлюза.
  10. Платёжный шлюз подтверждает успешную оплату.
  11. Система изменяет статус заказа на «Оплачен».
  12. Система отправляет письмо-подтверждение покупателю.

Альтернативные потоки:
  A1. Товар стал недоступен при оформлении
      Точка ветвления: Шаг 7
      Условие: WMS сообщает о недостатке товара
      1. Система уведомляет покупателя о недоступности товара.
      2. Система предлагает удалить товар из заказа или выбрать аналог.
      3. Покупатель корректирует корзину.
      Возврат: Шаг 3 основного потока

  A2. Оплата не прошла
      Точка ветвления: Шаг 10
      Условие: Платёжный шлюз вернул ошибку
      1. Система уведомляет покупателя об ошибке оплаты.
      2. Система сохраняет заказ со статусом «Ожидает оплаты».
      3. Система освобождает резервацию в WMS.
      Завершение: Частичный успех (заказ создан, но не оплачен)

  A3. Покупатель отменил оформление
      Точка ветвления: Любой шаг до шага 6
      Условие: Покупатель нажал «Отмена» или закрыл страницу
      1. Система сохраняет содержимое корзины.
      Завершение: Без изменений

Исключения:
  E1. WMS недоступна
      Точка возникновения: Шаг 7
      Условие: Таймаут ответа WMS > 5 секунд
      1. Система логирует ошибку.
      2. Система уведомляет покупателя о временной недоступности.
      3. Заказ не создаётся.
      Завершение: Аварийное

Бизнес-правила:
  BR-101: Минимальная сумма заказа — 500 ₽.
  BR-102: Резервация товара действительна 30 минут.
  BR-103: Доставка бесплатна при сумме заказа от 3000 ₽.

Нефункциональные требования:
  NFR-042: Время отклика шага 4 (расчёт доставки) < 2 секунд.
  NFR-043: Данные карты не хранятся в системе (токенизация через шлюз).

Приоритет:       Высокий
Частота использования: ~500 раз/час в пиковый период

---

User Story: Шаблон

US-XXX: [Краткое название]

Как [конкретная роль],
Я хочу [действие/возможность],
Чтобы [ценность/бизнес-результат].

Приоритет:       Must / Should / Could / Won't
Оценка:          [Story Points / T-shirt size]
Эпик:            [Название эпика]

Критерии приёмки:
  Given [предусловие]
  When [действие]
  Then [ожидаемый результат]

  Given ...
  When ...
  Then ...

Контекст / Заметки:
  - [Ссылка на макет]
  - [Техническое ограничение]
  - [Зависимость от US-YYY]

Пример: US-187 «Сохранение карты для повторных покупок»

US-187: Сохранение банковской карты

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

Приоритет:       Should
Оценка:          5 SP
Эпик:            Оформление заказа

Критерии приёмки:
  AC1: Успешное сохранение
    Given покупатель находится на странице оплаты
    When покупатель отмечает чекбокс «Сохранить карту» и успешно оплачивает заказ
    Then маска карты (последние 4 цифры) появляется в разделе «Мои карты» профиля
    And при следующем оформлении карта доступна для выбора без ввода CVV

  AC2: Отказ от сохранения
    Given покупатель находится на странице оплаты
    When покупатель НЕ отмечает чекбокс «Сохранить карту» и оплачивает заказ
    Then карта не сохраняется в профиле
    And при следующем оформлении требуется полный ввод реквизитов

  AC3: Удаление сохранённой карты
    Given у покупателя есть сохранённая карта в профиле
    When покупатель нажимает «Удалить» рядом с картой
    Then карта удаляется из профиля немедленно
    And подтверждение удаления не требуется (undo не нужен)

  AC4: Ошибка токенизации
    Given покупатель отметил «Сохранить карту»
    When платёжный шлюз не смог создать токен
    Then оплата проходит успешно (если авторизация прошла)
    And карта НЕ сохраняется
    And пользователь видит уведомление «Карта не сохранена, попробуйте позже»

Контекст / Заметки:
  - Макет: Figma → Checkout v3 → Frame "Save card"
  - Токенизация через API платёжного шлюза (см. INT-012)
  - CVV никогда не сохраняется (PCI DSS)
  - Зависит от US-185 «Профиль пользователя»

---

Сравнительная таблица примеров

Аспект	UC-042 «Оформить заказ»	US-187 «Сохранение карты»
Объём	Полный процесс от начала до конца	Одна дискретная возможность
Уровень детализации	Все потоки, исключения, бизнес-правила	Только критерии приёмки для ключевых сценариев
Ценность	Неявная (часть большого процесса)	Явная («сократить время оформления»)
Акторы	Покупатель + WMS + платёжный шлюз	Только покупатель
Назначение	Спецификация для разработки и тестирования сложного процесса	Единица планирования и обсуждения в бэклоге
Жизненный цикл	Утверждается формально, меняется через CR	Обсуждается на refinement, уточняется в спринте
UI-детали	Отсутствуют (поведение системы)	Минимальны (чекбокс, маска карты — как часть AC)

---