Case Study - הדגמה מקצה לקצה

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

שאלות UX ותהליך: - היכן בדיוק בתהליך הזמנת הכרטיס מוצגת ההצעה? - האם המשתמש יכול לדחות את ההצעה ולהמשיך בהזמנה רגילה? - האם ההצעה מופיעה בצעד נפרד, כ-Modal, או כאופציה בבחירת סוג הכרטיס? - מה קורה אם המשתמש יוצא מהתהליך באמצע ההצעה? שאלות עסקיות: - מה שם המועדון ומה ההטבות הספציפיות? - מה החוקים העסקיים שמגדירים זכאות - ומי מאשר אותם? - האם ניתן להגביל את ההצעה לסגמנטים מסוימים של משתמשים? - מה ה-Target Conversion לפיצ'ר? שאלות טכניות: - איזה שירות עורפי מחזיר את רשימת הכרטיסים הזמינים? - האם הכרטיס החדש כבר קיים במערכת העורפית? - כיצד מוחזרים חוקי הזכאות - API ייעודי, Flags, טבלה? - מהי מדיניות ה-Fallback אם בדיקת הזכאות נכשלת? שאלות משפטיות: - האם נדרש אישור משפטי לניסוח ההצעה? - האם קיימות מגבלות רגולטוריות על שיווק כרטיסי אשראי בתוך תהליך הזמנה? שאלות דאטה: - מה ההגדרה המדויקת של 'ראה את ההצעה' לצורך מדידה? - מה ההגדרה של 'נכשל' ו-'שלב הכישלון'?

מטרה (עובדה): הוספת הצעת כרטיס אשראי המשויך למועדון כדורגל בתוך תהליך הזמנת הכרטיסים הקיים, לפי חוקים עסקיים. תהליך (הנחה - ממתין לאישור טכני): 1. משתמש נכנס לתהליך הזמנת כרטיס אשראי. 2. המערכת בודקת זכאות להצעת המועדון. 3. אם זכאי - מוצגת ההצעה לכרטיס המשויך. 4. המשתמש בוחר לקבל או לדחות. 5. אם דחה - ממשיך לתהליך ההזמנה הרגילה. 6. אם קיבל - ממשיך לתהליך הצטרפות ייעודי לכרטיס. דרישות תצוגה: - ההצעה מוצגת בשלב [שאלה פתוחה: היכן בדיוק?] - ניסוח ההצעה - [שאלה פתוחה: נדרש אישור משפטי] - המשתמש יכול לדחות ולהמשיך. דרישות זכאות: - חוקי הזכאות - [שאלה פתוחה: נדרש אישור עסקי] - מדיניות Fallback אם הבדיקה נכשלת - [שאלה פתוחה] מדידה (עובדה): - Event: הצעה הוצגה - Event: משתמש התחיל תהליך - Event: תהליך הושלם בהצלחה - Event: תהליך נכשל + שלב הכישלון מה לא בסקופ: - שינוי בתהליך ההזמנה הקיים לכרטיסים אחרים - ממשק ניהול לכללי זכאות

Epic 1: הצגת ההצעה הגדרת ממשק ההצעה, תוכנו, מיקומו בתהליך, ועיצובו. תלויות: אישור עסקי על ניסוח + אישור משפטי + החלטת UX על מיקום. Epic 2: בדיקת זכאות שילוב בדיקת זכאות מהמערכת העורפית: מה ה-API, מה הלוגיקה, מה ה-Fallback. תלויות: אישור טכני על קיום ה-API + אישור עסקי על חוקי זכאות. Epic 3: תהליך ההצטרפות ה-Flow שבו משתמש שקיבל את ההצעה מבצע הצטרפות לכרטיס - צעדים, שגיאות, סיום מוצלח. תלויות: אישור טכני על Integration עם מערכת הכרטיסים. Epic 4: מדידה ואנליטיקה הגדרת כל ה-Events שצריך לשלוח, מבנה ה-Payload, ומי קולט את הדאטה. תלויות: אישור צוות דאטה על מבנה Events. Epic 5: ניהול תהליך (הנחה) הנחה: נדרש ממשק כלשהו לניהול חוקי הזכאות או ה-A/B Test - תלוי בהחלטה עסקית.

US-01: הצגת ההצעה לזכאים כמשתמש שנמצא בתהליך הזמנת כרטיס ועומד בחוקי הזכאות, אני רוצה לראות הצעה לכרטיס המשויך למועדון הכדורגל, כדי שאוכל לבחור להצטרף אליו. AC: - בדיקת זכאות מבוצעת לפני הצגת ההצעה - הצעה מוצגת רק למשתמשים שעוברים את בדיקת הזכאות - הצעה לא מוצגת למשתמשים שאינם זכאים - תוכן ההצעה תואם לאישור המשפטי [שאלה פתוחה: ניסוח מדויק] US-02: דחיית ההצעה כמשתמש שראה את ההצעה, אני רוצה לדחות אותה ולהמשיך בהזמנת כרטיס רגיל, כדי שאוכל להשלים את ההזמנה שלי. AC: - כפתור 'לא, תודה' או שווה ערך קיים ונגיש - לחיצה על דחייה מחזירה את המשתמש לתהליך הרגיל - דחייה נשמרת ב-Event לצורך מדידה US-03: השלמת הצטרפות מוצלחת כמשתמש שקיבל את ההצעה, אני רוצה להשלים הצטרפות לכרטיס המועדון, כדי להנות מהטבות המועדון. AC: - תהליך ההצטרפות מוביל לסיום מוצלח - בסיום מוצלח נשלח Event 'הושלם' - הודעת אישור מוצגת למשתמש US-04: טיפול בשגיאת זכאות כמשתמש שמנסה לקבל הצעה כשבדיקת הזכאות נכשלת, אני לא רוצה לראות הצאה שגויה, כדי שחוויית המשתמש שלי לא תיפגע. AC: - כישלון בבדיקת זכאות לא מציג את ההצעה - המשתמש ממשיך לתהליך הרגיל [Fallback - שאלה פתוחה: מה הדיפולט?]

