באחת מהחברות שבהן עבדתי היה מנהל פיתוח שהיה בעל כוחות על, נקרא לו גל שמבדוי, ואני חייב להודות: זה לא משהו רגיל. היה לו כוח על לאו דווקא ב-++C או #C, בענן או בתשתיות, למרות שגם בזה הוא היה טוב, אבל טוב רגיל.
הכוח שלו היה בזה שהוא תמיד ידע איך המשתמש משתמש במוצר שלנו, מה הוא אוהב, מה הוא לא אוהב אבל בעיקר במה הוא לא משתמש.
והיופי בדבר היה שהוא לא היה זקוק לסטטיסטיקה של המוצר או לגוגל אנליטיקס. הוא פשוט ידע.
למשל:
בודק: כשהמשתמש לוחץ על כפתור התפריט אבל לא בוחר כלום ויוצא ממנו המוצר נתקע.
גל שמבדוי: אף משתמש לא לוחץ על התפריט בלי לבחור כלום. או:
בודק: כשבמחשב יש שני משתמשים פעילים (switch user) המוצר יקריס את הדפדפן.
גל שמבדוי: רק 3% מחוברים באותו זמן אז זה לא חשוב. אמנם גם אם הוא היה צודק לגבי האחוזים זה לא אומר שזה לא חשוב, אבל מי אמר שהוא צודק? כששאלתי מאיפה לו הנתון התשובה הייתה: ראיתי את זה באיזה מקום. לא יודע אם היה קשר אבל הכוחות שלו היו בשיאם כשהיה מדובר בתיקון מורכב ומתסכל או כשהוא התחייב לתאריך שחרור שהיה יכול להתארך בשל הבאג.
אמנם זה קוריוז, אבל רבים מאתנו "חוטאים" בהיבריס או גאוות יתר, כלומר חושבים שאנו יודעים מה המשתמש עושה או רוצה או מה הוא מרגיש. גם אני, בגרסה הצעירה יותר שלי ובעלת האגו הגבוה יותר, חשבתי שאני יודע את הדברים האלה. אבל יום אחד נפל האסימון (דימוי מיושן משהו, לא?), וכך אולי זה קרה:
כשאני מחפש אפליקציה בטלפון שלי אני באנדרואיד נכנס למגירה ומחפש, ואם אני לא מוצא ברפרוף אני מחפש בשדה החיפוש. ואז התברר לי שיש אנשים שפשוט לא טורחים. הם מחפשים את האפליקציה מתוך ה-Play Store.
זה לא הגיוני, הסברתי לאיש. החיפוש במגירה מהיר יותר (לא יוצא החוצה לרשת) וממוקד (אין לי בד"כ אפליקציות דומות. בסטור אקבל הרבה תשובות).
הו, אבל זה מאוד הגיוני, הוא ענה. זה בכ"ז די מהיר, אני בדרך רואה אפליקציות דומות ואולי לפתע אזהה אחת טובה יותר, וכך אני גם רואה אם האפליקציה צריכה עדכון.
אכן הגיוני.
כלומר לא מדובר במשתמש מיוחד, או "מאותגר" טכנולוגית או בכלל (וגם להם צריך לדאוג), אלא במשתמש אינטליגנטי שמבצע פעולות הגיוניות רק בדרך שונה ממה שאני עשיתי (שגם היה ביצוע פעולות הגיוניות). בתור בודקים, אנו מאוד רוצים לדעת איך המשתמש משתמש. הבעיה היא שהכי קל לנו לדעת איך המשתמש משתמש אם המשתמש הוא... אני. ואולי אני מייצג בדברים מסוימים את הרוב המוחץ של המשתמשים, אבל אולי לא. וצריך ענווה בכדי להבין זאת. אז מה עושים? הנה כמה רעיונות:
1. אם יש לנו מזל נוכל להשיג גישה למשתמשים וממש לראות אותם עובדים. אם מדובר במוצר לקהל לקוחות קטן אז זו האפשרות הטובה וגם הכי מוצלחת מול האפשרויות האחרות.
2. אם לא, ומדובר במוצר המיועד לקהל הרחב, אולי כדאי להפיץ במקום העבודה ולקבל משוב מהעובדים (dog food).
3. עוד רעיון זה להשיג מידע אמתי בעזרת כלי אנליטי כזה או אחר. זה מצויין אבל רק לפיצ'רים שכבר יצאו.
4. כדאי לחשוב על קראודטסטינג.
5. אולי להפיץ את הפיצ'רים החדשים לקהל מצומצם.
6. להשתמש ב-AB Tests.
7. לנסות לחשוב על דרכים שונות להשגת אותה מטרה, ומצד שני על מטרות שונות מאותה פעולה.
8. שימוש בפרסונות.
9. אקספלורטורי.
10. אחרי שהמוצר יצא לעקוב אחרי דיווח הבעיות, פורומים, אסקייפ באגס וכד'.
11. במידה וניתן - להגיע אל המשתמשים, ואם זה לא ניתן אז למצוא דרכים למשוך מהם משוב באופן יזום (לא לחכות למעט הבאגים שטורחים לדווח לנו) - פנייה בסקר, יותר כפתורי משוב ולהראות שבאמת אכפת לנו מהמשוב ואנו מתאימים את המוצר בהתאם.*
12. באפליקציות SaaS - להשתמש בכלים שפותחו לצרכי DevOps - ולראות מה המשתמשים עושים באמת, היכן הם מתמהמהים, מהיכן הם מגיעים לכל נקודה...(כמובן שזה ייתן לנו רק משוב על איך הם עובדים במצב הנתון, וקצת פחות לגבי מה הם היו רוצים ואיך הם היו רוצים לעבוד ולא יכולים כי לא סיפקנו להם את היכולת).* *נקודות ע"י קובי הלפרין מפורום הבדיקות: https://www.facebook.com/groups/IL.Testing.QA
למשל:
בודק: כשהמשתמש לוחץ על כפתור התפריט אבל לא בוחר כלום ויוצא ממנו המוצר נתקע.
גל שמבדוי: אף משתמש לא לוחץ על התפריט בלי לבחור כלום. או:
בודק: כשבמחשב יש שני משתמשים פעילים (switch user) המוצר יקריס את הדפדפן.
גל שמבדוי: רק 3% מחוברים באותו זמן אז זה לא חשוב. אמנם גם אם הוא היה צודק לגבי האחוזים זה לא אומר שזה לא חשוב, אבל מי אמר שהוא צודק? כששאלתי מאיפה לו הנתון התשובה הייתה: ראיתי את זה באיזה מקום. לא יודע אם היה קשר אבל הכוחות שלו היו בשיאם כשהיה מדובר בתיקון מורכב ומתסכל או כשהוא התחייב לתאריך שחרור שהיה יכול להתארך בשל הבאג.
כשאני מחפש אפליקציה בטלפון שלי אני באנדרואיד נכנס למגירה ומחפש, ואם אני לא מוצא ברפרוף אני מחפש בשדה החיפוש. ואז התברר לי שיש אנשים שפשוט לא טורחים. הם מחפשים את האפליקציה מתוך ה-Play Store.
זה לא הגיוני, הסברתי לאיש. החיפוש במגירה מהיר יותר (לא יוצא החוצה לרשת) וממוקד (אין לי בד"כ אפליקציות דומות. בסטור אקבל הרבה תשובות).
הו, אבל זה מאוד הגיוני, הוא ענה. זה בכ"ז די מהיר, אני בדרך רואה אפליקציות דומות ואולי לפתע אזהה אחת טובה יותר, וכך אני גם רואה אם האפליקציה צריכה עדכון.
אכן הגיוני.
כלומר לא מדובר במשתמש מיוחד, או "מאותגר" טכנולוגית או בכלל (וגם להם צריך לדאוג), אלא במשתמש אינטליגנטי שמבצע פעולות הגיוניות רק בדרך שונה ממה שאני עשיתי (שגם היה ביצוע פעולות הגיוניות). בתור בודקים, אנו מאוד רוצים לדעת איך המשתמש משתמש. הבעיה היא שהכי קל לנו לדעת איך המשתמש משתמש אם המשתמש הוא... אני. ואולי אני מייצג בדברים מסוימים את הרוב המוחץ של המשתמשים, אבל אולי לא. וצריך ענווה בכדי להבין זאת. אז מה עושים? הנה כמה רעיונות:
1. אם יש לנו מזל נוכל להשיג גישה למשתמשים וממש לראות אותם עובדים. אם מדובר במוצר לקהל לקוחות קטן אז זו האפשרות הטובה וגם הכי מוצלחת מול האפשרויות האחרות.
2. אם לא, ומדובר במוצר המיועד לקהל הרחב, אולי כדאי להפיץ במקום העבודה ולקבל משוב מהעובדים (dog food).
3. עוד רעיון זה להשיג מידע אמתי בעזרת כלי אנליטי כזה או אחר. זה מצויין אבל רק לפיצ'רים שכבר יצאו.
4. כדאי לחשוב על קראודטסטינג.
5. אולי להפיץ את הפיצ'רים החדשים לקהל מצומצם.
6. להשתמש ב-AB Tests.
7. לנסות לחשוב על דרכים שונות להשגת אותה מטרה, ומצד שני על מטרות שונות מאותה פעולה.
8. שימוש בפרסונות.
9. אקספלורטורי.
10. אחרי שהמוצר יצא לעקוב אחרי דיווח הבעיות, פורומים, אסקייפ באגס וכד'.
11. במידה וניתן - להגיע אל המשתמשים, ואם זה לא ניתן אז למצוא דרכים למשוך מהם משוב באופן יזום (לא לחכות למעט הבאגים שטורחים לדווח לנו) - פנייה בסקר, יותר כפתורי משוב ולהראות שבאמת אכפת לנו מהמשוב ואנו מתאימים את המוצר בהתאם.*
12. באפליקציות SaaS - להשתמש בכלים שפותחו לצרכי DevOps - ולראות מה המשתמשים עושים באמת, היכן הם מתמהמהים, מהיכן הם מגיעים לכל נקודה...(כמובן שזה ייתן לנו רק משוב על איך הם עובדים במצב הנתון, וקצת פחות לגבי מה הם היו רוצים ואיך הם היו רוצים לעבוד ולא יכולים כי לא סיפקנו להם את היכולת).* *נקודות ע"י קובי הלפרין מפורום הבדיקות: https://www.facebook.com/groups/IL.Testing.QA
אין תגובות:
הוסף רשומת תגובה