Почему фасилитация – обязательный навык современного системного аналитика

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

1. Для выявления истинных, а не озвученных требований.

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

2. Для преодоления конфликтов и достижения консенсуса.

Разные стейкхолдеры (бизнес-пользователи, технические специалисты, менеджеры) часто имеют противоположные взгляды на одну и ту же проблему. Задача аналитика – не принять чью-то сторону, а помочь команде прийти к общему, аргументированному решению. Фасилитация предоставляет инструменты для этого: анализ «за и против», критериальное оценивание, матрицы приоритизации.

3. Для радикального повышения эффективности коммуникации.

Сколько часов было потрачено впустую на проектах из-за бесполезных, затянувшихся митингов? Фасилитация борется с этим путем:

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

Тайм-менеджмента: жесткое, но справедливое распределение времени на каждый вопрос.

Визуализации: использование флипчартов, досок и стикеров помогает структурировать мысли и буквально «увидеть» общую картину.

4. Для ускорения процессов анализа и проектирования.

Совместные фасилитированные сессии (например, Event Storming, User Story Mapping) позволяют за несколько часов проработать и согласовать такие объемные задачи, как проектирование архитектуры процесса, разбивка эпиков на пользовательские истории, проработка сценариев использования. Это в разы быстрее, чем затянувшаяся переписка по email и индивидуальные интервью.

5. Для укрепления собственного авторитета и проактивной позиции.

Системный аналитик, который может грамотно провести сложную рабочую сессию и помочь группе принять решение, перестает быть просто «тем, кто спрашивает и записывает». Он становится настоящим лидером мнений, катализатором прогресса и ценнейшим членом команды, которому доверяют и бизнес, и разработчики.

Первое, что нужно освоить – модель «Бриллиант Фасилитации», которая наглядно описывает путь мышления группы:

Первый этап – дивергенция (расширение). Команда изучает проблему. На этом этапе важно собрать как можно больше идей, точек зрения и данных, не критикуя их. Задача фасилитатора – расширить поле зрения. Например, с помощью мозгового штурма или метода «5 почему?» – это техника, которая помогает докопаться до истинной, корневой причины проблемы, а не довольствоваться поверхностным объяснением. Фасилитатор задает вопрос последовательно несколько раз, углубляясь в предыдущий ответ.

Пример применения метода «5 почему?» на практике:

Проблема: Пользователи не используют новую функцию в системе.

Почему? – Им неудобно её находить.

Почему? – Кнопка вызова функции находится в глубине меню.

Почему? – При проектировании интерфейса её разместили туда для экономии места.

Почему? – Не было проведено юзабилити-тестирование с реальными пользователями.

Почему? – Не заложили время и бюджет на этапе проектирования.

Итог: Вместо поверхностного вывода «функция неудобная» нашли корневую причину – процесс проектирования не включает этап тестирования с пользователями. Именно это и нужно исправлять.

Второй этап – зона дискомфорта (зона «стонов»). Критически важная переходная фаза обсуждения, которую многие пытаются проскочить. После генерации массы идей группа сталкивается с хаосом, непониманием, как все это структурировать, и кажущейся невозможностью найти общее решение. Наступает разочарование, дискуссия может буксовать («Ой, да мы никогда не договоримся!»). Задача фасилитатора – признать этот дискомфорт, нормализовать его («Ребята, это нормально, мы просто перерабатываем информацию») и мягко, с помощью правильных методов, вывести группу на этап конвергенции. Пропуск этой стадии ведет к некачественным и непроработанным решениям.

Третий этап – конвергенция (сужение). Группа выходит из «зоны стона», начинает сужать варианты, фильтровать идеи, оценивать их по критериям и двигаться к консенсусу. Задача фасилитатора – помочь сузить выбор до оптимального решения. На этом этапе используются методы:

1. Сортировка по сходству. Участники группируют идеи на основе общих признаков. Для этого можно использовать стикеры. Это помогает выявить скрытые закономерности, структурировать хаотичный набор предложений и объединить схожие мысли, выраженные в разной форме.
2. Голосование точками. Каждый участник получает несколько наклеек (точек) для распределения между понравившимися идеями или вариантами. Это наглядно показывает коллективные предпочтения, помогает быстро отобрать самые популярные варианты и избежать долгих споров, выявив реальный приоритет группы.
3. Матрица приоритизации. Идеи оцениваются по двум заданным критериям (например, «стоимость» и «ценность»), после чего размещаются на координатной плоскости. Это позволяет визуально разделить все предложения на четыре категории (например, «быстрые победы», «стратегические цели») и объективно выбрать самые выгодные и реализуемые варианты.

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

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

Кейс 1: Приоритизация бэклога при планировании следующего релиза или классический PBR (Product Backlog Refinement)

Бэклог – это список задач, требований и функций, необходимых для создания, доработки и развития продукта. Не всегда в команде есть скрам-мастер, который будет фасилитировать все встречи. Системный аналитик идеально подходит на роль фасилитатора для PBR, целью которого является уточнение бэклога, так как он понимает и бизнес-цели, и технические нюансы. Его задача – помочь команде структурировать обсуждение каждой истории ответить на три ключевых вопроса:

• «Зачем?» (ценность) - это мотивирует и помогает принимать правильные технические решения.
• «Что?» (детали и критерии) - позволяет создать четкие и недвусмысленные критерии приемки, которые устраивают всех.
• «Сколько?» (оценка усилий) - помогает выявить расхождения в понимании сложности и проработать их на месте, что даст реалистичную оценку).

Кейс 2: Разрешение конфликта при проектировании сложного бизнес-процесса

Системный аналитик не выбирает сторону, а управляет процессом. Это помогает найти новое, улучшенное решение, учитывающее интересы всех.

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

Кейс 3: Проработка альтернативных сценариев для новой рискованной фичи

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

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

Кейс 4: Проработка сложной пользовательской истории

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

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