RSS לפוסטים RSS לתגובות 228 מאמרים ו- 1,974 תגובות עד כה מאז 2005

16 דו"חות שמישות להורדה

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

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

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

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

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

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

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

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

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

2 תגובות על “16 דו"חות שמישות להורדה”

  1. 14/08/2007 בשעה 10:30 מורד

    אמיר, תודה רבה !

  2. 11/04/2017 בשעה 21:10 אריאל

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

    אריאל

RSS לתגובות לפוסט זה

הוספת תגובה