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