איך מגדירים MVP לפרויקט Salesforce בלי ליצור מערכת זמנית

המבחן שמפריד בין MVP לבין מערכת זמנית

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

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

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

שלוש הגדרות שמבלבלים ביניהן

הבחירה בין השלושה אינה סמנטית. PoC אפשר לזרוק, MVP לא — ולכן ל-MVP מותר להיבנות רק בסטנדרט של ייצור.

אילו החלטות אסור לדחות

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

• האובייקט שמחזיק את התהליך העסקי ויחסו לישויות הליבה.
• המפתח הייחודי שמזהה לקוח מול מערכות חיצוניות.
• ברירת המחדל של הנראות בכל אובייקט מרכזי.
• מבנה הבעלות על רשומה — מי ה-Owner ומה קורה כשעובד עוזב.
• הגדרת מקור האמת לכל ישות שמסונכרנת עם מערכת אחרת.

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

איך בוחרים את התהליך של הגל הראשון

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

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

קריטריון יציאה — מה מסמן שהגל הצליח

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

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

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

עלות דחייה — הכלי שמכריע ויכוחי Scope

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

דוגמה להמחשה: חברת לוגיסטיקה בינלאומית

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

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

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

סימנים שה-MVP הפך למערכת זמנית

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

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

שילוב עם לוח הזמנים הכולל

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

הצעד הבא

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