Слухайте іменники

🌐 Також доступно 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.

Він каже людина, а ви думаєте:

Contact.

Він каже розподільчий центр, а ви вже міркуєте, чи потрібен користувацький об’єкт.

Поки що не робіть цього.

На цьому етапі мені байдуже, чи стане клієнт зрештою Account, Person Account, користувацьким об’єктом чи чимось іншим. Спершу я хочу зрозуміти бізнес.

Ось різниця між моделюванням бізнесу і налаштуванням Salesforce. Якщо я починаю з об’єктів Salesforce, я вже обмежив своє мислення однією реалізацією. Я можу опинитися саме там, де й очікував, але хочу дійти туди, бо мене привів бізнес, а не тому, що Account і Contact були першими двома об’єктами, які я знав.

Тож на кілька хвилин забудьте про 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 — сімейну компанію, яку ми використовуватимемо протягом усього курсу. Вона доставляє великі речі (холодильники, пральні машини, телевізори) з розподільчих центрів великих мереж прямо додому і деякі з них встановлює.

У першій розмові ми чуємо:

• Роздрібний партнер
• Отримувач
• Розподільчий центр
• Маніфест
• Доставка
• Маршрут
• Бригада
• Вантажівка

Це вже корисно. Я можу почати ставити прямокутники на дошку.

Тож помістіть іменники в прямокутники. На цьому етапі вони лише прямокутники. Жодних ліній, жодних кольорів, нічого, що каже «Salesforce». Пізніше в курсі форми й кольори почнуть щось означати. Поки що прямокутник — це просто річ, про яку говорить бізнес.

Потім почніть їх розташовувати. Ставлячи кожен прямокутник, думайте про дві речі: як вони пов’язані між собою і що це за вид даних. Деякі з них — дані клієнтів: компанії й люди, з якими ми працюємо. Деякі — транзакційні дані, як замовлення й позиції замовлень: те, що відбувається знову і знову. А деякі — довідкові дані, як продукти чи послуги, які пропонує бізнес: те, від чого залежить робота.

У Steve Trucking роздрібний партнер і отримувач — дані клієнтів. Маніфест, доставка і маршрут — транзакції. Розподільчий центр, бригада і вантажівка — те, від чого залежить робота.

Click to enlarge

Але тут є важливе слово: кандидат.

Іменник — це підказка. Він не стає автоматично сутністю і вже точно не стає автоматично об’єктом Salesforce.

На сесії з виявлення вимог я записую кожен іменник. Про кожен іменник, який вони вимовляють, я ставлю собі одне запитання: це людина, що виконує роботу, чи частина даних? Менеджер з розвитку бізнесу — людина, що виконує роботу. Це користувач, роль, можливо, набір дозволів. Замовлення, рахунки, позиції — це частини даних. Важливе і те, й інше, але вони опиняються в дуже різних місцях дизайну, і раннє сортування рятує мене від того, щоб малювати прямокутник для кожної посади з оргструктури.

Деякі з цих іменників будуть людьми. У Steve Trucking це отримувач, який чекає на холодильник, люди в роздрібного партнера, що надсилають маніфест, і бригада: водії й помічники на вантажівці. Це ролі, і роль може не здаватися даними. Але коли люди діють із даними або пов’язані з ними, їх треба відобразити в самих даних. Хто це доставив? Хто розписався? Хто надіслав маніфест? Тож багато ролей, а іноді й усі, теж потрапляють у модель.

Послухайте, як говорить Steve Trucking, і ви щось помітите. Вони ніколи не кажуть просто «клієнт». Є два види клієнтів. Роздрібний партнер — велика мережа, для якої Steve Trucking доставляє: вона надсилає маніфест і платить за кожну доставку. Отримувач — людина, якій доставляють холодильник. Отримувач купив його в магазині і, можливо, ніколи не чув про Steve Trucking.

Якби я намалював один прямокутник Customer, я змішав би дві зовсім різні речі.

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

Можливо, інший іменник виявиться лише атрибутом чогось іншого.

Саме це ми намагаємося з’ясувати. Ми ще не створюємо об’єктів. Ми будуємо своє розуміння бізнесу.

Тепер слухайте зв’язки

Іменники дають мені відправну точку. Потім я слухаю, як бізнес їх пов’язує.

Роздрібний партнер має розподільчі центри.

