בניתם Skills. למה אף אחד בצוות לא משתמש בהם?

המספר הלא נעים

לפני חודשיים ספרתי את ה-skills בריפו שלנו: 41. אחר כך בדקתי כמה אנשים באמת השתמשו בהם. אחד. אני.

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

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

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

ארבעת המבחנים של skill צוותי

כדי ש-skill יהפוך מכלי אישי לתשתית צוותית, הוא צריך לעבור ארבעה מבחנים:

1. גילוי. האם הוא מופיע ברגע שבו צריך אותו?
2. התאמה. האם הוא מתאים לדרך שבה הצוות באמת עובד?
3. אמון. האם אפשר לצפות את הפלט ואת גבולות הפעולה שלו?
4. בעלות. מי מתחזק, מודד ופורש אותו?

שאר הפוסט עובר על המבחנים האלה אחד-אחד - כולל איך הם נראים כשנכשלים.

גילוי והתאמה: למה skills טובים מתים

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

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

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

כשל התאמה. ה-skill נבנה סביב ה-workflow של הכותב - השמות שלו, מבנה המשימות שלו, הנחות העבודה שלו. עבור שאר הצוות הוא אולי טוב, אבל הוא לא מתאים לעבודה שהם באמת עושים.

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

אימוץ: שלושה מנגנונים, לא שלוש חלופות

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

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

Paved road הופכת את ההתנהגות לקלה. ה-skill מופיע בתוך המקום שבו העבודה כבר מתרחשת: בתבנית המשימה, ב-PR, ב-CLI. לא צריך לזכור את שמו או לחפש איך להפעיל אותו.

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

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

• skill ל-review של migration מופעל מתוך ה-PR המתאים.
• skill לסיכום ספרינט מקבל אוטומטית את המשימות מהספרינט.
• skill ל-deploy נטען מתוך ה-command שכבר משמש לפריסה.

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

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

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

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

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

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

לכן הזהירות צריכה להיות חלק מהכלי, לא מהמשתמש:

• אישור אנושי לפני פעולות בלתי הפיכות.
• תקרות שימוש ועלות.
• הרשאות מוגבלות למשימה, ו-blast radius קטן כברירת מחדל.

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

בעלות: מי מטפל בו כשמשהו נשבר

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

המודל שהתייצבנו עליו: לכל skill בריפו המשותף יש צוות בעלים ואדם שמוביל את התחזוקה. כשהאדם עובר תפקיד, הבעלות נשארת אצל הצוות וממונה maintainer חדש. ככה זה נראה בראש כל skill:

owner_team: platform    # the team that inherits
maintainer: dana.k      # the person who leads today
backup: platform-oncall # who acts when both are away
review: 2026-11-01      # next scheduled look

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

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

מדידה: reach, speed, quality

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

מה שעבד לנו הוא לבדוק שלושה ממדים ביחד. Reach - כמה משתמשים ייחודיים השבוע. Speed - האם זמן הביצוע או הזמן ל-PR ראשון ירדו. Quality - האם סבבי התיקון וההתערבויות הידניות נשארו יציבים או ירדו. אימוץ בלי שיפור הוא פעילות; מהירות בלי איכות היא חוב. skill מצליח מגיע ליותר אנשים, מקצר עבודה, ולא מעביר את המחיר ל-review או לפרודקשן.

סייג אחד חשוב: זמן ל-PR הוא מדד שימושי רק כשמשווים משימות דומות ובודקים מגמה לאורך זמן. אחרת הוא מושפע מגודל המשימה ומהוותק של המפתח יותר מאשר מה-skill.

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