В предыдущей статье мы разобрали третье базовое понятие BABOK — Изменение (Change). Мы выяснили, что изменение — это не событие, а процесс, и что 70% инициатив проваливаются не потому что техника плохая, а потому что человеческая сторона проигнорирована. Но предположим, вы всё сделали правильно: нашли нужные заинтересованные стороны, сформулировали истинную потребность, спроектировали переход. Следующий вопрос — самый дорогостоящий в буквальном смысле слова:

Что именно мы будем строить или менять?

Именно здесь в игру вступает четвёртое базовое понятие BABOK — Решение (Solution). И именно здесь совершается ошибка, за которую бизнес платит дороже всего: команда влюбляется в первое пришедшее в голову техническое решение и перестаёт искать альтернативы.

По данным Gartner, более 45% ИТ-проектов завершаются без достижения ожидаемой бизнес-ценности — не из-за ошибок разработки, а из-за того, что изначально было выбрано неправильное решение. Команда блестяще построила не то, что нужно.

Чтобы разобраться, как принимать качественные решения, а не просто реализовывать первую идею заказчика — давайте разберем это понятие. Итак, Решение (Solution).

Почему четвёртое базовое понятие именно «Решение»?

К этому моменту в нашей причинно-следственной цепочке BABOK уже три звена: мы знаем, кто затронут (Заинтересованная сторона), что нужно бизнесу (Потребность) и как произойдёт переход (Изменение). Теперь встаёт вопрос: чем именно мы закроем эту потребность?

Решение — это ответ на вопрос «что делаем?». Но его особенность в том, что правильных ответов всегда несколько, а выбрать нужно один. И качество этого выбора определяет, получит ли бизнес ценность или потратит ресурсы впустую.

Почему именно сейчас, после Изменения? Потому что:

• Заинтересованные стороны — определяют, для кого создаётся решение и кто его примет.

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

• Изменение — ограничивает выбор: некоторые технически блестящие решения неприемлемы, потому что организация к ним не готова.

• Решение — это то, что в итоге создаётся, внедряется и оценивается по ценности.

Пропустить анализ альтернатив и сразу перейти к реализации первой идеи — всё равно что принять лекарство, не читая инструкцию: оно может помочь, но может и навредить.

Что такое Решение и где кроется подвох?

Согласно BABOK v3.0:

«Решение — это конкретный способ удовлетворения одной или нескольких потребностей в некотором контексте. Решение удовлетворяет потребность путем разрешения проблемы, с которой сталкиваются заинтересованные стороны, или позволяя заинтересованным сторонам реализовать возможность».

Ключевое слово здесь — «конкретный способ». Одну и ту же потребность можно удовлетворить десятком разных способов. Задача бизнес-аналитика — убедиться, что команда рассмотрела достаточно альтернатив и выбрала оптимальную, а не просто первую.

Главная ловушка звучит так: «Нам нужно вот это» — и заказчик с самого начала называет конкретное решение, минуя этап анализа. Звучит знакомо? Это та же проблема, что и с Потребностью: люди приходят с ответом, а не с вопросом.

Аналитик-новичок воспринимает названное заказчиком решение как данность и начинает собирать требования к нему. Аналитик-эксперт делает шаг назад и задаёт неудобный вопрос: «А почему именно это решение? Какие альтернативы мы рассмотрели?»

Ключевая мысль: Решение — это не то, что заказчик назвал первым. Это то, что прошло через анализ альтернатив и доказало свою оптимальность относительно потребности, контекста и ограничений.

Три типа решений: не всё измеряется строками кода

Одна из самых устойчивых иллюзий в ИТ-проектах: «решение» — это всегда про разработку программного обеспечения. BABOK намеренно расширяет это понятие. Решение может относиться к трём принципиально разным классам:

На практике большинство значимых изменений требуют комбинации всех трёх типов. Например, внедрение системы управления обращениями клиентов — это одновременно ИТ-решение (новая платформа), процессное решение (новый порядок обработки запросов) и организационное решение (переобучение команды, новые KPI для операторов).