Роздрібний партнер надсилає маніфест для кожного DC і дня доставки.

Маніфест містить перелік доставок.

Доставка йде до отримувача.

Маршрут — це денний рейс приблизно з десяти зупинок.

Бригада з двох людей працює на вантажівці.

Тепер щось відбувається. Я вже дивлюся не на перелік іменників. Я починаю бачити модель.

Click to enlarge

Саме тут з’являються й запитання.

Чи може в роздрібного партнера бути більше одного розподільчого центру?

Доставка — це те саме, що зупинка?

Чи може одна зупинка обслуговувати двох отримувачів?

Бригада — це завжди ті самі двоє людей?

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

Зверніть увагу, що ми робимо. Ми ще не ставимо запитань про Salesforce. Ми ставимо бізнес-запитання. І ці відповіді зрештою визначатимуть дизайн Salesforce.

Ваша перша модель не мусить бути ідеальною

Я не очікую, що перші намальовані прямокутники переживуть усе без змін. Насправді я насторожився б, якби так сталося.

Сенс першої моделі не в тому, щоб бути правильною. Сенс — дати нам щось достатньо конкретне, щоб виявити, де ми помиляємося.

Поставте на дошку Доставку, Маршрут, Бригаду і Вантажівку — і люди зможуть на них відреагувати.

«Насправді доставка — не завжди один предмет. Це може бути пральна машина, сушарка і вивезення старих».

Добре. Розкажіть більше.

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

Чудово. Що є в маршруті?

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

Тепер ми дізнаємося щось важливе.

Діаграма перетворила розмиту розмову на щось, що можна оскаржити. Це одна з причин, чому я люблю моделювати рано. Я не намагаюся вразити кімнату гарною діаграмою. Я намагаюся вчитися швидше.

Модель — частина розмови.

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

Для того, що ми почали будувати, є формальна назва: концептуальна модель даних.

На цьому рівні мене цікавлять важливі для бізнесу речі і те, як вони пов’язані. Я ще не переймаюся стандартними чи користувацькими об’єктами, API-іменами полів, lookup чи master-detail, обов’язковими полями, індексами, автоматизацією, Apex чи Flows. Ці речі важливі, і ми до них дійдемо. Але якщо вирішувати їх, перш ніж ми зрозуміли, що моделюємо, ми першою розв’язуємо не ту задачу.

Концептуальна модель має бути зрозумілою людям у кімнаті, які не знають Salesforce. Це корисний тест. Якщо мені треба пояснити, що означає Delivery__c, перш ніж операційний менеджер зможе прочитати мою діаграму, я надто рано перейшов до реалізації.

Я хочу, щоб вони подивилися на модель і сказали:

«Так, наш бізнес працює саме так».

Або, ще краще:

«Ні, усе працює не так».

Бо тепер у мене є що виправити.

Та сама техніка працює, коли ніхто не говорить

Я користуюся цим не лише під час виявлення вимог із клієнтом. Це працює й тоді, коли «клієнт» — документ.

Коли я опрацьовую документ із вимогами, я роблю майже те саме. Які важливі бізнес-поняття? Які зв’язки описано? Що повторюється? Що має власний життєвий цикл, потребує окремої ідентифікації чи історії? Що створюється, змінюється, призначається, передається, планується чи виводиться з ужитку?

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

Модель — не просто те, що ви робите після того, як розв’язали задачу. Це один з інструментів, якими ви її розв’язуєте.

Що тут вирішує архітектор

До кінця цього першого проходу я намагаюся вирішити:

• Які іменники є змістовними кандидатами в сутності.
• Які різні слова позначають те саме бізнес-поняття, а яке одне слово ховає два (як «клієнт»).
• Яким поняттям потрібні власний запис і життєвий цикл.
• Як основні поняття пов’язані між собою.
• На які запитання бізнес має відповісти, перш ніж я зможу впевнено їх змоделювати.

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

За межами іспиту: що змінює ШІ. Дайте ШІ-інструменту документ із вимогами, і він за секунди знайде іменники, запропонує сутності й накидає зв’язки. Використовуйте це для прискорення виявлення вимог, але не передавайте на аутсорс розуміння: він не може знати, що «клієнт» у Steve Trucking означає дві різні речі, якщо бізнес вам цього не скаже. Покажіть його першу модель людям, що ведуть бізнес, і запитайте: «Чи справді ваш бізнес працює так?»