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

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

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

לאה כהן | 8 ביוני 2009 | כללי | אין תגובות


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

שאלה:
מה נחשב משוב רלוונטי מלקוח?
  1. מישהו מהחברה שלך שולח לך דואל: “אני לא בטוח שהתמונה הזאת מעודדת אנשים להקליק”
  2. אשתך שולחת לך דואל שאומר “אני ממש לא אוהבת את הצבע הזה”
  3. קולגה שלך קופץ למשרדך ואומר “אתר יפה! אבל יש לי בעיה אחת איתו - זה ממש מרגיז אותי שאני צריך להקליק כדי לעשות את הדבר ההוא”
  4. הבוס שלך - למרות שאישר את זה קודם - אומר “אני חושב שאנחנו צריכים לעשות משהו עם המיקום של הטקסט. לא נראה לי שהוא עושה את העבודה במיקום הנוכחי שלו”
  5. כל התשובות לעיל
  6. אף אחת מהתשובות לעיל
אם בחרת 5, ניצחת. חשבת שזה 6, נכון? תתבייש לך. קל לשכוח שבאינטרנט, העולם הוא בסיס המשתמשים שלך. חלק יותר חשובים לך מאחרים, ואתה ללא ספק חייב לשקלל את זה בקבלת ההחלטות העיצוביות שלך. אבל השלם עם העובדה שכל אחד הוא משתמש, וכל המשובים הם תמימים עד שיוכח אחרת. ככל שתשלים עם זה מהר יותר, יקל עליך לתכנן אתרים תותחיים.
אני בסך הכל ממליץ לך לשמוע מה שיש לכל אחד לומר; בודאי שיש הצדקה להתעלמות מחלק מהמשובים, אבל אל תתעלם ממנו לפני שהפנמת אותו. נסה לנתק את עצמך מהצורך לחשוב על זה כביקורת, ובמקום זה חשוב על זה כרמז למשהו שבור. ברגע שהאתר שלך הושק, אתה בלש - כל הזמן מחפש רמזים - מנסה לגרום לאתר שלך להגיע לזן הפוטנציאלי שלו (במקום לנסות לפתור תעלומה). אם תהיה מאזין קשוב, המשתמשים יעשו בשבילך את כל העבודה הקשה בזה שיתנו לך רמזים. שלב אותם עם כלי ניתוח אתרים (site analytics) ואין ספק שתצליח.”

לאה כהן | 18 במאי 2009 | כללי | אין תגובות

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

