פיילוט

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

1. תוכן

2. מבנה

3. פונקציונאליות

תוכן

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

מבנה

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

פונקציונאליות

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

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

אז מאיפה מתחילים ?

החלטה על משך הפיילוט

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

תשתית הפיילוט

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

משתמשי הפיילוט

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

כלים תומכים

בארגז הכלים של הפיילוט מומלץ להחזיק תבנית של כל אחד מהמסמכים הבאים:

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

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

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

תזמון הפיילוט

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

ממצאי הפיילוט

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

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

---

רוצה ללמוד עוד על טכנולוגיות ניהול ידע?

הנה מספר כתבות שאולי יעניינו אותך:

• שישה טיפים לשימוש יומיומי

• מנוע חיפוש ארגוני - קוים לדמותו

• וWIKI: ללכת בלי - להרגיש עם