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

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

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

אה,
וגם שדרגנו את גרסת המודל שלנו ל-1.9.7.

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

ועכשיו נתחיל מההתחלה…

מוטיבציה

במשך שנים רבות היה עורך אחד ויחיד בכליקיט3 – עורך של חברת מייקרוסופט. הוא הכיל את כל הכפתורים המוכרים מ-Word, וגם כמה כפתורים מיוחדים למערכת שלנו: כפתור הוספת אינטראקציות, כפתור יצירת קישור למטלת LMS, כפתור של ציור חופשי. בקיצור, אידיליה.
יום אחד, יצא לשוק דפדפן חדש : אינטרנט אקספלורר 7.  מיד עם יציאתו לשוק הוחלט שחלק מחברי הצוות ישדרגו את דפדפנם לגרסה החדשה, כדי להתנסות בו עם מערכת הכליקיט ולתקן בעיות אם ישנן. ואכן לאחר זמן קצר התברר שקוד ה-JavScript של העורך אינו תואם את הסטנדרטים של הדפדפן החדש, ומספר כפתורים מקפיצים הודעות שגיאה. מהר אצנו-רצנו ותיקנו את השגיאות כדי שכולם יוכלו להשתמש בעורך בכל גרסאות אקספלורר, והשקט שב לאזורנו.  זה היה הרמז הראשון כי זמנו של עורך לא סטנדרטי עומד להסתיים, והתחלנו לחשוב מה לעשות.
ובכן, זמן מרובה למחשבה לא היה לנו, מפני שאך סיימנו להתמודד עם IE7, צצה וקפצה לה מערכת הפעלה חדשה: Windows Vista. כאן לא עזרו לנו תחבולות שונות בעורך – מערכת ההפעלה אבחנה את העורך כיצור עוין מבחינה אבטחתית, ואנחנו היינו מוגבלים ביכולת שלנו לשנות את דעתה בגלל הקוד המורכב של העורך.
בשלב ההוא עדיין לא שקלנו הכנסת עורכים אחרים מלבד זה של מייקרוסופט. היתה תחושה של – זה העורך שלנו ואיתו ננצח. עם זאת, כדי לתת פתרון למשתמשי ויסטה, עמדה לרשותנו מתכנתת מדהימה, והיא קיבלה על עצמה לכתוב עורך שיתאים לסטנדרטים. חיש קל ניגשה לעבודה, ותוך מספר שבועות עמד על רגליו עורך סטנדרטי, המכיל את הכפתורים העיקריים הנחוצים לערכית טקסט באינטרנט, ועובד בכל מערכות ההפעלה ודפדפני האינטרנט (כן, גם פיירפוקס!). האם הגענו אל המנוחה ואל הנחלה? ממש לא – התברר שהכפתורים שלא הספקנו ליישם בעורך החדש (המכונה במחוזותינו "העורך הקל") – כגון אותם כפתורים מותאמים למערכת כמו אינטראקציות ודומיו – היו מאד חסרים למשתמשי המערכת, והגבילו מאד את שימושם בעורך הקל. הבנו שהפתרון הזה הוא זמני בלבד. עם זאת, העורך הזה בכל זאת קיבל עדנה כאשר החלטנו להשתמש בו גם במקרים שהכותב גולש בדפדפן סטנדרטי, כגון פיירפוקס, וכך הוא הוכנס כעורך בין השאר גם לפורומים ולתגובות, לשמחתם הרבה של הגולשים הסטנדרטיים.
הקש ששבר את גב הגמל היה לא אחר מאשר אינטרנט אקספלורר 8. מיד עם יציאתו לשוק בדקנו בו את העורך, וראינו שגם הוא, כאחיו 7, סרב לתמוך בעורך בלתי סטנדרטי, אך הוא הוסיף חטא על פשע – הוא לא שלח לקוד זיהוי ברור של זהותו, ועל כן היה קשה מאד לזהות משתמשי אקספולרר 8 ולהגיש להם את העורך הקל. לאחר עבודה קשה הצלחנו למצוא דרך לזהות את אדון 8, אבל הבנו שבגרסה הבאה של אקספלורר שוב תיווצר הבעיה, והחלטנו לשים לעניין סוף – הקש הזה גרם לנו להחליט לעבור לעורך מלא וסטנדרטי לחלוטין. בשלב זה של חיינו המקצועיים כבר היינו אחרי הקמת מערכת כליקיט לייט, ואחרי הטמעת מערכת וורדפרס אצלנו, ולכן היתה לנו כבר היכרות עם עורך כזה – TinyMCE. מצאנו מתכנת שיודע היטב JavaScript שיוכל להוסיף לעורך הנפלא הזה את הכפתורים המיוחדים למערכת שלנו, ויצאנו לדרך.

היישום – עם באגים

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

(אנחת רווחה)