להלן כמה דברים שניתן לעשות כדי להוציא מתוק מעז:

  • להשתמש ברשימה (checklist) של הדרישות בסוף הסעיף הזה (*) כדי להעריך את מסמך הדרישות אם הדרישות לא טובות מספיק, אז צריך להפסיק לעבוד, לחזור אחורה, ולתקן אותן לפני שממשיכים. נכון, זה נותן תחושה שאנחנו מתעכבים אם מפסיקים לקודד בשלב הזה. אבל אם אנחנו נוסעים משיקגו ללוס-אנג’לס, האם זה בזבוז זמן לעצור ולהתבוננן במפה כשאנחנו רואים שילוט לניו-יורק? לא. אם נוסעים בדרך לא נכונה, עלינו לעצור ולבדוק את הכיוון
  • לוודא שכולם יודעים את מחיר שינוי הדרישות לקוחות מתרגשים כשהם מצליחים לחשוב על פיצ’ר חדש. בהתרגשותם, הדם שלהם מתדלל וזורם ללשד עצמותיהם, והם נהיים מסוחררים, ושוכחים את כל ישיבות האפיון שהיו, את טקס החתימה, ואת כל מסמך הדרישות. הדרך הקלה ביותר להתמודד עם מורעלי-פיצ’רים כאלה היא לומר: “וואו, זה נשמע רעיון מצוין. מאחר שזה לא נמצא במסמך הדרישות, אני אצור כעת לוח זמנים מעודכן והערכת עלות, כדי שתוכל להחליט אם אתה רוצה להוסיף את זה עכשיו או אחר-כך”. המלים “לוח זמנים” ו”עלות” מפכחים יותר מקפה ומקלחת קרה, והרבה פיצ’רים “חיוניים” יהפכו להיות “נחמד אם יהיה”
  • ליזום הליך בקרת שינויים אם ההתלהבות של הלקוח ממשיכה, שקלו הקמת ועדת בקרה רשמית שתסקור הצעות לשינויים. זה בסדר גמור אם הלקוח משנה את דעתו ומחליט שהוא זקוק ליכולות נוספות. הבעיה היא שהם מציעים שינויים בתדירות כל כך גבוהה, שאי אפשר לעמוד בקצב. הליך מובנה של בקרת שינויים משמחת את כולם. אתם שמחים כי אתם יודעים שתצטרכו לעבוד על שינויים רק בזמן מסוים. הלקוח שמח כי הוא יודע שיש לכם תכנית לטיפול בבקשות שלו
  • להשתמש בגישות פיתוח המתאימות עצמן לשינויים ישנן גישות פיתוח הממקסמות של היכולת להגיב לדרישות משתנות. גישת אב טיפוס אבולוציוני מסייעת לחקור דרישות מערכת לפני ששולחים את כל הכוחות לבנות אותה. מסירה אבולוציונית היא גישה המוסרת את המערכת בשלבים. אפשר לבנות מעט, לקבל מעט משוב מהמשתמשים, לתקן קצת את הכיוון, לעשות כמה שינויים, ולבנות עוד קצת. המפתח הוא שימוש במחזורי פיתוח קצרים כדי שאפשר יהיה להענות למשתמשים במהירות
  • להיפטר מהפרוייקט אם הדרישות הן גרועות במיוחד או הפכפכות, ואף אחת מההצעות לעיל אינה אפשרית, בטל את הפרוייקט. אפילו אם זה לא אפשרי ממש לבטל את הפרוייקט, דמיינו איך זה יהיה לבטל אותו. נסו לחשב לאיזו רמה גרועה הפרוייקט יצטרך להגיע כדי שאפשר יהיה לבטל אותו. אם יש מקרה שבו הייתם נפטרים ממנו, לפחות שאלו את עצמכם מה ההבדל בין המקרה ההוא למקרה הנוכחי.
  • לשמור על ה-business case של הפרוייקט הרבה ענייני דרישות נעלמים בקלות ברגע שחוזרים לסיבה לעסקית שבגללה הותחל הפרוייקט. דרישות שנראו כרעיונות טובים כשחשבו עליהם כ”פיצ’רים”, עשויים להראות כרעיונות גרועים כשמנסים לחשב את “הערך העסקי המוסף”. מתכנתים הזוכרים להתחשב בהשפעה העסקית של ההחלטה שלהם שווים את ערכם בזהב - למרות שהייתי שמח לקבל את העמלה שלי על הייעוץ הזה במזומן.

(*) הרשימה נמצאת בעמוד 42 בספר. לצערי היא ארוכה מכדי להעתיק אותה לכאן.

לאה כהן | 7 במאי 2009 | כללי | אין תגובות

User Interface Engineering היא חברה בראשותו של Jared Spool, מומחה usability ידוע. באתר החברה הוא מפרסם מאמרים רבים בנושא שמישות וחווית משתמש.
במאמר שקראתי שם לאחרונה, מוצגות 3 שאלות שכל חברה שרוצה ליצור מוצר עם חוויית משתמש נפלאה צריכה לשאול את עצמה.

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

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

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

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

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

לאה כהן | 25 בינואר 2009 | מנשק משתמש, פיתוח, שמישות ושימושיות | תגובה אחת

כמה מחשבות מהירות על אבטחת מידע.

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

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

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

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

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

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

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

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

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

זה הכל.

:)

יהונתן לרנר | 11 בדצמבר 2008 | אינטרנט, כללי | 4 תגובות

