התשובה הקצרה
סיפור טוב ב-Salesforce מתאר מי, מה הוא מנסה להשיג, ומה יהיה נכון אחרי הפעולה - ולא איזה שדה יופיע באיזה מסך. הבדיקה הפשוטה: אם אפשר לכתוב את קריטריוני הקבלה בלי לדעת אם המימוש יהיה Flow, Validation Rule או Apex, הסיפור נוסח נכון.
הכשל הנפוץ הוא סיפור שכבר מכיל את הפתרון. ברגע שכתוב "הוסף שדה Picklist למסך העסקה", הדיון על התהליך נסגר לפני שהתחיל.
מבנה שעובד
| רכיב | תפקידו | מבחן איכות |
|---|---|---|
| הקשר | מי המשתמש ומתי הוא כאן | תפקיד אמיתי, לא "משתמש" |
| כוונה | מה הוא מנסה להשיג | מנוסח בשפת העסק |
| קריטריוני קבלה | מה נבדק | ניתן להריץ כתרחיש עם נתוני בדיקה |
| מקרי קצה | מה נכשל בכוונה | לפחות אחד שלילי |
| חוץ מ-Scope | מה במפורש לא נכלל | מונע ויכוח בקבלה |
השורה האחרונה חוסכת את רוב הסכסוכים. הצהרה מפורשת שמה שלא נכלל אינו נכלל שווה יותר משלוש פסקאות תיאור.
פירוק: Vertical Slice ולא שכבות
הפיתוי בפרויקט CRM הוא לפרק לפי רכיבים טכניים - קודם מודל הנתונים, אחר כך האוטומציות, בסוף הדוחות. התוצאה היא שאין מה להראות עד הסוף, ואיש אינו יודע אם התהליך עובד.
הפירוק הנכון הוא אנכי: תרחיש מלא אחד, מקצה לקצה, לפרופיל משתמש אחד. עסקה אחת שנפתחת, מתקדמת, נסגרת ומופיעה בדוח - שווה יותר מעשרה אובייקטים מוגדרים בלי תהליך. בהמשך מוסיפים פרופילים ותרחישים סביב אותו שלד.
תעדוף כשהכל דחוף
שלושה קריטריונים מספיקים, בסדר הזה:
- חוסם עלייה לאוויר? - בלעדיו התהליך אינו שלם. אין מקום למשא ומתן.
- כמה משתמשים ביום? - תדירות גוברת על עוצמת התלונה. פריט שנוגע ב-80 נציגים יומית קודם לבקשה של מנהל אחד.
- מה עלות הדחייה? - האם עלות המימוש עולה אם נעשה אותו אחרי ההשקה? שינוי במודל נתונים כן, שינוי בדוח לא.
מה שאינו עובר את שלושת אלה עובר ל-Parking Lot. הפרדה זו מונעת Backlog שהופך לארכיון של משאלות. עומק על ניהול שינויים בהיקף מופיע בScope Creep ובקרת שינויים.
חוב דרישות: הכשל השקט
חוב דרישות נוצר כשסיפור נסגר בלי שהוחלט מה קורה במקרה הקצה - נשאר "נטפל בזה אחר כך". אחרי ההשקה, מקרי הקצה האלה הם רוב הקריאות לתמיכה.
הריסון הפשוט: פריט אינו נסגר בלי החלטה מתועדת לכל שאלה פתוחה שנרשמה בו, גם אם ההחלטה היא "בכוונה לא מטפלים". תיעוד הוויתור שווה יותר מהיעדר תיעוד.
הקשר לבדיקות
קריטריוני קבלה שנכתבו נכון הם למעשה תסריטי ה-UAT. כשהם נכתבים אחרי הפיתוח, ה-UAT הופך להדגמה של מה שנבנה במקום לבדיקה של מה שנדרש. הרצף מפורט במדריך UAT.
סיכום
Backlog איכותי אינו ארוך אלא ברור: כל פריט אומר למי הוא מיועד, מה יימדד כהצלחה, ומה במפורש אינו כלול. שלוש השאלות האלה, שנשאלות לפני הבנייה ולא אחריה, קובעות כמעט את כל איכות הקבלה בסוף הפרויקט.