Posts tagged ‘Product owner’

כל אחד הוא מיוחד

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

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

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

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

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

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

חבל על הזמן…

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

יום שני 11:00 – ישיבת הנהלה הכירה:
המנכ”ל גדי מברך את כולם ביום טוב וסוקר את הפעילויות הצפויות לחברה בעתיד הקרוב, לקוחות פוטנציאלים ועוד מספר עניינים אדמיניסטרטיביים, גדי מזכיר לכולם שהחברה החליטה לעבור לגישות אג’יליות ורזות יותר, “השינויים שאנחנו עושים הם חשובים, הם נוגעים לחלקכם, ויש להקדיש זמן ליועץ שהבאנו ולהתייחס בכובד ראש לדברים” הוא אומר, “מסכנים הפיתוח“ אומרת דליה סמנכלית השיווק, גדי מחייך.
אחד כך עובר גדי לסבב הרגיל של דיווחי סטטוס:
image– שירה, סמנכ”לית פיתוח, מסתכלת על גדי ומספרת על מצב הפרויקטים, הבעיות, ואף מציינת שכבר שני צוותים עברו לפיתוח “בשיטת סקראם” שזה הטרנד החם כרגע בעולם תהליכי פיתוח התוכנה האג’ילים, “יופי, איך הולך?” שאל גדי, “אנחנו מנסים את זה, גם דיברנו עם היועץ שיעזור לנו, אני מאמינה שזה יכול לקצר משמעותית זמני פיתוח ולהגביר את האיכות”, מעולה! אומר גדי תעדכני אותי כשיהיו מסקנות.
– אחרי שירה דיבר יניב, סמנכ”ל HR, הוא סיפר לכולם שעקב חוסר תקציב אין יום כיף השנה, וגם כנראה לא יהיו בונוסים. בנוסף הוא הזכיר שיש למלא את הערכות העובדים עד סוף השבוע ולקבוע יעדים אישיים חדשים לשנה הבאה, “ולא לשכוח לנרמל את התוצאות ברמת הצוות, והמחלקה”, כולם מהנהנים.
– לבסוף מדבר אורן, סמנכ”ל תפעול, הוא טוען שהוא גילה לאחרונה שלקוחות יוצרים קשר עם אנשי פיתוח ולהיפך “זו תופעה חמורה ואנחנו חייבים לנתק את הקשר הזה”, כולם מהנהנים בהסכמה.
– דליה סמנכ”לית שיווק, מעלה בתורה את הבעיה שאנו לא עומדים בזמנים שהבטחנו ללקוח, ומעבר לכך יש לנו בעיה קשה עם לקוח X, יש כרגע מספר בעיות קריטיות וחייבים לפתור לו את הבעיות, ומהר. גדי (המנכ”ל) מסתכל על שירה, שירה אומרת שהם עושים את המקסימום והמפתחים כבר באו 3 סופי שבוע אחרונים בכדי לנסות להדביק את הפער, “והשבוע עוד מפתח עוזב, באמת שאנחנו עושים את המקסימום.”, “את צריכה לשמור על האנשי שלך יותר טוב” אומר גדי בחצי חיוך חצי רצינות. “אני מאמינה שעד סוף הגירסה נצליח להשלים את הפער” אומרת שירה. השיחה ממשיכה עוד קצת ואז תם הזמן לישיבה.
– “טוב, שבוע טוב לכולם” אומר גדי. שבוע טוב, הם עונים לו.

בואו ננתח קצת את הסיפור:
כרגע (וזה עלול להשתנות) אני לא רואה סיכוי רב לחברה הזאת להצליח לאמץ באמת תפיסה אג’ילית ורזה יותר, ניתן “להריח” יותר מידי דברים שמונעים מהם להצליח.
המנכ”ל:
גדי לא ממש מעורב, או לא מבין את המשמעות.
הוא מדבר על החשיבות אבל לא מדבר על מעשים. הייתי ממליץ למנכ”ל שלפחות ילמד לזהות בעיות ברמת הארגון (נתייחס בהמשך) וימנע מהם לקרות או יפעל לשינוי.
עצם חוסר ההתערבות מעביר תחושה לאנשים שהוא רק מפקח ומצפה לתוצאות.
לאורך כל הישיבה המנכ”ל מגלה חוסר הבנה בסיסי בנוגע למשמעויות, הוא אפילו לא יודע מה זה סקראם! (Scrum).אני לא טוען שעל המנכ”ל להכיר כל פרט ופרט, אבל כן להכיר את העקרונות והרעיונות העיקריים.

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

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

