מלחמת העולמות, מלחמת מנועי החיפוש

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

הנה כמה פרטים מעניינים על מלחמת העולמות:
המונח החשוב כאן הוא נקודות הגישה לחיפוש, SAP - Search Access Points.
יש כמה כאלה:
DSP שזה Default Search Provider. זה המנוע שמביא את הפרסומות, סליחה את התוצאות בעמוד תוצאות החיפוש - Search Engine Results Page.
באקספלורר 7 ו-8 יש את הקופסה בצד ימין למעלה ובאקספלורר 7, 8 ו-9 זה שולט על תוצאות החיפוש שבאות מתוך ה-address bar (או בשם אחר: שדה ה-URL).

בכל הפיירפוקסים ה-DSP הוא בקופסה הממוקמת בערך באותו מקום כמו האקספלורר, אבל ה-Address bar אינו ה-DSP אלא פרמטר פנימי של הפיירפוקס: Keyword.url.

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

New Tab: ברור שמי ששולט בו בד"כ יוסיף לו שדה חיפוש לקישוט.

Home Page: כמו שרבים שמים את גוגל כעמוד הבית גם אחרים רוצים.

כמובן שגם בכל סרגל כלים יש שדה חיפוש.

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

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

אילו מערכות הפעלה ודפדפנים חובה לבדוק (ואילו פחות)

ברור שלכל אחד שיקול משלו, למשל באפליקציות שרת יש לשים לב למערכות הפעלה מותאמות שרת כגון windows server 2008. אבל ברגיל בשרת לא משתמשים בקליינטים נפוצים כמו של תחנות עבודה, למשל ב-Office.

אני מכוון כאן למי שתחנות העבודה הם קהל היעד שלו. גם כאן עדיף לבדוק הכל ברמת הסביר:
XP, Vista,Win7, Win8 וכל אחד גם 32 ביט וגם 64 ביט. אם אין זמן יש לבדוק:
- XP x86 כי אין הרבה XP עם 64 ביט.
- Vista x86 גם כאן אין כמות נפוצה של 64 ביט ובכל אופן יש דמיון בין ה-Vista ל-Win7 ולבדוק את שתיהן זו כפילות מסויימת.
- Win7 x64, Win8x64 כי כאן יש יותר 64 מהקודמות.

דפדפנים:
שוב, תלוי באפליקציה וכד'. אבל אם היא בנויה מדפי HTML 4 "רגילים" (למשל ללא פלאש וכד'):

Internet Explorer:
כולם, כולל 6 (כן, עוד ישנם כאלה) בעיקר בסביבת ה-Java Script. יש לשים לב ש-IE 10 כבר מאוד דומיננטי.

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

Chrome:
האחרון ובטא.

בניית עץ בדיקות

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

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

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

ביקורת מוצר: KeyNote

