Прислушайтесь к существительным

🌐 Также доступно на 28 языках

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 1 из 6 главы Моделирование данных ради смысла, глава 2 курса Data Architect. Каждый модуль самостоятелен. Назад: обзор главы · Далее: Нарисуйте связи

Вопрос, на который отвечает этот модуль: Как найти зачатки модели данных в деловом разговоре?

Одно из того, что я делаю на первом звонке с клиентом, — прислушиваюсь к существительным.

Я не говорю о первой сессии проектирования. Я говорю о том самом первом разговоре, когда я еще пытаюсь понять бизнес и то, чего он хочет добиться.

Они говорят. Я слушаю.

И я прислушиваюсь к таким словам:

Розничный партнер. Получатель. Распределительный центр. Манифест. Доставка. Маршрут. Бригада. Грузовик.

Эти существительные сразу привлекают мое внимание, потому что где-то в этом разговоре зарождается моя модель данных.

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

Для меня это начинается с существительных.

На минуту забудьте о Salesforce

Здесь я хочу, чтобы вы сопротивлялись инстинкту, который особенно силен, если вы уже какое-то время работаете администратором Salesforce.

Клиент говорит клиент, а вы думаете:

Организация (Account).

Они говорят человек, а вы думаете:

Контакт.

Они говорят распределительный центр, а вы уже прикидываете, нужен ли пользовательский объект.

Пока не делайте этого.

На этом этапе мне все равно, станет ли клиент в итоге организацией, персональной учетной записью (Person Account), пользовательским объектом или чем-то еще. Сначала я хочу понять бизнес.

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

Так что на несколько минут забудьте о Salesforce. Послушайте, как описывают свой мир люди, которые на самом деле ведут этот бизнес.

Сидеть, стоять, моделировать

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

Вот собака: Marcus — владелец Bella. Ее вывел питомник Maple Ridge Kennels. Она лабрадор и знает команды «Сидеть», «Стоять» и «Дай лапу».

Прислушайтесь к существительным: Marcus, Bella, Maple Ridge Kennels, лабрадор, «Сидеть». Но это имена — конкретные вещи. Мне нужен вид вещи, к которому относится каждое имя. Bella — это Собака. Marcus — Владелец. Maple Ridge Kennels — Заводчик. Лабрадор — Порода. «Сидеть» — Трюк. Пять существительных, пять прямоугольников-кандидатов.

Click to enlarge

Затем вопрос, который я задаю о каждом существительном: это человек, выполняющий работу, или это часть данных? Marcus — человек. Но владеть Bella — это не работа; это факт о Bella, и рано или поздно кто-нибудь спросит: «Чья это собака?» Поэтому Владелец входит в модель. Дрессировщик, который научил Bella давать лапу, — это человек, выполняющий работу, и ему, возможно, никогда не понадобится свой прямоугольник, если только бизнес не начнет спрашивать, кто какому трюку научил.

И обратите внимание на слово кандидат. Порода — это правда отдельный прямоугольник или просто слово, записанное у собаки? Держите этот вопрос в голове; мы ответим на него, когда будем нормализовать в модуле 4.

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

Существительные дают сущности-кандидаты

Давайте послушаем Steve Trucking — семейную компанию, которую мы будем использовать на протяжении всего курса. Она доставляет крупные товары (холодильники, стиральные машины, телевизоры) из распределительных центров крупных сетевых ритейлеров к людям домой и часть из них устанавливает.

В первом разговоре мы слышим:

• Розничный партнер (Retail Partner)
• Получатель (Recipient)
• Распределительный центр (Distribution Center)
• Манифест (Manifest)
• Доставка (Delivery)
• Маршрут (Route)
• Бригада (Crew)
• Грузовик (Truck)

Это уже полезно. Я могу начать рисовать прямоугольники на доске.

Так что поместите существительные в прямоугольники. На этом этапе они только этим и являются: прямоугольниками. Никаких линий, никаких цветов, ничего, что говорило бы о Salesforce. Позже в курсе формы и цвета начнут что-то значить. А пока прямоугольник — это просто вещь, о которой говорит бизнес.

Затем начните их располагать. Размещая каждый прямоугольник, думайте о двух вещах: как они связаны друг с другом и что это за данные. Часть из них — данные о клиентах: компании и люди, с которыми мы работаем. Часть — транзакционные данные, например заказы и позиции заказов: то, что происходит снова и снова. А часть — справочные данные, например продукты или услуги, которые предлагает бизнес: то, от чего зависит работа.

В Steve Trucking розничный партнер и получатель — это данные о клиентах. Манифест, доставка и маршрут — транзакции. Распределительный центр, бригада и грузовик — то, от чего зависит работа.

Click to enlarge

Но здесь есть важное слово: кандидат.

Существительное — это подсказка. Оно не становится автоматически сущностью и уж точно не становится автоматически объектом Salesforce.

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

