XRAY for Jira: סוגי הדוחות השונים (בהיי לבל)

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

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

ראיון עם מנהל מוצר

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

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

המשפטים המודגשים הם השאלות ששאלתי, תחתן התשובות שקיבלתי.

מהו תפקידו של מנהל המוצר?

תפקידו של מנהל המוצר שונה בכל חברה. מ"רק" לכתוב דרישות ועד למה שנקרא (ואני לא אוהב את המונח) "ה-CEO של המוצר”. ישנן חברות בהן מנהל המוצר אחראי רק על חווית המשתמש, ויש חברות בהן הוא אחראי גם על הצד העסקי והרווחים.

בחברות מסוימות מנהל המוצר כותב PRDs עבי כרס, באחרות זה כתוב פחות פורמלי, למשל בג'ירה. בחברות הזנק לפעמים מוקאפים במצגת וישיבות מספיקים.

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

  

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

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

  

הממשקים של מנהל המוצר למשל ב-AVG הם עם:

1.      המחלקה המשפטית.

2.      שיווק.

3.      UX.

4.      Compliance, למשל האם המוצר שלנו תואם את הדרישות של מייקרוסופט.

5.      עבודה מול התמיכה הטכנית.

6.      מנהלי מוצר אחרים.

7.      מנהלי פרויקטים.

8.      פיתוח.

9.      QA.

10.   הנהלה (מצגות והרבה).

  

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

  

איך יודעים מה להכניס למוצר? איך לדייק בטעם של האנשים או בצורך שלהם?

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

ab tests עונים לנו על השאלה מה המשתמשים עושים, ו- Usability tests עונים לנו על השאלה למה משתמשים עושים משהו.

כדאי שהגרסה הראשונה תהיה MVP – minimal viable product כדי שכמה שיותר מהר נצא לשוק ונראה את תגובה המשתמשים.

  

תמיד יש סכנה ש-MVP יהיה דל מידי וייפול על זה

זה בדיוק ה-V ב-MVP. צריך שיהיה למשתמש ערך מהמוצר הראשוני.

הדפדפן החדש של מייקרוסופט, ה-Edge, האם הוא לא מקרה של מעט מידי ערך ולכן הוא לא מצליח?

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

אגב מוצר חדש, יש לך השערה איך בנוקיה ובמייקרוסופט לא הבינו ב-2007 את הפוטנציאל של ה-iPhone?

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

  

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

פרסומת עכשווית של אייפון. הפוקוס הוא על המשתמש

מהם המדדים של הצלחת המוצר?

יש לשים לב לשלשה דברים שיש להם השפעה על המוצר:

engagement, retention, monetization

engagement = כמה פעמים המשתמש משתמש במוצר

retention = כמה זמן מותקן המוצר אצל המשתמש

monetization = הרווח שהמוצר מפיק 

כאשר ה- retention ו/או ה- engagement עולים, לרוב זה משפיע גם על ההכנסות.

  

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

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

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

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

פורסם במקור ב-2016

עבודה עם הבקלוג

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

יש לבקלוג ארבע תכונות עיקריות:

It is detailed appropriately, estimated, emergent, and prioritized, making it DEEP.

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

יש להשקיע כ-10% מזמן העבודה של כולם לתחזוק הבקלוג. כולם שותפים בקביעת הפריטים ותוכנם.


למרבית ההפתעה, טכנולוגיה נוחה לניהול הבקלוג היא... פתקי נייר.

