הארגון משווע לכוח אדם טכני? 10 הצעות...

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

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

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

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

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

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

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

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

מתוך הבנת המגמות, השכר והשאיפות, מרחפת שאלה: האם נידונו יחידות ה IT בארגונים למות? לעבור לידיים זרות (של חברות שהפיתוח הוא המוצר שלהם)?

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

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

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

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

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

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

3. שילוב LowCode: בארגון מפתח, המשתמש בכלי פיתוח חזקים, מתפתחת הנטיה לפתור כל צורך פיתוחי ב... כלי הפיתוח החזקים, סוג של: "כל המחזיק פטיש יותר מדי זמן - רואה כל בעיה כמסמר" . אולם, מה לעשות שברוב המכריע של מערכות התכנה, יש המון עבודת UI תהליכית, שאינה קשור לעולמות המורכבים כמו IOT, ריבוי טרנזקציות, ממשקים מורכבים וכיוצ' אלא פשוט מאפשרת לארגון לעבוד ולנהל תהליכים את התהליכים שלו. ותפיסת העולם שמי מכבר פתר אתגר פיתוחי כבד, "קטן עליו לפתח כמה מסכים לארגון" כנראה נכונה - למפתח - אבל ממש לא לארגון. שכן כלים כבדים, דורשים כ"א מומחה, יקר, זמן הכשרה ארוך, מקום רב לתקלות (וכיוצ'), מה שמלמד אותנו שלא תמיד נצליח להרוג יתוש עם טנק. השימוש בטכנולוגיות לא מדויקות, מייצר את בהחלט מאתגר אותנו בכ"א. בכדי להפחית את הצורך באנשי תוכנה חזקים צריך לדייק את אזורי הפיתוח בכלי פיתוח "כבדים" ובשאר המקומות (מתוך משנה סדור וארכיטקטורה מתוכננת היטב) להשתמש בכלי LowCode המאפשר זמן הכשרה מהיר, עלות מופחתת של כ"א, תפוקה מהירה בסדר גודל של בין פי 6 ל פי 10 ועוד, הרבה פחות מקום לתקלות, הקטנת מאמץ התחזוקה, שיפור ה Time To Market של הפתרון הבא, אבל - רק באזורים שהמוצר מתאים ומכסה את עיקר הצורך.

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

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

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

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

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

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

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

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