מוטיבציה להתפתח

בסאמה

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

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

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

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

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

vinney

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

lifeAndStuff

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

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

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

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

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

vinney

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

user32

Well-known member
מנהל
אכן מצב נפוץ
בדיוק במקרים שתיארת. יש אנשים שיתקשו לקבל את המצב ולא תמיד אפשר לתקן את זה. זה נגמר הרבה פעמים בעזיבה עד כמה שזה מצער.

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

בסאמה

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

vinney

Well-known member
זה נשמע שיוסי בדרך החוצה
אני מציע שתתחיל לעבוד על תוכנית חפיפה מסודרת.
 

Miki Watts

New member
מה שיוסי אומר לך זה בדיוק ההפך ממה שאמור להיות
אתם הולכים להיתקל מהר מאד במחסום שקצב הפיתוח הפיצרים ילך וירד וכמות הבאגים תלך ותעלה ככל שתמשיכו להוסיף עוד ועוד קוד בלגניסטי ללא עיצוב נכון וטוב, עד לרמה של הפסקת פיתוח לגמרי. בדרך כלל אם תתנו לזה להימשך תמצאו את עצמכם במצב שעוד שנה בערך תצטרכו לשכתב את כל הקוד מחדש כי כל שינוי קטן בקוד במקום שעה יקח שבוע.
&nbsp
זה משהו שחשוב להבין שגם כאשר יש לחץ של פיתוח פיצרים, ו*תמיד* יהיה לחץ כזה, חשוב ביותר להקפיד על דיזיין טוב ותמיד יש לכלול את זמן הדיזיין בתוך הזמן שנותנים להערכת הזמן לפיצר כולו. (ואני לא מדבר בכלל על כל הנושא של unit tests עדיין).
&nbsp
יש סיפורים מפה ועד הודעה חדשה על אנשים מהסוג של יוסי שמצליחים לתפוס לעצמם עמדה בחברה כי ההנהלה לא מבינה כלום בקוד ובמשך שנים משתלטים על הקוד הלכה למעשה כך שהם היחידים שמסוגלים לעשות משהו עם זה ומוציאים את עצמם בתור הגיבורים שפותרים באגים אחרי ששאר המתכנתים מסתבכים עם זה במשך חודש (לא בגלל הקושי של הבאג, אלא בגלל הבלגן בקוד).
אותם אנשים יעשו הכל כדי לא לאבד עמדה כזאת בחברה וברוב המקרים זה מסתיים במצב שאו הם או דני עוזבים את מקום העבודה, נדיר שיקרה מצב שהם יתאימו את עצמם.
 

בסאמה

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

אתה מראה לו משהו בעייתי בקוד, והוא מסרב לתקן?

אתה אומר שצריך לעשות דיזיין לפני פיתוח והוא מסרב?
 

Miki Watts

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

amir_aikido

New member
כהנהלה, מה סדר העדיפויות שניכר מהקצאת המשאבים?
שאלה קשה:
&nbsp
אם נשאל את הצוות שלך, על בסיס הקצאות הזמן והמטלות, מה סדר העדיפויות שהם יגידו
שיש להנהלה?
&nbsp
דוגמאות לשאלות שההנהלה צריכה לשאול את עצמה:
* האם תעכב כניסה של פיצ'ר למוצר רק כי הוא כתוב לא נקי? או שתכניס אותו ותבקש מהמתכנת לנקות אותו במקביל לעבודה על הפיצ'ר הבא ?
אם השני קורה, הרי שיוסי צודק !
* האם תכנת יקבל בונוס/הערכה דומה על "עבודת ניקיון" כמו על עבודה בהיקף דומה על פיצ'ר חדש?
אם לא, יוסי שוב צודק !
* ...
&nbsp
&nbsp
ביחס למוטיבציה עבור יוסי, הרי שזו רלבנטית רק אם אתם באמת מאמינים בניקוי, וזה מתבטא גם בהקצאות המשאבים של ההנהלה. ואז, אולי כדאי להציץ בנהלים המקובלים במקומות גדולים, וכך לעודד אותו להבין שבעצם אתם דורשים ממנו להשביח את ערכו כתוכניתן, כך שילמד לעבוד כמו במקומות גדולים יותר.
&nbsp
&nbsp

אמיר
 

user32

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

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

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

amir_aikido

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

amir_aikido

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