המוצר - או נכון יותר השירות - הזה, הkeynote (http://www.keynote.com/), מיועד בעצם למי שאחראי על אתר וחשוב לו שהאתר יהיה זמין 24X7, יעלה במהירות סבירה ומכל העולם.

יש שני שלבים עיקריים בתפעולו:

1.      מורידים תכנה בשם KITE (http://kite.keynote.com/).

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

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

עד כאן בחינם.

השירות המלא כולל בתוכו את הדברים האלה:

רשימה ארוכה של מיקומים מהם ניתן לבדוק וכן רשימה של ISP.

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

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

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

דוגמא לדוח. אפשר לבחור בנקודה ולקבל מידע רלוונטי.

חסרונות:

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

ב.      ה-alarms לא מגיעים ב-S.M.S. וגם היום זהו חסרון.

ג.       המחיר. למשל לחודש של בדיקה של עשרה עמודים פעם בשעה מחמישה מקומות (2 ארה"ב, 2 אירופה ואחד המזרח הרחוק) משלמים 431$. ברור שזה לא מספק כי אתה רוצה לדעת בזמן אמת שיש בעייה בשירות, ואולי ליותר דפים. למשל ל-20 דפים כל 5 דקות אפשר לעבור את ה-3k וזה בלירות שטרלינג.

ד.      אין תמחור אחיד – צריך לדבר עם אנשי מכירות.

סיכום:

לא בדקתי מתחרים וכד'. דבר אחד ברור – זה לא כלי שמיועד לדיווח בזמן אמת אם יש בעייה באתר אבל יעיל לדעת איך מתנהג האתר שלך כשאתה לא מסתכל.

האסקלציסטים*

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

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

כישורים: קרוב למנהל בכיר כזה או אחר / שוכב עם המנהל הנ"ל / חבר של מנהל הנ"ל.

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

הבנת המוצר: רמת הסיסמאות.

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

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

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

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

בארגון מסודר היו מתעלמים מהאסקליסט (אבל לא מהבעיות). בארגון עוד יותר מסודר לא היו אסקליסטים, אבל זה לא קורה.

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

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

איך מנטרלים את האסקליסט?

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

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

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

העבודה מול חברות off-shore בהודו - לא פתרון קסם

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מעקרונות קבוצת אג'ייל: פשטות

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

מעקרונות קבוצת אג'ייל: תקשורת ומידע

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

מעקרונות קבוצת אג'ייל: לספק ללקוח בדיוק את מה שהוא צריך

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

מעקרונות קבוצת אג'ייל: פידבק מתמשך

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

מעקרונות קבוצת אג'ייל: אין תפקיד ספציפי של QA

אין בקבוצה תפקיד של Quality Assurance, רק של בודק, כמו שאין תפקיד של מפתח, אלא של מתכנת. תפקיד כל הקבוצה לפתח, תפקיד כל הקבוצה לדאוג לאיכות המוצר (למשל בדרישות ובקוד). תפקיד הבודק הוא להיות חלק מאלו שדואגים לאיכות במקרו, ולהשתמש בכלים האלה במיקרו בהיותו מייצג את הלקוח.

מדוע הבדיקות והתמיכה צריכים להיות מאוחדים מבחינה ארגונית

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

1. בד"כ אנשי הבדיקות הם אלה שמכירים את המערכת כמערכת בצורה הטובה ביותר. ברגע שאנשי התמיכה נמצאים בתוך מחלקת הבדיקות, אפילו כצוות נפרד, יש להם אנשים זמינים בקלות (פיזית ומכאן גם חברתית) שהם בעלי הידע. יש את מי לשאול, יש עם מי להתייעץ.
2. אנשי הבדיקות תמיד מעודכנים בכל פיצ'ר חדש, בחסרונות שלו, ב-workarounds, בזמן העלייה שלו לפרודקשין וכד'. ברגע שהמנהל, שהוא גם המנהל של התמיכה, מארגן העברת ידע מסודרת בין הבודקים לתומכים, תהיה לתמיכה האינפורמציה האחרונה והמקיפה לגבי המערכת.
3. מצד שני, כשיש בעיה חדשה במערכת, התומכים הם הראשונים לדעת. תומך טוב יכול להבין שיש בעיה לפעמים לפני האנשים הטכניים, ולפעמים במקומם. למשל: אם שרת נפל, במערכת הבנוייה היטב אנשי הסיסטם יקבלו SMS ובתקוה, יטפלו בעניין מייד. אבל נניח שאיזשהו פיצ'ר הפסיק לעבוד (למשל בגלל עדכון תוכנה שאינו קשור למוצר, כמו Service pack חדש למע' ההפעלה). איש תמיכה טוב, אפילו ש"אצלו זה עובד", כבר יבין מהמייל השני שיש בעיה ויתחיל לעבוד עם הלקוחות בניתוח הבעיה.
4. התומכים הם צינור טוב למידע על ומהלקוח: מה מפריע לו, מה הוא לא מבין במערכת, לפעמים אילו רעיונות יש לו. למשל אם מקבלים מיילים חוזרים שמשתמש לא מבין איך עושים פעולה X, אז אפילו שלצוות הטכני זה נראה ברור מאיליו, כנראה שיש בעיה. פתרונה ירצה גם את הלקוח וגם את התמיכה בכך שמספר הפניות אליו יקטנו.

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

מנהל פרוייקטי בדיקות

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

מה מצופה מראשי הצוותים שלכם?

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

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

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

תפקיד בעל המוצר (מנהל המוצר) בסביבת סקראם

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

עוד על 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. אגב, קרה במקום מסוים שזיהינו את הבעייתיות שהשיווק לא ממשיך ללוות את מחזור החיים של המוצר, וביקשנו מהם להצטרף בנק' מסויימות. אבל זה מעט מידי ולא יעיל כשצעד כזה אינו מאוגד בתשתית תהליכית.

ערכים בארגון

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

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

חזון של חברה עסקית

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

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

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

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

וכשהחברה מסורה לחזון ועושה את זה נכון גם הלקוחות יכולים להרגיש חלק מהחזון ולהיות מעורבים רגשית. ומי צריך יותר מזה. ערב אותם, שתף, דווח. תן להם להרגיש שההצלחה שלך היא גם שלהם. But you better mean it. לבולשיט יש ליווי של ריח רע שאנשים קולטים.

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

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

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

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