שיווק (או הצד העסקי):
לפי איך שהדברים שנאמרו, עושה רושם שאין יחסים טובים בין השיווק לפיתוח, דליה אפילו לא פונה אל שירה, היא מדברת אליה דרך המנכ”ל (והוא – משתף פעולה!)
גם היא כמו שירה, לא מחפשת פתרונות אחרים או מציעה עזרה לפתרון הבעיה אלא משליכה אותה על ה-R&D (מי אמר “לשבור את הקיר”)
כמו כן דליה לא רואה עצמה כחלק מהשינוי בכלל, לדעתה הוא לא נוגע לה.

סיכום:
עד שלא יפתרו לפחות חלק מהבעיות הללו, לדעתי: “חבל על הזמן…” אל תנסו אפילו לאמץ תפיסה אג’ילית יותר, היא תעלה לכם זמן וכסף, ובתמורה היא בעיקר תפריע לכם ולא תוסיף ערך רב.

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

נ.ב.
אחרי שקראתי את הפוסט הבנתי שעקב ריבוי הדמויות והמידע (יחסית לרמת הפירוט) אפשר לפרש את הישיבה בכל מיני צורות וצבעים, כוונתי היתה הפשט, בבקשה אל תניחו הנחות אלא התבססו על העובדות.
ואולי אכתוב עוד אחד כזה על ישיבת R&D…. אולי.

אלמנטים של סקראם… מיון רשימת הדרישות (Product backlog) – חלק ראשון

אחד הגורמים שמשפיעים על הצלחתם של פרויקטים בכלל, ופרויקט תוכנה בפרט הוא ההחזר על ההשקעה (ROI – Return on investment), סקראם (Scrum) מתייחס בכובד ראש לעניין זה ולכן טוען שעל רשימת הדרישות להיות מסודרת בצורה כזו, שבראש הרשימה נמצאים האלמנטים בעלי הערך הגדול ביותר. כמובן שיש יוצאי דופן כגון פריטים שמהווים בסיס לפיתוחם של אחרים, אבל באופן כללי אנו שואפים למזער תלויות. בהינתן שהפריטים ברשימה מסודרים “נכון”, ואנו מפתחים את התוכנה לפי הסדר של הפריטים ב-backlog, אנו למעשה מגדילים משמעותית את הסיכוי להצלחתו של הפרויקט מבחינת ה-ROI.

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

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

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

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

clip_image004מרגש –Exciter – אלה הם מאפיינים של מוצר שהלקוח אפילו לא ידע שהוא רוצה עד שהוא ראה אותם, דוגמא למאפיין כזה הוא למשל שלט שפותח את דלתות המכונית, וכן, בד”כ מאפיינים מסוג זה לא נשארים כאלה לאורך זמן.
חובה–
Mandatory– מאפיינים שבלעדיהם אין זכות קיום למוצר, דוגמא למאפיין כזה היא למשל האפשרות לשמור קבצים במעבד תמלילים.
לינארי – Linear – ניתן לאפיין את הסוג הזה בעזרת המשפט “כל המרבה, הרי זה משובח”, ככל שיש יותר כאלה, כך שביעות הרצון של הלקוח עולה. דוגמא למאפיין כזה היא למשל כמות הזיכרונות במכשיר סלולארי.
מפוקפק – Questionable – כזה שלא מספיק ברור לגביו מה הסיווג.
הפוך – Reverse – כזה שברור שהלקוח לא רוצה.
משהו – Indifferent – משהו שלא משנה ולא במעט את שביעות הרצון של הלקוח.

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

לתשובות לשאלות, קאנו מציע פורמט טקסטואלי לתשובות, וטבלה שעבור כל זוג תשובות, מספקת סיווג (האות בטבלה מסומנת באדום בהגדרת הסיווג שמעל):
– מאוד מוצא חן בעיני.
Kano table– אני מצפה לכך.
– אני ניטרלי.
– לא מאוד מפריע לי.
– מפריע לי.
אז מה עושים אחרי שסיווגנו ? אין המלצה חד משמעית, ברור שכל מה שסווג כ-M חייב להיות במוצר, גם ברור שיש צורך בלפחות חלק מה-L, וכדאי מאוד שגם תשאירו מקום ל-E. בשלב הזה לצערי תאלצו להפעיל את הראש קצת מעבר למודל, כאן נכנסים שיקולים נוספים כגון יעדי הפרויקט, מצב השוק וכדומה.
המודל של קאנו מספק לכם יותר מידע לגבי הפריטים, ואולי גם חלוקה גסה, אבל הוא לא מספק פתרון מלא ומשאיר מקום לשיקול דעת ומחשבה, וטוב שכך.

