DCSIMG
August 2010 - Posts - הבלוג הפתוח למנהל הפיתוח

הבלוג הפתוח למנהל הפיתוח

מנהל פיתוח תוכנה? זה המקום שלך ללמוד וללמד

על הבלוג

נתקלת פעם באתגרים כמנהל פיתוח? התמודדת עם ניהול אנשים? טיפלת בפרויקטים מורכבים בתחום פיתוח התוכנה? עמדת (פחות או יותר) בלו"ז מאתגר על מנת להביא מערכת לייצור? נדרשת לבחור ארכיטקטורה, כלי פיתוח ו/או סביבת פיתוח? התנסית בהטמעה של מתודולגיות פיתוח מתקדמות כגון Agile ו -SCRUM? התלבטת היכן למקם את צוותי הבדיקות? עמדת באתגרים של התאמת כיוון לאור שינוי בהיבטים העסקיים? אם ענית על אחת מהשאלות הללו בחיוב, ואתה משמש בתפקיד בכיר בעולם פיתוח התוכנה, יש סיכוי טוב שהבלוג הזה יעניין אותך. אנחנו נקדיש זמן ומחשבה לדון בסוגיות אלו ואחרות על בסיס הנסיון האישי שלי, שלכם ושל עמיתינו למקצוע. למה הבלוג הפתוח? כי נסיון של אדם לא מספיק כדי ללמוד ממנו, לכן גם אתם מוזמנים לתרום אם בצורה של תגובות לפוסטים ואם ע"י פוסטים אורחים. מה לגבי ההמשך? כולי תקווה כי בעתיד ניתן יהיה לארוז את תכני הבלוג ותכנים נוספים בתצורה מובנית יותר בצורה של ספר. Follow MosheKaplan on Twitter

August 2010 - Posts

למה ניהול סיכונים לא מעניין אף אחד

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

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

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

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

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

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

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

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

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

בטבלה המצורפת תוכלו לראות כיצד אותו חבר מימש את השיטה הזאת. במקרה הזה מדובר על דילמה כיצד לממש מנגנון עדכון נתונים מהשרת למערכת המשלבת מבחר Clients בפלפורמות סלולאריות (Nokia, BlackBerry, Android, iPhone ואחרות) ובפלטפורמה אינטרנטית מסורתית (דפדפן :-). הפתרונות כוללים 1) התבססות על מנגנון דגימה מדי מספר דקות על בסיס HTTP (בדומה למנגנון העדכונים של פייסבוק), 2) על שרת שמחזיק TCP Conncections פתוחים לאורך זמן, או על 3) שימוש בפתרונות Push יעודיים שקיימים בפלטפורמות הסלולאר המובילות. בטבלה מפורטים עלויות הפיתוח, העלויות השוטפות של תעבורת רשת ושרתים והסיכונים השונים.
ניתוח חלופות לפיתוח מערכת COMET ל - WEB, iPhone, Android, RIM, Blackberry, Long Polling, TCP Connections and Push
לבסוף צריך להציג המלצה. ברגע שהצגתם בצורה טובה את החלופות האפשרויות והסיכונים המתלווים להם בצורה גרפית פשוטה, למנהל יהיה קל מאוד לקבל החלטה. באופן די מפתיע הוא גם יתחשב בסיכונים שהצגתם (בניגוד למה שאולי אתם חושבים, מנהלים לא ממש אוהבים סיכונים וברגע שמציגים להם פיתרון טוב הם ישמחו לקחת אותו). במקרה הזה לא תתפלאו שההנהלה של אותו חבר בחרה בפתרון הראשון של מנגנון Poliing כפתרון קצר טווח להגעה לשוק, ופיתוח מנגנוני Push יעודיים בהמשך לכל פלטפורמה כפתרון הארוך טווח על מנת לצמצם עלויות. פתרון ה - TCP Connection הוגדר כבעל סיכונים גדולים מדי, ויתרונות מעטים מדי יחסית למאמץ.

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

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

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

ממשיכים לפתח,

משה קפלן

Follow MosheKaplan on Twitter

נ"ב מתעניינים למה כל כך הרבה חברות גדולות הופכות את המוצרים שלהם ל - Open Source? אתם מוזמנים לקרוא את הניתוח שלי בבלוג האנגלי על נושאי ענן וביצועים

