הקדמה

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

כל הבלאגן הזה עשה צרה למנהלים.
חברות שהפכו לפתרונות תוכנה נאלצו להתמודד עם משהו חדש - הון אנושי.
מתכנתים מוכשרים לא מוצאים במכולת, והרבה מגייסים הבינו את זה.
הדבר הראשון שמגייסים מחפשים זה פשוט על הנייר - כמה שנים עבדת.
לעיתים אפילו לא חשוב במה.
אתה יודע C# ועסקת בזה 3 שנים?
לא נורא… יהיה לך קל עם JavaScript ו-Ruby.

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

זה גרם למה שאני קורא לו… שגעת הסניורים.

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

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

ג’וניור

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

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

כאן אעלה שאלה מעניינת -

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

ג’וניור מסוג אחר - בוגר קורס

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

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

ג’וניור מסוג אחר - בוגר מכללה

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

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

ג’וניור מסוג אחר - הסבת מקצוע

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

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

ג’וניור מסוג אחר - בוגר יחידה טכנולוגית צבאית

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

אך יש גם חסרונות לבוגרי צבא בתחום התוכנה:

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

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

סניור

מהו סיניור?

• אדם בוגר יותר
• אדם בעל ניסיון יותר רב
• אדם בעל סמכות גבוה יותר

בפשטות סניור הוא אדם מנוסה יותר.
בראייה לעבודה - לתפקיד סניור לעיתים צריך 3,5 או אפילו 10 שנים ניסיון על מנת להחשב סניור מספיק בשביל להתראיין לעבודה.
רגע… זהו זה? אממ כן.

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

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

השוואת משרות

1
2
3
4
5
6
7
8
9

Senior Backend Developer
......

מה צריך:
5 ומעלה שנות ניסיון בפיתוח תוכנה
3 שנות ניסיון בפיתוח Asp.Net ו-Python
ניסיון ב-SQL
ניסיון בעבודה בסביבת Cloud
ניסיון ב-Microservices

1
2
3
4
5
6
7
8

Backend Technical Lead
....
מה צריך:
10 שנות ניסיון בפיתוח Backend
4 שנים בפיתוח Python
עבודה בסביבת AWS
עבודה עם Big Data
תואר ראשון טכנולוגי

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Senior Full Stack Developer 
Required Senior Full Stack Developer
Requirements:
At least 6 years of experience in development
Great interpersonal skills
At least 2 years of experience with NodeJS
1+ years of experience working with React/Angular, preferably also with TypeScript
Solid understanding of RESTful web services
A passion for problem-solving, reading and learning, and of course, building great software
Can-do attitude
Its even better if you have:
Experience working with Kafka
Experience working with ElasticSearch
Experience working with NestJs
Familiarity with AWS services like Lambda, SQS and EKS.
A Bachelor's degree in Computer Science, Engineering, or equivalent relevant experience.

איזה מספרים אנו רואים כאן?

• פיתוח תוכנה כללי - 6, 10 או 5 שנות ניסיון בכל צורת פיתוח תוכנה.
• שנה, שנתיים, 3 או 4 שנות ניסיון לטכנולוגיה ספציפית

מה עוד אנו רואים?

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

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

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

למה סינון כזה יכול להיות בעייתי?
בתחום התוכנה זה לא הסנדלר הולך יחף אלה צריך להתאים לסנדלר את הנעליים המתאימות לו.

“סינדרלה סינדרלה, האם זו הנעל שלך?”
“ לא… כתוב שזה 8 שנים ניסיון ולי יש רק 3”

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

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

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

סניור מסוג אחר - הייתי 10 שנים באותו מקום

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

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

סניור מסוג אחר - עובד רק בשפה אחת

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

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

סניור מסוג אחר - מנהל בלבד

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

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

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

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

סניור מסוג אחר - מנהל מוצר

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

סניור מסוג אחר - צרות של אנשים

סניורים הם אנשים.
ואם יש אנשים יש בעיות…
אני מאמין שסטאלין אמר זאת.

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

השמרנים

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

הזאב הבודד

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

אגו גדול

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

אין עזרה לג’וניורים

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

שומר השער

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

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

סניור מסוג אחר - ידע דומיין רב

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

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

שגעת הסניורים

כשכולם סניורים - אף אחד לא סניור.

בתור סניור בעצמי אני רוצה לומר.. זו שגעת.
מעולם לא אהבתי לקרוא לעצמי סניור למרות הניסיון שלי.

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

