ציד מהנדסי רפאים: איך לזהות את התרומה האמיתית של מפתחים

"Ghost engineers" — אחד מכל עשרה מפתחים כמעט אינו עושה עבודה מועילה, אלא רק יוצר מראית עין משכנעת של עומס. הסיבות האמיתיות לחוסר הפעילות — עבודה נוספת מהצד, שחיקה או סתם בטלה — יכולות להישאר נסתרות מההנהלה במשך זמן רב מאוד. (מחקר סטנפורד מ-2024: השרשור המקורי)

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

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

ואולי פשוט כדאי להניח להם — לרוחות הרפאים האלה. הרי החברה אפילו לא תרגיש שהכסף חסר.

אבל יש כאן מלכוד…

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

רק שה"מחר" הזה כבר היה אתמול ושלשום — ובינתיים הפך למסורת.

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

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

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

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

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

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

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

אבל כדי לבדוק את החשדות צריך עקבות דיגיטליים.

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

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

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

DORA: מהירות ואמינות של גרסאות

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

זו הערכה טובה של תהליך ה-delivery, אבל לא של תרומה אישית. אם אדם אחד עושה עבודה של שלושה ואחר מסתתר מאחורי התוצאה הכוללת של הצוות, DORA לא תראה זאת.

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

בדיקות ופגמים: עד כמה העבודה נעשתה היטב

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

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

Jira ו-story points: כמה משימות נסגרו

Jira מציגה משימות סגורות ו-story points, אבל הצוות עצמו קובע את ההערכות. את אותה עבודה אפשר להעריך בשלוש נקודות או בשלוש עשרה, לפצל לחמש משימות או לאחד למשימה אחת.

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

הן נוחות גם בתור KPI. מזינים נתונים ומזיזים משימות אך ורק כדי לעבור quality gates. הרבה עבודה ידנית וחסרת תועלת.

קומיטים ושורות קוד: עובדות בלי הקשר

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

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

Swarmia,‏ LinearB ו-Waydev: כל מערכת הפיתוח במקום אחד

Swarmia,‏ LinearB ו-Waydev מרכזות נתונים מ-Git, ממערכת ניהול המשימות ומ-CI/CD. מנהלים רואים מדדי DORA, תורים לסקירה, זמני מעבר של שינויים ותוצאות סקרים.

הן מספקות תמונה מועילה של מערכת הפיתוח — ולעיתים קרובות חושפות שהבעיה טמונה בתהליך, לא באדם. אבל מדידה בת-השוואה של היקף העבודה של מפתח מסוים אינה השאלה המרכזית שעליה הפלטפורמות האלה מנסות לענות. Swarmia, LinearB, Waydev.

GitClear: מה נשאר אחרי רעש הקוד

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

כך מתקבלת Diff Delta — היחידה של GitClear לשינויים מהותיים שנשארו בבסיס הקוד. קוד שהועתק או נזרק במהירות מקבל משקל נמוך יותר משינוי קטן וממוקד שממשיך לעבוד ב-production. איך Diff Delta פועלת.

Diff Delta אינה עונה על השאלה כמה עבודה נדרשה. היא מראה את היקף השינוי המהותי שנותר אחרי הרעש והעבודה החוזרת. החוזקה של GitClear היא מדידת העמידות והאיכות של הקוד וניתוח ההשפעה של AI.

אנחנו כבר מתקרבים. השירות מפרסם benchmarks, אבל Diff Delta נשארת יחידה ייחודית לו: מספר כמו 10,000 אינו אומר הרבה בלי השוואה מתאימה והבנה של המתודולוגיה. אין כאן נקודת ייחוס ברורה כמו "100% הם הנורמה". ה-benchmarks של Diff Delta.

BlueOptima: אותה שאלה בקנה מידה ארגוני

אני מכיר את BlueOptima מניסיון אישי. התחלתי לעבוד עם הפלטפורמה ב-2019. החוויה הזאת היא שנתנה לי השראה לבנות מוצר משלי.

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

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

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

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

אותו קנה מידה, בלי מכרז

כשבניתי את DevGhost, לא ניסיתי ליצור עוד פלטפורמה שמכילה כל מדד הנדסי שאפשר להעלות על הדעת.

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

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

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

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

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

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

ומי ישפוט את השופט?

השאלה המתבקשת ביותר היא: למה בכלל לסמוך על הערכה שמייצרת מכונה? התשובה הקצרה היא שלא צריך לסמוך עליה בעיניים עצומות.

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

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

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

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

"אני כבר יודע איך כל אחד בצוות שלי עובד"

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

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

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

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

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

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

ומה אם מפתח אחד מספק תפוקה של שלושה?

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

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

כיום השאלה כבר אינה אם מפתח משתמש ב-AI — עבור רבים הוא הפך לחלק רגיל מהעבודה. השאלה היא באיזו יעילות האדם הופך סוכנים לכושר ייצור נוסף.

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

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

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

אל תהפכו את קנה המידה לנשק

כל מדד זוכה לאותו גורל: במוקדם או במאוחר מישהו מנסה להפוך אותו ל-KPI. ‏Ghost% אינו מתאים לכך.

הפכו את Ghost% ל-KPI של הצוות, ואנשים יתחילו להתאים אליו את העבודה. פרסמו דירוג, והאמון ייעלם. הפכו את הציון לכפתור פיטורים, והטעויות יהפכו לבלתי נמנעות.

הייתי קובע ארבעה כללים:

• אל תסיקו מסקנות ממדידה אחת או מתקופה קצרה.
• הביאו בחשבון את תפקיד האדם, את החלק מזמנו שמוקדש לפיתוח ואת העבודה שמתרחשת מחוץ לקוד.
• הציגו למפתח את התוצאה ותנו לו הזדמנות להסביר את ההקשר.
• אל תשתמשו ב-Ghost% כבסיס היחיד להחלטת כוח אדם.

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

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

דחיית מדדים אינה מבטלת את הערכת האנשים. היא רק משאירה במקום המספרים תחושות בטן, סיפורים מישיבות stand-up והעדפות אישיות של המנהל.

מהירות, איכות והיקף עבודה דורשים כלים שונים. DORA מראה כיצד שינויים נעים אל ה-production. בדיקות ופגמים מראים איכות. DevGhost מוסיף הערכה של העבודה שמאחורי שינויי הקוד.

אף אחד מהמדדים האלה לא צריך לקבל החלטות במקום המנהל.

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

איך אתם מעריכים את היקף העבודה של מפתחים — ואיפה עובר מבחינתכם הגבול בין שקיפות מועילה למעקב?