Staff Engineer: התמודדות עם מורכבויות

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

דוגמאות לדילמות:

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

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

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

מודל ההתקדמות-במורכבות של ליאפולד [1]

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

אתחיל בלתאר את שלבי המודל, בזה אחר זה.

שלב ראשון: דילמה

צעד ראשון: זיקוק

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

• לתאר אותה.
• לחדד מה בדיוק יודעים.
• לחדד מה עוד לא ברור / פתוח.
• להסיר פרטים מיותרים / לא נחוצים.
• למצוא דרך פשוטה להסביר לאחרים, שחסר להם הֶקְשֵׁר – מה שאתם כבר יודעים.

אני חושב שאצלי תהליך הזיקוק כבר דיי אוטמטי ומתרחש בדרך כלל בראש, בחצי דקה (״טוב… מה העניין?״ – אני שואל את עצמי) – אבל הוא בחלט קורה. במקרים יותר מורכבים אני אכתוב כמה נקודות על פתק (יש לי פתקיות בשולחן העבודה, ואני משתמש בהן כל יום), או אלך ליצור תרשים (משהו מהיר ב excalidraw). עוד אופציה היא להתחיל מסמך (Google Docs) – ולסכם את הדברים, לרוב בנקודות.

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

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

קשה לי להבהיר כמה התהליך הזה הוא חשוב ומשמעותי, ולמרות שהוא נשמע טכני או פעוט – הייתי ממליץ לכם בחום לקחת אותו ברצינות רבה, ולהתנסות ולראות שאתם מצליחים לזקק את העניין, כל עניין מורכב שאתם נתקלים בו – לסיכום קצר (״Elevator pitch״).

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

צעד שני: איסוף נתונים

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

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

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

קיבלתי תשובה!

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

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

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

צעד שלישי: הצלבת נתונים

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

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

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

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

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

עד כה – בסך הכל חידדנו והבנו טוב יותר את הדילמה, ועדיין לא פתרנו אותה.

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

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

שלב שני: הצעת פתרון לדילמה

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

עלינו להבין מי הפורום הנכון לקבל / להיות שותף להחלטה (אני מניח שזה כבר טבעי לנו, בכל זאת: Staff Engineer…) – ולהכין הצעת פתרון לאישור בפורום הזה.

צעד ראשון: גישוש

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

אם נגיע עם הצעת פתרון לא מספיק מגובשת ובשלה אזי:

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

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

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

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

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

צעד שני: השגת קונצנזוס

זה השלב להגיע להחלטה בנושא:

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

שלב שלישי: פתרון מוסכם

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

לא כל-כך מהר! פה הרבה מהנדסים נופלים – ולא בעצם מספקים את מה שמצופה מ Staff Engineer.

צעד ראשון: הידוק וסגירת פינות

לא פעם נושאים מורכבים לא נגמרים בהחלטה אחת:

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

בתור מי שהוביל טיפול בדילמה, יצפו מכם כנראה לוודא שהיא סגורה / Done / Finito / Completo. כמובן שזה מעייף – ויותר נחמד לחזור ״להזרים קוד״ או אפילו לעבור לדילמה הבאה… לא סתם לא כל מהנדס מוכר כ Staff Engineer.

צעד שני: איתור השלב הבא

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

זה לא הסוף, עד שענינו ״מה השלב הבא״?

האם יש שלב הבא? עד שלא הובן שאין – נכון להניח שיש. אם יש ״שלב הבא״ (והרבה פעמים יש) – ולא איתרנו וטיפלנו בו, כנראה שלא סגרנו באמת את העניין. למשל:

• לתקשר את ההחלטה לגורמים / קבוצות שונות בארגון.
• יש מציאות חדשה (למשל: דרך פעולה חדשה של המערכת) – נדרשת הדרכה לגורמים מסוימים בארגון.
• הדילמה עיכבה תהליכים מסוימים – שעכשיו הגיע הזמן להניע מחדש.
• מקרה קלאסי: דילמה מובילה לעוד דילמה ועוד דילמה. פתרון אחד פתר את הדילמה המסוימת, אבל בצפייה קדימה, אנחנו מבינים שבעצם מעכשיו תהיה דילמה נוספת במקום אחר / לגורם אחר בארגון.
  • למשל: הפתרון כלל תחילת שימוש במערכת חדשה (למשל: Dynamo DB) – אבל עכשיו יש שאלה איך לגבות / לתפעל את הפתרון? זו לכאורה בעיה של ה Cloud Operations (להלן "DevOps״) – אבל לא באמת סגרנו את הפתרון – עד שטיפלנו גם בדילמה הבאה.
  • דוגמה נוספת: יצרנו מנגנון מסוים, אבל הוא יקשה על או יש שאלה כיצד ישתלב בתוכניות של צוות מסוים – שמושפע מהשינוי.
• לוודא שיש מישהו שיכול ומוכן לטפל בשלב הבא. שהשלב הבא מצא ״בית חם״.

עלינו לבחון ולהבין האם באמת ״זה סוף העניין, ולכולם״.

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

סיכום

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

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

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

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