כיצד להשפיע בתוך הארגון גם ללא סמכות רשמית

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

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

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

• שמיכה קצרה מדי (בעיית reach) – הרבה קבוצות UX מתנהלות במצב של חסר משמעותי במשאבים. במקום היחס האופטימאלי של איש UX אחד לכל שלושה מפתחי Front-End, בארגונים המובילים אנחנו רואים יחס של 1 ל- 5, וברובם אנחנו נאלצים להסתפק אפילו ביחס של 1 ל- 10 ואף למטה מכך. בין אם נאהב זאת ובין אם לא, עדיין, בשנת 2019, UX נתפש קצת כפריווילגיה של עשירים וכ"שומן" שאפשר לוותר עליו. זה בתורו יוצר מצב אוטומטי שלאנשי ה- UX פשוט אין אפשרות לתת מענה לכל הפרויקטים בארגון. ובמצב עניינים שכזה, ברור שהארגון לא ירצה לכבול את עצמו בשלשלאות, ולהפוך את עבודת ה- UX ע"י קבוצת ה- UX כשלב הכרחי בתהליך.
• מיצוב בעייתי – אנשי ה- UX נתפשים לעיתים קרובות, בצדק או שלא, כמי שאינם מחוברים למציאות – כמעין ארטיסטים שאין לצפות מהם לערכים של פרגמטיות וריאליזם, ושיש להוריד אותם לקרקע. התוצאה היא שהארגון מוצא לנכון להכפיף את קבוצת ה- UX לקבוצת המוצר, או גרוע מכך, לקבוצת הפיתוח. זה יכול לעבוד בסדר, אבל זה אוטומטית שם את קבוצת ה- UX בעמדת התגוננות. כשהכל עובד כמו שצריך העמדה הזאת לא מפריעה, אבל כשמתגלעות מחלוקות, הנחיתות המובנית עלולה לבוא לידי ביטוי.
• מבנה ארגוני – ברוב הארגונים הגדולים בארץ אין עדיין מנהלי UX בדרגת ניהול בכירה (C Level), וברובם אף מסתפקים בדרגות של ניהול זוטר כגון Team Lead או Manager לכל היותר. זה לא יכול להיות מקרי, בודאי לאור העבודה שבארגונים מקבילים בעולם המצב שונה – בארגונים רבים בארה"ב אנשי UX ממלאים תפקידי CDO (או CXO) שמשפיעים על הכיוון האסטרטגי של הארגון ועל תהליכי העבודה הרשמיים שלו. זאת עדות נוספת לכך שלארגונים בישראל יש עוד דרך לעשות בהקשר הזה – קבוצת המוצר והפיתוח יצטרכו ללמוד לוותר קצת מכוחן לטובת תהליכי עבודה מועילים יותר. אך בינתיים, באופן טבעי, דרגות הניהול הנוכחיות לא יכולות להשיג את הסמכות הרשמית שאמורה להתלוות לאחריות התפקיד, ונאבקות כמעט מדי יום להשיג הישגים ללא ההגדרה הרשמית.

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

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

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

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

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

1. שיתוף פעולה טוב עדיף על אכיפה – אנשים שמבינים את הערך של משהו ייטו הרבה יותר לשתף פעולה מאשר אם יכריחו אותם לעשות זאת. לכן חשוב מאוד לנמק היטב את העבודה שלנו, וחשוב עוד יותר להביא ערך משמעותי. הערך המשמעותי הזה בא בד"כ בכמה מישורים:
   • כאשר אנחנו מצליחים לשנות את התפישות של מנהל המוצר או הפיתוח (ועל כך אולי אספר בהרחבה בפעם אחרת)
   • כאשר אנחנו מספקים פתרונות פרגמטיים
   • כאשר האנשים שאיתם אנו עובדים רואים שאנחנו קשובים למגבלות של זמן ומשאבים
   • כאשר אנו מספקים תוצרים שאף אחד אחר בארגון אינו יכול לספק – לרוב יהיו אלה תוצרים גרפיים שמעט מאוד אנשים בארגון מחזיקים במיומנות הדרושה על מנת להפיק אותם.
