אמלק;
במקום למדוד מפתחים לפי שורות קוד או מספר משימות, צוות מחקר ייחודי בגוגל בונה מערך הוליסטי שמודד את ההשפעה האמיתית של עבודת הפיתוח — על המשתמשים, על הקוד, ועל המפתחים עצמם. הפוסט הזה מסכם פרק פודקאסט עם חוקרות הצוות, בוחן את העקרונות שמאחורי שיטת המדידה שלהן, ומעמיק בשלושה מאמרים שמלווים את הגישה הזו — כולל תובנות מעשיות שכל ארגון יכול ליישם.
צוות מחקר בגוגל? כן — וזה מה שמיוחד בו
כשמדברים על גוגל, חושבים מיד על מהנדסי-על, אלגוריתמים מתקדמים ותשתיות בקנה מידה עולמי. אבל מתחת למכסה, פועל צוות פחות מוכר אך לא פחות חשוב: צוות חוצה-תחומים שחוקר את חוויית הפיתוח עצמה. הצוות הזה כולל חוקרי UX, מהנדסי תוכנה, פסיכולוגים תעשייתיים, כלכלנים התנהגותיים ומנהלי מוצר — והמשימה שלו פשוטה להפליא (אבל קשה מאוד לביצוע): להבין ולשפר את פרודוקטיביות המפתחים בגוגל.
מה שמייחד את הצוות הוא השילוב בין נתונים כמותיים (לוגים, זמני ריצה, ביצועים) לבין מחקר איכותני (סקרים, ראיונות, תצפיות). הם לא מחפשים את המדד האחד שישקף פרודוקטיביות, אלא בונים תשתית שמכירה בכך ש"זה תלוי הקשר", ודורשת הסתכלות רחבה על מטרות, תחושות, תוצרים ותהליכים. זו תפיסה הוליסטית, שמכבדת את מורכבות העבודה ההנדסית המודרנית.
למה שורות קוד זה לא מדד — ואיך כן כדאי לחשוב
מדידת פרודוקטיביות לפי מספר שורות קוד, או משימות שנסגרו, הייתה תמיד פתרון נוח — אבל גם מטעה. כמו שהוזכר בפרק, קל מאוד "לשחק את המערכת": להגיש PRים קטנים יותר, להפריד משימות מלאכותית, או פשוט להוסיף קוד במקום להסיר אותו. יותר מזה — מדדים כאלה עלולים להוביל לפוליטיקה ארגונית ולהרס תרבות של עבודת צוות.
במקום זה, צוות המחקר בגוגל מציע לחשוב על שלושה ממדים של פרודוקטיביות:
- מהירות (Velocity) — כמה מהר אפשר להתקדם בעבודה אמיתית.
- קלות (Ease) — כמה חסמים עומדים בדרכו של המפתח.
- איכות (Quality) — עד כמה התוצר הסופי עומד בסטנדרטים גבוהים של אמינות, תחזוקה וחוויית משתמש.
Build Time זה לא רק עניין של שניות
במקרה קונקרטי, הצוות ניסה למדוד זמני Build כדי להבין האם יש מקום לשיפורים. אבל מהר מאוד התברר שהנתונים כוללים גם טריגרים אוטומטיים (כמו builds שמופעלים ע"י מערכות אחרות), או כאלה שלא משקפים את זמן ההמתנה בפועל של המפתח. אחרי פילוח חכם, הם הבינו שהבעיה העיקרית היא לא הזמן עצמו — אלא חוויית ההמתנה. למשל, כש-build נכשל ואין שגיאה ברורה, הזמן מרגיש ארוך ומתסכל, גם אם בפועל הוא קצר. מכאן עלתה התובנה: חוויית build היא מדד איכותי לא פחות מזמן build.
סקרים רבעוניים: האנליטיקה האנושית
אחד הכלים המשמעותיים ביותר בגישה של גוגל הוא סקרי מפתחים רבעוניים. אלה כוללים שאלות על עומס, טכניות, זרימה, הבנה הדדית בין צוותים, איכות הכלים הפנימיים ועוד. גוגל מודדת גם שינוי לאורך זמן, גם הבדלים בין קבוצות, וגם קורלציות מול מדדים אחרים. המטרה היא לא להחליף אנליטיקה, אלא להשלים אותה — ולוודא שהקול האנושי נשמע. זהו מרכיב קריטי במדידה של פרודוקטיביות ממוקדת-אדם.
מאמרים מטעם הצוות של גוגל
מאמר 1: Measuring Engineering Productivity — מודל GSM
המאמר הראשון מציג את המודל שמהווה בסיס למדידת פרודוקטיביות בצוות: Goals → Signals → Metrics. ראשית, מגדירים את המטרה הארגונית (למשל, “לשפר את זמן ההגעה לשוק”). לאחר מכן מזהים אותות (signals) שיכולים להעיד אם המטרה מושגת (למשל, זמן ממוצע בין merge ל-deploy), ואז בוחרים מדדים מדויקים שניתן לעקוב אחריהם.
מה יוצא לי מזה?
כמנהלי צוותים או פיתוח, אפשר לאמץ את השיטה הזו לתכנון KPIs, להימנע ממדדים שרירותיים, ולוודא שכל מדד קשור ישירות למטרה חשובה.
מאמר 2: Measuring and Managing Tech Debt — החוב שלא כתוב בג'ירה
במאמר השני, גוגל מציגה דרך שיטתית לזהות ולמדוד חוב טכני — לא רק כקוד לא איכותי, אלא כשורה של מחסומים שמונעים התקדמות חלקה: תיעוד חסר, בדיקות שלא מכסות מקרים קריטיים, תשתיות איטיות, תלותיות בין צוותים ועוד.
מה יוצא לי מזה?
אם אתם מרגישים ש"הכול איטי" אבל לא יודעים למה — ייתכן שזו הדרך לפרק את זה לגורמים. הסקרים, בשילוב ניתוח תשתיות, יכולים להאיר איפה הבעיה האמיתית.
מאמר 3: A Human-Centered Approach — כשפרודוקטיביות מתחילה באדם
המאמר האקדמי החשוב ביותר מבין השלושה מנסח את ההנחה שהובילה את כל הצוות: פרודוקטיביות של מפתחים היא לא רק מה הם מייצרים — אלא גם איך הם חווים את העבודה. הם מציעים מדדים חדשים כמו "כמות שעות עבודה לא מופרעת בשבוע", או "שביעות רצון מכלים פנימיים".
מה יוצא לי מזה?
זו דרך טובה לבנות אמון ולהתחיל שיחה על שיפור, בלי לחפש אשמים.
סיכום: מה נמדוד מחר בבוקר?
הגישה של גוגל היא לא פתרון קסם, אלא תהליך מתמשך שדורש סקרנות, הקשבה ורוחב מחשבה. אבל מה שיפה בה הוא שהיא ישימה — גם בארגון קטן. כל אחד מאיתנו יכול להתחיל בקטן:
- לשאול את הצוות: מה הדבר שהכי מעכב אותנו?
- לבנות טבלה של מטרות, אותות ומדדים.
- להפעיל סקר קצר רבעוני כדי לזהות צווארי בקבוק.
- לעקוב אחרי חוב טכני בצורה מבוססת-תחושה, לא רק בקוד.
המודלים לא צריכים להיות מושלמים — אבל הם צריכים להיות שיחה מתמשכת.
האזינו לפרק המלא:
🎧 How Google measures and improves developer productivity
