ניהול צוות מתכנתים: איך ואיך להניע אותם נכון? חלק שני

אֶפִּיגְרָף:
הבעל, מביט בילדים המלוכלכים, אומר לאשתו: נו, האם נשטוף את אלה או שנולד ילדים חדשים?

מתחת לגזרה נמצא החלק השני של מאמר של ראש הצוות שלנו, כמו גם מנהל פיתוח המוצר של RAS איגור מרנת, על המוזרויות של הנעת מתכנתים. את החלק הראשון של המאמר ניתן למצוא כאן - habr.com/ru/company/parallels/blog/452598

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

ג - צורך בשייכות ובאהבה

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

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

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

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

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

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

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

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

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

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

IV. צורך בהכרה

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

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

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

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

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

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

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

V. הצורך בהכרה ובמימוש עצמי.

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

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

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

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

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

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

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

הראשון הוא הנראות והקרבה של התוצאה.

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

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

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

הנקודה השנייה היא משחקיות ותחרות.

בעת פיתוח אחד המוצרים, לצוות ההנדסה שלנו הייתה מטרה לתפוס עמדה בולטת בקהילה של אחד ממוצרי הקוד הפתוח, כדי להיכנס ל-3 המובילים. באותה תקופה, לא הייתה דרך אובייקטיבית להעריך את הנראות של מישהו בקהילה; כל אחת מהחברות הגדולות המשתתפות יכלה לטעון (וטענו מעת לעת) שהיא התורם מספר אחת, אבל לא הייתה דרך אמיתית להשוות את התרומה של המשתתפים בינם לבין עצמם, כדי להעריך את הדינמיקה שלו בזמן. בהתאם, לא הייתה דרך להגדיר לצוות יעד שניתן למדוד בחלק מהתוכים, להעריך את מידת ההישג שלו וכו'. כדי לפתור בעיה זו, הצוות שלנו פיתח כלי למדידה והצגה של התרומה של חברות ותורמים בודדים www.stackalytics.com. מנקודת מבט מוטיבציונית, התברר שזו רק פצצה. לא רק מהנדסים וצוותים עקבו כל הזמן אחר ההתקדמות שלהם ושל התקדמות עמיתיהם ומתחריהם. ההנהלה הבכירה של החברה שלנו וכל המתחרים הגדולים התחילו גם הם את יומם עם Stacklytics. הכל נעשה מאוד שקוף וויזואלי, כולם יכלו לעקוב בקפידה אחר ההתקדמות שלו, להשוות עם עמיתים וכו'. זה הפך נוח וקל למהנדסים, מנהלים וצוותים להגדיר יעדים.

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

ולבסוף, הנקודה השלישית - בלי שטויות.

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

מקור: www.habr.com