עוד מודלים בפוסט הבא.

אלמנטים של סקראם…מה זה DONE ?

תזכורת: בפרויקט אג’יל’י (בפרט סקראם) מצפים מהצוות שיהיה מסוגל להציג בכל סוף איטרציה (ספרינט) מוצר בעל ערך ללקוח, או בהגדרה הפורמאלית מוצר פוטנציאלית מוכן (potentially shippable product).
אחת הסיבות הנפוצות לכישלונם של פרויקטים אג’ילים היא אי יכולת לספק ערך בסוף כל איטרציה. הצוות אכן מציג בסוף כל ספרינט את המוצר, אפילו עם פיתוחים חדשים, אבל…. המוצר איננו פוטנציאלית מוכן – המוצר רק חצי בדוק, רק חצי מתועד – רק חצי מוכן.

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

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

בואו נתבונן רגע בהגדרת DONE:

  • הקוד גמור
  • בדיקות גמורות
  • הפיצ’ר אושר ע”י מנהל המוצר.

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

  • הקוד גמור
  • נכתבו Unit tests והם רצים בהצלחה.
  • נכתבו Integration tests והם רצים בהצלחה.
  • הבדיקות התווספו לתשתית האוטומציה.
  • הפיצ’ר תועד (לפי הצורך).

מה אתם אומרים עכשיו? בודאי שההגדרה הזאת טובה יותר ומחדדת את ההגדרה אבל עדיין… זה לא זה. ניקח למשל את הסעיף של הבדיקות Unit tests. האם מובטח שהבדיקות מקיפות ומספיקות. אז שוב, גם ההגדרה הזאת איננה מבטיחה מוצר פוטנציאלית מוכן.
אין לי כוונה לסקור כעת טכניקות להגדרת ה-DONE (פוסט אחר), אבל הנקודה שרציתי להעביר היא שהאיכות של הגדרת ה-DONE הינה גורם קריטי להצלחת הפרויקט.

את הגדרת ה-DONE קובעים ביחד ובהסכמה מנהל המוצר והצוות, ובד”כ ההגדרה משתנה עם הזמן ובהתאם למה שהצוות מסוגל לספק, אבל אמרנו שמוצר פוטנציאלית מוכן הוא מוצר ש-100% מהפיצ’רים שלו הם DONE, אז מה קורה כשההגדרה משתנה, ובפרט מתרחבת? אז נוצר מצב שבו כל הפיצ’רים שפותחו עד כה הם לא DONE. נכון. במצב כזה על הצוות להביא את הפיצ’רים הללו למצב DONE.

האדם שאחראי להחליט האם המוצר או הפיצ’ר הוא DONE הוא מנהל המוצר, הוא אחראי לוודא שהצוות אכן עומד בקריטריונים המתבקשים, זה קורה בישיבת סוף הספרינט – Sprint review.

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

נ.ב. – התוספת של התמונות לפוסטים מפריעה? מוסיפה? לא משנה? – אנא תגובתכם.

זהו – אני סיימתי – …I am DONE

 

*מקור התמונה : http://www.flickr.com/photos/hawaii-mcgraths/2701705139/lightbox/

אלמנטים של סקראם והפעם… Scrum master.

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

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

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

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

ללמד ולשתף את הצוות במהותה של השיטה (סקראם).
לקבוע ולהנחות את ישיבת הצוות היומית (Daily).
לקבוע ולהנחות את ישיבת תכנון הספרינט (Sprint planning)
לקבוע ולהנחות את ישיבת הצגת תכולת הספרינט (Sprint review)
לקבוע ולהנחות את ישיבת הרטרוספקטיבה (Retrospective)
לדאוג לכך שלא יפריעו לצוות לעבוד במהלך הספרינט.
לעזור לצוות להסיר מכשולים לביצוע ההתחייבויות.
– לתת לצוות כלים לעבודה נכונה בסביבה “סקראמית”.


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

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

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

נ.ב. – כן, זה בכוונה שהתייחסתי לסקראם מסטר בלשון נקבה, אני פשוט חושב שנדרשת אפליה מתקנת לנשים בתחום שלנו (את הרעיון לקחתי מ- Mike Cohnאשר בספריו בנושא מתייחס ל-Product owner בלשון נקבה)

dir="ltr"

אלמנטים של סקראם והפעם… Product owner.

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

