אפיון מערכת מידע - השיטה המיטבית

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

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

הבעיה: אפיון מונע טכנולוגיה (Technology-Driven Design)

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

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

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

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

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

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

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

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

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

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

הפתרון: אפיון ממוקד משתמש (User-Centered Design)

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

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

אפיון המערכת על פי מתודולוגית User-Centered Design, משיג הפרדה מלאה בין אפיון ממשק המשתמש לבין האפיון הטכנולוגי ומגדיר בצורה ברורה את סדר העדיפויות באפיון המערכת: משתמשים על פני טכנולוגיה!

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

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

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

הערכת מומחים (Expert Review / Heuristic Evaluation)

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

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

מבחן שימושיות (Usability Testing)

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

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

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

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