תרחישי Happy Path: 1. משתמש זכאי רואה הצעה → מקבל → משלים הצטרפות בהצלחה 2. משתמש זכאי רואה הצעה → דוחה → ממשיך להזמנה רגילה 3. משתמש לא זכאי - לא רואה הצעה, ממשיך לתהליך רגיל Edge Cases - זכאות: 4. בדיקת הזכאות מחזירה שגיאת תקשורת (Timeout / 500) - מה קורה? 5. בדיקת הזכאות מחזירה תגובה לא צפויה - מה קורה? 6. משתמש כבר מחזיק כרטיס מועדון - האם ההצעה מוצגת? Edge Cases - תהליך: 7. משתמש יוצא מהאפליקציה באמצע ההצעה - מה קורה בכניסה חוזרת? 8. משתמש לוחץ חזרה לאחר שהתחיל את ההצטרפות 9. הגשה כפולה - המשתמש לוחץ 'הצטרף' פעמיים 10. משתמש שדחה את ההצעה - האם יראה אותה שוב בביקור הבא? Edge Cases - מדידה: 11. Event נשלח אך בדיקת זכאות לא הסתיימה - האם ה-Event נשלח לפי תזמון נכון? 12. שני Events זהים בפרק זמן קצר (refresh מהיר) - האם נספרים פעמיים? הנחה: כל שאלות ה-Edge Cases דורשות תשובות מהצוות הטכני לפני כתיבת Test Cases מפורטים.

מדדי ההצלחה שסופקו (עובדה): - כמה משתמשים ראו את ההצעה - כמה התחילו את תהליך ההצטרפות - כמה השלימו בהצלחה - כמה נכשלו ובאיזה שלב Events נדרשים (הנחה - ממתינים לאישור דאטה): Event 1: club_card_offer_shown מתי: כאשר ההצעה מוצגת למשתמש Payload: user_id, timestamp, eligibility_source [שאלה פתוחה] Event 2: club_card_offer_started מתי: כאשר משתמש לחץ על 'הצטרף' / 'רוצה לדעת עוד' Payload: user_id, timestamp Event 3: club_card_offer_completed מתי: בסיום הצטרפות מוצלחת Payload: user_id, timestamp Event 4: club_card_offer_failed מתי: כאשר תהליך נכשל Payload: user_id, timestamp, failure_stage, error_code [שאלה פתוחה] Event 5: club_card_offer_dismissed מתי: כאשר משתמש דחה את ההצעה Payload: user_id, timestamp הנחה: יש להגדיר יחד עם צוות הדאטה את המבנה הסופי של ה-Payload לפני הפיתוח.

שאלות שהדשבורד צריך לענות: 1. כמה משתמשים ראו את ההצעה בכל יום / שבוע? 2. מה ה-Conversion Rate מ'ראה הצעה' ל'התחיל הצטרפות'? 3. מה ה-Conversion Rate מ'התחיל' ל'השלים בהצלחה'? 4. באיזה שלב המשתמשים נושרים הכי הרבה? 5. מה ה-Dismissal Rate - כמה דחו את ההצעה? פילוחים נדרשים (הנחה): - לפי סגמנט גיל / סוג משתמש [שאלה פתוחה: אילו סגמנטים רלוונטיים?] - לפי מכשיר (iOS / Android) - לפי גרסת אפליקציה - לפי שעה / יום בשבוע הנחה: נדרש Meeting עם צוות הדאטה לאישור הפילוחים לפני הבנייה.

סטטוס: At Risk מה התקדם: - BRD הושלם ואושר על ידי הצוות העסקי. - PRD נכתב וכולל את כל הדרישות הידועות. - רשימת Epics ו-User Stories מוכנות. סיכונים מרכזיים: - חוקי הזכאות לא אושרו סופית - עיכוב בפיתוח Epic 2. - ניסוח ההצעה תלוי באישור משפטי - אין תאריך אישור. - ה-API של בדיקת הזכאות לא אומת עם הצוות הטכני. חסמים: - נדרש Meeting עם הצוות המשפטי לאישור ניסוח. - נדרשת תשובה מהצוות העסקי על חוקי הזכאות. - נדרש Kick-off טכני לאימות ה-API. החלטות שנדרשות מהמנהל: - אישור לקדם לפיתוח Epic 1 (הצגת ההצעה) תוך המתנה לאישורים האחרים. - מי הגורם שיוביל את המסלול המשפטי ומה לוח הזמנים? צעדים הבאים: - תאם Meeting עם משפטי עד [תאריך - שאלה פתוחה]. - קבל תשובה על חוקי זכאות עד [תאריך - שאלה פתוחה]. - Kick-off טכני - Epic 2.