מי זה מי ב-IT?

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

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

ייצור IT לחסרי התחלה

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

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

נכון לעכשיו, אני ממשיך לעבוד על הנושא הזה, אבל ברמה אחרת. כראש מרכז הפיתוח של חברת IT, אני נאלץ לא פעם לתקשר עם סטודנטים, מורים באוניברסיטאות, מועמדים, תלמידי בתי ספר ואחרים שרוצים להשתתף ביצירת מוצר IT כדי לקדם את מותג המעסיק בשוק העבודה של טריטוריה חדשה (Yaroslavl). תקשורת זו אינה קלה בשל המודעות הנמוכה של בני השיח לאופן ארגון תהליך פיתוח התוכנה, וכתוצאה מכך, חוסר ההבנה שלהם בנושא השיחה. לאחר 5-10 דקות של דיאלוג, אתה מפסיק לקבל משוב ומתחיל להרגיש כמו זר שהדיבור שלו דורש תרגום. ככלל, בין בני השיח יש מי שמתווה קו בדיאלוג ומשמיע מיתוס עממי משנות ה-90: "בכל מקרה, כל מומחי ה-IT הם מתכנתים". מקורות המיתוס הם:

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

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

מחזור חיי תוכנה כבסיס לתפקידי ייצור

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

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

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

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

מגוון עמדות תוך שימוש בדוגמה של תפקיד האנליטיקאי

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

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

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

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

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

האם אנחנו לוקחים מבחוץ או גדלים?

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

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

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

הצטלבות, אינטגרציה והתפתחות של תפקידי ייצור

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

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

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

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

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

מה רע ב"גן החיות" של עמדות IT?

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

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

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

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

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

האם אפשר להביא הכל למכנה משותף?

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

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

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

דרכים לבניית עבודת כוח אדם יעילה בייצור IT

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

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

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

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

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

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

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

מקור: www.habr.com