От хаоса к системе: фасилитация и SMART-цели

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

Теперь движемся дальше. Во второй части поговорим о фасилитации – как собрать разрозненные мнения команды в единую систему. И о 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. Если пропустили первую статью —> вот она. Там фундамент, без которого дальше будет сложно.

Другие статьи
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
Email
guest
0 комментариев
Популярные
Новые Старые
Межтекстовые Отзывы
Посмотреть все комментарии
Об авторе
author

Бизнес-аналитик. Специалист по Data Science. Имеет опыт в проектах HoReCa и разработке мобильных приложений. Своей сильной стороной считает способность анализировать сложные задачи и структурировать их в простые и эффективные решения. Знает всё о сборе и анализе требований и о BPMN- и UML-диаграммах.

Поиск
Получите совет