נדגים את השגעת הזו ע”י רמות עבודה בחברות ומלחמות תארים שונות.

חברות גדולות - רמות למפתחים ומנהלים

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

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

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

level 4/X/Y/Z - רמות שונות יוגדרו לצרכים שונים, כגון

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

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

מיקרוסופט

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

L59 - Software Engineer (Entry Level)

Fresh graduates or junior developers.
Focus on learning, small tasks, and contributing to projects under guidance.
L60-L62 - Software Engineer II

Intermediate-level developer.
Works more independently, contributing significantly to projects.
L63-L64 - Senior Software Engineer

Leads smaller projects or significant components of larger projects.
Mentors junior developers, actively involved in system design.
L65-L66 - Principal Software Engineer

Leads large-scale projects and teams.
Strong influence over technical strategy and cross-team collaborations.
L67+ - Partner/Distinguished Engineers

Technical visionaries with organization-wide impact.
Drive innovation and influence company-wide engineering decisions.
L68+ - Technical Fellow

אמזון

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

L4 - Software Development Engineer I (SDE I)

Entry-level developers.
L5 - Software Development Engineer II (SDE II)

Mid-level developers with solid independence.
L6 - Senior Software Engineer

Leads projects, mentors team members.
L7 - Principal Engineer

Oversees technical strategy and leads across multiple teams.
L8+ - Senior Principal/Distinguished Engineer

Drives organization-wide technical decisions.

גוגל

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

L3 - Software Engineer (Entry Level)

New grads or entry-level engineers.
L4 - Software Engineer II

Mid-level developers with a few years of experience.
L5 - Senior Software Engineer

Leads projects and mentors peers.
L6 - Staff Software Engineer

Manages and guides teams; deeply involved in design and architecture.
L7 - Senior Staff Engineer

Leads engineering efforts across teams or departments.
L8 - Principal Engineer/Director

Sets strategic directions and drives large, cross-company projects.
L9+ - Distinguished Engineer/Google Fellow

Industry leaders with a massive impact on Google's technology and vision.

מה הרשימות האלו מלמדות אותנו

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

האמת על התפקידים

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

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

מפתחים לעיתים עוסקים בין 20-80% מהזמן שלהם, בעבודה שהיא לא פיתוחית נטו.

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

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

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

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

מלחמת התארים

ברכותיי!
אתם סניורים.
מה תכתבו בקו”ח?
Senior Software Developer?
או Software Architect?
או Senior Software Lead?

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

היררכיה מול יצירתיות

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

תוכנה כמודל היררכי

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

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

תוכנה כמודל יצירתי

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

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

מודלים כאלו מעניקים סמכות פתוחה למפתחים וכותבי הקוד.
למה?
בשביל לפתור בעיה “מחוץ לקופסה” צריך ליצור סביבה שהיא מחוץ לקופסה - מחוץ להיררכיה הסמכותית.

המשיכה האינסופית בין יצירתיות להיררכיה

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

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

יצירתיות, היררכיה והגדרת תפקיד

להיות יותר יצירתי אבל לא להיות כפוך לסמכות?
תהיו ארכיטקט.
יותר סמכות?
מנהל בכיר.

אתם רוצים לנהל צוות מבלי הסמכות הגדולה מדי?
תהיו “מוביל תוכנה”.

אתם רוצים קידום אבל אין באמת הגדרת תפקיד?
תהיו סניור שקר כלשהו…

וכאן מתחילה השגעת הרצינית.

שגעת התפקידים

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

כמה תפקידים שמצאתי:

• Senior Software Developer
• Solutions architect
• Group Manager
• Infra Dev-OPS
• Technology Leader
• Lead Program Manager
• Chief evangelist
• Team Lead
• AI Engineer

קיים רציונל טוב להגדרת תפקיד:

• מה התפקיד עושה
• במה הוא מתעסק
• ומה הסמכות שלו

AI Engineer Team Lead - בברור אומר שזה צוות מנהדסים שעובדים בתחום הבינה והתפקיד מגדיר אותו בתור ראש הצוות.
אבל מה ההבדל בין Group Manager ל-Senior Software Lead?
מה ההבדל בין Technology Leader ל -Solutions Architect?

אינפלציית התארים

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

אני אחזור על זה שוב:

כשכולם סניורים אף אחד לא סניור

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

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

סוף דבר

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

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

תודה על הקריאה!