לחשוב Developer eXperience (DX)

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

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

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

זה עבד! ומאז המטאפורה הזו התפרסמה כדוגמה.

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

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

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

סקר של מקינזי בקרב "מומחים"/מנהלים בכירים מה משפיע על הפריון של מפתחים

Code-level DX

אני רוצה להתחיל בשימוש במטאפורה של DX לרמת הקוד, בכדי לעזור לנו לכתוב קוד טוב יותר.
נתחיל בדוגמה קצת קשוחה… אובייקט ה java.util.Date (שהוחלף לחלוטין בג'אווה 8)

  println(new Date(2020, 5, 35)) // Result: Mon Jul 05 00:00:00 IDT 3920
  println(new Date(120, 4, 1)) // Result: Fri May 01 00:00:00 IDT 2020

כאשר אני מאתחל את אובייקט ה Date בג'אווה ל 35 במאי 2020, אני מקבל את התאריך 5 ביולי 3920.
למה?? איך?!
אובייקט ה Date הציג Interface שהוא פשוט זוועה, במיוחד בגרסאות הראשונות שלו (ה constructor בו השתמשתי הוא deprecated):

  • את השנה מצפים שאספק מ 1900 (על משקל Java Epoch 🤯), כך כ 2020 היא 120.
  • את החודש מצפים שאספק באינדקס-0, כך ש 5 הוא יוני (כי 0 הוא ינואר… לא ברור?)
  • אם יש גלישה של ימים (35 ביוני) אז לא תיזרק שגיאה, אלא יוסיפו את הימים כבר לחודש הבא (ההפך מ Fail Fast) – וכך הגענו ל 5 ביולי.

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

אם אתם רוצים לעשות DX טוב אתם צריכים לכתוב API/Interface שמפתחים ייהנו לעבוד אתו. לא… לא "יצליחו לעבוד" אתו – ייהנו לעבוד אתו!
השאיפה הזו להנאה עשויה להציב את הרף הנכון לרמת הקוד שאנו מבקשים, כפי ש"כל הפארק הוא במה" עזר לעובדים של דיסני להבין את רף החוויה שהם מצופים היו לתת למבקרים בפארקים של דיסני.

הנה דוגמה הרבה פחות קיצונית:

fun DataPoints.plus(other: DataPoints): DataPoints {
    val intersectKeys = this.keys.intersect(other.keys)
    val intersectEntries = (this.entries + other.entries).filterKeys { it in intersectKeys }
    return DataPoints(intersectEntries)
}

אני משתמש בפונקציה בשם plus, שבעצם מבצעת חיתוך של איברים – כלומר: אני מסיים עם פחות איברים.
יכול להיות שבהקשר של Data Points זה הגיוני (מי יודע?! – נניח שאני לא מכיר את הדומיין), אבל זה לא אינטואיטיבי לי כאדם ולשכל הישר שלי. האם אני כותב את הקוד כ Domain Expert או כאדם?

כנראה שאני קופץ בין שניהם, ואם לרגע אני מסיר את "כובע" ה Domain Expert וחושב בהיגיון פשוט של אדם – זה מבלבל. אם בזבזתי עכשיו חצי שעה לדבג קוד רק כדי להבין שהפונקציה plus מצמצת את מספר האיברים – זה כנראה יוביל לכך שלא אהנה מה interface של הפונקציה – וזה אומר נקודת כישלון של DX. המחשבה על DX אמורה לשים את כל הטיעונים של "הצודקים לכאורה" של ה Domain בצד "אבל ברור ש…", "אבל ידוע ש…", אם אני מתבלבל כי לרגע חשבתי כאדם ונותרתי עם חוויה לא טובה – זה לא DX טוב.

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

דוגמה אחרונה, הסתכלו על ה interface הבא:

interface NoFun {

  fun updateCustomerDataPoints(customerId: CustomerId, dataPoints: List<DataPoint>)
  
  data class DataPoint(
    val type: DataPointType, 
    val value: DataPointValue, 
    val effectiveDate: LocalDate
  )

}

במקרה הזה אנו מעדכנים את הלקוח עם DataPoints מסוימים, אבל בתסריטים מסוימים חשוב לעדכן את ה effective Date על כל ה Data Points. ברור למומחה העסקי מדוע זה נכון, אבל אני מקווה שברור לכם הקוראים – מדוע לצרכן של ה API זה לא אינטואיטיבי, וקל לשכוח את זה – שלא לומר שלעבור על רשימה של איברים שאני שולח ולשנות אותם עלול להרגיש כמו משהו לא נכון או hacky שאני כמשתמש עושה. פעולה כזו לא מתאימה ל"שימושיות גבוהה"

שינוי קטן ב API (הוספה של שדה אופציונלי של effectiveDate) יכול לשדרג את השימושיות שלו בצורה משמעותית:

fun updateCustomerDataPoints(customerId: CustomerId, dataPoints: List<DataPoint>, effectiveDate: LocalDate? = null)

המימוש של ה API יעבור על ה Data Points ויעדכן את ה effective date שלהם – זו פעולה פשוטה. אבל עצם זה שהאופציה ניתנת לי בחתימת ה API: א. עוזרת לי לזכור אותה, ב. נוסכת בי בטחון שאני עושה את הדבר הנכון – ולא איזה hack שתוצאותיו לא ברורות. נראה שחסר כאן תיעוד שמסביר כיצד ומתי בדיוק לשלוח ערך ב effective date – זה עדיין לא טריוויאלי מספיק מתוך החתימה.

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

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

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

DX ברמת ארגון הפיתוח

DX הוא מטאפורה מצוינת למפתחים, שיעזור להם ליצור APIs, Intefaces, ובכלל קוד טוב וקריא יותר. השאלה "האם מי שישתמש בקוד שלי עומד ליהנות?" – תוביל למסקנה שונה (והרבה פעמים: טובה יותר) מאשר השאלה "האם הקוד הזה בסדר / תקין / מסודר?"

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

תלונות כמו:

  • "ה Build אטי"
  • "ה Security Tools והדרישה להכניס סיסמה כל פעם – פשוט מטרידים"
  • "לפתוח באג בג'ירה זה פשוט סיוט… למה זה כ"כ מסובך?"

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

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

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

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

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

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

קראתי כמה מאמרים שטענו ש DX גבוה יותר (איך מודדים?) משפיע בצורה משמעותית על הצלחת הארגון ("פי 4-5") ועל שביעות הרצון של העובדים – אבל לא מצאתי נתונים משמעותיים ששווה להציג. רק דיבורים.

אני מניח שאלו הדברים שבשלב הזה הם עניין של אמונה: כמה אתם מאמינים ששיפור חווית הפיתוח של המפתחים בארגון שלכם תשתלם בפריון ושביעות רצון גם בלי יכולת למדוד כל שיפור? או עד כמה אתם נצמדים למה שניתן למדוד ותשקיעו רק היכן שיש ROI מוכח (כנראה: בעיקר בפריון).

העיקרון הראשון בשיפור ה DX למפתחים ברמת הארגון הוא להקצות בצורה בלתי-מפשרת משאבים איכותיים ומשמעותיים לנושא. אלו לא נושאים קלים.

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

מונח מתאים מעולם ה UX הוא ה Friction Log – תיעוד אזורים בהם קשה למשתמשים להתקדם ב UI המערכת והם חווים בהם תסכול. באופן דומה כנראה שכדאי לבקש מהמפתחים לשתף ולתעד – היכן הם חווים קושי, עיכובים, ותסכול ברמת הפיתוח, ובטוח שיש הרבה כאלו.

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

כמו בארכיטקטורה של מערכת, כדי להיות יעילים הרבה פעמים שווה להשקיע בלהפוך בעיות ברמת חומרה "High" לבעיות ברמת חומרה "low" או אפילו "רק medium" ולעבור לבעיה הבאה – מאשר לנסות להעלים את הבעיה לגמרי. Build Pipeline איטי מציק אם הוא אורך 30 דקות, אבל כנראה ש 10 דקות זה בסדר. המאמץ להביא אותו ל 2 דקות – עשוי להיות אדיר, ולא משתלם.

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

אני מאמין ש DX גבוה יכול להגיע רק מתוך שיתוף פעולה פרואקטיבי עם המפתחים וגם מניהול של העניין ע"י מישהו שמגיע מעולמות הפיתוח. לא Operations ולא תפעול.

סיכום

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

האם המטאפורה העדיפה (בשאיפה) – תוביל לתוצאות טובות יותר? אתם תגידו – אבל יש לי אופטימיות שייתכן וכן.

שיהיה בהצלחה!

המדריך המהיר לזום ברצינות

זום (Zoom) היא תוכנה שנפלה לחיינו כך פתאום, והפכה לאחת התוכנות שאנו מבלים במחיצתה הכי הרבה זמן.

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

  • אתם רוצים להזמין מישהו לפגישה שלא הוזמן מלכתחילה – כמה זמן לוקח לכם להזמין אותו?
  • שיתוף מסך/הקלטה – קרה לכם שלכמה רגעים לא מצאתם את הכפתור?
  • פגישה מרובת-משתתפים וקצת רועשת. איך מוצאים מי מרעיש? מה אפשר לעשות?
    • פגישות שחוויתי בבתי הספר של הילדים היו לעתים ממש קשות – כאשר ילד אחד התחיל לקשקש על המסך (annotate), ולא ידעו לאתר מי זה…
  • שיתוף וידאו מתוך Youtube קופץ / אודיו לא מסונכרן / אין אודיו
  • כאלה…
הייתי רוצה לכתוב את הפוסט הזה גם לחברי לעבודה, גם לעובדי חברות אחרות, וגם למורים בבתי-הספר של ילדי. נראה שקשה לקלוע לכולם – אך אנסה לכוון לאדם בעל אינטואיציה טכנית גבוהה, שלא הקדיש זמן להעמיק בזום ויכולותיו השימושיות.
למשל, אני, לא ידעתי להגדיר Virtual Background עד שהחלה הקורונה. עד עכשיו כבר ביליתי כמה מאות שעות בזום – מה שקצת קידם אותי.
בואו נתחיל.
״זום זום זום…״

קביעת פגישות: קישור קבוע או קישור משתנה?

קביעת פגישה בזום נעשית על החשבון (Account) של מי שהזמין אותה.
לכל חשבון יש Meeting Id אחד קבוע – שייחודי רק לו.
אני יכול לבחור אילו פגישות ייקבעו על ה Meeting Id הקבוע, ואלו על Meeting Id זמני.
  • Meeting Id קבוע – אנשים יכולים לשמור את הקישור או אפילו לזכור (בעזרת Alias – אפרט בהמשך). מספיק לומר בסלאק למישהו ״בוא ניפגש בזום״ – והצד השני יכול להתחבר מבלי לקבל מייל / לקבוע פגישה דרך זום.
    • יותר חשוב: אתם יודעים תמיד להיכן להתחבר אם זו פגישה שאתם קבעתם. ה Meeting Id הקבוע יהיה תמיד בזיכרון של אפליקציית הזום שלכם.
    • שימו לב שבארגונים, ה Admin יכול לחסום את השימוש ב Meeting Id קבוע, משיקולי אבטחה (לא שאני תומך בזה, לארגון שאינו ״חשאי״).
  • Meeting Id זמני – הוא טוב בכדי למנוע ״כניסות לא מתוכננות״ לפגישה. למשל: מישהו מהפגישה הבאה ביומן. לפעמים זה לא נוח ולא מתאים.
    • מקרה דמיוני לחלוטין: אמא שלכם מצטרפת באמצע פגישה רבת משתתפים…
    • עוד יתרון של Meeting Id זמני – אתם יכולים לעזוב לפגישה הבאה – ושאר המשתתפים ימשיכו בפגישה (ניתן למנות מארח אחר). זה בלתי אפשרי אם זו פגישה על ה Meeting Id הקבוע שלכם.
מה עושים? הכי חשוב להכיר את ה Tradeoff ולהחליט מה נוח לכם. אני משתמש כמעט תמיד ב Meeting Id הקבוע – כי יש לי עליו +5 פגישות ביום, ונוח לי כך להיכנס אליהן.
את ה Meeting Id שלכם אתם יכולים למצוא בהגדרות שבווב. אפליקציות הזום השונות כוללות בתוכן מספר הגדרות (אפליקציית המובייל – מעט הגדרות, אפליקציה למחשב – יותר הגדרות), אך עדיין חלק גדול מההגדרות נמצא רק בווב. ניתן להגיע אליהן ישירות בלינק או באפליקציה של זום ע״י Settings / General / View More settings.
הנה ההגדרות: כאן אתם יכולים למצוא מה ה Meeting Id שלכם, לקבוע Alias (קישור ה ״Customize״), או לקבוע אם פגישות מיידיות (שלא נקבעו מראש לתאריך) יהיו על גבי ה Meeting Id הקבוע, או לא.
שווה לציין, שאם קבעתם Person Link עם Alias טקסטואלי, באפליקציות מובייל יהיה על המשתמש ללחוץ על ״Join with a personal link name״ לפני שיוכל להקליד את ה Alias.

אני מציין, בכדי שתוכלו לתמוך באחרים.

הקלטת פגישות לצורך תיעוד / שיתוף

אחד הפיצ׳רים השימושיים בזום, שמבינים לאחר זמן מה – הוא הקלטה של פגישות.
כאשר אתם מקיימים פגישה, ומישהו לא הצליח להצטרף – אתם יכולים להקליט עבורו את מהלך הפגישה.
כל פעם שיש דיון חשוב (במיוחד רב משתתפים) – אני מקליט את הפגישה. אנשים לעתים חוזרים לפגישות הללו, ולא תמיד מישהו שחשבתם עליו בזמן הפגישה.
הקלטה של הפגישה יכולה להיעשות רק ע״י ה Host (ניתן גם למנות Co-Hosts עם הרשאות דומות ל Host) ורק ממחשב. ברגע שההקלטה החלה, תהיה אינדיקציה ברורה לכל המשתתפים – בדמות עיגול אדום בפינה של המסך.
ניתן להקליט את הפגישה מקומית למחשב או לענן של זום (האופציה הזו זמינה רק למשתמשים בתשלום).
הענן של זום שומר מעין ״פורטל״ של ההקלטות של הארגון – אבל כרגע הוא מאוד מאוד בסיסי. ישנן אינטרגציות לחברות שמתמחות בניהול וידאו (כמו קלטורה הישראלית, Panpoto, Knowmia, ועוד). מיד כשהוידאו מוכן – הוא יעבור לפלטפורמת ניהול התוכן של הצד השלישי ובעצם ינוהל שם.
מבחינת איכות, ההקלטה של זום היא בעלת דחיסה גבוה מאוד, המתבססת על הנחות שתוכנת דחיסה "גנרית" לא תניח אותן (ערוץ אחד של audio – מונו, הגדרות שמתאימות לתזוזה מעטה, מה שלא טיפוסי בוידאו, וכו׳). ההקלטה היא עדיין ברזולוציה של HD כך שמסך מחשב שמשותף יהיה חד וברור.
בהגדרות של Recording (חלקן רק בווב), ניתן לקבוע הגדרות שונות לגבי ההקלטה, למשל: תמלול של ההקלטה (אל תנסו עם מבטא ישראלי). 2 הגדרות נפוצות הם אפשור של HD Video ו Group HD (ברגע שיש יותר משני משתתפים בפגישה, זום מוריד את איכות הוידאו המועבר של המשתתפים, הגדרה זו תשאיר את הדובר, בכל רגע נתון, באיכות HD).

שיתוף מסך בזריזות, ומבלי לפגוע בפרטיות

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

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

פגישת עבודה שוטפת (שלא נצמדת למצגת מוכנה-מראש) תדרוש שיתופים קצרים שונים מאנשים שונים.
אני אישית משתף מסך בעזרת קיצור מקשים (מסתבר שיש כאלו בזום), וספציפית Cmd+^+S במק.
אליה וקוץ בה: קיצור מקשים יפעל רק כאשר החלון של זום הוא הפעיל בשולחן העבודה – וזה העיכוב הראשון שפתחנו בו.
לשמחתנו, הגדרה של צירוף מקשים כ Global יהפוך אותו לזמין גם כאשר החלון של זום איננו בפוקוס.
אלטרנטיבה נוספת: לגשת לפעולות שונות מתוך ה Tray Icon של זום (לי היה פחות נוח).
את שורת הפקדים של זום (Mute, שיתוף, צ'ט, וכו – שלפעמים מתחבאת) ניתן לקבע כך שתמיד תופיע (ואז תוכלו מהר יותר לגשת לכפתורים השימושיים). בהגדרות: Settings/Accessibility/Always show meeting controls.
מומלץ מאוד, לפחות במקומות עבודה, לאפשר בהגדרות הפגישה בווב – לכל משתתף להתחיל להציג גם כאשר מישהו אחר כבר משתף מסך. לי זה חוסך במצטבר כמה דקות ביום.

פרטיות
יופי! התחלנו לשתף מסך בזריזות – איך אנחנו מוודאים שלא בטעות שיתפנו אימייל פתוח שלא כולם צריכים לקרוא? אולי בזמן שיתוף המסך מישהו שולח לי הודעה פרטית / רגישה בסלאק / Whatsapp – ותחילת ההודעה נקלטת ומוקלטת, כחלק מהפגישה? 😱
לי התקלות הללו קרו מספר פעמים. לא נעים!
חשוב להבין שזום היא סביבה בעלת סיכונים לפרטיות המשתתפים. לדוגמה, פעם היה פיצ׳ר שעזר למארח לזהות מי מהמשתתפים לא בקשב – אך הפיצ׳ר בוטל, משיקולי פרטיות מובנים.
בגדול ישנן 2 גישות לשיתוף בזום:
  • שיתוף כל ה Desktop עם כל מה שכלול בו. 
    • יתרון: אפשר לעבור בין אפליקציות במהירות – והכל משותף.
    • חיסרון: כל מה שפתוח – ניתן לצפות בו. למשל: הלינקים שלכם בדפדפן. שולחן העבודה, וכו'.
  • שיתוף חלון ספציפי, בכל פעם.
    • יתרון: שליטה גבוהה במה משותף (אך גם כאן ייתכנו ״זליגות״ של מידע פרטי. שימו לב).
    • חיסרון: מעבר אטי בשיתוף מסכים מאפליקציות שונות (IDE, ואז Github, ואז Command Line – למשל).
זהו Tradeoff אמיתי, אישי לאדם ולסיטואציה – ואין באמת פתרון שטוב לכל המקרים.
הנה כמה עצות איך לעשות את השיתופים הללו קלים ובטוחים יותר:
  • שיתוף כל ה Desktop:
    • במידה ויש לכם מסך שני – אתם יכולים לרוקן אותו לפני שאתם משתפים – ואז לשתף אותו ולשלוט ביתר קלות / זהירות מה יופיע בו.
      • לי היו קיצור מקשים להעברת כל החלונות לDesktop הראשי + קיצור להעביר חלון ל Desktop ספציפי.
      • לצערי: מאז הקורונה, ריבוי ילדים בזום הגביר את הדרישה למסכים במשפחתנו. אני כרגע משתמש במסך יחיד.
    •  ההגדרה הבאה פישטה את חיי כליל. אני חושב שהיום זו הגדרת ברירת-המחדל, אך אולי למשתמשים ותיקים יותר – היא לא פעילה. חשוב!:
    • בכל רגע ניתן "להקפיא" את שיתוף המסך (קיצור מקשים במק Cmd+^+T). כאשר אתם לרגע, למשל, מחפשים במייל או בסלאק – זה הזמן ״להקפיא״ לרגע את השידור. שאר המשתתפים יראו את התמונה שהוצגה על המסך ברגע שלפני ההקפאה – ולא ידעו שבינתיים אתם רואים משהו אחר. עוד לחיצה על הקיצור – תחזור לשדר את התוכן העדכני.
  • שיתוף חלון ספציפי במערכת ההפעלה:
    • כאשר אתם רוצים לעבור אפליקציה ולהמשיך לשתף, עליכם להפסיק את השיתוף הנוכחי – ולהתחיל שיתוף חדש.
    • צירוף מקשים הוא ה״מלך״ כאן. אם אתם משתמשים בקיצור-מקשים תוכלו לבצע מעברים כאלו בזריזות ואלגנטיות. אם לא – ההתנהלות תהיה מסורבלת ואטית.

טיפול ברעשים

הנה אחד העניינים המטרידים בזמן פגישות זום: רעשי רקע מאחד (או יותר) מהמשתתפים. יש מה לעשות – וכדאי להכיר את זה.
כאשר יש הרבה משתתפים (+10) לא תמיד הקריאה ״מי שרועש שיעבור למיוט״ – עובדת.
בעיקרון ניתן לזהות מאיזה משתמשים מגיע אודיו מעל סף מסוים – במסך ה Participant (מסך שימושי לעוד כמה צרכים):
אתם תראו ״אנימציה של גל״ בתוך הצלמית של המיקרופון – לכל מי שממנו מגיע עוצמה מסויימת של אודיו, ובתור Host אתם יכולים להעביר אותו ל Mute.
מטעמי פרטיות המארח לא יכול לעשות Unmute למשתתף – אלא רק המשתתף עצמו (וטוב שכך).
אם הרעש הוא רעש רקע, בזום יש יכולת מובנה להפחתת רעשים. זום בוחר את רמת הפחתת הרעשים באופן אוטומטי – מה שהוא לא עושה היטב. ניתן בהגדרות ה Audio של אפליקציית הזום לקבוע את רמת הפחתת הרעשים ל״High״ מה שבהחלט יעיל. ההגדרה הזו עושה פלאים ויכולה להשתיק כליל רעשי רקע של שיפוץ, גנן, שכנים רועשים, וגם ילדים צורחים בחדר סמוך.
החסרון היחידי: כאשר יש שקט מסביב – ישמעו אתכם פחות טוב, ויהיה כדאי לחזור ל Low או Auto.
בקיצור: קביעת רמת הפחתת הרעשים בצורה אוטומטית ע״י זום – לא עובדת היטב, אך בקביעה ידנית הפיצ׳ר הזה מאוד יעיל.
יש אפליקציה בשם Krsip המיועדת לעשות עבודה טובה יותר. ניתן להשתמש בה כמה שעות חינם בחודש, או לרכוש מנוי ב $3 ומשהו לחודש. כמה אנשים שעובדים איתי ממש מרוצים ממנה – אך אני עדיין לא הצלחתי להבחין בהבדלים בין העבודה שלה ליכולת המובנה של זום (כאשר מכוונת ל High).
בחזרה לפגישות מרובות משתתפים: שווה להזכיר שלמארח יש יכולת להשתיק את כל המשתתפים מלבד זה שמציג (שוב: ממסך ה Participants). כל משתמש שרוצה ״לזרוק מילה״ יכול להשתמש במקש הרווח (Spacebar) ב "Push to Talk״ – ממש כמו מכשיר קשר שצבא.
זה יעיל ושימושי, אם כי יכול להיות שלחלק מהאנשים חסרה ההגדרה. אם מוצא חן בעינכם – פשוט שתפו בארגון.

לסיום: מגניבות לתחילים

(סבים וסבתות יקרים: זה מה שהנכדים שלכם עושים כל הזמן, שאולי קצת מבלבל/משגע אתכם)
ניתן להוסיף רקעים ואפקטים לוידאו שלכם מתוך תפריט ה Start/Stop Video של זום. רוב היכולות זמינות רק לאפליקציה של זום למחשב.
יש המון מקורות לרקעים זמינים ברשת (הנה רשימה של זום, ו Unsplash – עוד אתר פופולארי). אצלנו בחברה מדי פעם אנשים ״מתכתבים״ ברקעים, ומעבירים בעזרתם מסר / בדיחה קבוצתית. למשל: ביום ההולדת אדם צפוי לראות הרבה רקעים של ״יומולדת שמח״ או הקשורים לימי הולדת. יש רקעים של סרטים אהובים, ספורטאים נערצים, וכו׳. נסו להיות מקוריים (רק בבקשה הקפידו על רזולוציה סבירה של תמונה 😊).
שווה לציין שזום, כברירת מחדל עושה Mirroring לוידאו שלכם, ולכן רקע עם כיתוב יראה לכם הפוך (אך שאר המשתתפים יראו אותו בסדר). אפשר לבטל את ה Mirroring בהגדרות הוידאו.
מה שפחות אנשים מכירים, הוא את היכולת להוסיף קובץ mp4. (ברזולוציה סבירה) כרקע דינאמי – כמו הרקעים הדימנמיים המגיעים עם זום. רק חפשו "mp4 background״ בגוגל – ותמצאו אינספור מקורות. חשוב למצוא רקע שלא מושך יותר מדי תשומת לב: ללא תזוזות מהירות, ועדיף בפוקוס-חלקי. אלו רקעים נעימים שלא גוזלים יותר מדי תשומת לב (ורוחב-פס) מהמשתתפים האחרים בפגישה.
לאחרונה נוספו לזום, פילטרים ו Studio Effects שיכולים לשנות בצורה ניכרת את המראה שלכם.

זה משעשע לרגע – אבל לא כל-כך מתאים לסביבת עבודה. אולי יותר לשיחות בזום עם הסבים / סבתות.

אם אתם רוצים אפקטים מגוונים / מושקעים באמת – אזי Snap Camera היא כנראה הכתובת.

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