В первой части мы разобрали, как превратить хаотичные жалобы клиентов в четкие требования. Научились слушать заказчика, задавать правильные вопросы и не подменять его боль своими догадками. А еще – познакомились с нашим героем, который только начинает свой путь в аналитике.
Теперь движемся дальше. Во второй части поговорим о фасилитации – как собрать разрозненные мнения команды в единую систему. И о SMART-целях – чтобы «хочу, чтобы покупали» превратилось в измеримый результат.
Готовы? Тогда – к делу.
Фасилитация: из фрагментов в систему

Одна встреча с владельцем продукта – это важно. Но часто недостаточно. Даже у самого вдумчивого заказчика нет всех ответов. Они рассыпаны по людям. По тем, кто живет в продукте каждый день: отвечает на письма, упаковывает коробки, настраивает лендинг, чинит баги, пишет тексты.
У каждого – свой фрагмент картины. Своя правда. Своя боль. И задача аналитика – не собрать жалобы, а впервые соединить эти фрагменты вместе.
Это и есть фасилитация. Не просто встреча, а пространство, где можно безопасно произнести вслух то, что обычно прячется между строк.
Чтобы это пространство стало рабочим, аналитик использует техники. Не ради модности, а чтобы лучше понять суть – и помочь команде тоже ее увидеть.
Карта стейкхолдеров (Stakeholder Map)
Визуальная схема: кто вовлечен, кто решает, кто влияет, кто просто затронут. Все роли – на одной карте.
🟡 Зачем нужна:
– чтобы никого не забыть,
– чтобы понимать, чьи интересы критичны,
– кого нужно звать, кто может заблокировать проект, а кто – принести ключевые данные.
🟢 Когда применять:
- в начале проекта – для ориентировки,
- при подготовке к фасилитации,
- при конфликтах мнений – чтобы понять, откуда они.
🔵 Пример. В проекте онлайн–курсов на карту попали:
🔹 руководитель (хочет KPI и отчетность),
🔹 методист (думает о структуре),
🔹 маркетолог (болеет за конверсию),
🔹 пользователь (просто хочет учиться удобно),
🔹 разработчик (не любит срочные правки).
Эта карта помогла увидеть: если слушать только одного, получится перекос.
Crazy 8 – восемь идей за восемь минут
Техника генерации решений. Каждый делит лист на 8 частей и за 8 минут рисует 8 разных подходов.
🟡 Зачем нужна:
– чтобы вынуть из головы скрытые идеи,
– разогнать мышление,
– уйти от шаблонов вроде «давайте как у конкурентов».
🟢 Когда применять:
- когда команда застряла,
- в начале – для сбора гипотез,
- чтобы прогнать варианты без споров.
🔵 Пример. Обсуждая оформление заказа в приложении, команда за 8 минут выдала:
🔸 убрать лишние поля,
🔸 добавить автоподстановку,
🔸 разбить процесс на шаги,
🔸 заменить кнопки иконками,
🔸 показать прогресс,
🔸 встроить помощь,
🔸 оформить через WhatsApp,
🔸 «отложить» заказ.
Три идеи ушли в проработку.
Доска Х–сценариев (X–Scenarios board)
Таблица, где фиксируются позитивные и негативные сценарии использования.
🟡 Зачем нужна:
– чтобы предусмотреть исключения,
– сделать путь пользователя устойчивым,
– понять, где может все пойти не так.
🟢 Когда применять:
- перед UX/UI–проектированием,
- при проработке логики,
- если есть жалобы, но неясно, где сбой.
🔵 Пример. Сценарий «оформление заказа»:
➕ Позитивный: добавить товар → оформить → оплатить → получить подтверждение.
➖ Негативный: забыл пароль, закрыл вкладку, не оплатил, ошибка в карте, нажал «назад» и потерял все.
Это позволило сохранить корзину, автосохранять адрес, предупредить об истекающей сессии. Конверсия выросла.
Эти техники – не «поиграть в фасилитацию». Они необходимы, чтобы команда перестала работать вслепую. Чтобы те, кого не спрашивали, наконец заговорили. Чтобы хаос превратился в карту движения.
Когда это происходит – система начинает дышать.
Поддержка: "Покупатели жалуются, что приходится дважды вводить адрес".
Доставка: "Без телефона не можем – а его забывают указать".
Разработчик: "Форму взяли с шаблона, не успели адаптировать".
Это не обвинения. Это артефакты. Они говорят: проблема – не в людях, а в стыковке процессов.
Хорошая фасилитация показывает не «кто виноват», а «как мы устроены».
Это и есть ее ценность. Люди перестают чувствовать себя изолированными винтиками – и начинают видеть: они часть системы. А значит – часть решения.
Когда аналитик дает голос каждому, он собирает не жалобы, а факты. Не мнения, а наблюдения. Он вытаскивает из фона баги, костыли, усталость и недосказанности – и только из этого рождаются настоящие требования.
Наш герой почувствовал: неясность бывает не только у заказчика. А настоящая ясность – всегда коллективная. Сначала он растерянно смотрел, кто есть кто. Кто влияет, а кто просто рядом. Но с каждой встречей он начал видеть связи: между болью и причиной, отделами и решениями, словами и тишиной. Он понял: фасилитация – не значит «спросить мнение». Это значит «понять, как мы устроены».
У него появилась первая лапа – та, что не хватает, а удерживает пространство. Пространство, где можно не спорить, а исследовать.
Совет героя
Фасилитация – не встреча ради галочки. Это метод наблюдения.
Слушай не чтобы ответить, а чтобы понять.
Каждый участник – носитель уникального контекста.
Не перебивай. Не решай за других. Помоги им высказаться и соединить фрагменты в рабочую картину.
SMART: превращаем размытое «хочу» в цель, на которую можно опереться
«Если не определить четкие и достижимые цели, нельзя понять, добились ли вы успеха. А без этого нет смысла и в самой работе.»
S. & J. Robertson, Mastering the Requirements Process
– Хочу, чтобы покупали, – говорит заказчик.
– Хорошо. А “покупали” – это как? Один заказ в день или сто? Через неделю? Через месяц?
– Ну… просто чтобы лучше шло.
– А что значит “лучше”? В два раза? Быстрее? Дешевле? Часто?
Так начинается поворотный момент – когда расплывчатое “хочу” становится направлением..
Именно в этот момент аналитик помогает не просто «услышать», а сформулировать направление движения. Без этого обсуждение рискует превратиться в спор вкусов или набор случайных правок.
Здесь и вступает в игру SMART – классический, но мощный инструмент.
Он не про отчетность. Он про осмысленную ясность.
Было: «Хочу, чтобы покупали»
Стало: «Хочу за 3 месяца поднять конверсию с 15% до 25% и увеличить средний чек с 2 до 3 баночек»
Это уже не желание, а ориентир. Он:
🔹 измерим (конверсия, чек),
🔹 ограничен по времени (3 месяца),
🔹 проверяем – можно свериться с реальностью и понять, удалось или нет.
Почему это работает на практике?
- Команда больше не плавает между «давайте перекрасим кнопку» и «переделаем корзину». Есть вектор.
- В спорах появляется объективность: это работает на цель – или нет?
- При проверке гипотез есть конкретная метрика, по которой можно судить. Не “чувствую, стало лучше”, а “чек вырос на 20%”.
- Даже самые разные участники проекта – от маркетолога до разработчика – начинают смотреть в одну сторону.
И наш герой впервые понял:
Цель – это не то, что вдохновляет, а то, что направляет.
У него появилась вторая лапа – точная, устойчивая.
Он остановился, посмотрел по сторонам – и выбрал направление.
Теперь он шел не туда, где громче, а туда, где важнее.
Совет героя
Когда слышишь “хочу”, не торопись соглашаться.
Лучше спроси: «А как ты поймешь, что это случилось?»
Если ответ – «ну… как–нибудь», значит, вы еще в тумане.
SMART не убивает мечты – он помогает превратить мечту в маршрут. И именно по нему потом будет идти команда.
Теперь у нашего героя есть не только уши, чтобы слышать, но и инструменты, чтобы структурировать услышанное. Он научился:
- Проводить фасилитацию, где каждый голос становится частью решения.
- Формулировать цели так, чтобы они вели команду, а не запутывали.
Но это все еще только начало. В третьей части разберем, как зафиксировать требования в документах: BRD, SRS и Backlog. Узнаем, чем функциональные требования отличаются от нефункциональных и как не утонуть в бюрократии, сохранив суть.
А еще дадим практическое задание. Проверим, сможете ли вы превратить «хочу что-то про лояльность» в работающие решения. До встречи!
P.S. Если пропустили первую статью —> вот она. Там фундамент, без которого дальше будет сложно.