Brainstorming Sessions

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

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

Being a great manager - is good for your boss

Being a brilliant mentor - is best for your team

יאללה מספיק סיסמאות, בואו ניגש לעבודה!

לוחות זמנים, תעדופים, גאנט, ישיבות, והיכולת שלי לדחוף קדימה - הכל טוב ויפה, אבל עצרו שניה ותחשבו מה לעזאזל עשיתם בשביל הצוות שלכם לאחרונה? איך נראה השבוע/החודש/3 חודשים/חצי שנה ראשונה של איש צוות חדש? מהיא הדינמיקה בצוות? האם חולקים ידע? האם יש לכם איש מפתח בלעדיו אתם אבודים? האם אנשים מתקשרים זה עם זה מלבד לחלוק חוויות סוף שבוע? האם הם עושים code review אחד לשני? האם אני כמנהל פיתוח עשיתי להם? האם היו ניצולים תוך כדי החוויה? :-)

Brainstorming Sessions

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

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

הרעיון הוא פשוט אז מה בעצם קיבלנו?

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

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

מה שמשאיר לי הרבה יותר זמן לגלוש באתרי נופש ולדמיין את החופשה הבאה... 

בהצלחה!

כלים לבניה נכונה של צוות הפיתוח - שלב הגיוס

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

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

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

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

תיאור משרה

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

ראיונות - טיפים קטנים וחשובים

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

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

ראיון אישיותי ופרקטי

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

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

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

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

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

תאום ציפיות

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

חשוב לזכור: Not hiring is better than bad hiring

השבוע הראשון

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

החודש הראשון

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

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

לאחר 3 חודשים

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

ותובנה אחרונה

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

בהצלחה !

מוטיביה - בעצם למה לי לשפר יכולות ניהול הפיתוח?

איך נראית השגרה היומיומית שלנו?

כמפתחים/בודקים

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

כמפתחים בכירים/ארכיטקטים

• מתעוררים לגלות שאנחנו חיים באותה הבועה הטכנולוגית החד גונית כבר שנים
• ודי נוח לנו שם, בבועה, אין צורך מיידי בחידושים, בלמידה, באתגרים: if it ain't broke... don't fix it 
• תוך כדי פיהוק פתאום שמים לב שהמפתחים הצעירים נושאים אלינו עיניים 24/7
• הפכנו מדולפינים זריזים וחיוניים לליוותני מידע גדולים ומסורבלים, חוששים מהיום בו נאלץ לצאת מהבועה

כראשי צוותים

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

התוצאה לא מאחרת להגיע...

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

אנחנו לא מבינים איך זה קרה? אנחנו מנהלים טובים כל כך (נכון, אבל מנהלים של מה?)

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

אך חוששים להרים בעצמנו את מכסה המנוע של הצוות שלנו (מי יודע מה נמצא תחתיו?)

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

כאשר עמוק בפנים, שמים לב שעם הזמן זה רק הולך ונהיה קשה יותר (we become - comfortably numb)

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

רק כדי לגלות שיכולנו להגיע לכל התובנות בכוחות עצמנו

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

איך אני מפסיק לנהל משימות, ומתחיל לנהל אנשים?