מה למנהלי מוצר ולאג'יל, לניהול ספרינטים ולג'ירה?

אנחנו כבר מכירים, אז אני מעדיף להתחיל ישר ולעניין (אל תכעסו אלי):

• זאת לא עבודה של מנהלי מוצר לנהל ספרינטים.

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

• ג'ירה היא באמת הכלי הרווח, יחד עם זאת ניתן לנהל מוצר גם בכל כלי אחר.

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

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

באילו משימות מנהלי מוצר צריכים להתפקס?

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

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

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

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

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

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

---

אז למה מנהלי מוצר כל כך עסוקים בג'ירה ספרינטים ואג'יל?

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

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

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

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

אז איפה עובר הגבול?

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

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

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

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

---

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

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

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

ממה מורכבת ג'ירה ומה כדאי לנו להכיר?

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

2. מסך ה Backlog - הוא רשימת כל ה Issues בפרויקט, הוא משמש כ"מחסן" לכל ה Epics, Stories, Tasks, Bugs וכו'.הבקלוג בג'ירה מאפשר גרירה של יישויות כך שבכל שלב ניתן לסדר אותם מה 1 עד N לפי סדר חשיבות יחסי לאחרים.לכל פרויקט יש רק Backlog אחד והוא יכול לכלול יישויות ממוצרים שונים, עבור צוותים מרובים. תחשבו שבקלוג הוא תור ולו יש רק מפתח אחד פנוי לבצע רק משימה אחת - מה תהיה המשימה הבאה שעליו לקחת.הבקלוג מציג רק משימות שטרם הסתיימו. במידה ויש צורך לנתח משימות שכבר הסתיימו, ניתן לעבור ל Issue Navigator שם יוצגו כל סוגי הישויות בכל סוגי הסטטוסים.

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

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

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

4. ניהול ספרינט - מה לא נאמר עליו כבר ולפעמים זה מרגיש שכל האחריות עליו.ננסה לעשות את זה פשוט, ספרינט הוא אינטרוול זמן קבוע ומחזורי, כ 99% מהחברות שהכרתי מגדירות ספרינט בין שבוע לשלושה שבועות, כשרובן מגדירות אותו כשבועיים. כך לדוגמא אם שבוע העבודה מתחיל ביום ראשון הספרינט יסתיים בשבת בעוד שבועיים שהם 14 ימים ברוטו ובערך 10 ימי עבודה נטו.

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

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

5. ניהול Issue - (יישות) הם כלל משימות העבודה והניהול: אפיקים, סטוריז, באגים, טאסקים וסאב טאסקים.

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

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

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

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

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

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

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

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

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

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

---

לסיכום:

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

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

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

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

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

לכל צוות פיתוח ומוצר יש איך להשתפר,

צרו קשר, בואו נפגש - אפשר לעשות פלאים בלי שינויים דרסתיים :-)