כיצד מהנדס staff מאתר בעיות שכדאי לפתור

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

לספוג בעיות, לא בקשות

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

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

לתת לבעיות להצטבר

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

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

מבקשות תכונה להרחבות

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

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

למה זה חשוב

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