Некоторые из этих существительных будут людьми. В Steve Trucking это получатель, который ждет холодильник, люди у розничного партнера, которые отправляют манифест, и бригада: водители и помощники на грузовике. Это роли, а роль может не казаться данными. Но когда люди действуют с данными или связаны с ними, они сами должны быть представлены в данных. Кто это доставил? Кто расписался в получении? Кто отправил манифест? Поэтому многие роли, а иногда и все, тоже оказываются в модели.

Послушайте, как говорят в Steve Trucking, и вы кое-что заметите. Они никогда не говорят просто «клиент». Есть два вида клиентов. Розничный партнер — это крупный сетевой ритейлер, для которого Steve Trucking выполняет доставку: он отправляет манифест и платит за каждую доставку. Получатель — это человек, которому доставляют холодильник. Получатель купил его в магазине и, возможно, никогда не слышал о Steve Trucking.

Если бы я нарисовал один прямоугольник под названием «Клиент», я бы смешал две совершенно разные вещи.

Может быть, распределительный центр достаточно важен, чтобы иметь собственную запись, историю, связи и атрибуты.

Может быть, другое существительное окажется всего лишь атрибутом чего-то еще.

Именно это мы и пытаемся выяснить. Мы еще не создаем объекты. Мы выстраиваем свое понимание бизнеса.

Теперь прислушайтесь к связям

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

Розничный партнер управляет распределительными центрами.

Розничный партнер отправляет манифест на каждый DC и день доставки.

Манифест перечисляет доставки.

Доставка идет получателю.

Маршрут — это дневной рейс примерно из десяти остановок.

Бригада из двух человек работает на грузовике.

Теперь кое-что происходит. Я смотрю уже не на список существительных. Я начинаю видеть модель.

Click to enlarge

Здесь же начинают появляться вопросы.

Может ли у розничного партнера быть больше одного распределительного центра?

Доставка — это то же самое, что остановка?

Может ли одна остановка обслуживать двух получателей?

Бригада — это всегда одни и те же два человека?

Нам важно, у какой бригады какой грузовик был в прошлом месяце, или только то, на каком грузовике они ездят сегодня?

Заметьте, что мы делаем. Мы пока не задаем вопросов о Salesforce. Мы задаем бизнес-вопросы. И со временем ответы на них определят проект в Salesforce.

Первая модель не обязана быть идеальной

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

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

Поместите на доску доставку, маршрут, бригаду и грузовик, и люди смогут на них отреагировать.

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

Хорошо. Расскажите подробнее.

«Мы не назначаем бригаду на доставку. Мы назначаем бригаду на маршрут».

Отлично. А что входит в маршрут?

«А если есть установка, бригада не может закрыть остановку, пока не выполнены чек-лист и фотографии».

Вот теперь мы узнаем что-то важное.

Диаграмма превратила расплывчатый разговор в то, что можно оспорить. Это одна из причин, по которым я люблю моделировать рано. Я не пытаюсь впечатлить аудиторию красивой диаграммой. Я пытаюсь быстрее учиться.

Модель — это часть разговора.

Это ваша концептуальная модель

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

На этом уровне меня интересуют важные вещи, о которых заботится бизнес, и то, как они связаны. Меня пока не волнуют стандартные или пользовательские объекты, API-имена полей, lookup или master-detail, обязательные поля, индексы, автоматизация, Apex или Flows. Все это важно, и мы до этого доберемся. Но если мы решим это до того, как поймем, что моделируем, мы первым делом решим не ту задачу.

Концептуальная модель должна быть понятна людям в комнате, которые не знают Salesforce. Это полезный тест. Если мне приходится объяснять, что значит Delivery__c, прежде чем операционный менеджер сможет прочитать мою диаграмму, я слишком рано перешел к реализации.

Я хочу, чтобы они посмотрели на модель и сказали:

«Да, именно так работает наш бизнес».

Или, что еще лучше:

«Нет, все работает не так».

Потому что теперь мне есть что исправлять.

Та же техника работает, когда никто не говорит

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

Когда я прорабатываю документ с требованиями, я делаю почти то же самое. Какие бизнес-понятия важны? Какие связи описаны? Что встречается снова и снова? У чего есть собственный жизненный цикл, что нужно идентифицировать отдельно или для чего нужна история? Что создается, изменяется, назначается, передается, планируется или выводится из употребления?

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

Модель — это не просто то, что вы выдаете после того, как решили задачу. Это один из инструментов, которыми вы задачу решаете.

Что здесь решает архитектор

К концу этого первого прохода я пытаюсь решить:

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

Я пока не решаю, как это будет реализовано в Salesforce. Сначала нужно понять бизнес достаточно хорошо, чтобы его нарисовать. А когда существительные уже на доске, следующее, что я хочу понять, — линии между ними.

За пределами экзамена: что меняет ИИ. Дайте ИИ-инструменту документ с требованиями, и он за секунды найдет существительные, предложит сущности и набросает связи. Используйте это, чтобы ускорить выявление требований, но не перепоручайте понимание: он не может знать, что «клиент» в Steve Trucking означает две разные вещи, если этого не скажет вам бизнес. Покажите его первую модель людям, которые ведут бизнес, и спросите: «Ваш бизнес действительно так работает?»