אחד מהמשפטים שיוצא לי להגיד הרבה במהלך קורסי ניהול המוצר שאני מלמד עכשיו הוא “זה לא שיעור פילוסופיה, לכל מה שאני מלמד צריך להיות ערך פרקטי לעבודה שלכם. אם לא הבנתם מה הערך עבורכם תשאלו”. ובשבוע שעבר שאלו אותי את זה לגבי החלוקה לתימות, אפיקים ופיצרים. למה לא פשוט לרשום רשימה של פיצרים ואז לתעדף אותם? למה להסתבך?
אז הנה הערך שחלוקה הזו עושה עבורי, אבל לפני זה קצת הגדרות: תימה היא תחום שבו המוצר שלי מספק ערך, אפיק הוא פיתרון שאני רוצה לספק למשתמשים שלי, ופיצר הוא פתרון ספציפי לאפיק.
תימות
המטרה של חלוקה לתימות (Themes) היא שאני כמנהל מוצר אוכל לוודא באיזה תחום אני נותן ערך למשתמשים שלי. אם יש לי אפליקציה שמנהלת נסיעות עסקיות ומאפשרת לי להזמין טיסות, מלונות ושכירת רכבים עבור עובדים בחברה אז יכולים להיות לי מספר תימות, למשל: חיסכון בכסף, חיסכון בזמן, ושיפור ניהול כוח אדם. אם אני כמנהל מוצר מגיע למסקנה שהדבר שהכי מפריע ללקוחות שלי הוא חיסכון בכסף אני יכול לתעדף כמה פתרונות מהתימה של חיסכון בכסף. על ידי ההתמקדות בתימה ספציפית ובחירת פיצרים ליישום מאותה התימה, אני יכול מאפשר לתת מענה לתחום ספציפי. אם אני לא מתמקד בתימה ספציפית אני יכול לתת חוויה כללית יותר מוצלחת במוצר שלי עם ידי זה שאקפיד לבחור פיצרים מכמה תימות שונות. הבחירה אם לבחור לפתח מנוע השוואות יותר חכם לקבל את ההצעה היותר טובה או לפתח מנגנון לשכפול הזמנות יושבת ממש על הנקודה הזו. מנוע השוואות חכם יותר יחסוך כסף, מנגנון שיכפול הזמנות יחסוך זמן למי שמתפעל את ההזמנות. מה יותר חשוב למשתמשים שלי?
אפיקים
אפיק (Epic) הוא לרוב בעיה שאני רוצה לפתור או פיתרון שאני רוצה לספק מבלי לציין את היכולת הספציפית. המטרה של החלוקה לאפיקים עבורי היא שאני לא אספק כמה פתרונות לאותה הבעיה. למשל אם יש לי אפיק של “לספק התראה למנהל על כל רכישת כרטיס טיסה”. אני יכול ליישם את האפיק הזה על ידי כמה פיצרים שונים: שליחת הודעת מייל, או שליחת הודעת SMS, או על ידי הקפצת התראה באפליקציה של המנהל. כל אלו הם פתרונות לגיטימיים להתראה על רכישה. אבל לפתח את כולם מייד כנראה יהיה לא יעיל כי זה יהיה הרבה עבודה בשביל לתת פתרונות שונים לאותה הבעיה. לכן אני אבחר אחד מהפיצרים הללו, כנראה על פי אחד מהמפתחות הבאים: את הפיצר שיפתור את הבעיה לכמה שיותר משתמשים, את זה שיהיה הכי קל ליישם, או את זה שנותן לי יתרון רוחבי כלשהו כי בניית מנגנון שליחת הודעות יכול לשמש ליותר מאשר רק התראות על רכישת כרטיסי טיסה. המטרה פה היא לוודא שאני לא מיישם כמה פתרונות שונים לאותה בעיה בטעות. או בקצרה, החלוקה הזו מאפשרת לי לראות את החלופות לפתרון שיש לי לבעיה ספציפית בכדי לקבל החלטה מודעת למה לבחור.
פיצ’ר
וזה מביא אותנו לפיצרים (Features) פיצר זה משהו שאנחנו באמת מיישמים. זה פתרון שפציפי לבעיה שיכול להירשם באפיון, להיות מפותח על ידי תוכניתן ולתת ערך למשתמש. המטרה של פיצר זה להיות יחידה קטנה מספיק בשביל שתעמוד בפני עצמה ושהאיפיון שלה יהיה ברור. אחת מהבעיות שנתקלתי בהן לעיתים קרובות היו שלפעמים יש לי אפיק מפלצתי שמוליד פיצר מפלצתי תחתיו שדורש המון פיתוח. במקרה כזה אני משתדל לפרק את הפיצר המפלצתי לכמה פיצרים קטנים שמשלימים אחד את השני לפתרון כולל. לפעמים על ידי חלוקה לוגית ולפעמים בשביל למקבל את העבודה בין כמה אנשי צוות. אולי חשוב לציין פה את המושג משימה (task), בניית פיצר יכולה להתחלק למספר משימות, אבל לפעמים גם על ידי חלוקה למספר פיצרים קטנים יותר. בעיקר אם חלק קטן יותר מהפיצר יהיה בשימוש על ידי פיצרים אחרים. אני לרוב מאפיין פיצרים עם user story אבל שימו לב שלפעמים ל-user story יכול להיות ממומש על ידי יותר מפיצר אחד, למשל שליחת תמונה בפלאפון לחבר יכולה להיעשות עם מספר אפליקציות שונות.
באופן כללי החלוקה הזו גם פותחת את הראש להבנה של קבלת החלטות ברמות שונות ועל ידי גורמים שונים. הנהלת החברה יכולה להחליט באיזה כיוונים החברה רוצה לשים דגש, שזה מתרגם להעדפה של תימות, שמתרגם לתיעדוף שונה על ידי מנהל המוצר.
מקווה שזה עשה לכם קצת סדר בראש.
אורי
תודה לאיתמר מושקין ולגלי זיסמן על ההערות בפייסבוק על הפוסט.
