הסבר קצר ופשוט על: Waterfall, Scrum, Agile ו-Product Owner

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

מאת עמית גולדברג

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

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

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

ואז נולדה האג׳ייל

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

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

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

מילכוד 22 של Product owner

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

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

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

מה ניתן לעשות

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

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

לקריאה נוספת: האם scrum הוא פתרון קסם לכל הבעיות?

הכותב הינו מנהל מוצר בחברת פלייטיקה

כתב אורח

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

הגב

5 Comments on "הסבר קצר ופשוט על: Waterfall, Scrum, Agile ו-Product Owner"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
מישהו שמבין
Guest

כתבה סופר מעניינת, מחכה לכתבות נוספות בנושא

רועי
Guest

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

מתכנת ותיק
Guest

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

רועי
Guest

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

Chen
Guest

מצוין

wpDiscuz

תגיות לכתבה: