Как понять домен клиента. Анализируем и систематизируем базу знаний компании

Привет, меня зовут Владимир Скляр, я бизнес-аналитик в компании Artkai, занимаюсь Presale, Discovery и оптимизацией процессов компании. Данная статья будет полезна тем, кто работает с анализом и систематизацией доменных знаний.

Анализ доменов (Domain Analysis) рассматривается как один из видов аналитической деятельности, направленной на подготовку к выявлению требований для понимания контекста бизнеса, высокоуровневых процессов и общих тенденций в рыночном сегменте. Командам разработки необходимо периодически актуализировать свои знания и онбордить новичков. Кроме того, знания о домене позволяют понять поведение пользователей и являются источником продуктовых гипотез.

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

Индустриальный домен и домен приложения

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

Домен программного приложения — это тематическая область применения ПО, обобщенная с точки зрения знаний, а также выполняемых функций и обрабатываемых данных. Примерами домена приложений являются ERP (Enterprise Resource Planning), CMS (Content Management System), marketplace и так далее. Примеры классификаций ПО можно найти на сайтах таких сервисов, как g2, TrustRadius, TechnologyAdvice.

Индустриальные домены классифицируются согласно видам производственных процессов, бизнес-моделям, предлагаемым продуктам и сервисам. Существует несколько десятков классификаций индустрий, разработанных различными национальными и международными организациями. Примерами индустриальных доменов являются автомобильная промышленность, BFSI (Banking, Financial Services and Insurance), логистика, энергетика и так далее.

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

Применение базы знаний компании в процессах разработки ПО и лидогенерации

Анализ доменов в ІТ-компании может быть направлен на решение следующих задач:

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

Таким образом, анализ доменов и связанное с ним развитие базы знаний является основой как для создания ПО на основе повторного использования имеющихся наработок, так и для проведения лидогенерации на основе имеющейся информации о домене и бизнес-кейсах (см. рисунок).

Применение базы знаний компании в процессах разработки ПО и лидогенерации

Для реализации подобных процессов необходимо решить ряд вопросов, связанных с:

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

Ответ на эти вопросы дает процедура анализа доменов.

Процедура анализа доменов

При детализации процедуры анализа доменов мы сфокусировались на гипотезе о том, что в области программной инженерии уже существуют релевантные наработки, применимые для решения задач по анализу доменов. Действительно, в программной инженерии уже более 15 лет используют Domain Driven Design (DDD). Это фреймворк был предложен специально для того, чтобы разработка ПО основывалась на знаниях, учитывающих модели, функции, бизнес-логику и проблемы, свойственные тому или иному домену. При этом не проводится четкой границы между индустриальным доменом и доменом приложения.

В свою очередь, многие из идей DDD перекликаются с более ранним подходом, опубликованным SEI (Software Engineering Institute) под названием Feature Oriented Domain Analysis (FODA) в 1990 году. Фреймворк FODA, предназначенный для анализа домена ПО, основывается на следующих трех этапах:

  1. Анализ контекста для определения границ, интерфейсов, входов и выходов предметной области.
  2. Моделирование домена через описание проблем в предметной области, которые решаются программными приложениями с учетом особенностей ПО, программных сущностей, данных и других спецификаций.
  3. Моделирование архитектуры ПО, реализующей решение проблем в домене путем использования существующих технических решений.

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

Исходными данными и условием для возможности реализации предлагаемой процедуры является наличие адаптированных под нужды ІТ-компании классификаций индустриальных доменов и доменов прикладного ПО.

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

Под моделированием в контексте анализа индустриальных доменов будем понимать выявление проблем пользователей и поиск путей их решения. Подходящие для этого техники Value Proposition Canvas (VP Canvas) и профиль идеального клиента (Ideal Client Profile, ICP). Для этого предварительно следует провести анализ доступных материалов, составить ссылочную базу, глоссарий для домена и выявить перечень функций, выполняемых программными приложениями.

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

