אני מניח שאחת לכמה זמן אתם מנהלים דיונים טכניים בקבוצה. לפעמים זה קורה כמה פעמים בשבוע, ולפעמים אחת לכמה שבועות. דיונים בהם מסכימים על API או על Flow, פותרים סתירה במערכת, באג, או מנסים להבין מה הדרך הכי sustainable לכתוב את הקוד.
עד כמה הדיונים האלו יעילים?
- בהיבט הזמן – כמה מהר אתם מגיעים למסקנה / החלטה? איזה אחוז מהזמן אתם בדיונים, ואיזה אחוז כותבים קוד?
- חשוב לציין שכשהיבט יעילות-הזמן אינו מוצלח (= הדיון נגרר) – נגרמת שחיקה לאנשים המעורבים. שחיקה כללית (״נמאס לי!״ / ״לא כיף לי״) וגם שחיקה בדיון הספציפי ונכונות להתפשר באיכות הדיון – ״רק שייגמר״.
- בהיבט איכות הדיון והתוצאה – עד כמה הדיון הוביל לתוצאה טובה? כמה עמוק ומדויק הוא היה? כמה ההחלטה נכונה? עד כמה היא ברורה? האם הייתה הזדמנות מלאה להשפיע?
דיון טכני הוא לא קל, ופעמים רבות אנחנו מוצאים את עצמנו בדיונים ארוכים, מתישים, ושתוצאתם לא טובה. החלטה שהיא ״פשרה באמצע כי נגמר לאנשים הכוח להתדיין״ יכולה לחזור אלינו לאחר חודשים לעוד סבבים נוספים של דיונים ועבודה – בעקבות הסיבוכים שנוצרו מתוצאה לא מספיק טובה.
ובואו לא נזניח את האווירה: הרבה יותר כיף לעבוד במקום שבו יש דיונים טובים: זה מעשיר, מתגמל, ומעצים את תחושת העשייה. ההיפך הוא גם נכון.
העקרונות של דיון טכני מוצלח
אני משתדל לגלג על הטריוויאלי / בסיסי – ולגשת לנקודות שיכולות לעזור למהנדסים מנוסים.
הכנה
זה קצת מבאס, אבל בשביל דיון טכני יעיל אנחנו צריכים לעבוד מראש. ״כולה נדבר חצי שעה ונסגור את העניין״ היא לא הגישה הבריאה לעניין. לרוב, דיונים איכותיים דורשים הכנה.
חשוב לחשוב ולהבין מהי ההכנה המספיקה הנדרשת. לפעמים אלו כמה שאלות בסלאק לאנשים רלוונטיים – ולפעמים לסגור שעה-שעתיים כדי להכין חומר מוצלח לדיון.
ההכנה אמורה להשתלם. קרי: ישבתי שעתיים בכדי להכין חומר לדיון באורך שעה בו יש ארבעה משתתפים והדיון הסתיים – הוא מוצלח הרבה יותר מ ״נפגשנו ארבעתנו לשעה – אבל העניין לא נסגר*״ ואז ״קבענו לעוד שעה וכמעט סגרנו״ ואז ״אני ומשה נפגשנו לעוד חצי שעה לסגור פרטים אחרונים״.
במספרים: 6 = 1*2+4*1 < 4*2 + 2*2 = 10.
* קול פאסיבי. זה ״העניין״ שלא נסגר – לא שזה אנחנו, או משהו…
חשוב להזכיר שיעילות-זמן של דיון היא לא רק סה״כ שעות עבודה, אלא גם, ואולי בעיקר, Lead Time. ברור, שאדם אחד שעובד שעתיים וחוסך שעת דיון של ארבעה אנשים – הוא חסכון. החסכון הגדול יותר הוא בזה שדיון הוא לרוב Blocker להתקדמות אחרת בפיתוח. דיון שיסתיים ביום שני ולא ביום רביעי – משחרר צווארי בקבוק בפיתוח.
ארגון שמצליח לסגור דיונים בד״כ תוך מפגש אחד ולא תוך 1.9 מפגשים (ממוצע התעשייה, אני מנחש) – יתקדם בצורה יעילה הרבה יותר. יהיו הרבה פחות מקרים שבהם אנחנו עושים Context Switch (יקר) לעבור לעבוד על נושא אחר – עד שהדיונים יסתיימו.
מכאן סביר להניח שגם אדם שעובד ארבע שעות הכנה בכדי לחסוך שעת דיון של ארבעה אנשים – הוא חסכון ניכר. רוב הפעמים אין באמת צורך להשקיע ארבע שעות בהכנה לדיון. רק זכרו בחישובי הזמן את ה Lead Time והשחיקה המצטברת – שהם משמעותיים.
מהי ההכנה?
- הגעה עם העובדות הקריטיות לדיון, או יכולת מלאה לענות עליהן (דוגמה שלילית: ״האא… חשבתי שאחד מכם ידע <שאלה טכנית>. בואו נחפש אולי עכשיו את התשובה ביחד״) – חשוב להבין מראש האם יש שאלות קריטיות לדיון, ודאו מראש שיש לכם תשובות ו/או מי שמגיע לדיון ידע לספק בשלמות את העובדות הנדרשות. קשה לי לספור כמה דיונים ראיתי שנמרחו סתם כי פשוט היה חסר ידע לנהל דיון יעיל. לא פחות חבל: הרבה פעמים יש נטייה לנסות להמשיך למרות שברור שהדיון לא עומד להתקדם בצורה סבירה. הרבה דיונים עדיף לחתוך באמצע – מאשר להמשיך סתם. תהיו רציניים בבקשה, ואל תמשיכו דיון רק כי כמה אנשים התכנסו כבר ביחד.
- ודאו מראש ששיבוץ האנשים מאפשר להגיע ל "Delivery״ (תוצאה מוצלחת של הדיון).
דוגמה שלילית: ״אוי… שרון מה זה הייתה תורמת לנו לדיון. חבל שלא הזמנו אותה, אך היא עכשיו בפגישה אחרת״.
הבינו מי באמת צריך להיות בדיון וודאו שהוא שם. ברוב הארגונים אנשים לא זמינים מהרגע להרגע – ואי הזמנה של אדם יכולה לעכב את הדיון בימים => הארכת ה Lead Time להחלטה.- שאלה קצרה ב Slack ״היי… אנחנו רוצים להבין <בעיה טכנית> – אתה יכול לכסות את הנושא, או שאנחנו זקוקים למישהו נוסף?״ – יכולה להכריע בין דיון יעיל לבזבוז זמן.
- נסו גם לצמצם אנשים לא-רלוונטיים. חבל לעכב דיון רק כי אדם לא-רלוונטי לא מסוגל להגיע. היום בעידן הזום קל הקליט דיונים – וכך לאפשר לאנשים להקשיב לדיון מבלי להופיע.
- תעדו ופשטו את תיאור הבעיה – בכדי לאפשר דיון יעיל. (דוגמה שלילית: ״לא… בפעם הרביעית: X קורה לפני Y כי ….״). במיוחד כאשר הנושא הוא מורכב / רב בפרטים – הכינו תרשים ו/או רשימת נקודות שתעזור לכולם להתכנס מסביב לנושא. קשה לי להסביר כמה חומר כתוב, ושעבר איטרציה או שתיים של פישוט והבהרה – יכולים לקצר את הדיון.
- חשבו על החומר שאתם מכינים כמפת-ניווט לדיון. בניית מסלול לדיון כדי שאנשים לא יצטרכו להחזיק יותר מדי פרטים בראש. מוביל הדיון הוא מדריך פעולת ניווט, ובלי מפה טובה סביר הדיון יסתיים בהתברברות. הכנת מפה טובה לדיון הוא מיומנות שלוקח קצת זמן (אבל מאוד משתלם) לפתח.
- ליצור תרשים שמסביר Flow מורכב – הוא דבר שלוקח זמן. הקדישו פעם אחת את הזמן הזה לפני הדיון, במקום לנסות לייצר אותו חמש פעמים במהלך הדיון – וכך למרוח את הדיון.
- ראוי שחומר כתוב וברור – יהיה ציפייה מקדימה לדיון טכני.
- מדי פעם יהיו כאלו שיכינו חומר ארוך מדי / מתיש / מפורט מדי. עזרו להם לקצר. זה לא תמיד קל.
- הבינו מי המשתתפים בדיון. הרבה פעמים מגיעים לדיון אנשים שלא בקיאים בנושא, וחשוב להכין להם רקע קצר שיכניס אותם לדיון ביעילות: מה הבעיה, מה קרה עד עכשיו? מה אנחנו יודעים? על מה יש הסכמה, ועל מה יש אי-הסכמה?
- הכנת חומר לדיון בפעם הראשונה עלולה להיות פעולה לא מתגמלת. זה קשה, אורך זמן, ואולי בסוף לא יהיה דיון מוצלח. אני אנסה להבטיח לכם שזה משתפר בכל הממדים עם הזמן. 3-5 דיונים שהכנתם להם חומר – וזה יתחיל להראות אחרת: קל יותר, ומועיל יותר.
- עומק הדיון נגזר מעומק החומר שהוכן. כמו ב Designs, סכנה היא שמי שמכין את החומר / מתווה את הדיון – ידלג על נקודות מפתח, ואז הדיון ידלג עליהן (כי כולם ״שבויים״ ברצף שהוגדר). כמובן שאנחנו מצפים ממשתתפים לאתגר ולשים לב לחסר – אך בנושאים מורכבים לא פעם הכנה חסרה נגמרת בדיון חסר. אין לי פתרון לזה, מלבד להקפיד וללמד את מי שמכין את החומר שיעשה מעבר יסודי ויעיל על נקודות הממשק של הבעיה – בכדי להקטין את הסיכון לפספוסים.
התנהלות הדיון
הכנה טובה היא תנאי הכרחי, אך לא מספק לדיון טכני יעיל. ננסה לכסות בקצרה היכן רוב הדיונים כושלים במהלך ההתנהלות – ומה נכון לעשות טוב יותר.
- התייחסו לדיון כ Delivery. הוא כזה, אם תחליטו ותצרו תרבות מתאימה. תרבות דיון יעיל – תשרת אתכם בהחלטות מהירות יותר, וסביבת עבודה שאנשים רציניים – יעריכו יותר.
- חשוב שמי שמנהל את הדיון יהיה במנטליות של חתירה לסגירת הדיון. זו האחריות שלו לוודא שהדיון מתקדם בצורה יעילה. לא תמיד דיון יסתיים בזמן שתוכנן – וזה לגיטימי. לפעמים קשה להעריך מראש את המורכבות של הדיון. מצד שני – דיונים שסתם נמרחו – הם משהו שלא צריך לקבל. חבל על הזמן והכוחות של כולם.
- מומלץ מאוד להתחיל את הדיון בהצהרה מה מטרת הדיון. ״אנחנו עושים Barinstorming ומחפשים כיוונים אפשריים לפתרון בעיה X״ או ״אנחנו רוצים לקבל החלטה מה הפתרון לבעיה Y – בהתאם לאלטרנטיבות שנמצאו״ – הם שני דיונים בעלי אופי שונה, וחשוב שכולם יבינו איזה דיון מתנהל.
- המנעו מזליגה לדיונים אחרים. ״הא? הנושא מאוד קרוב גם לדיון ג׳? יופי. את דיון ג׳ אפשר לנהל במקום וזמן אחר – עכשיו אנחנו בדיון א״.
- עוד ואריאציה בעייתית היא אנשים שמעלים הגיגים פילוספיים ולא משמעותיים לדיון ״אם היה לנו …, מה זה היה אומר?״ או ״חשבתם על …? (משהו תאורטי לגמרי)״. חשוב לזהות את ההתברברויות האלו – ולעצור אותן מוקדם. לעצור מצבים שבו אנשים מבדרים (מלשון הִתְבַּדְּרוּת) את הדיון במקום לקדם ולהניע את הדיון לכיוון של Delivery.
- אם מישהו מתנהל בצורה לא יעילה, קרי: חופר יותר מדי – הציפיה שמי שמנהל את הדיון יחתוך אותו. צרו תרבות דיון שמאפשרת ומחייבת לעשות את זה. ״מה? לא דילברת את ההחלטה הטכנולוגית כי שרית לא הפסיקה לחפור? זו לא סיבה מספיק טובה. פעם הבאה – בבקשה עצור את החפירה. האחריות ל Delivery של ההחלטה – היא עליך״.
- ניהול זמן. לא סביר שעוד 10 דקות נגמר הדיון, ולא התחלנו להתכנס להחלטה. זה עוד היבט במנטליות של דיון = Delivery.
- דיון תמיד מתחיל ביצירת בסיס משותף. זוכרים את שלב ההכנה? מישהו הכין רקע להכניס את כולם לסדר העניינים. מישהו פירט ותאיר בצורה ברורה ואחידה את הבעיה עבור הדיון: אחידות בהבנת / הגדרת הבעיה – מסייעים מאוד לדיון יעיל. עכשיו זה הזמן ״לצרוך״ את ההכנה הזו, ולהביא את המשתתפים לבסיס משותף שיאפשר דיון יעיל.
- דרך טובה היא פשוט לקבוע ש 15 הדקות הראשונות של הדיון (או כל זמן אחר שיתאים) משמשות לקריאה פרטנית של החומר שהוכן. כל אחד קורא את המסמך (בשקט, לעצמו), מוסיף הערות – ואז עוברים עליהן לפני / תוך כדי הדיון. הפרקטיקה הזו עובדת לנו בנקסט מצוין – ואני בהחלט ממליץ עליה.
- כאשר הנושא הוא טעון / במחלוקת – חשוב להגיע להסכמה משותפת של הבעיה. ״צוות א׳ לא אוהב את פתרון הראשון כי <סיבה מנקודת מבט של צד א׳>, וצוות ב׳ לא אוהב את הפתרון השני כי הוא מוטרד מה <משהו>״. עצם ההסכמה של שני הצדדים על מה מדאיג כל צד – מאוד עוזרת לנהל דיון יעיל. אל תפספסו את זה. זכרו לנהל את הדיון כדרך למצוא את הפתרון הנכון ביותר בארגון – ולא כמאבק כוחות.
- המנעו מ Design באמצעות דיון. לא פעם, תוך כדי דיון מגלים בעיה חדשה שלא חשבו עליה. בעיה שדורשת חידוד, יצירת חלופות (alternatives), ניתוח החלופות – והערכה איזו טובה יותר. מין ״מיני תהליך דזיין״.
- דיון בקבוצה הוא דרך גרועה לביצוע דזיין. המנעו מהטעות הזו, בחרו אדם או שניים (בעלי אחריות) שיבצעו את התהליך: הגדרת חלופות, ניתוח שלהן וכו׳, יכתבו את הדברים בצורה ברורה לדיון – וכך תוכלו לקחת החלטה טובה – בדיון המשך.
- ברגע שאתם מזהים שבעצם מתנהל דזיין לא מתוכנן – עצרו זאת. זה יהיה דזיין חפוז ולא מדויק. לא מתקנים פנצ`ר תוך כדי נסיעה.
- דיון בקבוצה הוא דרך גרועה לביצוע דזיין. המנעו מהטעות הזו, בחרו אדם או שניים (בעלי אחריות) שיבצעו את התהליך: הגדרת חלופות, ניתוח שלהן וכו׳, יכתבו את הדברים בצורה ברורה לדיון – וכך תוכלו לקחת החלטה טובה – בדיון המשך.
תרבות דיון
כשמדברים על דיונים טכניים – לרוב עוסקים בהיבטים הללו. הם חשובים אך כנראה מוכרים, אחזור על נקודות עיקריות בזריזות:
- צרו ושָׁמְרוּ על Psychological Safety – אף אחד לא אמור להיות מובך / מושפל / מותקף בשל דיון או דברים שנאמרו בו. אם דיונים מגיעים למחוזות הפגיעה, אזי אנשים יעסקו בהתגוננות – ולא בעצם הדיון עצמו.
- אגרסיביות ובריונות קיימים גם אצל חְנָנוֹת בחברות הייטק. אי אפשר להכחיד אותם, אך הדפו אותם אחורה כאשר הם מופיעים. לא פעם בדיונים בין צוותים, הטיעון מדוע לפתח משהו בצוות אחד ולא אחר הוא ״אז לנו זה ייקח יותר זמן מכם״ או ״אנחנו פשוט נעביר לכם את כל הבאגים שקשורים לנושא, סבבה״. לא פעם, יש שמץ של אמת בטיעונים האלו – אבל חשוב לעשות דיון ענייני ולבחון את הערך לחברה, ולא לפעול לפי אינטרסים מקומיים.
- צרו סביבה שמאפשרת לכולם לדבר, גם אם הם ״זוטרים״. לא פעם, טוב שמוביל הדיון ישאל ויערב את הביישנים – גם אם הם לא יוזמים. ״משה – מה אתה חושב על זה? זה פתרון טוב מבחינתך?״. מצד שני – שימו לב שהדיון לא מתבדר רק כי רצינו שכולם ידברו.
סגירת הדיון
אם אנחנו ממשילים דיון ל Delivery, אנחנו לא רוצים תרבות שבה פיצ׳ר נגמר כשהמפתח לא מודע לעוד קוד שצריך להכתב. סיום – משמע קוד בדוק, ב master, שרץ בפרודקשיין.
באופן דומה, דיון לא מסתיים כאשר נגמר הזמן בפגישה. דיון מסתיים נכון כאשר יש סיכום ברור של הדברים – שאנשים מבינים, כאשר יש Action Aitems ודיוני משנה – אם נדרשים.
קורה שמתגלה קוד שחשבנו שסיימנו לעבוד עליו – עדיין דורש עבודה. זה קורה בזמן בדיקות, merge, ולרוע המזל – גם בפרודקשיין. גם הסגירה של דיון היא לעתים יותר רחוקה ממה שחשבנו בתחילה / רצינו.
דיון שכולם יצאו ממנו מבולבלים, אולי עם תקווה שאחרים הבינו וידעו מה לעשות – הוא דיון שנסגר רע. לרוע המזל, זה לא אירוע נדיר. כל עוד אין תרבות של סגירה הדוקה של דיונים – אנחנו נגרור עבודה, חוסרי הבנה, ולכן עוד עבודה – לעוד ועוד דיונים בהמשך הדרך. לא יעיל, לא בריא למערכת, ולא כיף לאנשים שעובדים על המערכת הזו.
- בשלב הבסיסי ביותר אנחנו זקוקים למסקנה. מסקנה לפעמים היא משפט יחיד ״לא עושים X״ ולפעמים זה שורה של החלטות ופרטים שחשוב להגדיר ולפרט בצורה ברורה.
- המסקנה צריכה להיות כתובה, באופן שניתן להבין אותו אח״כ. הכי מטופש זה לנהל דיון, לשכוח את המסקנה – ואז לפעול באופן אחר, כי אין זמן לעוד דיון. אני לכאורה אומר את המובן מאליו, אך נכחתי כבר בהרבה דיונים עם אנשים נבונים – שפספסו בנקודה הזו.
- חשוב לוודא שהמסקנה מוסכמת וברורה. גם כאן, באופן מפתיע – נופלים לא פעם גם אנשים נבונים. Minutes שנשלח בסוף הפגישה הוא כלי נפוץ ויעיל. גם תוך כדי הדיון לעצור ולהכריז: ״טוב, אז לגבי נושא … כולנו הסכמנו שעדיף … על פני … כי …״ – היא פרקטיקה מועילה. במיוחד כאשר, מדי פעם, אתם בטוחים שזה המצב ואז אנשים עונים: ״לא, מה פתאום! זה לא מה שאמרנו.״
- תפיסת קצוות ״קשים לתפיסה״ הם עוד תופעה ידועה: יש איזה עניין שהוא מבלבל ומורכב ולכן משתתפי הדיון פשוט מתעלמים ממנו ומסכמים אותו בצורה מעורפלת. הקצוות הללו נוטים להתגעגע ולחזור אלינו, חודשים מאוחר יותר, בפרודקשין, באמצע הלילה. סגירה רצינית היא לתפוס גם את הקצוות הקשים האלו – ולא לתת להם להתחמק. הרבה פעמים יידרש עוד דיון, ועוד הכנה מורכבת – עבור דיון-ההמשך הזה. צרו תרבות שדורשת ומבצעת סגירה של הקצוות, ולא כזו שמשאירה מדיונים טכניים ״שיירים אבודים״.
סיכום
ציינתי נקודות רבות, גבי ניהול דיון טכני יעיל. כל הנקודות הללו – מתוך מקרים שקרו. רובם, פעמים רבות – דפוסים שחזרו שוב ושוב בארגונים שונים ובזמנים שונים.
אני כותב לא מעט בבלוג על נושא ה Software Design – ודיון טכני יעיל הוא חלק מעשי מתהליכי דזיין, וצר לי שלא כתבתי על הנושא בשלב מוקדם יותר.
כמה דגשים אחרונים:
- החלטות הנדסיות הן Delivery משמעותי. חשוב לעשות דיונים היטב ולהיות גאים בעשייה – ולא לראות בהם ״תקורה״ שצריך לקצץ ולדלל. כל דיון שני על פריון בחברות תוכנה נגמר ב״יותר מדי פגישות״. אל תקצצו את הפגישות החשובות – דאגו שיהיו יעילות יותר! צרו תרבות שמכירה בערך של דיון טכני טוב. אמירות כמו: ״כל הכבוד שמוליק על הדיון, הוא היה מוצלח! (כי…)״ או ״סגרנו בספרינט ארבעה דיונים חשובים: א,ב,ג,ד״ – צריכות להיות טבעיות, ולא מוזרות.
- הכנה היא חלק חשוב, שהרבה פעמים מתפספס. כעומק ההכנה – עומק הדיון. האם אתם מוכנים שאצלכם יתנהלו בעיקר דיונים שטחיים?
- סגירה היא לא מובנת מאליה – וגם שם אנחנו נוטים לפספס הרבה: לא לזכור מה בדיוק היה הסיכום מלפני שבוע, ולעשות ״משהו״ – כי הרי כבר דנו בזה. ״לעשות את מה שעשינו ב 48״.
- נסו לצמצם Lead Time של דיונים טכניים. אם תצליחו באופן משמעותי – כל הארגון יודה לכם.
שיהיה בהצלחה!