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

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

מעניין אותי לשמוע מה דעתכם ואיך זה מתקבל בארגון שלכם (או בארגונים שעברתם בהם).

האם תוכניתן ותיק שלא עשה תפקיד ראש צוות הינו עוף מוזר?

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

גם כל חברה מגדירה אחרת את תפקיד ה"ארכיטקט", האם הוא רק כותב מסמכים או גם קוד. 

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

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

צטט: zvikico 2009-08-12 14:14:27

תוכניתן טוב מתקדם להיות ראש צוות?

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

 

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

מעניין אותי לשמוע מה דעתכם ואיך זה מתקבל בארגון שלכם (או בארגונים שעברתם בהם).

האם תוכניתן ותיק שלא עשה תפקיד ראש צוות הינו עוף מוזר?

 

 

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

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

מסלול התקדמות אחר הוא התמחות. אם אתה מתלבש על נושא מסויים (נניח סוג מסוים של אלגוריתמים, kernel של מערכת הפעלה מסויימת או נושא אחר שבו יש מעט מאוד אנשים שמבינים) אתה יכול אחרי כמה שנים של עיסוק בו להחשב מומחה או גורו.

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

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

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

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

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

יש מתכנתים ש"חצו את הכביש" ופנו לתפקידים שכנים שאינם תפקידי פיתוח כמו תמיכה טכנית, ניהול מוצר, ניהול קשרי לקוחות, pre/post sale , הדרכה וכו.

צטט: השכן ממול 2009-08-12 16:29:45

 

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

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

 

מסלול התקדמות אחר הוא התמחות. אם אתה מתלבש על נושא מסויים (נניח סוג מסוים של אלגוריתמים, kernel של מערכת הפעלה מסויימת או נושא אחר שבו יש מעט מאוד אנשים שמבינים) אתה יכול אחרי כמה שנים של עיסוק בו להחשב מומחה או גורו.

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

 

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

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

 

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

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

 

יש מתכנתים ש"חצו את הכביש" ופנו לתפקידים שכנים שאינם תפקידי פיתוח כמו תמיכה טכנית, ניהול מוצר, ניהול קשרי לקוחות, pre/post sale , הדרכה וכו.

 

 

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

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

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

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

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

אם מצד שני תפקיד המנהל הוא יותר באיזורי התכנון, המעקב ובניית הצוות הנכון, יהיה בצוות כזה מקום טוב לאותו "מומחה kernel" ואף אחד לא יסתכל עליו בצורה עקומה למה הוא עדיין לא התקדם והחליף (!) את הר"צ.

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

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

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

צטט: ariel-segal 2009-08-12 18:25:40

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

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

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

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

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

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

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

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

שכר של מהנדס עם 8 שנות נסיון ושל מהנדס עם 15 שנות נסיון יהיה דומה (למעשה עם 15 שנות נסיון אתה כבר מגיע לגיל שבו אזה נחשב "זקן"והשכר יכול להתחיל לרדת).

בתפקידי ראש צוות הקידום יותר מדיד, יש הבדל בין ראש צוות של 2 אנשים לראש צוות של 8 אנשים. את ההבדל הזה אתה יכול להעביר איתך ממקום למקום.

צטט: השכן ממול 2009-08-13 10:30:20

 

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

  

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

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

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

צטט: ariel-segal 2009-08-13 18:10:53

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

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

 

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

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

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

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

כמו שכבר נכתב יש סיכוי גדול שמהנדס תעשיה וניהול יהיה מנהל יותר טוב ממהנדס תוכנה.

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

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

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

באופו טבעי יש אנשים שלוקחים אחריות ומגלים ראיה רחבה יותר והופכים למובילים.

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

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

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

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