אך לא. לא זו בלבד שמלקוחותינו לא נשמעה אנחת רווחה, אלא שהחלו להישמע קולות מצוקה: במסגרת התאמת העורך למערכת הכליקיט, יישמנו בו את הפלגאין המאפשר העלאת תמונות. בבדיקות שלנו וידאנו כי תמונותהמצורפות לטקסטים  אכן מועלות לשרת, אך שכחנו לבדוק שהן גם נשארות שם…
עוד זה מדבר וזה בא: גילינו כי TinyMCE אינו מסוגל להתמודד עם רבים מהטקסטים שנערכו בעורך המייקרוסופטי. העורך המייקרוסופטי – בהיותו בלתי תואם סטנדרטים – היה מאד סלחני כלפי התוכן שנכנס אליו, ואיפשר גם את ה-HTML המזוויע ש-Word מייצר. TinyMCE, פדנט שכמותו, לא עמד בזה. כאשר ניסו לערוך בו טקסטים שכבר היו במערכת – הוא חתך אותם על ימין ועל שמאל (מאחר שהוא שואף לייצר HTML סטנדרטי ככל האפשר, העורך פשוט מנקה את התוכן שמכניסים אליו, וכמובן שנקיון זה אינו תמיד לרוח מזין התוכן….), הוסיף ריווחים היכן שלא צריך, ובאופן כללי השתדל לשדר מסר של אי שביעות רצון גדולה מהטקסטים שמבקשים ממנו לערוך…

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

היישום – ללא באגים?

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

הפסקת אש

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

ואחרי זה?

מי יודע? זה מה שכיף בעבודה עם אנשים – אתה אף פעם לא יודע מה יהיה הסוף. ימים יגידו.

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

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

באופן עקרוני, על מנת להטמיע את גוגל אנאליטקס באתר צריך להעתיק חתיכת קוד ולהשתיל אותה בפוטר של דף הבית. לאחר בחינה קלה, ראינו שכל חתיכות הקוד שגוגל אנאליטקס נותן לצורך השתלה באתר זהות זו לזו – אותן 13 שורות קוד הנדרשות להוספה בפוטר ש לאתר א’ זהות לאלו הנדרשות לאתר ב’ – חוץ ממחרוזת אחת שמופיעה בתחתיתו ושמתחילה ב-UA-xxxxxxx-xx. לכן, בתוך דף הניהול של האתר בכליקיט 3 יצרנו שדה שמאפשר למנהל האתר להזין את המחרוזת הזו, וככה הוא לא צריך להכנס לנבכי ה-HTML של דף הבית של האתר.

זהו זה, קל ופשוט.

להלן הרשמים מהמשחקים שלי איתה בחודשים האחרונים.

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

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

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

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

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

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

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

זהו זה.

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

שנה טובה!

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

תכנון חוויית משתמש איננו…

1. …תכנון ממשק משתמש
   ממשק הוא מרכיב בחוויית המשתמש, אבל יש הרבה יותר. עיצוב אינו עניין קוסמטי, הזזת פיקסלים ומיקום כפתורים. זהו דבר הוליסטי ומהווה עניין לכולם, לא רק לטיפוסים "יצירתיים".
2. …צעד בתהליך
   הוא עצמו התהליך. כדי ליצור חוויה מצויינת למשתמשים שלך ולא רק לעצב משהו שהיינו רוצים להשתמש בו, אנחנו חייבים להמשיך לחזור ולהקשיב ולעצב בהתאם. עיצוב חוויית משתמש אינה משהו חד פעמי. זה חיב להיות מוטמע בכל מה שאתה עושה.
3. …קשור לטכנולוגיה
   חווית משתמש גם אינה קשורה לטכנולוגיה. היא קשורה לדרך החיים שלנו, לכל מה שאנו עושים. מעצבי חוויית משתמש משתמשים בטכנולוגיה כדי לעזור לאנשים לממש את מטרתם. אבל המטרה העיקרית היא לעזור לאנשים, לא ליצור טכנלוגיה מדהימה. באמת, מעצב חוויית משתמש יכול לסייע בשיפור חויה של אדם כמעט עם כל דבר – ידית, ברז, עגלת קניות. אנחנו פשוט בד"כ לא מתייחסים לאנשים הללו כ"משתמשים", אבל זה מה שהם.
4. …קשור רק לשמישות
   אנשים בד"כ חושבים שעיצוב חוויית משתמש היא דרך להפוך מוצרים לא מוצלחים למוצרים מוצלחים ע"י הפניית משאבים לעיצוב המוצר. אבל יצירת מוצרים קלים ואינטואיטיביים היא ממש לא המטרה היחידה. שמישות היא אמנם חשובה, אבל ההתמקדות שלה ביעילות ותועלת מטשטשת את המרכיבים החשובים הנוספים בחויית משתמש, כולל קלות לימוד ותגובות רגשיות והתנהגותיות למוצרים ולשרותים שבה אנו משתמשים. לא כל דבר חייב להיות הכי פשוט בעולם, אם קל ללמוד אותו. והעיצוב שלו כמוצר מושך היא קריטית, אחרת אנשים לעולם לא ירצו בכלל להתממשק איתו