זהו, נראה לי שזה הפוסט האחרון בנושא החדש והמסעיר של יעילות.
בפוסט הזה אני מביאה כמה קישורים שקשורים לכמה נקודות שעלו בהרצאה של ד”ר טל בן שחר.
כשד”ר בן שחר דיבר על לחץ (stress), הוא אמר שהבעיה אינה הלחץ עצמו, אלא חוסר ההתאוששות ממנו. על זה יש לאדון זן (כוכב הפוסט הקודם) מאמר הנותן 15 דרכים בטוחות לעשות סדר במוח.
חוץ מעשיית סדר במוח כאמצעי התאוששות מלחץ, ד”ר בן שחר דיבר גם על להיות נוכח. להיות נוכח פירושו שכשעוסקים בפעילות מסויימת, או מבצעים משימה מסויימת - יש לעסוק בזה נטו, בלי לערב שום פעולות אחרות. למשל כשנמצאים עם המשפחה, לא לענות לטלפונים ולבדוק דואלים. לאדון זן (אולי הוא יהיה גם כוכב הפוסט הזה…) יש שלושה פוסטים של הדרכה, השראה וטיפים מעשיים, לאנשים עסוקי-היתר (מי אלה?), כיצד להיות נוכחים ברגע.
דרך נוספת שד”ר בן שחר המליץ עליה להרגעה היא נשימות. פסיכיאטרית שכתבה פוסט אורח אצל אדון זן מסבירה כיצד להרגע תוך 6 שניות. לא צריך רבע שעה מנוחה, או חצי שעת שינה. מספיקות 6 שניות כדי להרגיע את עצמנו. איך אפשר לתת לעצמנו את המתנה של נשימות מרגיעות אפילו בימים הכי לחוצים שלנו? אחת האפשרויות היא לקשור את הנשימות המרגיעות עם פעילות שחוזרת על עצמה במשך היום. למשל, אם את מזכירה, אז כל פעם שהטלפון מצלצל, תנשמי (גם אחרי 6 שניות אפשר להספיק לענות לטלפון). לכל אחד מאיתנו יש הרבה פעילויות שחוזרת על עצמן - לחיצה על כפתור שמירה, כתיבת דואל, קומפילציה. לא חסר לנו למה לקשור, פשוט צריך להתחיל עם זה.
הדבר האחרון שד”ר בן שחר דיבר עליו הוא הכרת תודה. התבוננות בטוב שבחיינו ממקדת אותנו בפן החיובי של חיינו, ומכלל הן אתה שומע לאו.
לפני למעלה משנה התוודעתי לסרט הסוד. הסרט מתאר איך למשוך לחיינו את הדברים שאנו רוצים בהם, איך לממש מטרות, ואיך להרחיק דברים בלתי רצויים. הדרך העיקרית להגיע לזה היא ע”י התמקדות בדברים שאנו רוצים (זה בניגוד לכך שהרבה אנשים מתמקדים, מדברים וחושבים דווקא על הדברים המפריעים והבלתי רצויים בחייהם). על אף שהסרט קצת נוטה לניו-אייג’יות, ואינו מתאים לציניקנים, אני מאד התחברתי אליו.
הסרט מחולק ל-9 חלקים בני 10 דק’ כ”א, ובפרק הרביעי הסרט מדבר על הכרת הטוב כאמצעי למשיכת הדברים הטובים לחיינו. יש שם גם טכניקה איך ליישם את הכרת התודה כל יום בחיינו (בדומה לנשימות, גם האיש בסרט מראה איך הוא קושר את הפעילות של הכרת התודה לפעילות יומיומית שהוא מבצע), וגם סיפור על איך הכרת תודה הצילה חיים של ילד באפריקה (אמרתי ניו אייג’י ולא לציניקנים, לא?).
ואסיים בפוסט אחרון של אדון זן, הקשור ל”הסוד”: איך להיות ממוקד. שווה קריאה.
אז זהו, גמרתי לחפור. כל הכבוד למי שהגיע עד הלום!

לאה כהן | 8 בדצמבר 2008 | יעילות | אין תגובות

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

לפני שנה וחצי בערך התוודעתי לבלוג בשם “הרגלי זן” (Zen Habits) . מחבר הבלוג דוגל בפשטות וביעילות, וכל הפוסטים שלו עוסקים באספקטים שונים של נושאים אלה.
אז הפוסט הראשון שמתאים בנושא הזה, כותרתו (באופן מפתיע) היא “איך לא לעבוד בריבוי משימות”. הוא מתחיל במניית 3 סיבות לכך שריבוי משימות הוא גרוע, וממשיך בכללים הבאים (שאת החשובים שבהם הוא מפרט בפוסטים אחרים שאצטט כאן לרווחת תושבי הסביבה):
- ליצור רשימת משימות (to-do list);
- שיהיה כלי לרישום הערות ועניינים אחרים;
- שיהיה Inbox פיזי ודואלי;
- לתכנן את היום בבלוקים;
- דבר ראשון בבוקר - להתחיל מהמשימות החשובות ביותר;
- לכבות את כל המסיחים;
- להלחם בצורך לבדוק דואל ושות’;
- אם נכנסים דברים חדשים תוך כדי ביצוע המשימה הנוכחית להכניס אותם לאחד ה-Ibox-ים (הפיזי או הדואלי);
- כל כמה זמן לעבד את מה שיש ברשימות וב-Inbox-ים;
- אם מה שנכנס תוך כדי המשימה אינו סובל דיחוי, אז לרשום כמה שיותר דברים מהמשימה הנוכחית שיאשרו לנו לחזור אליה באופן חלק.