לתפיסתי והבנתי ל-product owner יש חמישה תפקידים עיקריים:

  • מיון ועדכון ה-product backlog – , כפי שכבר ציינתי ה-product backlog מעודכן באופן תדיר ורצוף ע”י גורמים שונים כגון, הלקוח, ה-product owner, הצוות וכו’.
    בסקראם אין שום מגבלה על הוספת פריטים לרשימה, אך היחיד שמותר לו למיין את הרשימה ולהחליט מה בעדיפות גבוהה הוא ה-product owner. מכך ניתן להסיק למעשה שעל כתפיו של ה-product owner מונחת אחריות כבדה, עליו “לנווט את הפרויקט במים סוערים” ולדאוג שהכיוון שאליו אנו מפליגים הוא אכן בעל הערך הרב ביותר עבור הלקוח, מכך נובע שהתפקיד דורש הבנה אמיתית של צרכי הלקוח ואף רצוי מאוד קשר רציף ואיכותי עם הלקוח עצמו ע”מ לוודא באופן קבוע שמה שאנחנו עושים מספק ערך ללקוח.
    יש להדגיש, ה-product owner איננו נחשב חלק מהפיתוח, ואין לו שום סמכות מקצועית לגבי ה”איך” וה”כמה” אלא רק לגבי ה”מה”, שם יש לו מנדט מלא לקבלת החלטות, גם בניגוד לדעתם של צוותי הפיתוח.
  • שומר השער של המוצר – כפי שכבר הזכרתי בעבר, כאשר מסתיים ספרינט והצוות מציג את הפריטים שהם סיימו מתוך הרשימה, על ה-product owner (והלקוח אם הוא שם) להחליט אם הפריט בוצע לשביעות רצונם של המעורבים – בסקראם למצב של שביעות רצון קוראים DONE, כאשר מסכמים על פיתוח פריט נקבעים בין הצוות ל-product owner גם הקריטריונים לשביעות רצונם של המעורבים. כאשר הצוות מציג את הפריט בסוף איטרציה (ספרינט), על ה-product owner להחליט האם הפיתוח עומד בקריטריונים הללו או לא.
  • להיות הקול של הלקוח עבוד צוות הפיתוח – כדי להגדיל את הסיכויים להצלחת הפרויקט (סיפוק רצונו של הלקוח) חשוב לקיים קשר רציף בין הפיתוח ללקוח. כאשר צוות הפיתוח זקוק להבהרות לגבי דרישות אלא ואחרות, הוא פונה ל-product owner, הוא אמור לספק את התשובות הרלוונטיות תוך ייצוג תפיסת עולמו של הלקוח. על ה-product owner מוטלת החובה והאחריות לוודא שהצוות עומד בסטנדרטים גבוהים של איכות, למשל עליו להתעקש על כיסוי בדיקות גבוה (לפחות 70%), על שקיפות של הפיתוח ועוד, אך עליו לשים לב לא להציב מטרות בלתי אפשריות ובכך להביא למצב שתפוקת הצוות תרד משמעותית.
  • השתתפות בתכנון ספרינט – בתחילתו של כל ספרינט יושב ה-product owner ביחד עם הצוות ומסביר לפי הצורך על הפריטים שנמצאים בראש ה-product backlog, הצוות אז בוחר על כמה מתוך הפריטים בראש הרשימה הוא יכול להתחייב ויוצא לדרך.
    למה אני מציין את זה כתפקיד? זו סה”כ ישיבה, לא? לא!
    ישיבת תכנון הספרינט היא ישיבה חשובה ארוכה וקשה, ויש נטייה למשל להגיע לא מוכן לישיבה, ה-product backlog לא מעודכן, או שה-product owner לא מבין את הפריטים ברמה מספיקה כדי לספק תשובות לצוות. תפקידו של ה-product owner להשתתף בישיבה ולמלא את חלקו, לא מספיק להיות שם, הצלחת הישיבה היא רכיב קריטי להצלחת הספרינט.
  • לא להפריע – תפקיד חשוב שיש ל-product owner הוא לא להפריע לצוות, אני יודע שזה אולי נשמע טריוויאלי אבל זה לא, ממרום מושבו ה-product owner עלול לחוש סמכות על הצוות ואף עלול להרשות לעצמו להציק להם מהלך הספרינט, להציע הצעות טכניות, לבדוק, לשאול, ולעיתים רחוקות אף נתקלתי בכאלה שמבקשים לשנות את התכולה של הספרינט. ובכן, לא מקובל! ה-product owner מקבל התחייבות מהצוות בתחילת כל ספרינט לתכולה מסוימת, בתמורה הוא מתחייב לא להפריע להם במהלך הספרינט. אני לא אומר הפרדת רשויות, אך עליו לכבד את הפיתוח ואת הזמן שלהם – נושא בעייתי בפיתוח גם ככה.

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

יש לכם רעיון איך אומרים product owner בעברית ? תגיבו.