גילוי ותיאור פרטי הבקלוג
בשיטה זו, הנוהג אינו תיאור ארוך ומפורט לגבי כל פריט. במקום זה הפריט משתנה לכל אורך מחזור החיים שלו (כולל בזמן פיתוח).
גילוי הפריטים: מתחיל ביצירתם ע"י סיעור מוחות של צוות הסקראם ובעלי עניין (מומחים למשל ל-GUI וכד'). בעזרת חזון המוצר וה-road map. יש להתפקסס על מינימום פונקציונליות.
במשך הזמן הבקלוג יגדל בהתאם לדרישות הלקוחות. יש להשאיר את חזון המוצר כמדריך בחירה ולהמשיך בבחינה מדוקדקת ומינימליסטית של פריטים.
אחרי מילוי ראשוני יש הזדמנויות רבות להמשיך ולמלא אותו. כל פריט חדש שנכנס גם אם מהלקוח חייב review רציני.
תיאור הפריטים: אפשרות אחת היא user stories, כלומר על שימוש במוצר. יש בזה שם, תיאור קצר, ותנאים שמילואם הכרחי בכדי שהסיפור יתקיים. סיפורים בסיסיים כאלה נקראים epics. בנוסף יכולים להיות סקיצות ופרוטוטייפים.

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

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

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

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

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

פירוק פריטים: כלומר הקטנתם עד שיתאימו לספרינט. נקרא גם: progressive requirements decomposition. ייתכן שבמקרה של פיצ'ר גדול נצטרך כמה ספרינטים עד שתתי-הפריט יהיו בגודל מתאים.

אם יש תכונות מורכבות מידי אפשר לפרק את הפיתוח לכמה ספרינטים. במקרה של אי-ודאות ניתן להכניס פריט לבקלוג כמו: לחקור נושא כזה-וכזה. את סיפור המשתמש ניתן לפתל לתת-סיפורים עם מטרות משלהם וזמני דליברי שונים. נקרא: slicing the cake.

נתינת זמנים לפריטים עוזרת בקביעת הפריוריטיזציה שלהם ובחיזוי זמני הפרויקט.
יש שני סוגי הערכות זמנים: coarse-grained, כלומר היי לבל, ו- fine-grained.

הערכה coarse-grained, יכולה להימדד ע"י story points. כאן הציון הוא יחסי ותלוי בקבוצה הנותנת אותו (קבוצה גדולה או עם אנשים מרובי יכולות מול ההיפך). הציונים כאן אינם לינארים ויכולים להיות משהו כמו:
0, 1, 2, 3, 5, 8, 13, 20. זה אינו לינארי כיוון שזה חוסך ויכוחים על נקודה לכאן ולשם. כל אחד מחברי הצוות נותן נקודות אחרי הסבר קצר של בעל המוצר. אם יש הפרשים, אלו הקיצוניים לכל צד יסבירו את דעתם.

להשיג הערכת זמנים טובה יש למלא שלש דרישות:

1. הבנה טכנית של התכונה.
2. הבנה של תלויות.
3. הבנה כללית של הצוות לגבי התכונה.

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

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

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

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

---------

האמור למעלה הינו סיכום של הפרק השלישי בספר Agile Product Management with Scrum. שוב, הכל פשטני, טוב כהקדמה.
בנוסף, אני כותב את זה יותר בשבילי, לכן זה מוצג כנקודות, לא ממש כניסיון לתת תקציר.

החזון של המוצר

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

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

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

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

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

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

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

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

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

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


ה-Road map
כל הנאמר למעלה קשור למוצר חדש. במוצר קיים החזור הוא בעצם ה-Road map. זהו מכשיר המראה את התפתחות המוצר לאורך הגרסאות. מומלץ להשאיר את ה-Road map פשוט ומפוקס בעיקר. עליו לכלול תאריכי יעד, קהל היעד וצרכיו, ואת 3-5 הפיצ'רים המובילים. הפרטים יוכנסו אח"כ בבקלוג. יש לזכור שה-Road map לא מחליף סקר שוק רציני. זה רק כולל את המקום אותו המוצר אמור לתפוס כפי שאנו רואים את המצב כעת.
מסמך ה-Road map הינו מסמך חי שיש לעדכן.
את מסמך ה-Road map יש לכתוב רק אחרי הצלחת הגרסה הראשונה שיוצאת לשוק. כמו תמיד יש לערב בו את צוות הסקראם. הוא אמור לראות חצי שנה עד שנה קדימה.

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

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

----

