כל חברה מתמודדת עם העלות של קליטת עובדים חדשים, עובדי פיתוח חדשים מבלים חודשים עד שהם נותנים ערך אמיתי. הם מסיימים עבודה לאט יותר מעובדים קיימים, נזקקים לתמיכה, ל״טריינינג״ ולמידה ואף עושים הרבה טעויות בדרך. במקרים גרועים יותר, חלקם ״שואבים״ את המשאבים הקיימים ואז עוזבים או מפוטרים בגלל שלא הצליחו להיות אפקטיבים בזמן הנדרש.
חלק גדול מהעלות הזו היא באשמתנו. עובדים חדשים לא יודעים אצל מי ״התשובות הנכונות״ ומבזבזים זמן רב בדרך. מערכות העבודה שלנו נועדו בעיקר לשרת את המוצר ואת הביזנס ופחות מרוכזות ב-״דרך״ או ב-״קלות השימוש״.
כיום, קדנציה של מפתח עומדת על בערך כשנתיים וחצי. בעיני, יש משמעות גבוהה לארגון בכניסה מהירה של מפתחים, צמצום ״שאיבת המשאבים״ וקבלת ערך כמה שיותר מהר.
אני מאמין שמפתח חדש צריך לתת ערך אחרי כ-4 שבועות, עם תוכנית קליטה מתוכננת, אינטנסיבית ויעילה.
תחשבו על האלטרנטיבה, בה מפתח נותן ערך אחרי כ-6 חודשים. ישנו הפסד של כחמישה חודשים, שזה כמעט 20% הפסד מתקציב העובד. באסה.
ממוצע קדנציה של מפתחי תוכנה בארה״ב
בעזרת הטיפים הבאים, ניתן יהיה לבנות תוכנית יעילה לקליטת עובדי פיתוח חדשים:
1.קליטת עובד היא 100% אחריות של ראש הצוות: על מנהל הפיתוח להבין שזה אחריותו, לפנות זמן לתהליך ולהיות מושקע בו. לא אנשי הHR ולא מנהל הקבוצה - אחריות מלאה של מנהל הפיתוח.
2. קליטה-מכוונת-משימות: כל התהליך צריך לבוא לידי ביטוי בצורה של משימות. נתחיל מיצירת Story ונקרא לו Onboarding. ב-Jira או בכל כלי אחר. נפתח תתי משימות שיכללו את כל מה שעל העובד החדש לבצע. נעקוב עליהם בדיילי, ונתחייב עליהם כחלק מהספרינט.
3. ״הנדס-און״ ממש מההתחלה: תהליך הקליטה יכיל משימות קוד ומשימות פרודקשן, ממש מההתחלה. נתחיל ב״תרגיל קוד״ ליישור קו על הסטנדרטים והתכנים הטכניים וישר לאחר מכן במשימות פרודקשן.
4. משך זמן האונבורדינג: 4 שבועות. מתוכם שבועיים ללוגיסטיקה, התקנת סביבות ו״תרגיל קוד״. ושבועיים נוספים למשימות פרודקשן. משימות פרודקשן יכולים להיות: באגים קטנים, ריפקטור, תיקוני תשתית ועוד.
5. הזדמנות לזהות ״גיוס חלש״ או "low performers״: גיוסים חלשים קורים תמיד. אל תדחו את זה יותר מידי זמן. נסו לזהות קווים אדומים כבר בהתחלה.
6. הזדמנות לזהות ״חולשות טכניות״ או ״איזורים לשיפור״: לדוגמא, ייתכן שהגיוס מוצלח, אך אין לו שום ידע בסיסי במסדי נתונים. זהו את החולשה וצרו משימות (בזמן הקליטה) לתיקון, לדוגמא: משימת הפרודקשן תכלול כתיבה לדטהבייס וחניכה של מפתח מנוסה.
7. ״יישור קו טקסי״: זה הזמן ללמד וליישר קו בכל הטקסים שהצוות מנהל. הערכות זמנים, technical design, code review ודיילי. המפתח החדש ידווח כל יום בדיילי על ההתקדמות שלו בתהליך הקליטה, יתן הערכות זמנים למשימות הקליטה שלו, וחברי צוות יבצעו לו code review.
8. ״יישור קו טכני״: בתהליך הקליטה המפתח ידחוף קוד כל הזמן. בחלקו לSample repository ובחלקו לפרודקשן. בזמן הזה ניישר קו לקונבנציות ולסטנדרט שיש בצוות ובחברה, ע״י code reivew ו Pair programming.
9. באדי / קונטקסט: נגדיר באדי אחד (מפתח בכיר) שילווה את המועמד החדש. נגדיר שכל שאלה תילך אליו. נרצה לצמצם את ה context switch עבור שאר חברי הצוות וגם עבור המועמד. בנוסף, זוהי הזדמנות לבדוק ולקדם עובדים בעלי ״פוטנציאל ניהולי״.
10. ״הובלה עצמית״: מצופה מהעובד החדש להוביל בעצמו את תהליך הקליטה. הוא אחראי על המשימות ועל ההתקדמות שלו. הוא יעדכן אותנו, ״הכדור אצלו״.
11. חוק ״ברוקס״: לא נכניס את העובד החדש למשימות דחופות בהתחלה. גם אם יש לחץ - זה רק ייצור נזק. ניתן לזה זמן. אפילו חודשיים מהכניסה לתפקיד.
12. הזדמנות להכיר את חברי הצוות, דרך ״סשנים של למידה״: נגדיר לכל חבר צוות משימה תחת הסטורי, בוא עליו ללמד את העובד החדש נושא טכני. לדוגמא: שיעור על הסרביסים של הבקנד. שיעור על הדטהבייסים והסכמות הקיימות. שיעור מחברי הדב-אופס ועוד.
13. סביבת פיתוח לוקאלית: כמה שיותר מהר להרים סביבת עבודה לוקאלית טובה. וודאו שיש לכם מסמך שמפרט בשלבים איך לעשות זאת, ואם לא - זו ההזדמנות לעשות אחד.
14. ״בדיקות שפיות״: ב(11) אמרנו שעל העובד לנהל לבד את כל התהליך. וודאו שהוא בכיוון והכל מתקדם כמו שצריך דרך מפגשים קצרים של 15 דקות (2-3 בשבוע): ״האם אתה צריך עוד זמן איתי״ ? ״האם אתה צריך עוד זמן לבד?״ , ״האם אתה צריך עזרה בנושאים ספציפיים״?.
15. רטרוספקטיב: בסוף התהליך, בצעו תחקיר ולמידה. אספו דאטא לאורך כמה וכמה תהליכים כאלה ותקנו בהתאם. Onboarding זה תהליך איטרטיבי ומותאם אישית לכל ארגון וצוות.
16. תהליך הקליטה הוא דו-כיווני: זוהי הזדמנות להראות לעובד החדש שהוא הגיע למקום רציני ומקצועי. אל תפספסו הזדמנות זו!
אחרי שסקרנו כמה רעיונות לבניית תוכנית קליטה לעובד, עליכם עכשיו לבנות אותה בהתאם לאופי הצוות. תוכנית קליטה של מפתח בקנד תהיה שונה מתוכנית של מפתח פרונט, תוכנית לצוות ״מוצר״ תהיה שונה מתוכנית לצוות ״תשתיות״ אך תשמור על אותם העקרונות.
כלי נוסף שיכול לסייע בבניית תוכנית ספציפית, היא כתיבה של Check Lists ספציפיים לכל תחום. הגדרה מראש (ובצורה איטרטיבית לאחר כמה וכמה קליטות של עובדים), תחסוך זמן רב ותעשה סדר לעובד החדש. לדוגמא: צ׳קליסט ״התקנת כלים לפיתוח בסביבה מקומית״, צ׳קליסט ״לוגיסטי״ (כרטיס סיבוס, מערכת ניהול שעות וכו) יוגדרו מראש ועל העובד החדש לעקוב אחר ביצוע.
ככה זה נראה אצלנו:
צפייה בוידאו 
האזנה לפרק 
קריאת הבלוג 
תשאלו אותנו הכל
