Заказчик часто приходит с образом результата в голове, а команда — с ограничениями по срокам, объёму и качеству. Разрыв между «что думают, что получат» и «что реально поставим» — типичная причина конфликтов на приёмке, даже когда формальные требования выполнены. Управление ожиданиями (expectation management) — ваша работа по выявлению, согласованию и регулярной калибровке этих представлений: не переговоры ради победы и не ведение встреч ради протокола, а мост между бизнес-запросом и реализуемым решением.
1. Суть темы
Управление ожиданиями заказчика — целенаправленная работа системного аналитика (и команды) по согласованию представлений о целях, объёме, сроках, качестве, рисках, роли SA и процессе принятия решений до и в ходе проекта. Цель — снизить expectation gap: разрыв между ожидаемым и фактическим результатом. В BABOK это часть Stakeholder Engagement и Communicate BA Information — см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).
Граница темы
| Входит в 09.07 | Относится к соседним статьям |
|---|---|
| Коммуникативное выравнивание: что слышит заказчик и что команда обязуется | Как узнать ожидания — 09.01 Техники активного слушания и опросов |
| Калибровка неписаных договорённостей, допущений, «что изменилось для вас» | Формат и проведение сессий — 09.02 Проведение эффективных встреч и воркшопов |
| Последовательность: feasibility → артефакты → калибровка → внешний commitment | Разрешение противоречий и торг — 09.03 Управление конфликтами и переговоры |
| Согласование обещаний после переговоров с dev | SA ↔ техкоманда — 09.06 Ведение переговоров с техническими командами |
| Донесение согласованных рамок до стейкхолдеров | Сторителлинг и narrative — 09.04 Презентация результатов анализа и сторителлинг |
| Процессный слой: impact statement, change log, scope baseline, triage creep | 02.05.03 Управление объёмом (Scope Creep) и ожиданиями — объём, baseline, material change |
09.07 vs 02.05.03: здесь — как донести и пересогласовать ожидания (диалог, alignment, мандат на обещания); в 02.05.03 — как удерживать scope baseline, оформлять change и отличать clarification от material change. Impact statement и change log — инструменты BA/PM; SA использует их для калибровки, но шаблоны и governance — в 02.05.03 и 02.05.02 Управление изменениями (Change Control Board).
flowchart LR
E[Ожидания заказчика] --> SA[SA: выявление и фиксация]
SA --> DEV[Dev: feasibility]
DEV --> A[Артефакты: scope, AC]
A --> CAL[SA: калибровка]
SYNC[Pre-status sync] --> CAL
CAL -->|согласованный commitment| E
X[Изменение контекста] --> SA
CAL -.->|без sync — не обещать наружу| E
Ключевое различение: управление ожиданиями — управление информацией и обязательствами, а не только «хорошие отношения». Формально выполненный backlog при несогласованных ожиданиях всё равно приводит к недовольству.
Управление ожиданиями не равно согласию на любой scope — это не capitulation, а прозрачность trade-off. Когда интересы уже столкнулись, подключаются переговоры; когда нужно понять feasibility — сначала переговоры с техкомандой, потом commitment наружу.
Кто «заказчик»
В аутсорсе — внешний клиент и его decision maker. В продуктовой модели — PO, бизнес-владелец, internal customer. Приёмы те же: явные допущения, проверка понимания, единый источник правды; меняется канал (статус для клиента vs refinement с PO) и мандат на commitment. При мультиподрядной схеме SA часто калибрует ожидания между конечным заказчиком и подрядчиками: зафиксируйте, чья зона — контракт и сроки (PM/интегратор), чья — содержательное alignment (SA + PO клиента).
2. Ключевые понятия
| Понятие | Суть |
|---|---|
| Ожидания (expectations) | Субъективные предположения о результате, сроках, участии, «как должно работать» и уровне сервиса; часто неформализованы; «перегретые» обещания — зона [[01.07 Когнитивные искажения и критическое мышление |
| Управление ожиданиями (expectation management) | Проактивное выявление, документирование, согласование и пересмотр ожиданий |
| Expectation gap | Разрыв между ожидаемым и фактическим; частая причина провала при «выполненных» требованиях |
| Psychological contract | Неписаные договорённости («SA всё сделает», «доработаем бесплатно») — см. слои ниже |
| Scope / success criteria | Границы поставки и измеримые критерии успеха — основной инструмент фиксации ожиданий |
| Under-promise / over-deliver | Классический приём снижения разочарования; в SA важнее точное обещание и прозрачность trade-off; систематический over-deliver поднимает планку на следующий релиз |
| RACI / роли | Кто принимает решения — снимает ожидание «SA = владелец продукта / бюджета» |
| Assumption log / decision log | Явные допущения и решения; смена контекста — триггер пересмотра |
| Communication plan / cadence | Частота, канал, формат и «что считается ответом» — ожидания по скорости реакции и глубине проработки |
| Change impact | Любое изменение scope / сроков / качества требует пересогласования ожиданий, а не только «обновили backlog» |
Три слоя обязательств
| Слой | Что это | Роль SA |
|---|---|---|
| Psychological contract | Неписаные ожидания, «мы же договорились на созвоне» | Выявить, перевести в явную формулировку с владельцем и датой пересмотра |
| Формальный scope | In/out, AC, backlog, протоколы sign-off | Калибровать понимание; единый источник правды — см. 02.05.03 Управление объёмом (Scope Creep) и ожиданиями |
| Юридический договор | SOW, SLA, контракт | SA не подписывает и не трактует; фиксирует расхождения «в голове vs в контракте» для PM / legal |
Опорные модели
- Stakeholder analysis — кому и как часто калибровать; см. 02.01.03 Анализ заинтересованных сторон (Stakeholder Map).
- MoSCoW / Kano — язык «must have» vs «nice to have» для заказчика; методы — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано).
- Project management triangle — классический треугольник scope–time–cost; quality часто трактуют как измерение внутри scope или отдельное ограничение — используйте как визуализацию trade-off, не как четвёртый «угол треугольника» без пояснения.
Expectation–Experience matrix
Две оси: уровень ожиданий до старта (завышен / реалистичен / занижен) и фактический опыт на вехах (ниже / соответствует / выше).
| Опыт ниже ожиданий | Опыт соответствует | Опыт выше ожиданий | |
|---|---|---|---|
| Завышенные ожидания | Критический gap — gap brief, сценарии MVP/фаз, walkthrough до commitment; без мандата — эскалация | Риск «везёт, но планка высокая» — явно зафиксировать границы следующей фазы | Редко; проверить, не скрыт ли tech debt или снижение качества |
| Реалистичные ожидания | Ранний status с открытыми рисками; пересмотр допущений в assumption log | Целевое состояние — поддерживать cadence калибровки | Over-deliver → калибровка новой планки до релиза N+1, иначе psychological contract сдвигается вверх |
| Заниженные ожидания | Уточнить: реальная проблема или «немые» стейкхолдеры; отдельная сессия с decision maker | Базовый alignment — достаточно регулярного status | Риск раздувания scope на следующей фазе — явно обозначить out of scope и триггеры change |
Мандат SA на обещания
| SA может от своего имени | Только после формального решения PO/PM/спонсора |
|---|---|
| Зафиксировать понимание, допущения, открытые вопросы | Срок релиза, бюджет, контрактные обязательства |
| Рекомендовать варианты A/B/C с trade-off | Commitment спринта и приоритет roadmap |
| Провести калибровку: «команда может X при условии Y» | «Мы гарантируем X к дате D» |
| Обновить артефакты по согласованному решению | Архитектурный или tech-debt выбор без архитектора/техлида |
Формулировка для заказчика: «Моя роль — зафиксировать варианты и риски; решение о сроке и scope утверждает [PO/PM/спонсор]». См. 00.01 Кто такой аналитик (роли BA, SA, FA).
3. Как применяется в работе аналитика
Фокус раздела — что сказать заказчику, когда пересогласовать и что не обещать. Оформление change, triage creep и governance scope — в 02.05.03 Управление объёмом (Scope Creep) и ожиданиями.
Калибровка на входе
Цель блока — не повторить инициацию BA, а снять неявные ожидания. Методы elicitation — 02.02.01 Интервьюирование и анкетирование; софт — 09.01 Техники активного слушания и опросов, 09.02 Проведение эффективных встреч и воркшопов. Форматы документов — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD); границы решения — 02.01.04 Определение границ решения (Scope Modelling). Чеклист перед стартом разработки — 10.04 Чеклист аналитика перед стартом разработки.
Обязательный блок вопросов калибровки:
- «Что для вас успех через 3 / 6 месяцев?» — см. 02.01.02 Цели, KPI и критерии успеха (SMART, GQM).
- «Что точно не входит?»
- «Какие ограничения не обсуждаются?»
- «Кто принимает финальное решение по scope и срокам?»
Итог — assumption log с владельцем и датой пересмотра; критерии успеха и AC — 02.04.02 Критерии приёмки (Acceptance Criteria). Критерий успеха калибровки: decision maker своими словами формулирует, что получит к дедлайну и что — нет; запись — в протоколе встречи и decision log, не только устно.
В ходе работы: SA-действия
- Pre-status sync (15 мин, SA + PM + техлид): что меняется для заказчика, кто что говорит, что не обещаем. Без этого sync — status только с фактами и открытыми вопросами, без commitment.
- Status с акцентом на ожидания — не только «сделано 60 %», а «что подтвердили / что открыто / что изменилось для вас».
- Prototype / walkthrough раньше финальной спецификации — снижение неверных образов; см. 02.02.04 Прототипирование и UI-UX-исследования. Фокус на alignment, не на сторителлинге (09.04 Презентация результатов анализа и сторителлинг).
- Новый запрос от заказчика — SA не обещает «да» устно; формулирует: «услышал X, влияние на срок и scope уточню после sync с dev». Impact и triage — 02.05.03 Управление объёмом (Scope Creep) и ожиданиями; оценка для диалога — 02.05.04 Совместная оценка трудоёмкости требований.
- Единый narrative наружу — после pre-status sync SA, PM и техлид говорят одно; расхождение «в чате пообещали» vs документ SA поднимает на sync, не дублируя governance из 02.05.03.
- Изменение scope или сроков — SA сообщает заказчику что изменилось для него и инициирует пересогласование; оформление change log и baseline — 02.05.03 Управление объёмом (Scope Creep) и ожиданиями.
Коммуникационный план
Зафиксируйте до активной фазы (можно в charter или отдельным артефактом):
| Элемент | Пример |
|---|---|
| Канал status | Еженедельный созвон + письменный summary в Confluence |
| SLA на ответ SA | «Уточнение по требованию — 1 раб. день; impact на scope — после sync с dev» |
| Эскалация | PM + спонсор / head of product, если gap не закрывается за 2 итерации калибровки |
| Async / remote | Письменное подтверждение понимания после ключевых решений; «прочитал, согласен» ≠ sign-off без walkthrough |
Сложные ситуации
- Завышенные ожидания от sales / руководства — gap brief и сценарии фаз; без мандата SA не переписывает контракт — эскалация (см. ниже).
- Агрессивный deadline — SA озвучивает trade-off и risk acceptance; переговоры о сроке — 09.03 Управление конфликтами и переговоры.
- «Немые» стейкхолдеры — отдельная калибровка с decision maker; 02.01.03 Анализ заинтересованных сторон (Stakeholder Map).
- Новый участник со стороны заказчика — onboarding в agreed рамки; 09.05 Наставничество и передача знаний.
- Agile «гибкость без границ» — SA проговаривает timebox и явный change наружу; процесс — 05.02 Scrum и Kanban (аналитик в Agile).
Эскалация без мандата
| Шаг | Действие |
|---|---|
| 1 | Expectation gap brief (1 стр.): обещание vs факт, риски, 2–3 сценария |
| 2 | Кому (зависит от модели): аутсорс — account / PM / спонсор клиента; продукт — PO / head of product / chapter lead SA; decision maker — если есть прямой доступ |
| 3 | Ask: пересмотр контракта / фазирование / явный отказ от scope / назначение владельца commitment |
| 4 | Артефакт: протокол с датой; без sign-off — не обещать «как в sales deck» |
После переговоров с техкомандой
Если итог меняет обещания внешнему заказчику — явное пересогласование до публичного commitment. Последовательность: 09.06 Ведение переговоров с техническими командами → обновление артефактов → калибровка ожиданий → только потом «мы обязуемся».
Перед UAT и приёмкой
Проактивная настройка снижает «сюрпризы на приёмке»:
- Кто участвует в UAT, кто принимает решение по дефекту vs change request.
- Walkthrough сценариев и AC — 02.04.02 Критерии приёмки (Acceptance Criteria).
- Формально «принято» ≠ согласованные ожидания — см. 02.04.01 Верификация и валидация (V&V); sign-off без walkthrough не закрывает expectation gap.
- Явно: «готово к prod» ≠ «всё из wishlist»; out of scope для текущей фазы — в протоколе.
После вехи: ретроспектива ожиданий
Короткий разбор: какие допущения сработали, где возник gap, что обновить в assumption log перед следующей фазой. Не копить неявный долг ожиданий на релиз N+1.
Артефакты SA (коммуникационный слой)
| Артефакт | Роль в управлении ожиданиями |
|---|---|
| Charter / brief этапа | Рамки, роли, цели |
| Success metrics / AC | Измеримый «успех» |
| Assumption & decision log | Явные допущения; формулировка decision maker после калибровки |
| Expectation gap brief | Эскалация при расхождении с sales/контрактом |
| Коммуникационный план | Cadence, SLA, каналы |
| Change log (ссылка на 02.05) | История с impact на ожидания |
Риски, влияющие на обещания, — 08.05 Управление рисками на этапе анализа; ожидания «audit trail как в Excel» при регуляторных ограничениях — отдельная калибровка с legal/compliance, SA фиксирует gap для PM.
Прокси-метрики alignment (не метрики процесса)
Ориентиры доверия и сюрпризов, не качества артефактов (метрики процесса — 08.01 Метрики и KPI процесса анализа, качество требований — 02.04.03 Управление качеством требований):
- Количество «сюрпризов» на UAT / приёмке.
- Переоткрытые споры о scope после sign-off.
- Короткий опрос после вех (3–5 вопросов): «ожидания совпали с результатом?».
Если метрики ухудшаются: усилить cadence калибровки (короткие sync с decision maker), подготовить expectation gap brief по повторяющимся темам, эскалировать по таблице выше — не ждать финальной приёмки.
Пример: калибровка после «обещания продаж»
Контекст: заказчик ожидает «полную автоматизацию отчётности за квартал»; по итогам discovery — 12 типов отчётов, 3 legacy-источника, нестабильный API. В контракте — формулировка sales без детализации.
Ветка A — SA mandated к пересогласованию (есть спонсор на встрече):
- Expectation gap brief без обвинений.
- Сценарии: MVP (3 отчёта), фаза 2, spike на интеграцию; оценка — 02.05.04 Совместная оценка трудоёмкости требований.
- Walkthrough прототипа — 02.02.04 Прототипирование и UI-UX-исследования.
- Sign-off scope фазы 1 с out of scope; запись в decision log.
Ветка B — decision maker не на встрече / обещание только в контракте:
- SA готовит gap brief и варианты; не обещает клиенту MVP устно.
- Эскалация account/PM (или head of product в продукте): «нужен спонсор и пересмотр commitment до status с клиентом».
- До ответа — status только с фактами discovery и открытыми вопросами, без «мы успеем к кварталу».
Похожий старт без требований — 10.03 Разбор кейса "Старт проекта без требований".
4. Типовые ошибки и ограничения
Ограничения
- SA не всегда mandated пересогласовывать обещания sales / руководства — нужны спонсор и эскалация (схема выше).
- Ожидания эмоциональны и политичны; одной документации недостаточно без повторяющегося диалога.
- В agile «гибкость» часто misread как «без границ» — timebox и change process.
- Remote / async усиливают gap: письменное подтверждение, walkthrough записью, явный SLA в communication plan.
- Юридический договор и ожидания в голове расходятся — SA не заменяет legal; фиксирует для PM / юристов.
- Регуляторика (audit trail, PCI и т.п.) может быть вне функционального scope — калибровка с compliance, не обещание «как в Excel» без проверки.
Типичные ошибки SA
| Ошибка | Последствие | Как избежать |
|---|---|---|
| «Да, посмотрим» без impact | Неявное обещание | Формулировка «уточню после sync»; impact — 02.05.03 Управление объёмом (Scope Creep) и ожиданиями |
| Откладывание bad news | Шок на приёмке | Ранний status с открытыми рисками |
| Sign-off ради галочки | Разные трактовки scope | Walkthrough + запись формулировки decision maker в протокол |
| Scope creep через «мелкие доработки» | Невыполнимый объём | Пересогласование наружу; change — 02.05.03 Управление объёмом (Scope Creep) и ожиданиями |
| Разные сообщения от SA, PM, техлида | Заказчик выбирает удобное | Pre-status sync, единый narrative |
| Чрезмерный under-promise | Потеря credibility | Точные обещения с допущениями |
| Систематический over-deliver | Планка ожиданий растёт на N+1 | Калибровка «новой нормы» после вехи (см. matrix выше) |
| Обещание от имени команды без мандата | Конфликт с PO/PM | Таблица «Мандат SA на обещания» выше |
| Игнор новых стейкхолдеров | Каждый добавляет scope | Onboarding в agreed рамки |
| Путать alignment с capitulation | Scope без trade-off | [[09.03 Управление конфликтами и переговоры |
| Commitment до sync с dev | Конфликт с реальностью | Сначала [[09.06 Ведение переговоров с техническими командами |
Красные флаги
Наблюдаемые симптомы — без отдельного remediation; действия см. в таблице ошибок и разделе «В ходе работы» выше:
- «Мы уже пообещали» блокирует обсуждение impact.
- В протоколах только «что делаем», нет out of scope.
- Заказчик узнаёт о проблеме на демо, а не на status.
- Assumption log пустой или без владельцев.
- Каждый новый участник расширяет scope без change process.
Критерий зрелости: для любого обещания, данного заказчику, за две минуты показываете: где зафиксировано, кто утвердил, какие допущения, что при их нарушении. Если нет — ожидания управляются случайно.
Связи с другими разделами базы
- Приоритеты при изменчивости и пересмотр roadmap — 02.05.02 Управление приоритетами в условиях изменчивости
- Жизненный цикл требования и момент пересогласования ожиданий — 02.05.05 Жизненный цикл требования
- Инструменты единого источника правды (backlog, Confluence) — 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence)
- Governance изменений и CCB — 02.05.02 Управление изменениями (Change Control Board)
Источники и дополнительные материалы
Книги и стандарты
- IIBA — Business Analysis Body of Knowledge (BABOK): Stakeholder Engagement, Communicate Business Analysis Information — https://www.iiba.org/knowledgehub/ (см. также 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148))
- PMI — A Guide to the Project Management Body of Knowledge (PMBOK® Guide): процесс Manage Stakeholder Expectations (4-е изд., гл. 10) / Manage Stakeholder Engagement (5–6-е изд., раздел Project Stakeholder Management) — выравнивание видения стейкхолдеров с deliverables проекта
- Scrum Guide: transparency, stakeholders, Product Owner — https://scrumguides.org/scrum-guide.html
Статьи и справочные материалы
- Wikipedia — Psychological contract — https://en.wikipedia.org/wiki/Psychological_contract
- Wikipedia — Project management triangle — https://en.wikipedia.org/wiki/Project_management_triangle
- ProjectManager — How to Make a Stakeholder Management Plan — https://www.projectmanager.com/blog/stakeholder-management-plan