2. יש לכבד את המקום של מנהלי המוצר – לרוב מנהלי המוצר יש נסיון רב והם יודעים על מה הם מדברים, וממילא הארגון הטיל עליהם את המשימה לנהל את קידום המוצר, ולכן חשוב לכבד את גבולות הגזרה. נכון, לעיתים קשה לראות היכן איש המוצר נגמר ואיש ה- UX מתחיל, והסינרגיה ביניהם מאוד חשובה, אך מערך הכוחות הבסיסי צריך להיות ברור – כל עוד לא מדובר בהחלטה UXית טהורה, מנהל המוצר צריך להיות זה שקובע את ה"מה" ואיש ה- UX את ה"איך".
3. מעורבות אמיתית – למעט אם ישנם אילוצים מיוחדים (למשל, בעיית reach קשה כפי שתיארתי קודם לכן), איש ה- UX צריך להיות חלק אינטגרלי לחלוטין של הפרויקט – עליו להשתתף בכל הרוטינות של הפיתוח, להכיר את הפרטים, האילוצים ולוחות הזמנים לעומק, לקחת חלק בבדיקות האיכות, לפתוח באגים ולעקוב אחריהם. אבל איש UX מצטיין במיוחד עושה גם קצת מעבר – הוא משמש כיד ימינו של איש המוצר. אם נדמה את זה לקבוצת כדורסל, איש המוצר הוא המאמן ואיש ה- UX צריך להיות הרכז – השחקן שמחבר את השחקנים האחרים ומניע את המשחק קדימה. הוא בד"כ "שחקן נשמה" שתפקידו להוציא לפועל את הוראות המאמן ולתת את המענה הרצוי על המגרש ברוח המאמן. יחד עם זאת, וכאן גם מגיע הגבול של האנלוגיה לכדורסל, צריך לזכור את הנקודה הקודמת ולדעת מתי לעצור. ואם בכל זאת נרצה להצמד לאנלוגיה – צריך לדעת מתי לבקש פסק זמן כדי להתייעץ עם המאמן ושאר חברי הקבוצה.
4. יש לכבד את המגבלות הטכנולוגיות ואת אילוצי הזמן – אנשי UX הם לרוב אנשים יצירתיים, והם אוהבים לחדש. זאת תכונה נפלאה שיש לשמר אותה, אבל לעיתים היא מתנגשת עם מגבלות המציאות. לכן חשוב מאוד להסביר לאנשי הצוות בקבוצת ה- UX שמציאת פתרונות פרגמטיים זה חלק מהמקצועיות שלהם. לאנשי הצוות שלי תמיד אמרתי שתשובה כמו "זה לא הפתרון האידאלי אבל הוא עובד היטב במסגרת האילוצים" היא תשובה תקפה לגמרי, ואני אהיה הראשון להעריך אותה. יחד עם זאת, חשוב לוודא שנעשה נסיון אמיתי ורציני לעשות את הטוב ביותר, ושמסגרת האילוצים לא הופכת לתירוץ קבוע.
5. יש לקחת את המשוב שאנו מקבלים ברצינות רבה ולהתייחס אליו כאל הזדמנות להשתפרות – אני מוצא את הנקודה הזאת קשה במיוחד לאנשי ה- UX, בעיקר למתחילים שבינינו. לכולם קשה לקבל ביקורת, אבל כיוון שרובנו פרפקציוניסטים מטבעם, נראה שלנו קשה במיוחד. אנחנו לא אוהבים לטעות. כדי להתמודד עם הקושי הזה, אני מציע לאנשי הצוות שלי לעבוד לפי המודל הבא:
   השלב הראשון הוא לעצור ולהקשיב. אבל באמת להקשיב. אולי יש ממש במשוב שקיבלנו? אולי הוא מוצדק? זה שלב שדורש אימון כיוון שהוא מחייב לשים את האגו בצד.אם לאחר שבדקנו את עצמנו פעם נוספת בכנות, אנחנו עדיין משוכנעים בצידקתינו, עוברים לשלב השני: תחת ההנחה שההתנגדויות הן ענייניות ולא נובעות מקושי פוליטי כזה או אחר, יש להתייחס לקושי כאל אתגר שיכנועי. זה אומר לנסות להסביר עוד פעם, אך בדרך קצת שונה. אגב, התנגדויות ענייניות לא חייבות להיות מקצועיות, הן יכולות להיות גם פסיכולוגיות – למשל, פחד משינוי הרגלים שהוא מאוד מאוד נפוץ, בעיקר באוכלוסיות מסוימות כמו אצל רופאים לדוגמא. יש לזהות את מקורות ההתנגדות ואז יש להתמודד איתם בהתאם. למשל, אם זיהינו שמנהל המוצר חושש לקחת את הסיכון שמשתמשים יידחו את העיצוב החדש, אנחנו יכולים להציע לו לבצע בדיקת שמישות שתפריך (או אולי תאמת) את החשש שלו.
   אם נכשלנו גם בשלב הזה, אני מציע שנשאל את עצמנו אם המלחמה הזאת משתלמת. לא כל דבר שווה מריבות והתכתשויות, ולעיתים עדיף לוותר למען שלום בית. לבסוף, אם בדקנו את עצמו ביושר, ניסינו לזהות את מקור ההתנגדויות ועשינו מאמץ נוסף ושונה לשכנע, והגענו למסקנה שמדובר במלחמה צודקת, אפשר לעלות במדרג הניהולי למנהלים שלנו ולבקש מהם עזרה.
   השלבים הללו חשובים כי הם מקטינים חיכוכים למינימום ההכרחי, אך מאפשרים לנו להשפיע באופן אפקטיבי, דבר שבתורו הופך אותנו לאנשי מקצוע טובים יותר ולכאלה שניתן לסמוך עליהם.

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

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

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

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

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

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

תודה רבה לשי אבירם על העזרה בעריכת המאמר