הקשיבו לשמות העצם

🌐 זמין גם ב-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 בפרק מידול נתונים למען המשמעות, הפרק השני בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: סקירת הפרק · הבא: שרטטו את הקשרים

השאלה שהיחידה הזו עונה עליה: איך מוצאים את ההתחלות של מודל נתונים בשיחה עסקית?

אחד הדברים שאני עושה בשיחה ראשונה עם לקוח הוא להקשיב לשמות העצם.

אני לא מדבר על פגישת התכנון הראשונה. אני מדבר על השיחה ההתחלתית, שבה אני עדיין מנסה להבין את העסק ומה הם מנסים להשיג.

הם מדברים. אני מקשיב.

ואני מקשיב למילים כמו:

שותף קמעונאי. נמען. מרכז הפצה. מניפסט. משלוח. מסלול. צוות. משאית.

שמות העצם האלה תופסים מיד את תשומת הלב שלי, כי איפשהו בשיחה הזו נמצאות ההתחלות של מודל הנתונים שלי.

אני לא מחכה עד שאני חושב שאני מבין את הבעיה עד הסוף. אני מתחיל לראות את הנתונים עוד בזמן שאני מקשיב: אני שומע את שמות העצם, מתחיל לשרטט איך הם קשורים, והשרטוט הזה עוזר לי למסגר את השיחה הבאה. לפעמים, עד סוף פגישה ראשונה עם לקוח, כבר יש לי מודל נתונים פרטי משלי משורטט.

אצלי, זה מתחיל משמות העצם.

שכחו מ-Salesforce לרגע

כאן אני רוצה שתתנגדו לאינסטינקט שחזק במיוחד אם הייתם אדמינים של Salesforce כבר תקופה.

הלקוח אומר לקוח, ואתם חושבים:

חשבון (Account).

הם אומרים אדם, ואתם חושבים:

איש קשר (Contact).

הם אומרים מרכז הפצה, ואתם כבר תוהים אם צריך אובייקט מותאם אישית.

אל תעשו את זה עדיין.

בשלב הזה, לא אכפת לי אם לקוח יהפוך בסוף לחשבון, לחשבון אישי (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) ויום משלוחים.

מניפסט מפרט משלוחים.

משלוח הולך לנמען.

מסלול הוא סבב יומי של בערך עשר עצירות (Stops).

צוות של שניים מפעיל משאית.

עכשיו משהו קורה. אני כבר לא מסתכל על רשימה של שמות עצם. אני מתחיל לראות מודל.

Click to enlarge

זה גם המקום שבו מתחילות לצוץ שאלות.

האם לשותף קמעונאי יכול להיות יותר ממרכז הפצה אחד?

האם משלוח הוא אותו דבר כמו עצירה?

האם עצירה אחת יכולה למסור לשני נמענים?

האם צוות הוא תמיד אותם שני אנשים?

האם אכפת לנו איזה צוות נהג באיזו משאית בחודש שעבר, או רק באיזו משאית הם נוהגים היום?

שימו לב מה אנחנו עושים. אנחנו עוד לא שואלים שאלות על Salesforce. אנחנו שואלים שאלות עסקיות. והתשובות האלה הן שיניעו בסופו של דבר את התכנון ב-Salesforce.

המודל הראשון שלכם לא צריך להיות מושלם

אני לא מצפה שהקופסאות הראשונות שאני משרטט ישרדו בלי שינוי. למעשה, הייתי חושד אם הן היו שורדות.

המטרה של המודל הראשון היא לא להיות נכון. המטרה היא לתת לנו משהו קונקרטי מספיק כדי לגלות איפה אנחנו טועים.

שימו משלוח, מסלול, צוות ומשאית על הלוח, ואנשים יכולים להגיב להם.

“בעצם, משלוח הוא לא תמיד פריט אחד. זה יכול להיות מכונת כביסה, מייבש, ופינוי של הישנים.”

יופי. ספרו לי עוד.

“אנחנו לא משבצים צוות למשלוח. אנחנו משבצים את הצוות למסלול.”

מצוין. מה יש במסלול?

“ואם יש התקנה, הצוות לא יכול לסגור את העצירה עד שרשימת הבדיקה והתמונות מוכנות.”