Ошибка — фокусироваться только на ИТ-части и считать задачу выполненной, когда система запущена. Знакомая история? Именно об этом была наша предыдущая статья про Изменение.

Почему лучшее техническое решение почти никогда не является лучшим бизнес-решением?

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

Посмотрите на разницу в системе оценки:

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

Приведу реальный пример. В одном из проектов команда предложила микросервисную архитектуру для модернизации системы расчётов — технически это было правильное решение с точки зрения масштабируемости и независимости компонентов. Но анализ показал: внедрение займёт 18 месяцев, потребует найма 5 новых специалистов с редкими компетенциями и полной перестройки CI/CD-пайплайна. Монолитный рефакторинг с выделением ключевых модулей решал ту же бизнес-потребность за 6 месяцев силами существующей команды. Был выбран второй вариант — и это было правильным решением, хотя технически «хуже».

Рабочие техники: как выбрать правильное решение?

В BABOK v3.0 выбор и оценка решений описываются в разделе Solution Evaluation (глава 8) и в техниках Decision Analysis (раздел 10.16). Ниже — четыре наиболее практичных инструмента, которые я рекомендую использовать в связке:

1. Генерация альтернатив

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

Практическое правило: для любой нетривиальной задачи должно быть сформулировано минимум три альтернативы:

• Вариант 1 — «Ничего не делать». Всегда включайте его явно. Это позволяет честно ответить на вопрос: что произойдёт, если мы оставим всё как есть? Иногда оказывается, что «ничего» — это вполне приемлемый выбор.

• Вариант 2 — «Минимальное вмешательство». Наименее затратный путь, который хотя бы частично закрывает потребность. Процессные или организационные изменения без ИТ.

• Вариант 3 — «Целевой вариант». Полноценные варианты реализации с разными профилями стоимости, риска и скорости.

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

2. Взвешенная матрица решений

Это основной инструмент объективной оценки альтернатив. Суть проста: выбираете критерии оценки, назначаете веса (отражающие приоритеты бизнеса), оцениваете каждую альтернативу по каждому критерию и получаете взвешенную сумму.

Пример матрицы для выбора решения по автоматизации клиентских обращений:

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

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

3. Анализ осуществимости

Даже самое привлекательное по матрице решение может оказаться нереализуемым. Анализ осуществимости — это проверка решения по нескольким измерениям осуществимости до того, как оно попало в бэклог:

• Операционная осуществимость: сможет ли организация работать с этим решением? Есть ли у сотрудников нужные компетенции? Не противоречит ли оно существующим процессам и культуре?

• Техническая осуществимость: существуют ли технологии для реализации? Позволяет ли текущий технологический стек? Какова зрелость команды относительно предлагаемого подхода?

• Финансовая осуществимость: укладывается ли решение в бюджет? Каков ROI? Как быстро окупится инвестиция?

• Временная осуществимость: реализуемо ли решение в нужные сроки? Есть ли hard deadline (регуляторный, сезонный, продуктовый), который нельзя сдвинуть?

• Регуляторная осуществимость: соответствует ли решение требованиям законодательства, внутренних политик, отраслевых стандартов? Это измерение особенно критично в финансовой отрасли, здравоохранении, телекоме.

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

4. Оценка решения через призму потребности

BABOK выделяет Solution Evaluation в отдельную область знаний (глава 8) — и не случайно. Оценка решения не заканчивается в момент выбора. Она продолжается на всём жизненном цикле: до внедрения, во время и после.

Три ключевых вопроса на каждом этапе:

Самый игнорируемый этап — «после внедрения». Команды переходят на следующий проект, не проверив, принесло ли внедрённое решение обещанный результат. В BABOK это называется Benefits Realization — реализация выгод. Без этой проверки организация не накапливает опыт и повторяет одни и те же ошибки выбора.

Классическая ошибка: «влюблённость в решение»

Разберём кейс, который в том или ином виде встречается почти в каждой компании, работающей с ИТ-проектами.

Контекст: Компания столкнулась с проблемой: операционные менеджеры тратили до 3 часов в день на ручную сверку данных между двумя системами. Бизнес-потребность была чёткой — сократить операционные затраты на сверку и снизить количество ошибок.