מה נפוליאון היה שואל בראיון עבודה

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

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

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

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

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

אז מה לשאול?

  1. החימום: אין כמו Small Talk במכירות, וכך גם בראיון עבודה. אל תשכחו לפטפט מעט עם המרואיין, להציע לו שתייה, אוכל ונוחיות. השיחה הזאת מאפשרת לייצר קשר אישי שיפתח את השיחה וגם לאסוף מעט מידע כללי (האם באמת הוא עדיין עובד, מאיפה הגיע וכו').
  2. שאלות קו"ח: עברו על הקו"ח עם המועמד ועמתו אותו עם סוגיות מהותיות ומה שחורג ונראה לא מסתדר עם פרופיל התפקיד. עדיף לשאול עכשיו מאשר להיות מופתעים אח"כ
    1. טיפ: רב האנשים שכבר לא עובדים ידברו על מקום העבודה הקודם בלשון עבר ו/או בגוף שלישי ("הם עושים"). בד"כ גם אם הם ינסו להחביא את זה, זה יפלט במהלך הראיון. אין בזה שום דבר רע, אם המועמד סיים לפני שבועיים את העבודה והחליט במודע לעשות הפרדה בין שני מקומות העבודה. זה פחות טוב אם הוא מנסה להסתיר את זה (אמינות כמו שעדיין קוראים לזה בבה"ד 1).
    2. טיפ נוסף: ודאו את נושא הלימודים, מרואיינים רבים מגלים בשלבים מאוחרים של הראיונות ו/או אחרי הקליטה שהם לומדים בחצי/רבע משרה, רק בערבים (צריכים לצאת פעמיים בשבוע ב - 15:00). אין שום דבר רע באנשים שמרחיבים את הדעת, אלא אם אתם סטארט אפ של שלושה אנשים שבנה על מתכנת נוסף שיעבוד איתם לתוך הלילה.
  3. שאלות מקצועיות טכניות: האמת שבד"כ קוראים לזה "השאלות שגם המראיין לא ממש היה יודע אם הוא לא היה פותח את הספר קודם לכן". מה עושה Constructor סטטי ב - C Sharp. איזה שטויות אפשר לעשות ב - Multi Threaded ו - Design Patterns יצירתיים יותר או פחות. המטרה של השאלות הללו לראות האם האדם עשה הכנה לראיון, ומה הכיוון והשפשוף שהיה לו עם התאוריה.
  4. שאלות כלליות: תפיסה מרחבית - מה היתה ארכיקטורת המערכת שלכם? מה המבנה הארגוני? באיזה מוצרים השתמשתם? בד"כ זה יאפשר למועמד לשרטט תרשימים על דף שיעידו על רמת הראייה המרחבית שלו. תגובות מגומגמות ושרטוטים אמורפיים, יצביעו על בעיה בנושא, והיות המרואיין בורג קטן במערכת מבחירה (וכן, יש תפקידים שתשמחו לאייש באנשים שיעשו את העבודה שלהם ולא יגרמו יותר מדי רעש). עודף פרטים והתקשקשות על קטנות בציורים? צפו להתאים את האדם למשרה מפוקסת שיהיה לו קשה להתברבר בה.
  5. שאלות מקצועיות מערכתיות: הצגת בעיה מערכתית (בעיית ביצועים לדוגמה, ומי שמכיר אותי לא יתפלא למה בחרתי בדוגמה כזאת), ובקשה מהנבחן להסביר מאיפה נובעת הבעייה ואיך הוא יזהה ויפתור אותה. השאלה הזאת תשמש אתכם לזהות מה הנטייה של האדם: האם הוא מתחיל מהשרת, בסיס הנתונים או דווקא מהחומרה, התקשורת או ה - GUI? איזה כלים הוא מכיר ובמה יבחר להתחיל? האם נתקל בבעיות כאלו בעבר? אין פה תשובות נכונות או לא. רציתם לדעת אם אתם מגייסים איש Server או איש Client? רציתם לדעת אם הוא איש אינטרנט או RIA/Rich Client? האם הוא מאוהב ב - Design Patterns או דווקא אוהב להתקין שרתים? השאלה הזאת תתן לכם את התשובה.
  6. שאלות אישיותיות: תן 3 תכונות טובות שלך... את השאלות הללו אני אוהב להשאיר לכ"א. בד"כ את התשובות לכך תוכלו לקבל מהשאלות המקצועיות: האדם פרפקציוניסט? הוא ישרטט לכם את התרשימים כמו סרגל, ויתקן 10 פעמים כדי לעמוד בעובדות. האדם מעופף? אתם תראו את זה בתשובות (בעיקר לשאלות הכלליות והמערכתיות). רוצים לראות תגובה למקרי לחץ ו/או התנהגות תחת לחץ, הקשו על המועמד את התשובה לשאלה המערכתית, ותראו כיצד הוא מתמודד איתה. מחפשים אדם שהטכנולוגיה באמת מעניינת אותו? שאלו על הכירות עם Open Source והשתתפות בכנסים ואירועים חברתיים של התעשייה.
  7. סגירה: בקשו מהמועמדים לשאול שאלות, כדי לחסוך אי נעימויות אח"כ, לראות לאן הם נוטים (אם הם לא באמת מעוניינים במשרה הם לא ישאלו) וללמוד על נטיות ליבם (האם החברה יציבה? האם החברה בצמיחה? איזה ארוחות צהרים יש באיזור? למה אין חניה לאורחים?). זה  גם המקום להציג בקצרה את החברה, התפקיד, ואופי העבודה (למה לא לעשות את זה בהתחלה? סביר שהמועמד נרגש ועדיין לא מפוקס בתחילת הראיון ובסופו הוא יטה להקשיב יותר), כמו גם הציגו להם את תהליך הראיונות והמיון. לבסוף הודו להם על זמנם, ומסרו להם שנציגי החברה יהיו איתם בקשר.

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

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

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

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

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