העיקר בגישה של אדון זן (שקוראים לו באמת ליאו בבוטה, אבל בליבי אני קוראת לו Mr. Zen Habits), כפי שאני תופסת אותו, הוא הנושא של MIT - המשימות החשובות ביותר (Most Important Tasks), לכן ארחיב על זה קצת: MIT הוא המשימה שאתה הכי רוצה או הכי צריך לבצע היום. במקרה של אדון זן, הוא שינה את זה ל-3 משימות - 3 דברים שהוא מוכרח לבצע היום. כמובן שהוא מצליח לבצע יותר מ-3 משימות, אבל הרעיון הוא שלא משנה מה עוד אני עושה היום, אלה הדברים שאני רוצה לוודא שאני מבצע. אז ה-MIT הוא הדבר הראשון שהוא מבצע כל בוקר. והנה המפתח ל-MITים שלו: לפחות אחד ה-MIT-ים צריך להיות קשור לאחת המטרות שלו בחיים (וכאן הוא מפרט איך לבחור מטרות בחיים). שתי המשימות האחרות יכולות להיות בענייני עבודה (והן בד”כ אכן כאלה), אבל אחת חייבת להיות הצעד הבא באחת המטרות שלו. כך הוא מוודא שהיום הוא עושה משהו כדי לקדם את המטרות שלו. וזה הדבר הכי משמעותי: כל יום הוא עושה משהו להגשמת חלומותיו. עוד מפתח: לעשות את ה-MIT-ים דבר ראשון בבוקר, בבית או מיד כשמגיעים לעבודה. אם דוחים אותם, אז נהיים עסוקים והזמן בורח. תגמרו איתם, ושאר היום הוא רווח נקי!
בפוסט נוסף בנושא המעטת משימות, אדון זן מסביר למה 3 זה המספר האופטימלי של משימות להקצות לעצמנו: מצד אחד 3 זה מספר קטן, ואמרנו כבר שאנחנו צריכים לנסות להספיק פחות כדי להספיק יותר; ומצד שני אילו היתה לנו רק משימה אחת והיא היתה נתקעת (למשל, היינו מחכים למישהו אחר שיבצע חלק במשימה) אז היינו מבטלים את זמננו בהמתנה חסרת מעש.
גם הנושא של תכנון יום העבודה הוא משמעותי מאד בדרך להיות יעילים. במאמר בניו-יורק-טיימס מלפני שנה, מסבירה יועצת יעילות איך תכנון נכון יכול להשפיע לטובה.

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

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

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

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

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

לאה כהן | 2 בדצמבר 2008 | יעילות | אין תגובות

