מחזור חיים אופייני, של פרוייקט הקמת מערכת מידע, כולל מספר שלבים מרכזיים:
חברות האינטגרציה ובתי התוכנה, מתגאים ביכולתם לספק פתרון כולל, החל משלב תכנון המערכת, דרך יישומה והטמעתה בצד הלקוח, וכלה באספקת תמיכה ותחזוקה שוטפת במהלך תפעולה היומיומי.
לכאורה, שיטת עבודה זו נראית ללא דופי: תהליך העבודה ברור ומוגדר, המתודולוגיות מקצועיות ומשכנעות, לוחות הזמנים סבירים, ואנשי המקצוע (מנהלי פרוייקטים, מנתחי מערכות ומתכנתים) הינם מהשורה הראשונה בתחומם.
אולם למעשה, שיטת העבודה הזו טומנת בחובה בעיה קונספטואלית, אשר פוגעת ביכולות החברה למקסם את מטרותיה העסקיות של המערכת. היכן טמונה הבעיה? מדוע שיטת העבודה הזו אינה מובילה להשגת מטרותיה העסקיות של המערכת?
הבעיה: תכנון מונע טכנולוגיה
מומחיותן והתמקדותן של חברות האינטגרציה ובתי התוכנה בניתוח הדרישות הטכנולוגיות ויישומן, מובילות לתכנון מערכת המידע בשיטה אשר מכונה "Technology-Driven Design". כלומר, תהליך הקמת מערכת המידע מנותב בהתאם לטכנולוגיה ועל פי תפיסת עולמם של מנתחי מערכות ומומחים טכנולוגים.
לחברות האינטגרציה ולבתי התוכנה, ניסיון עשיר בפיתוח והטמעת מערכות מידע. אין ספק, כי גודלם, ניסיונם ומגוון הפרוייקטים שזקפו לזכותם, מקנים את הביטחון ההכרחי, כי אכן מתייחסים הם בדייקנות לכלל הנושאים, הקשורים בתכנון המערכת.
אך האם באמת מתייחסים בתי התוכנה וחברות האינטגרציה לכלל מרכיבי תכנון המערכת? האם המערכת אכן תשיג את מטרותיה העסקיות בשלב התפעול השוטף?
שלביהם הראשונים של פרוייקטים לתכנון מערכות מידע, על פי שיטת ה- Technology-Driven Design, מתנהלים באופן דומה:
מנהל הפרוייקט, מטעם בית התוכנה, מקיים סדרת פגישות עם הגורמים המוסמכים בצד הלקוח, בהן מוגדרים הצרכים העסקיים ודרישות הפיתוח. רשימות הצרכים והדרישות הללו, מובילות בצורה ישירה לכתיבת המסמך המוכר לכולנו: "אפיון פונקציונאלי".
ניתוח מקצועי של האפיון הפונקציונאלי, מגלה כי ההתייחסות להיבט החשוב ביותר במערכת לוקה בחסר משמעותי- ממשק המשתמש.
האם יש באפשרותנו להבין מתוך מסמך האפיון הפונקציונאלי את איכותו של ממשק המשתמש? האם די במבט כללי על מבנה המערכת, כפי שמוצג באפיון הפונקציונאלי, כדי לקבוע שהמערכת אכן מתאימה ותפורה לתהליך העבודה של המשתמשים?
בחירה בשיטת ה- Technology-Driven Design, "שואבת" אותנו, מבלי שנשים לב, להתמקדות יתרה בדרישות הפיתוח, קודם להתמקדות במשתמשי המערכת ומטרותיהם. ממשק המשתמש במקרים הללו, הופך לתוצר לוואי של תהליכים טכנולוגים ואינו משקף את מטרות המשתמשים וצורת עבודתם האמיתית.
יתרה מכך, ההזדמנות הראשונה, בה נוכל למדוד ולבחון באופן שיטתי ומדויק את איכותו של ממשק המשתמש, היא רק בשלבים המתקדמים של פיתוח המערכת!
ברור, כי ככל שהמערכת מורכבת יותר, כך הפגיעה בממשק המשתמש מהותית יותר ובעלת השלכות מסחריות חמורות יותר.
נמחיש את האמור, באמצעות דוגמא פשוטה מחיינו היומיומיים: מכונת קפה אוטומטית.
כמעט כולנו, נחשבים למשתמשים פוטנציאלים של מכונות הקפה האוטומטיות, ומטרתנו כמשתמשים פוטנציאלים של מכונת הקפה ברורה: שתיית קפה. זו מטרתנו היחידה!
פעולת הכנת הקפה, היא האמצעי להשגת המטרה. היה באפשרותנו להכין את הקפה "בצורה ידנית", אך בחרנו להשיג את מטרתנו באמצעות שימוש פשוט ומהיר במכונה.
"תהליך העבודה" הנדרש מאיתנו (המשתמשים), כאשר אנו ניצבים מול המכונה הוא פשוט: בחירה בסוג הקפה הרצוי ולחיצה על הכפתור המתאים.
מטרתנו, כאמור, היא שתיית קפה – הפעולה הנדרשת מאיתנו, כדי להשיג את המטרה, היא לחיצה על כפתור אחד!
כעת, נניח שפרוייקט תכנון מכונת הקפה היה מבוסס על "תכנון מונע טכנולוגיה". כלומר, הצגת "ממשק המשתמש" של מכונת הקפה, כשיקוף של התהליכים הטכנולוגים המתבצעים במעמקי המכונה.
במקרה זה, היינו מגיעים למכונת הקפה ומגלים שלצורך הכנת הקפה, עלינו לעבור מספר שלבים. לשמחתנו, תהליך הכנת הקפה ברור ו- "ידידותי":
אכן התהליך ברור ומכונת הקפה אכן עומדת בדרישות הפונקציונאליות. תפקידה של המכונה להכין קפה והיא אכן מבצעת את תפקידה בהצלחה. אך מה לגבינו המשתמשים? האם יש היגיון בתהליך כה מסורבל לצורך ביצוע פעולה פשוטה כל כך?
נסו לתאר לעצמכם את אותה תופעה במערכת מידע מורכבת, אשר מספר אפשרויות הפעולה הכלולות בה, כמעט אינסופי מבחינת המשתמש. האם משתמשי המערכת יהיו מסוגלים "לפענח" את התהליכים הטכנולוגים? האם יש היגיון לדרוש מהמשתמשים לעבור תהליכים מסוג זה יום יום?
זוהי למעשה התוצאה הישירה של תכנון מערכת מידע על פי שיטת ה- Technology-Driven Design. אנו מציפים את המשתמש במכלול כפתורים, פונקציות ואפשרויות פעולה אשר במקום לסייע לו בהשגת המטרה, מכשילים אותו ומקשים עליו את השימוש.
הפתרון: תכנון ממוקד משתמש
מהו אם כן תכנון ממוקד משתמש? כיצד שונה תהליך תכנון ממוקד משתמש מתהליך תכנון מונע טכנולוגיה? מהם היתרונות בתכנון ממוקד משתמש?
תכנון ממוקד משתמש (UCD) כשמו כן הוא – אנו מציבים את המשתמשים בראש סדר העדיפויות ומשקיעים את עיקר המחשבה, בכל שלבי תכנון המערכת, במשתמשים במטרותיהם ובמשימותיהם.
ברור שאין הכוונה כי הטכנולוגיה מיותרת. הרי ללא האמצעים הטכנולוגים לא נוכל להשיג ולו מטרה אחת. יחד עם זאת, חשוב לזכור שהטכנולוגיה היא האמצעי להשגת מטרות המשתמשים ואינה מהווה מטרה בפני עצמה.
תכנון ממוקד משתמש, אינו נועד להחליף את תהליך תכנון המערכת בשיטה שהוזכרה לעיל. מטרתו העיקרית, הינה להשלים את הפתרון הכולל ולהקנות למשתמשי המערכת את החשיבות הראויה בשלבי התכנון.
תכנון ממוקד משתמש, כולל מספר "תוספות" המשתלבות במחזור חייו של הפרוייקט ובעיקר, מתייחס לסדרי העדיפויות בהגדרת שלבי תכנון המערכת:
תכנון המערכת על פי מתודולוגית User-Centered Design, משיג הפרדה מלאה בין תכנון ממשק המשתמש לבין האפיון הטכנולוגי ומגדיר בצורה ברורה את סדר העדיפויות בתכנון המערכת: משתמשים על פני טכנולוגיה!
תכנון ממשק המשתמש בשלבים המוקדמים של הפרוייקט והצגתו כאב-טיפוס, מאפשרים למקבלי ההחלטות בחברה, למדוד את איכותו של הממשק ולהבין מיד כיצד תתפקד המערכת בצד המשתמש. בצורה זו, נוכל לקבוע בבירור את יעילותה של המערכת והתאמתה למשתמשים, מבלי לכתוב ולו שורת קוד אחת!
לקבלת תוצאות איכותיות אף יותר, ניתן לבצע מבחני שימושיות בנקודות מפתח בפרוייקט, שמטרתם לבחון את המערכת בצורה חיה, באמצעות מספר משתמשים פוטנציאלים. ברוב המקרים, מבחן השימושיות המרכזי, מתבצע לאחר בניית אב הטיפוס (שלב 3), קודם לביצוע ניתוח המערכת וכתיבת מסמך האפיון הטכנולוגי.
מחקרים רבים שפורסמו בשנים האחרונות, מראים בבירור כי התמורה הכלכלית עבור תכנון מערכת מידע, על פי מתודולוגיות User-Centered Design, היא עצומה. ההשקעה ב-"תוספת" המתודולוגיות והשיטתיות לתכנון ממשק המשתמש, הנה מזערית ביחס להשקעה הכוללת בפיתוח המערכת וברובם המכריע של המקרים חוסכת עלויות של התאמות, תיקונים ושיפורים לאחר השקת המערכת.
מאמרים קשורים:
UCD for different project types, part 1 - IBM
UCD for different project types, part 2 - IBM
ספרים קשורים (Amazon.com):