Таблица. Задачи, выполняемые в ходе анализа доменов

Выполняемая задачаИсточники информацииРезультаты
Обзор домена и анализ трендовGoogle SearchИнформационные сайты для анализа материалов

Ключевые слова для поиска
Сегментирование доменаGoogle Search

Аналитические отчеты и статьи
Классификация субдоменов
Создание ссылочной базыGoogle Search

Сайты ведущих аналитических агентств
Аннотированный перечень источников

Нормативная база
Анализ терминологии и акронимовВикипедия

Аналитические отчеты и статьи
Глоссарий
Анализ типовых функцийСервисы рейтингов ПО (Capterra, Sensor Tower, G2 и так далее)Структура (дерево) функций, выполняемых для домена и субдоменов
Анализ пользовательского опыта (UX)Сервисы рейтингов ПО и сайты с отзывами пользователейValue Proposition (VP) Canvas
Анализ целевой аудиторииVP CanvasIdeal Client Profile (ICP)

Выводы

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

Для демонстрации этой идеи мы адаптировали давно известный фреймворк Feature Oriented Domain Analysis (FODA) и разработали процедуру анализа доменов, включающую следующие этапы:

  • обзор домена и анализ трендов;
  • сегментирование домена;
  • создание ссылочной базы;
  • анализ терминологии и акронимов;
  • анализ типовых функций;
  • анализ пользовательского опыта;
  • анализ целевой аудитории.

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

👍НравитсяПонравилось4
В избранноеВ избранном4
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
наработки, применимые для решения задач по анализу доменов

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

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

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

а потом

смотришь уже имеющийся код (если он есть).

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

Пустяк для пожилого вайтишника.

Пустяк для пожилого вайтишника.

Кто так не может — тoгo незачем брать на проекты. Толку с таких 0.

Комментарий Ваш, уважаемый тролль, никакой ценности не несет, как и вся Ваша деятельность на dou: 0 статей, зато 100+ провокационных обесценивающих комментариев. Как Вы изволили высказаться: «толку с таких 0»

Существуют ли показатели для оценки качества выполненного анализа домена?

Я не встречал. Возможно, потому что анализа домена, является не целью или конечным продуктов, а средством их достижения/создания

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

Есть галеры (большинство наверно) где всем пох на твою доменую экспертизу.
Но на собесах с заказчиком хорошо заметно что для них наоборот важна как экспертиза кандидата, та и его коммитмент.

Всё так. Но бывает, что на горизонте появляются и новые направления. И на галере тоже комфортней, когда с доменом знаком)

Бывают проекты, где доменная экспертиза просто «must have» на входе. Например, врядли возмут на позицию БА в серьезный HealthTech-проект человека без знания HL7 FHIR и CCD\CDA.

на ДОУ вакансиях как правило домен не пишут в заголовке, что как-бы характеризует галеры, напоминающие базарных что-вам-подсказать торгашей.
купил тушку — продал тушку.
время от времени просматриваю healhtcare направление по Джаве, но в Днепре кроме ISD мало кто над серьёзными продуктами работает,
Серв ещё аутсорсит по теме healhtcare на разных заказчиков.
Что-то начиналось у Оракла, судя по вакансиям, но HC- не их поле, думаю, на волне хайпа как начали, так и сдуются, там игра идёт в долгую и убытки тоже могут быть долгие.

У EdenLab (Киев), MedeAnalytics (Харьков), NIX (Харьков), Eleks (Львов) вроде были большие серьезные проекты в HealthTech

Например, врядли возмут на позицию БА в серьезный HealthTech-проект человека без знания HL7 FHIR и CCD\CDA.

Эти всяких стандартов — в healthcare напридумывали сотни. Всех не наосваиваешься.

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

HL7 FHIR, CCD\CDA — не такие уж и простые стандарты. Одних клинических терминов (SNOMED CT) — 311 тысяч. Видел у какой-то компании курс обучения — 14 недель.

Подписаться на комментарии