ב”ה כולנו עסוקים בעבודה. אני אומרת ברוך ה’ כי זה טוב - העובדה שאנחנו עסוקים פירושה הוא שיש עבודה, וכשיש עבודה יש פרנסה (בינתיים).
כשאנחנו עסוקים זה בד”כ מפני שאנו עובדים על מספר פרוייקטים בבת אחת, ובכל פרוייקט הרבה משימות. מאחר שבכל פרוייקט אנחנו צריכים להראות התקדמות (כדי שאף פרוייקט לא ירגיש מקופח) ההתמודדות שלנו היא לעבוד כמעט בבת אחת על כמה משימות. ניצול הזמן האופטימלי נראה כך: אנחנו כותבים אפיון של פרוייקט א’, תוך כדי זה מקבלים טלפון ומטפלים בענין של פרוייקט ב’, ומיד אח”כ נכנסים לישיבה עם נציג פרוייקט ג’, והופ - עברה שעה, והתקדמנו בשלושת הפרוייקטים. הפלא ופלא! עובד מצטיין של השנה!
אבל האם באמת ניצלנו את השעה הזאת באופן המקסימלי? האם ההתקדמות שלנו בכל פרוייקט בשעה הזו היתה ההתקדמות המירבית האפשרית? ג’ואל ספולסקי טוען שממש לא. במאמר שהוא כתב כבר לפני כמה שנים, המנתח את זמני העבודה על 2 משימות, הוא משווה בין הזמן שלוקח לכל משימה כשהעבודה נעשית באופן טורי (משימה אחת אחרי השניה), לבין הזמן שלוקח לכל משימה כשהעבודה נעשית באופן מקבילי (מעבר בין שתי המשימות).
מעבר לעובדה שבעזרת תרשים מאד פשוט הוא מראה כי ממוצע הזמנים של משימה קטן כמעט בחצי כאשר עובדים על המשימות זו אחרי זו, הוא מכניס אלמנט משמעותי למשוואה: זמן מעבר בין משימות. כשעוסקים במשימה הדורשת ריכוז גבוה, זמן המעבר בין המשימות הוא משמעותי. כשעוסקים בעיצוב, בתכנות, בכתיבת מסמך אפיון - אנחנו שומרים במוח הרבה דברים בבת אחת. אם עוזבים את המשימה הזו לטובת משימה אחרת - כל הדברים שהיו שמורים במוח נמחקים. ג’ואל מספר שהיה אצלם מצב שבו הם היו צריכים להפסיק את עבודת הפיתוח כדי לעזור ללקוח במצב חרום למשך שלושה שבועות. כשהם חזרו למשרד, נראה היה שעברו שלושה שבועות נוספים עד שחזרו לתפוקה מלאה בפיתוח.
ג’ואל מתחיל את מאמרו באמירה ש”הפלת תיקים” על אנשים היא חרב פיפיות: אם עושים אותה נכון, אפשר להשיג יעילות מהממת. אבל אם לא - מגיעים למצב שבו לא מצליחים לסיים שום דבר וכולם מתלוננים ש”אף פעם לא עושים כאן שום דבר”.
המאמר שלו מסתיים במסקנה חדש משמעית: “never let people work on more than one thing at once”.

לאה כהן | 19 בנובמבר 2008 | יעילות, פיתוח | 2 תגובות

ביום חמישי האחרון, ה 13.11.08 צוין בכל העולם יום השימושיות הבינלאומי (World Usability Day). ו UPA Israel גם השנה ארגנו כנס שכלל יום של הרצאות שהיו בתחום התחבורה (שהיה הנושא המרכזי שנבחר ליום השימושיות הבינלאומי), ממשק וחווית משתמש, וכולם (מי יותר מי פחות) היו בסימן making life easy והביטים של שימושיות.

פרופ’ יורם עשת דיבר על הקריאה בעידן הדיגיטאלי. ההנחה היא שעד 2020 כ 70% מחומרי הקריאה יהיו דיגיטאליים. ישנם הבדלים מהותיים בין קריאת טקסט מודפס לדיגיטאלי כמו :

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

האתגר בכתיבה (בכל מדיום) היא היכולת לכתוב טקסט קריא ומועיל. וחשיבות הקריאה היא הקריאה הביקורתית.

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

שני מרצים נוספים שהתייחסו לאופק הדיגיטאלי בשנת 2020 (ובאמת מעניין לדעת למה נבחרה דווקא השנה הזו). בנסיעה הביתה סרג’ הסב את תשומת ליבי ששניהם דיברו על העתיד וכל אחד רואה אותו אחרת לגמרי. דר’ ישע סיוון דיבר על :3D3C
3D + Community, Creation and Commerce
שהוא בעיניו לא עוד תת קטגוריה בהתפתחות ה
web, תחת web 3.0, אלא הוא רואה אותו כשלב הבא. דר’ ישע מדבר על עולמות וריטואלים אשר יתפסו נתח גדול יותר בחיינו. הוא לא מדבר על עולם וירטואלי אשר יחליף את העולם שלנו אלא יעשיר ויעצב אותו. ה”שמים הם הגבול” ללא ספק הגדרה מעליבה ליכולות של ה second life והיכולת של שילוב החיים האמיתיים בעולם הוירטואלי מעניינים מאוד (כמו למשל הרחבת המושג video conference משיחה שבו כולם רואים את כולם ליכולת לדמות את השהייה המשותפת במשרד ובו זמנית לצפות במצגת מועברת ובצד המסך גם לראות את האנשים בשר ודם). ד”ר ישע העלה כמה בעיות שמישות שנגעו לחומרה (העכבר – כרגע אין אפשרות לנווט באמצעות עכבר) ממשקי התוכנה ועוד.

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

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

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

