Пятница, коллеги. Вам не зашли Оксфордские упражнения, поэтому сегодня немного бизнес-анализа на примере орков из Warhammer.

На картинке к посту сформулирована вполне нормальная орочья потребность:

"Бойзы, надо сделать так, чтобы чоппы стукали лучше".

Давайте представим, что задача попала к аналитику из нашего мира, который ничего не знает об орках.

Что значит "стукали лучше"? Сильнее? Быстрее? Надежнее? Возможно, проблема в форме клинка. Или в его массе. Материал недостаточно прочный? Плохой баланс? Неудобная рукоять?

Начинаем исследовать чоппу.

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

А потом приходит орк и рисует на старой чоппе шашечки.

Готово. Чоппа стукает лучше.

На первый взгляд перед нами просто классическая орочья логика. Но с точки зрения бизнес-анализа ситуация интереснее.

Аналитик мог совершенно правильно исследовать сам объект и все равно двигаться не туда, потому что плохо исследовал предметную область.

В Warhammer орочья техника вообще существует по довольно своеобразным правилам. Цвета, символы и убеждения орков имеют для них значение, которое невозможно вывести из сопромата или устройства двигателя. Если аналитик этого не знает, никакое подробное исследование конструкции чоппы не обнаружит вариант "нарисовать шашечки".

И это уже вполне реальная проблема в любой вселенной.

Мы приходим в новую предметную область со своей моделью причинности. Если система работает медленно, мы ищем техническое ограничение. Если процесс занимает много времени, мы ищем лишние операции. Если пользователю неудобно, мы ищем недостатки интерфейса. Если сотрудники делают что-то странное, то предполагаем неэффективность.

Часто это хорошие гипотезы, да. Проблема появляется, когда гипотеза незаметно превращается в устройство мира.

У реальной предметной области тоже есть свои "шашечки". Регуляторное требование, о котором никто не написал в регламенте. Исключение для одного типа клиентов. Договоренность между подразделениями, появившаяся пять лет назад. Особенность конкретного рынка. Ограничение внешней системы. Ручная операция, которая выглядит бессмысленной, пока не узнаешь, от какой редкой ошибки она защищает.

Со стороны все это может выглядеть нелогично и даже иногда прямо абсурдно. Иногда оно действительно нелогично и давно должно быть устранено. Но сначала нужно понять, почему оно существует и какую роль играет в системе.

Именно поэтому знание объекта и знание предметной области - это не одно и то же. Можно досконально разобрать чоппу и ничего не понять про орков. Можно прекрасно знать возможности CRM и ничего не понимать в продажах конкретной компании. Можно изучить информационную систему до последнего поля и не знать, почему пользователи ведут рядом таблицу Excel. Можно нарисовать процесс целиком и пропустить одно неформальное правило, без которого он в реальности не работает.

Здесь есть еще одна ловушка. Чем глубже мы исследуем выбранное направление, тем дороже нам психологически из него выходить. После десятка интервью и нескольких дней анализа очень не хочется обнаружить, что существенная часть работы была построена на неверной исходной модели. Гораздо приятнее продолжить улучшать новую версию чоппы.

Поэтому иногда полезный вопрос звучит не "что еще мы не знаем об объекте?", а:

"Что мы еще не знаем о мире, в котором этот объект работает?"

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

А потом придет предметный эксперт и нарисует на нем шашечки.