הימים בהם מנהל המוצר היה יושב מבודד בחדר וכותב דרישות פסו מן העולם (אם כי לא בטוח שכולם יודעים את זה). במאמר זה אתאר את הדרך היותר נכונה מבחינתי לנהל מוצר כחלק מתפקיד חדש: בעל המוצר.
עוד על 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. אגב, קרה במקום מסוים שזיהינו את הבעייתיות שהשיווק לא ממשיך ללוות את מחזור החיים של המוצר, וביקשנו מהם להצטרף בנק' מסויימות. אבל זה מעט מידי ולא יעיל כשצעד כזה אינו מאוגד בתשתית תהליכית.
עוד על 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. אגב, קרה במקום מסוים שזיהינו את הבעייתיות שהשיווק לא ממשיך ללוות את מחזור החיים של המוצר, וביקשנו מהם להצטרף בנק' מסויימות. אבל זה מעט מידי ולא יעיל כשצעד כזה אינו מאוגד בתשתית תהליכית.
שלום
השבמחקממה שאתה אומר ה-PO צרך להיות בעל ידע טכני שידע לפרק דרישה לרכיבים, לאפיין וכו' (יכול להיות למשל מנהל פרויקט, ר"צ תוכנה, מנתח מערכות וכדומה, לפי אופי ומבנה הארגון והפרויקטים).
אם ארגון משתמש ב-PMO כדי לעזור בתכנוןובקרת הפרויקט (תכנון מול ביצוע, שימוש במעקב ת"ע ע"י MS project ועוד...) איך אפשר לשלב אותו בתהליך של Srcum כך שיוכל לסייע גם בתחום זה במעקב התקדמות משימות ובעצם לאחד את ניהול הפרויקט הרחב עם ניהול ומעקב של הסקראם? ...