להיפטר מהפחד מהעבודה הראשונה שלך

סטילס מהסרט "הארי פוטר והאסיר מאזקבאן"

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

צ'ארלס בוקובסקי

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

השאלות היו בערך כך:

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

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

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

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

הם לא יעסיקו אותך בכלל

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

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

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

מבין מאות בוגרים, רק כמה עשרות מעניינים את המעסיקים

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

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

אלברט איינשטיין

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

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

טיפש - תפטר

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

עולה חדש לתפקיד צפוי:

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

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

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

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

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

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

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

בדרך כלל השלבים להפעלת מוצר בסביבת בדיקה הם בערך כך:

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

במהלך תהליך הפעלת מערכת מקומית, יצוצו בהכרח בעיות בלתי צפויות.

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

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

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

רישום המחקר שלך בצורה של מסמך יאפשר לך:

• לפרוק פרטים קטנים מהראש שלך. לדוגמה, פרמטרי תצורה, כתובות DNS/IP, פקודות מסוף ושאילתות SQL.
• זכור "מה עשיתי אתמול" כאשר המשימה נמשכת מספר ימים
• אל תסתובב במעגלים. תמיד תוכל לקרוא מה עשית קודם ולהבין שחזרת לבעיה המקורית
• ענה בבירור על השאלה: "מה עשית היום?" גם אם אין עדיין פתרון מוכן.

אתה צריך להיות מסוגל לתקשר את מצב המשימות שלך לעמיתים

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

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

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

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

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

אתה מוזמן לבקש עזרה

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

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

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

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

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

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

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

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

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

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

• שאלות כמו "אם תעשה את זה ככה, זה ייצא ככה. זה לא בדרישות. זה צריך להיות?"
• משימות במעקב אחר באגים "הדרישות אומרות את זה, אבל במציאות זה כתוב אחרת."

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

אם תתבלבל, יפטרו אותך

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

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

העיקר ללמוד מטעויות ולא לחזור עליהן שוב.

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

עדיף להימנע מאירועים

גם אם אתה אישית לא פוטרת בגלל טעות, אירוע כזה יגרום לבעיות לא רצויות לצוות שלך ולפרויקט כולו. לכן, היזהר במיוחד עם פעולות מחיקה או יצירת טבלאות במסד הנתונים, קבצים, מופעי שירות ומסמכים במאגר הידע של הפרויקט. אם נתקלתם בכתובת של חיבור חדש, בדקו עם לפחות שני אנשים שונים מה אפשר לעשות שם. בדוק את הזכויות שלך בסביבות לא על ידי ניסוי וטעייה, אלא על ידי שימוש בפקודות המתאימות. לדוגמה, זכויות למחיקת קבצים באמצעות הפקודה `ls`, זכויות לעבודה עם טבלאות ב-mysql באמצעות הפקודה `SHOW GRANTS FOR 'user'@'host';` וכדומה. כמעט בכל כלי תהיה לך הזדמנות דומה.

בעת עריכת קבצים, שמור עותק של המקור לעצמך, ליתר בטחון.

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

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

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

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

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

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

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

אני מאחל לך סבלנות והתמדה.

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

מה היו המשימות הראשונות שלך בעבודה הראשונה שלך ב-IT?

• מורכב

• חָשׁוּב

• דחוף

• אף אחד מן הנזכרים מעלה

75 משתמשים הצביעו. 20 משתמשים נמנעו.

מה היית צריך לעשות בהתחלה בעבודה הראשונה שלך?

• התקן את המוצר באופן מקומי

• בדוק מוצר קיים

• בצע אימון, משימה מזויפת

• עשה פרויקט ניסיוני, אמיתי עבור לקוח

63 משתמשים הצביעו. 25 משתמשים נמנעו.

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

• 1 של 10

• 1 של 5

• כל שנייה

• הכל, למעט חריגים נדירים

70 משתמשים הצביעו. 19 משתמשים נמנעו.

מקור: www.habr.com