פרסונליזציה שנעשית ע”י המערכת / אפליקציה יכולה להיות מוצלחת ויכולה להיות מיותרת או כשלון. לדוגמא – סרגל הניווט העליון של word על האופציה של >> כלפי מטה והצגת הפריטים שהמשתמש משתמש בהם יותר בחלק העליון. אחת הבעיות הגדולות של זה היה שינוי בממשק דבר שגורם לחוסר התמצאות. שבירת הסטנדרט מצריכה גם הטמעה.

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

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

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

שיהיה לכולנו שנה של שימושיות בכל אשר נלך וכמובן בכל אשר נעצב ונתכנן.

רחלי ברט טננבאום | 17 בנובמבר 2008 | אינטרנט, כנסים ואירועים, רשתות חברתיות, שמישות ושימושיות | 3 תגובות

בצעירותי יצא לי להשתתף בפורומים, ותופעה שראיתי כמעט בכל הפורומים בהם השתתפתי היתה הופעתם של טרולים. טרולים הם משתתפים שכל מהותם היא לקלקל את ההנאה של משתתפי הפורום, או אם נשתמש בהגדרתו של ג’ואל ספולסקי: “כל המשתתפים רוצים לשחק שח-מט, והטרול רוצה לשחק בלזרוק את כל חיילי השחמט סביב”.

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

היזמים שלו - ג’ואל ספולסקי וג’ף אטווד - משדרים פודקאסט שבועי בו הם משתפים את המאזינים באספקטים שונים של בניית האתר.

אחד הנושאים שהועלו היה התמודדות עם השתתפות בלתי רצויה באתר.

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

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

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

ג’ואל לעומת זאת טוען (החל מדקה 31) שיש 2 אופציות: אפשר להתעסק עם אנשים שרוצים לריב, וזה מה שהם רוצים. או שאפשר לא להתעסק איתם ואז הם ישתעממו וימשיכו הלאה. ג’ואל קיבל את ההשראה לחשיבה הזאת - על אי-התעסקות - בעקבות אתר שהוא הכיר שהיה בו טרול. מנהלי האתר ידעו שאם הם ינסו לנדות את הטרול, הוא רק יצור חשבון אחר, או ישתמש בשם אחר, או ישיג כתובת IP אחרת או ימצא דרך אחרת לעקוף את המערכת. והוא יהיה מאד נרגז כך שתהיה לו מוטיווציה לעשות את זה. אז במקום זה הם קינפגו את השרת של האתר שלהם כך שכל מי שנכנס מכתובת ה-IP של המשתמש הזה, או אולי מטווח כתובות ה-IP שלו, השרת פשוט לא היה מגיב, והמשתמש קיבל הודעת שגיאה של TimeOut. השרת פשוט היה מריץ איזו לולאה של 30 שניות ואז מפסיק. התוצאה היתה שהמשתמש פשוט חשב שהמערכת דפוקה. הוא החליט שהמערכת איטית ובנויה בצורה גרועה והוא פשוט התייאש ממנה….

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

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

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

ואיך בכל זאת פותרים את הבעיה הזאת ב-stackoverflow? שם יש שיטה אחרת: כל משתתף יכול להחליט לתייג הודעה בתור offensive, ואם כמות מספקת של משתתפים תייגו אותה ככזאת, היא יוצאת מהמערכת. יש גם עניין של הצבעות - up-vote ו-down-vote. גם בפודקאסטים 19 (לקריאה, להאזנה) ו-20 (לקריאה, להאזנה) יש דיונים על צדדים אפלים באתרים חברתיים. מומלץ למי שהנושא הזה מעניין אותו.

לאה כהן | 23 באוקטובר 2008 | אינטרנט, אתרים, רשתות חברתיות | 3 תגובות

פוסטים אחרונים

כלים

בלוגרול

קישורים


RSS חדש בכליקיט

RSS חדש בכליקיט מומלצים