האמור למעלה הינו פחות-או-יותר סיכום של הפרק השני בספר Agile Product Management with Scrum.
הספר הזה מנסה להיות כמו מה שנאמר על המוצר: פשוט, ברור ולא מסובך. כמובן שבחיים הדברים לא כאלה פשוטים, ולכן יש לראות בו ספר מבוא למוצר בסביבת  ה-Scrum המתאים ככניסה לבעלי מוצר או סיפוק ידע כללי לשאר חברי הצוות.
נקודתית, לגבי שתי (או יותר) גרסאות למוצר, ישנה גישה לטעמי מוצלחת לא פחות ולעיתים יותר, והיא זו של מייקרוסופט. קחו למשל את "אופיס". מאוד קל לכתוב מסמך בוורד, לשמור ולהדפיס. אבל אפשר לליצור טפסים, עיצובים וכד'. זה עוד יותר מוחשי באקסל. "אופיס" זה סט מוצרים קלים להפעלה אבל יכולים להגיע למצבים מורכבים הרבה יותר גם למשתמשים המקצועיים.
לגבי מודל קאנו ותכונות חשובות ופחות חשובות. מצדו של הלקוח, הוא אינו מעוניין בתכונות של המוצר, אלא בתועלות. התועלות עשויות להיות  עינוגיות, אבל גם סמל סטטוס הוא תועלת, או רצון שיהיה לך את מה שיש לכולם וכד'.

תפקיד בעל המוצר (מנהל המוצר) בסביבת סקראם

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

עוד על Scrum ו-Agile

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

אחריות ה-PO: כשמפריטים את זה מקבלים שתפקידו של ה-PO הוא:
לפתח את החזון של המוצר,
לפרק לדרישות ל-backlog,
לתכנן את ה-release,
לעבוד מול הלקוח ומול המשתמשים,
לנהל את התקציב,
להכין את ההשקה,
להיות מעורב בישיבות ה-Scrum,
לשתף פעולה עם גורמים בארגון.

כלומר לא רק אחריות על המוצר אלא גם על מחזור החיים שלו.

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

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

העבודה מול ה-SCRUMMASTER (להלן SM): באחריותו של ה-SM לוודא שכל התהליך נעשה בצורה הנכונה. אם ה-PO עונה לשאלה "מה", ה-SM עונה לשאלה "אייך": איך תתנהל העבודה בצורה הטובה ביותר בהתאמה ל-Scrum.

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

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

בפרוייקטים גדולים בהם יש יותר משתי קבוצות מומלץ לצרף עוד PO - אחד או יותר, כאשר אחד הוא ה-Chief product owner והוא אחראי על שאר ה-PO ועל החזון של המוצר.

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

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

לסיכום:
בכתיבת המאמר נעזרתי בספר Agile Product Management with Scrum. אני חולק עליו בדבר אחד: אני לא חושב שיש הרבה אנשים שיכולים למלא את מלא התפקידים הכתובים מעלה שבעל המוצר אמור למלא. קשה למשל למצוא מישהו שמצד אחד יהיה טכני מספיק בכדי לכתוב דרישות טכניות ברמה של מפתח, אך מצד שני יכיר את השימוש שעושים הלקוחות במוצר, ומצד שלישי יהיה בעל כישורי מנהל פרוייקטים ועוד. ואני אומר את זה כאחד שעבד עם אנשים מוכשרים ביותר. בפועל, אני מאמין ש-כן, בעל המוצר זהו תפקיד לא פשוט אבל אפשרי לאיוש, אך יש לסייע לו ע"פ אופיו ואופי החברה. למשל סיוע של מפתח בגזירת המוצר לדרישות טכניות, או של "גורו" שיכול לרמוז לאן השוק מתפתח. מעבר לזאת - אני בהחלט חושב ש-Scrum הינו תהליך טוב יותא מאשר מודל ה-waterfall. אגב, קרה במקום מסוים שזיהינו את הבעייתיות שהשיווק לא ממשיך ללוות את מחזור החיים של המוצר, וביקשנו מהם להצטרף בנק' מסויימות. אבל זה מעט מידי ולא יעיל כשצעד כזה אינו מאוגד בתשתית תהליכית.