ממשיכים לפתח,
משה קפלן
Follow MosheKaplan on Twitter

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

שקט! מגייסים

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

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

מאיפה משיגים עובדים?

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

 

ראיונות עבודה בתחום פיתוח התוכנה

תהליך הראיונות:

  1. סינון קורות חיים: מעבר על קורות החיים וזיהוי בעיות ו/או שאלות: פערים בשנים, זיגזוג בין תחומי עיסוק, חוסר פוקוס ודברים שיצביעו על כך שהמועמד שלכם זה לא מה שחיפשתם (אדם שמחפש משרה סופר טכנית, ומצד שני בדיוק באמצע תואר במנהל עסקים, עבודה בסדרה של חברות כבדות ופתאום הופעה בחברת סטארט אפ). שימו לב, בנקודה זו להזהר ולא לצבור עודף של דעות קדומות, לפעמים דווקא זגזוגים קלים של המועמד מצביעים על ראייה מרחבית יותר ויכולות שיוכלו לגוון את הצוות שלכם.
  2. הצלבה מול Linkedin: תתפלאו, אבל אני סומך הרבה יותר על קו"ח הללו משתי סיבות עיקריות: אנשים בד"כ לא מעבירים אותם אצל אנשים שעושים להם "טיובים" ודבר שני, הרבה יותר קשה לעקם את האמת כאשר כולם רואים אותה באינטרנט, מאשר בדף נייר (או מסמך וורד) שנשלח רק אליכם ולעוד כמה עשרות אנשים. חוסר התאמה בתפקידים/שנים/תיאור מול מה שכתוב בקו"ח צריך להעלות סימני שאלה משמעותיים. התאמה מצד שני יכולה להוות אישוש לאמינות קו"ח.
  3. זיהוי מכרים/נקודות הצלבה בקריירה: תמיד טוב לקבל חוות דעת מאדם אחר שעבד איתו ולא עבר תדרוך מסיבי לפני כן (למרות שגם ממליצים כדאי לבחור). יש כאלו שמבצעים את הגישוש לבירור פרטים כבר בשלב הזה, ויש כאלו שיבצעו אותו רק לאחר פגישה עם המועמד.
  4. גיגול פשוט על השם בעברית ובאנגלית: תאמינו לי שאתם תשמחו מאוד לגלות שהמועמד שלכם תרם קוד לפרויקט Open Source, שואל שאלות מקצועיות בפורומים, או סתם מבלה להנאתו ב - GarageGeeks. כמובן שיכול להיות שתגלו דברים שפחות ישמחו אתכם.
  5. מעבר על מבנה קו"ח: פעמים רבות ניתן ללמוד רבות על המועמד שלכם מדברים שנראים שוליים לכאורה: אופן העימוד של המסמך, הפונטים, הסדר, רמת הפירוט, סדר הקו"ח (השכלה, נסיון, שירות צבאי וכו'), כיצד הוא ממצב את עצמו.
  6. סדר הראיונות ותהליך הקליטה:
    1. ראיון טלפוני: מקסימום 10 דקות, בצעו מספר שאלות רקע, ועברו על הנקודות "הכואבות" שזיהיתם. אם תבינו שאין על מה לדבר, חסכתם לעצמכם שעה, ולמועמד 3 שעות והרבה טרחה ועוגמת נפש. שיחת הטלפון יכולה להיות הדרך שלך לתת הזדמנות גם למועמדים שעל פניו יש בעיתיות בהם. אזהרה: יש לוודא עם המועמד שמדובר על זמן נוח, רב המועמדים ובעיקר האיכותייים בהם עדיין עובדים במהלך חיפוש העבודה, והעלמות לשיחות טלפון ארוכות מחשידות (ואת זה תוכלו לקרוא בפוסט הקודם על נטישת עובדים).
    2. ראיון ראשון: ראש צוות - זה האדם שיצטרך לעבוד עם המרואיין, ותפקידו הוא בעיקר סינון ראשוני וצמצום מספר המועמדים שמגיעים אליך, המיקוד צריך להיות מקצועי וחברתי על מנת לזהות כימיה והתאמה מקצועית. אני מאמין שבשלב זה רצוי לשלב שני מראיינים אחד אחרי השני או שניים ביחד. השילוב של שני אלו יאפשר השגה של מספר יתרונות משמעותיים:
      1. שיפור דיוק: זהו ראיון קריטי של מרואיין שעבר סינון ראשוני, לכן רצוי לא להסתמך על חוות דעת מקצועית אחת. אל תשכחו, בגלל שיקול דעת של אדם אחד (שיתכן שהניסיון שלו מצומצם יחסית) יתכן שתפסידו מועמד מצויין.
      2. שיפור אחוזי המרה: היכרות של המועמד עם מספר רב יותר של מהנדסים שיעבדו איתו יגביר את הסיכוי שהוא יצטרף אליכם. למה? אנשים אוהבים לדעת שהם הולכים לעבוד עם אנשים טובים. הם אמנם מעריכים מנהלים מצויינים, אבל הידיעה מי זה האדם שישב איתך בחדר מקטינה את החששות ומגדילה את ההזדהות עם הארגון.
      3. הכשרה: גם ראיון זה הכשרה, וכדי לראיין בצורה טובה צריך להתאמן. אם לא תאמנו את האנשים שלכם בשלב מוקדם לבצע את התהליך הזה, תשלמו על זה בהמשך.
      4. אימון: תתפלאו, אבל אפשר ללמוד דברים רבים מהאנשים שאתם מראיינים. מכיוון שאתם שכירים בארגון ולא מסתובבים בין חברות, תהליך הראיון הוא אחת מההזדמנויות שלהם ללמוד כיצד אחרים בתעשייה עובדים, כמה טובות שיטות הניהול שלהם ומה יכולות ה - Application Lifecycle Management שלהם.
      5. שימור עובדים: ראיון הוא עבודה, אבל הוא גם שבירת שגרה, זאת הזדמנות של המראיין להיזכר למה הוא עובד בחברה,למכור אותה ולגלות שיש שהמקום שהוא עובד בו טוב לפחות כמו האחרים.
    3. ראיון משאבי אנוש: על מנת לאתר חריגים. מנסיון, הדעה של כ"א לא תהיה שונה בהרבה ממה שאתם תזהו (אתם בכל זאת עושים את זה יותר מיום יומיים), אבל עדיין יש שאלות עדינות שלפעמים מזהות נקודות שמועמדים מיומנים יודעים להסתיר. הראיון הזה מאפשר לכם גם לקבל נקודת מבט שונה מאדם בעל רקע שונה משלכם.
    4. ראיון מסכם: ראש הקבוצה - סינון אחרון שעיקרו מבוסס על הנסיון והאינסטינקטים של אדם עם רקע טכני ובעל נסיון בגיוס ושילוב עובדים חדשים. המיקוד בראיון זה הוא בעיקר הראייה הרחבה שמחברת בין ההיבטים האנושיים והטכניים, כאשר המטרה היא למעשה קבלת החלטה. השלבים לאחר מכן ישמשו בעיקר לביצוע סגירה והבנה שלא עשיתם טעות בדרך.
    5. המלצות: לאחר הראיון מומלץ לטלפן לממליצים ולקבל אימות לנקודות החזקות והחלשות אותן זיהיתם. רצוי מאוד לבצע את השיחה בצורה מדוקדקת ולא רק כדי למלא וי במשבצת. מומלץ גם להצטייד מראש ברשימת שאלות כדוגמת:
      1. מה ההתרשמות הכללית שלך מהמועמד?
      2. האם ניהלת אותו באופן ישיר? (תתפלאו אבל לעיתים תקבלו תשובות שלא ציפיתם להן)
      3. מה הנקודות החלשות של המועמד?
      4. האם הייתם מגייסים אותו היום?
    6. סימני שאלה? צריכים הבהרה? לא צריך לפחד משילוב של ראיון קצר שיפתור את הדילמה. אם מדובר על מתכנת שצריך לעשות עבודה טכנית, בהחלט ניתן לשלב פעילות תכנות קצרה על מחשב (לצורך העניין הלפטופ שלי). המתכנת שלכם הרי לא הולך לכתוב קוד על נייר... או לפחות אני מקווה שזה המצב.
    7. הגועל נפש: אם הגעתם לכאן, כולם הסכימו (בתקווה) שמדובר בדיל טוב, ועכשיו רק נותר רק לסגור על הכסף/ימי חופש/אופציות/מענק גיוס/Title (מחק את המיותר).

אולי מרכז הערכה?

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


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

נ"ב אם אתם קוראים את הפוסט הזה בעיצומו של חודש אוגוסט ואתם מכירים איש QA מצויין בעל יכולות ונסיון באוטומציה ובדיקות עומסים שלא מפחד גם מבדיקות ידניות כשממש צריך, ורוצה להשתלב בקבוצה מצויינת. זה המקום לפנות mokplan at gmail dot com.

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

ממשיכים לפתח,
משה קפלן Follow MosheKaplan on Twitter

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

זה לא אתה, זה אני

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

 
כל אחד מאיתנו רוצה להמנע מהסיטואציה שבה מגיע אליו עובד ומודיע לו שהוא החליט לעזוב כי הוא מיצה את עצמו/החליט לעשות רלוקישן/תחום המחשבים לא בשבילו והוא עבר לעסקי המדיטציה (למרות ששבוע אח"כ תגלה שהוא עבר לעבוד אצל המתחרה)/יום אחד טלפן אליו מכר ותיק (שהוא לא פגש מעולם) והציע לו את הצעת חלומותיו (מחק את המיותר).
אבל לפעמים אנחנו מגיעים למצב שבו העובד החליט שהוא עוזב, או במצב הטוב יותר החליט שהוא רוצה לבדוק את עומק המים בחוץ, לאן מנשבת הרוח וכמה כסף מציעים אצל השכן.
 
זמן יקר
במצב כזה ידיעה מוקדמת של התהליך יכולה לספק לנו זמן ארוך יותר להתכוננות שיכולה לשמש אותנו לאחת מהמטרות הבאות:
  1. יירוט של מאמץ העובד: אם אנחנו מבינים שלא נתגבשה בו החלטת עזיבה. לדוגמה במקרה שהעובד מחפש קידום, יתכן שניתן יהיה לתפור הצעה מעניינת למספר חודשים קדימה, לפני שהעובד התחיל לקבל הצעות מעניינות מהמתחרים.
  2. צמצום הנזק הישיר: במקרה שהבנו שהעובד באמת מתכוון לעזוב (לדוגמה הוא מכחיש שהוא מחפש וטוען שהכל ממש מושלם למרות שהצלבנו מספר מקורות), זה הזמן לצמצם את התלות בעובד, ע"י הגדלת מספר ה - Code Reviews, מידור מפיתוח אסטרטגי שיבשיל רק בעוד מספר חודשים (בעיקר אם יש חשש שהוא יעבור למתחרה בתעשייה) ובניית תוכנית פעולה ליום שהעובד יודיע על עזיבתו.
  3. צמצום הנזק העקיף: עזיבות כמו צרות באות בצרורות, לכן עזיבה של עובד אחד, ובעיקר עובד מפתח, יכולה לבשר על גל עזיבות. זיהוי הסממן הראשון יאפשר לנו לצמצם נזקים, ע"י תיקון הסיבות לעזיבה. אם הצוות מרגיש שאין עתיד על רקע סיום פרויקט גדול, זה הזמן לייצר תנופת עשייה כדי לצמצם את זמן החשיבה. אם הצוות מרגיש שחוק, זה הזמן לבקש מההנהלה פיצוי. אם יש פער בתגמול לעובדים, זה הזמן לזהות את הבקיעים ולסגור אותם במקרה הצורך (תוכניות אופציות ובונוס עתידי שינתן מספר חודשים קדימה בהחלט יכול לצור את המנגנון שימנע את התגלגלות כדור השלג).
עזיבת עובדים
אז איך מזהים?
  1. רשתות חברתיות. מנהלים רבים מפחדים להיות בקשר חברתי עם עובדיהם באמצעות רשתות חברתיות באינטרנט. אני מאמין שאין מה לפחד. אתה נחשף, אבל יותר מכל אתה משיג אינפורמציה יקרה מפז (איך להמנע מפדיחות? כמו שלא תסתובב עם תחתונים על הראש באמצע המשרד, אני מציע לכם להמנע מהתנהגות שלא תתאים למנהלים במעמדכם ברשות הציבור, וכן, רשתות חברתיות באינטרנט זה בהחלט ברשות הציבור). כיום אחד המקורות האפקטיביים ביותר לזיהוי עזיבת עובד הוא פרופיל ה - Linkedin שלו. אם העובד ביצע יותר מפעולה אחת מהבאות יש סיכוי טוב שהוא מחפש עבודה (או יותר נכון לפחות התניע את התהליך המחשבתי לכך), או בעברית הוא מרענן את קורות החיים שלו:
    1. הוא שינה את ה - Title שלו לכותרת אטרקטיבית וסקסית שמתאימה יותר לתיאור התפקיד שהוא מחפש מאשר זה שהוא עושה בפועל.
    2. הוא עדכן את כל ההיסטוריה, ובעיקר את התפקיד האחרון.
    3. הוא הצטרף למספר רב של קבוצות. זהירות! אם הוא נרשם לקבוצות של חיפוש עבודה (ויש רבות כאלו) זה כבר צלצול אזעקה.
    4. הוא מצרף חברים חדשים בקצב הגיוס של מחזור אוגוסט.
    5. הוא מבקש ומשיג המלצות בקצב מסחרר.
  2. העובד שטרח לשלוח קו"ח למבצע חבר מביא חבר, פתאום איבד את כל החברים שלו.
  3. העובד מתחיל להגיע לעבודה בשעות מאוחרות יותר/יוצא לארוחות צהריים ארוכות/חייב לצאת מוקדם לסידורים/אישה/ילדים.
  4. שיחות טלפון ארוכות שנעשות תוך ריצה מהירה הרחק מטווח השמיעה או לחילופין ניתוקי טלפון זריזים
  5. מספר שעות העבודה מתחיל לרדת באופן עקבי. מספר שעות העבודה ורמת ההשקעה של העובד מעידים רבות על רמת ההזדהות שלו עם מקום העבודה.
  6. במקום חולצת הטי שירט והקרוקס שאיתם טרח להגיע עד עכשיו למשרד, פתאום הוא מצא את סט הנעליים האיטלקיות והחולצה המחוייטת מהחתונה של האח.
מה אסור לעשות?
  1. הסקת מסקנות פזיזה: יתכן שזיהיתם אחד מהסממנים אבל הוא לבדו לא אומר כלום (לדוגמה הוא ישב עם חבר בסופ"ש שהראה לו את פרופיל הלינדקאין המפואר שלו, מה שגרם לו לעדכן את הפרופיל). פעולה אגרסיבית יכולה לגרום לעובד לבצע דברים שהוא לא ציפה להם.
  2. הפרת פרטיות העובד: אסור לחטט בחשבון הדוא"ל של העובד או בכל דבר שיחשב להפרת הפרטיות. יש חוקים במדינת ישראל (וגם במדינות אחרות) וממש לא כדאי להתעסק איתם.
  3. להכנס להיסטריה: זיהוי מוקדם יכול למנוע את עזיבת העובד. עם זאת עזיבה היא דבר טבעי, ולא חייבים להלחם על כל עובד בכל האמצעים, בעיקר אם הוא דורש דרישות מוגזמות ו/או לא מהווה איום ליצירת כדור שלג. לפעמים עזיבה של עובד היא דווקא יתרון.
השורה התחתונה: זיהיתם? מה עושים?
  1. שיחה ישירה עם העובד כדי להבין את מצבו. אמירות רפות שהכל בסדר בד"כ יעידו על כוונות עזיבה רציניות מאוד ועל כך שהעובד כבר לא רואה את עצמו כחלק מהמערכת. עובד שישים את הקלפים על השולחן ויעיד על שיקוליו, מצביע על כך שהוא עדיין במערכת וש - "העסק" עדיין לא אבוד. וכן, תמיד יש סבירות שלא קרה כלום ויש הסבר פשוט וטריוואלי לחשדות שלכם.
  2. שיחות רקע (מסדרון) עם עמיתים לעבודה על מנת לאשש את החשדות.
  3. צמצום נזק בצורות שידברנו עליהם קודם לכן.
חושבים אחרת? יש לכם סימנים אחרים לעזיבה של עובד? רוצים לשתף בשיטות ההתמודדות שלכם?

נהנית מהפוסט? רישום לבלוג הפתוח למנהל הפיתוח יבטיח לכם עדכונים חדשים ישירות לדוא"ל!
 
ממשיכים לפתח,
 
הטיפים של אדי אהרונוביץ':
פוסט מעניין ומאוד רלוונטי בעידן שלנו. לטעמי עובד עוזב בשל אחת משתי סיבות:
  1. קידום (עניין, מצב כלכלי, מעמד).
  2. חוסר יציבות במקום העבודה הנוכחי.
הסיבה הראשונה תלויה בעיקר במנהלו הישיר ומחלקת כ״א. עזיבת עובד (טוב ככל שיהיה אינה תמיד דבר רע או אסון) ניתן למנוע אם מבינים את צרכיו ו״שוויו לחברה״ דומה להערכתו האישית בדרכים שציינת. הבעיות נוצרות כאשר מחלקת כ״א לא אחראית על טיפוח עובדים או כאשר הממונה הישיר לא רואה מעבר לשורות הקוד וה-project.
המקרה האחר הוא כאשר עובד מרגיש לא בטוח כיון שבכירים רבים עזבו או התחלופה בחברה גבוהה או ש״כולם יודעים״ שיגיע גל פיטורים ובמקרה כזה עלול עובד לחפש מקום אחר כמה שיותר מהר ועד אז יהיה מאוד טרוד. במקרה כזה נראה לי נכון יותר לשתף את העובדים באתגרים ולהסביר להם מה קורה ו״לאן פנינו״. זה לא בהכרח ישנה מגמה אבל יסייע לשיפור התחושה בחברה.
מה שכדאי מאוד לשים לב שגם אם יש עזיבה (ואפילו מסיבית) יש לשמור על כבוד הדדי והבנה שייתכן שבעתיד עוד יצטלבו הדרכים ולא להשאיר ״דם רע״ כי זה לא תורם לאיש. 
הערות והבהרות (משה קפלן):
בנושא הסיבה הראשונה, לפעמים לטובה ולפעמים לא, נוצר "טרנד" היום שבמשרות הראשונת אנשים מדלגים עבודות על שנה שנתיים על מנת לשפר את השכר ואת התפקיד בצורה משמעותית.
מה שמייצר אתגר לא קטן לייצר להם אופק התפתחותי (מקצועי או ניהולי לפי העדפתם)