Что произошло:

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

• Идея понравилась всем. Заказчик закивал. Никто не задал вопрос: «А какие есть альтернативы?»

• Начали собирать требования к интеграции. Через три недели выяснилось: одна из систем — устаревшая, вендор прекращает её поддержку через год. Интеграция стала бессмысленной.

• Ещё через две недели обнаружилось, что процессное решение — передача данных через структурированный Excel-экспорт с автоматической загрузкой — решало 80% проблемы за две недели разработки вместо пяти месяцев.

Итог: пять недель потеряны на сбор требований к решению, которое никто не оценивал относительно альтернатив.

Где была ошибка? На этапе, когда прозвучало первое предложение, никто не остановился и не задал вопрос: «Хорошо, это один вариант. Какие ещё есть?» Роль бизнес-аналитика — задать именно этот вопрос, даже если в комнате присутствует уважаемый архитектор или авторитетный заказчик.

Опыт «БКС Мир инвестиций»: Discovery до начала разработки

В компании «БКС Мир инвестиций» мы выработали практику обязательного Discovery — этапа, который команда обязана пройти до начала любой нетривиальной разработки. Его цель — зафиксировать не только то, что мы делаем, но и то, почему именно это, а не что-то другое.

Структура по итогам Discovery:

• Потребность (одно предложение): что именно не работает или какую возможность мы используем? (Обязательная ссылка на измеримый KPI.)

• Рассмотренные альтернативы: в идеале минимум три варианта, включая «ничего не делать» и процессное решение без ИТ.

• Выбранное решение и обоснование: почему выбран именно этот вариант? Ссылка на взвешенную матрицу или явные критерии.

• Что не входит в решение (out of scope): явное указание границ — это экономит недели переговоров о требованиях.

• Критерии успеха: как мы поймём через 3–6 месяцев, что решение сработало? Конкретные метрики, сравнимые с baseline.

• Ключевые риски и допущения: что может пойти не так и какие предположения лежат в основе выбора?

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

Дополнительный эффект, который мы заметили: работа на этапе Discovery сама по себе становится механизмом выявления потребности. Когда заказчик пытается написать «Потребность одним предложением с измеримым KPI» — часто выясняется, что потребность ещё не сформулирована. Это лучше, чем обнаружить это на четвёртом спринте.

Мини-чеклист: «Действительно ли я выбрал решение, а не влюбился в первую идею?»

• Мы сформулировали минимум три альтернативы, включая «ничего не делать»?

• Каждая альтернатива — реальный вариант, а не «соломенное чучело»?

• Критерии оценки выбраны исходя из бизнес-потребности, а не технических предпочтений команды?

• Выбранное решение прошло проверку на операционную, техническую, финансовую и регуляторную осуществимость?

• Зафиксированы явные критерии успеха — как мы поймём, что решение сработало?

• Определены границы решения (out of scope) — чтобы не было «ползучего расширения» скоупа?

• Заинтересованные стороны согласны с логикой выбора, а не просто «одобрили»?

• Предусмотрен этап оценки после внедрения — проверки реализованных выгод (Benefits Realization)?

Итог

Решение — четвёртое звено в причинно-следственной цепочке BABOK: Нет правильных заинтересованных сторон → нет правильной потребности → изменение не спроектировано → выбрано неправильное решение → нет ценности.

Главная мысль этой статьи проста: оптимальное решение — не то, которое технически совершенно, а то, которое наилучшим образом закрывает сформулированную потребность в данном контексте с учётом реальных ограничений.

Бизнес-аналитик, который принимает первое названное заказчиком решение как данность, — это аналитик, который сдаётся ещё до начала настоящей работы. Задать вопрос «А какие ещё варианты мы рассмотрели?» — иногда самый ценный вклад, который аналитик вносит в проект. Именно он отличает архитектора бизнес-ценности от исполнителя чужих идей.

Что дальше в цикле?

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

Подпишитесь на наш блог, чтобы не пропустить.