עבודה עם הבקלוג

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

יש לבקלוג ארבע תכונות עיקריות:

It is detailed appropriately, estimated, emergent, and prioritized, making it DEEP.

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

יש להשקיע כ-10% מזמן העבודה של כולם לתחזוק הבקלוג. כולם שותפים בקביעת הפריטים ותוכנם.


למרבית ההפתעה, טכנולוגיה נוחה לניהול הבקלוג היא... פתקי נייר.

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

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

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

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

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

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

פירוק פריטים: כלומר הקטנתם עד שיתאימו לספרינט. נקרא גם: progressive requirements decomposition. ייתכן שבמקרה של פיצ'ר גדול נצטרך כמה ספרינטים עד שתתי-הפריט יהיו בגודל מתאים.

אם יש תכונות מורכבות מידי אפשר לפרק את הפיתוח לכמה ספרינטים. במקרה של אי-ודאות ניתן להכניס פריט לבקלוג כמו: לחקור נושא כזה-וכזה. את סיפור המשתמש ניתן לפתל לתת-סיפורים עם מטרות משלהם וזמני דליברי שונים. נקרא: slicing the cake.

נתינת זמנים לפריטים עוזרת בקביעת הפריוריטיזציה שלהם ובחיזוי זמני הפרויקט.
יש שני סוגי הערכות זמנים: coarse-grained, כלומר היי לבל, ו- fine-grained.

הערכה coarse-grained, יכולה להימדד ע"י story points. כאן הציון הוא יחסי ותלוי בקבוצה הנותנת אותו (קבוצה גדולה או עם אנשים מרובי יכולות מול ההיפך). הציונים כאן אינם לינארים ויכולים להיות משהו כמו:
0, 1, 2, 3, 5, 8, 13, 20. זה אינו לינארי כיוון שזה חוסך ויכוחים על נקודה לכאן ולשם. כל אחד מחברי הצוות נותן נקודות אחרי הסבר קצר של בעל המוצר. אם יש הפרשים, אלו הקיצוניים לכל צד יסבירו את דעתם.

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

1. הבנה טכנית של התכונה.
2. הבנה של תלויות.
3. הבנה כללית של הצוות לגבי התכונה.

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

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

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

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

---------

האמור למעלה הינו סיכום של הפרק השלישי בספר Agile Product Management with Scrum. שוב, הכל פשטני, טוב כהקדמה.
בנוסף, אני כותב את זה יותר בשבילי, לכן זה מוצג כנקודות, לא ממש כניסיון לתת תקציר.

החזון של המוצר

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

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

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

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

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

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

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

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

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

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


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

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

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

----

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