עכשיו אנחנו לומדים משהו חשוב.

תרשים הפך שיחה מעורפלת למשהו שאפשר לאתגר. זו אחת הסיבות שאני אוהב למדל מוקדם. אני לא מנסה להרשים את החדר בתרשים יפה. אני מנסה ללמוד מהר יותר.

המודל הוא חלק מהשיחה.

זה המודל המושגי שלכם

יש שם רשמי למה שהתחלנו לבנות: מודל נתונים מושגי.

ברמה הזו, אני מתעניין בדברים החשובים שהעסק מתעניין בהם ובאופן שבו הם קשורים. אני עוד לא מוטרד מאובייקטים סטנדרטיים לעומת מותאמים אישית, שמות API של שדות, lookup לעומת master-detail, שדות חובה, אינדקסים, אוטומציה, Apex או Flows. הדברים האלה חשובים, ונגיע אליהם. אבל אם נחליט עליהם לפני שנבין מה אנחנו ממדלים, אנחנו פותרים קודם את הבעיה הלא נכונה.

המודל המושגי צריך להיות הגיוני לאנשים בחדר שלא מכירים את Salesforce. זה מבחן שימושי. אם אני צריך להסביר מה המשמעות של Delivery__c לפני שמנהל התפעול יכול לקרוא את התרשים שלי, עברתי למימוש מוקדם מדי.

אני רוצה שהם יסתכלו על המודל ויגידו:

“כן, ככה העסק שלנו עובד.”

או, אפילו יותר טוב:

“לא, זה לא ככה עובד.”

כי עכשיו יש לי משהו לתקן.

אותה טכניקה עובדת גם כשאף אחד לא מדבר

זה לא רק משהו שאני משתמש בו בגילוי מול לקוחות. זה עובד גם כשה”לקוח” הוא מסמך.

כשאני עובר על מסמך דרישות, אני עושה פחות או יותר את אותו דבר. מהם המושגים העסקיים החשובים? אילו קשרים מתוארים? מה חוזר שוב ושוב? למה יש מחזור חיים משלו, מה צריך להיות מזוהה בפני עצמו, או מה צריך היסטוריה? מה נוצר, משתנה, משובץ, מועבר, מתוזמן או יוצא משימוש?

אלה אותם דברים שאני מקשיב להם בפגישה הראשונה. על דף, הרמזים האלה הופכים פסקאות של דרישות למודל שאפשר לחשוב עליו, ולשאלות טובות יותר לשיחה הבאה.

מודל הוא לא רק משהו שמפיקים אחרי שפתרתם את הבעיה. הוא אחד הכלים שבהם משתמשים כדי לפתור את הבעיה.

מה הארכיטקט מחליט כאן

עד סוף הסבב הראשון הזה, אני מנסה להחליט:

• אילו שמות עצם מייצגים ישויות מועמדות משמעותיות.
• אילו מילים שונות מייצגות את אותו מושג עסקי, ואיזו מילה אחת מסתירה שניים (כמו “לקוח”).
• לאילו מושגים צריכים רשומה ומחזור חיים משלהם.
• איך המושגים המרכזיים קשורים זה לזה.
• על אילו שאלות העסק צריך לענות לפני שאוכל למדל אותם בביטחון.

אני עוד לא מחליט על המימוש ב-Salesforce. קודם אנחנו צריכים להבין את העסק מספיק טוב כדי לשרטט אותו. וברגע ששמות העצם על הלוח, הדבר הבא שאני רוצה להבין הוא הקווים ביניהם.

מעבר למבחן: מה הבינה המלאכותית משנה. תנו לכלי בינה מלאכותית מסמך דרישות, והוא ימצא את שמות העצם, יציע ישויות וישרטט קשרים בתוך שניות. השתמשו בו כדי להאיץ את הגילוי, אבל אל תעבירו אליו את ההבנה: הוא לא יכול לדעת ש”לקוח” פירושו שני דברים שונים ב-Steve Trucking אלא אם העסק יגיד לכם. שימו את המודל הראשון שלו מול האנשים שמנהלים את העסק ושאלו: “זה באמת איך שהעסק שלכם עובד?”