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

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

עוד על 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. אגב, קרה במקום מסוים שזיהינו את הבעייתיות שהשיווק לא ממשיך ללוות את מחזור החיים של המוצר, וביקשנו מהם להצטרף בנק' מסויימות. אבל זה מעט מידי ולא יעיל כשצעד כזה אינו מאוגד בתשתית תהליכית.

ערכים בארגון

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

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