5. …קשור רק למשתמש
   רוס אונגר אוהב לומר שהמיתוס הגדול ביותר ב-UX הוא ה-U. יש גם כמה מטרות עסקיות שצריך לממש, והעיצוב מתייחס גם אליהן. אנחנו לא תמיד יכולים לעשות מה שטוב למשתמש. אנחנו חייבים לוודא שאנחנו מציגים חוויה כוללת היכולה לשרת מטרות וצרכים רבים ככל האפשר לעסק ולמשתמשים.
6. …יקר
   לפעמים תהליך עיצוב חוויית משתמש מלא הוא ממש לא מה שדרוש. בהחלט יתכן לבצע מספר שיפורים קטנים הן  לפרוייקט והן ולמוצר ע"י שימוש בטכניקות חווית משתמש
   אנשים נצמדים לדברים כמו פרסונות, סקר משתמשים וכד’. במציאות, למעצבים הטובים יש סט כלים המאפשר בחירה ושימוש במתודות עפ"י הצורך בכל פרוייקט.
7. …קל
   רק בגלל שאנחנו יודעים לבצע כמה פעולות מגניבות ומועילות, ומכירים את העסק שלנו ממש טוב, זה לא אומר שכל התהליך הזה הוא קלי קלות. להפך – נסיון לעגל פינות בצעדים חשובים הוא מתכון לאסון.
8. …תפקידו של אדם אחד או של מחלקה אחת
   אנחנו כתעשיה לא השכלנו להפריד בין תתי התמחויות ותפקידים בעיצוב חוויית משתמש וכך לקוחות אינם מבינים שעליהם להעזר בסוגי אנשים שונים בנקודות שונות בחיי הפרוייקט.
9. …דיסציפלינה יחידה
   יתכן שעדיין אי אפשר לומר שמדובר בקהילה. במקרה הטוב מדובר במודעות משותפת, חוט המקשר יחד אנשים מדיסציפלינות שונות שאכפת להם מעיצוב טוב.
   אנשים שונים מתמחים בחלקים שונים בתהליך. כשם שלא היית הולך לקרדיולוג כדי שירפא את הרגל השבורה שלך, אל תצפה מכל מומחה בתחום חוויית המשתמש להשיג את כל המטרות שלך.
10. …אופציה
    ג’ארד ספול, המייסד והמנכ"ל של חברת המחקר הגדולה בעולם בתחום חוויית המשתמש, ביצע חקירות נרחבות על איכות צוותי מוצר מוצלחים ומרוצים. בפשטות, הפגם הנפוץ ביותר שהוא מצא הוא חברות החושבת ש"חוית משתמש טובה היא תוספת, לא דרישה יסודית".

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

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

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

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

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

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

למה אני מתכוון? ההרצאה התחילה בחלוקת נושא האבטחה לשלוש שכבות:

1. רמת הרשת – מתייחסת לאנשי הסיסטם, הקמת פיירוולים וכיוב’.

2. רמת שרת – גישה לשרת, מתן הרשאות כתיבה וכיוב’.

3. רמת האפליקציה – שנוגעת ישירות למשתמש ולא לשרת עצמו וכוללת בין היתר את האפשרות לתמרן את המשתמש ולגרום לו למסור נתונים אישיים ללא ידיעתו.

פה נגמרו עשר דקות ההקשבה הטכנולוגית כשמיד לאחריהן התחלתי להרהר ביני לבין עצמי על המשמעות של הדברים. התחלתי להקשיב לא למה שאומר המרצה אלא למה שעומד מאחורי המילים, והגעתי לתובנה מעניינת. שמתי לב שהשיח שבו הוא משתמש מנותק לגמרי מהרמה של השיח היומיומי והממוצע – מפוצץ במילים שאין להן שום משמעות מעבר למהותן הטכנית – Post, Java Script , SQL, XSS, Stored Procedure. זאת אומרת, יש פה שיח שמכיל מונחים שבכלל לא רלוונטיים לשיחים אחרים. אבל זה לא נגמר רק פה, משום לשיח הטכנולוגי הזה יש משמעות נוספת, הוא גם ממדר בין אלו שיודעים ומכירים אותו לבין אלו שלא. במילים אחרות, נוצר פה מצב מעניין, האדם שבקיא בידע ולכן הוא חזק לעומת האדם שלא מכיר את הידע ולכן הוא חלש. אבל החלש שותף לידע הזה גם מבלי שהוא יודע, הוא נכנס לפייסבוק, הוא קונה דיסקים וספרים באמזון וכל זאת תחת מטריית אבטחה מקוונת – אבל המשתמש לא לגמרי מודע לכך וכך נוצרת בינו לבין השיח הטכנולוגי מערכת יחסים סמויה.

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

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

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

זה הכל.