Знакома ситуация, вы приходите в проект, а там разнобой в плане терминологии? “Клиент” для сейлзов - тот, кто подписался с нами. Для поддержки - функциональный заказчик. Для биллинга - лишь строка в реестре. А для маркетинга - абстрактный персонаж из воронки. И все они яростно спорят о “клиентском опыте”, вкладывая в это разный смысл. Знакомо? В попытках как-то сей процесс подчинить некоей логике я пришел к онтологии. Не пугайтесь этого термина. Если отбросить академичность, онтология - это явная, формальная договорённость о том, как устроен некий кусочек мира. Это не просто глоссарий, где мы записали, что “клиент - это…”. Это карта, на которой мы чётко указали: вот границы нашего леса (домен), вот такие в нём есть деревья (сущности), так они называются (термины), так связаны между собой (связи) и по каким правилам всё это живёт (ограничения). Зачем это нам? Чтобы перестать быть переводчиками между племенами, а стать этнографами. Чтобы требования рождались не из конфликта интерпретаций, а из общего понимания “что есть что”. Так как же эту штуку применить в ежедневной работе? Сначала ловим хаос: фиксируем “как говорят”. Не надо сразу строить идеальную модель. Начинаем с малого - на следующем созвоне просто запишем, как разные люди называют одно и то же. Продуктолог говорит “лид”, продажник - “клиент”, а в базе лежит “контрагент с таким-то флагом”. Это и есть зёрна будущей онтологии. Наша первая задача - не согласовать, а выявить этот разнобой. Часто уже одно осознание, что все говорят на разных диалектах, даёт озарение)) Затем выстраиваем порядок: договариваемся “как будет”. Вот здесь включается аналитик как модератор. Берём эти разночтения и задаём прямые вопросы. Сущности: “Коллеги, давайте начистоту. “Клиент” и “аккаунт” - это одно и то же или нет? А если нет, то может ли у одного клиента быть пять аккаунтов?” Связи: “Когда мы говорим “продукт привязан к клиенту” - мы имеем в виду, что он ему продан, или что он ему доступен для просмотра в каталоге?” Состояния: “А что вообще значит “сделка проведена”? Это когда подписан акт, когда зачислены деньги, или когда менеджер поставил галочку в CRM?” Цель наша - не найти “истину в последней инстанции”, а договориться о терминах. Вы не философствуете, вы проектируете семантический фундамент для будущей системы. Это и есть ядро онтологии. Так, мы превращаем договорённости в карту, в  инструмент. Уже после этого можно нарисовать простую диаграмму (не обязательно UML, подойдет вольный майндмап) - вот наши главные сущности, вот как они связаны. Эта картинка становится нашим главным оружием. Для бизнес-аналитика это готовый каркас для описания бизнес-процессов. Вместо “данные передаются из точки А в точку Б” мы можем говорить точно: “статус Заявки меняется на “Одобрено”, что создаёт новый Счёт для Аккаунта”. Ясность во главе угла. Для системного аналитика это готовый прототип концептуальной модели данных. Мы узнали ключевые сущности и их связи. Остаётся только добавить атрибуты и уточнить структуру БД. Плюсом, рзработчики будут благодарны за ясную терминологию в спеке. Для всех онтология это якорьив любом споре. “Смотрим на нашу согласованную схему, где “Пользователь” является частью “Аккаунта”. Значит, требование о самостоятельной регистрации “Пользователя” без “Аккаунта” ломает договорённости. Меняем ли мы схему или переформулируем задачу?” Что в сухом остатке? Зачем нам эти сложности? Без явной онтологии мы подобны слепцам, ощупывающим слона. Каждый прав по-своему, но общая картина - битва интерпретаций. С онтологией мы получаем общий язык. Это не панацея, но явный антидот от хаоса. Составление онтологии превращает аналитика из пассивного регистратора разношёрстных пожеланий в архитектора смыслов. Мы не просто спрашиваем “что нужно сделать”, а задаём направление “в рамках какой реальности это должно работать?”. И помогаем всем участникам договориться об устройстве этой реальности, ведь строить систему в согласованной вселенной куда проще, чем крутить кривое зеркало, в котором каждый видит своё отражение, не так ли?