מדי פעם עולה השאלה הבאה (בצורה זו או אחרת) באחת הקבוצות שקיימות סביב אג'ייל: "עברנו לאחרונה לאג'יל ואנחנו מתקרבים לתקופת הערכות העובדים וקביעת היעדים לשנה הבאה. איך עושים את זה באג'יל?" (אני כורך את שניהם יחדיו כיון שבד"כ הערכת העובדים מתבצעת ברובה על סמך היעדים שהוגדרו בשנה הקודמת).
רוב התגובות אומרות משהו בסגנון של "באג'יל אין הערכות עובדים", "אתם לא צריכים הערכות עובדים, תשנו את השיטה", "הערכות עובדים זה גרוע, יש שיטות הרבה יותר טובות ליצירת מוטיבציה".
עכשיו, יכול להיות שהם צודקים. ויכול להיות שזה גם עובד להם. הבעיה היא שבחברות גדולות (כמו בחברה שבה אני עובד ), אתה לא ממש יכול ללכת נגד התהליך. אתה יכול לנסות להסביר את ההגיון ואולי אפילו לשכנע כמה אנשים בכירים אבל בסופו של דבר תצטרך לבצע תהליך הערכות עובדים וקביעת יעדים.
כשזה קרה לי, עמדו בפני שתי ברירות:
האפשרות הראשונה, לבצע הערכת עובדים וקביעת יעדים כמו בעבר. מה שאומר שבדף היעדים יופיעו משפטים כגון "מהנדס X אמור לפתח תוכנה Y עד לתאריך Z" או "מהנדס X אמור לתמוך בפרוייקט W ולהביא אותו לייצור עם K באגים". מה שיקרה בעקבות כך הוא שבשנה הבאה בעת הערכות העובד אנו נעבור על הדף ונגלה שתוכנה Y בכלל נדחתה לשנה הבאה, ושהתוכן שלה השתנה ב 180 מעלות לעומת הדרישה המקורית או שפרוייקט W בכלל בוטל והוחלף בפרוייקט אחר. או ששום דבר לא השתנה אבל כחלק מהתהליך האג'ילי מהנדס אחר בכלל עבד בפועל על המשימה.
האפשרות השניה, לחשוב על יעדים מסוג חדש. יעדים שייתמכו בתהליך האג'ילי. כאלו שלא יישתנו או יישברו עם כל שינוי בפרוייקט זה או אחר.
אתם מנחשים באיזו אפשרות בחרתי?
אני מודה שזה לא היה פשוט. לשנות סגנון חשיבה בהקשר הזה בהחלט הצריך ניעור של התאים האפורים אבל בסופו של תהליך הגעתי למספר יעדים שאותם הצבתי לאנשים:
1. תרומה אקטיבית להליך השיפור המתמיד - ממהנדס שהוצבה לו מטרה כזו אני מצפה שלא רק יגיב לבעיות אלא שייבצע פעולות פרואקטיביות לשיפור התהליכים בצוות. לדוגמא לקחת אחריות על נושא בעייתי מסויים ולפעול לפתירתו. זה יכול להיות ע"י פיתוח כלי, הקמת קבוצת עבודה, וכו..
2. תרומה לשיפור העבודה השיתופית בצוות - כאן אני מצפה מהמהנדס לפעול לשיפור זרימת המידע בקבוצה (הדרכות, תחזוקת Wiki, שיתוף אנשים בין משימות ועוד...
3. שיפור הנגישות האישי - אני מניח שכולכם מכירים את מהנדס מהסוג שמפחדים לפנות אליו. ואם כבר פונים אז זה "בדחילו ורחימו". מהנדס כזה אני מצפה שישפר את הנגישות אליו. הוא יכול ליזום פניה ולהציע את עזרתו לאחרים, הוא יכול להתנדב לעשות code review ועוד... כל מה שבסופו של דבר יוריד את מפלס החרדה או הייראה של הסובבים אותו ויאפשר לדבר איתו בגובה העיניים. (ואל תגידו שצריך לפטר מישהו כזה. ברוב המקרים הוא הכוכב של הצוות וחבל לאבד אותו)
4. תרומה לאווירה הכיפית בצוות - אמנם בסופו של דבר אנחנו באים לעבוד אבל צריך גם שיהיה כיף. יש אנשים שנולדו לארגן, ולתרום לאווירה בצוות ואין סיבה שהם לא יתוגמלו על כך. זה יכול להתבטא בארגון "יום צוות", או אפילו ארוחת צהריים שבה כולם אוכלים ביחד (ומסתבר שזה לא טריוויאלי כמו שזה נשמע)
יעדים מסורתיים שהם אישיים לחלוטין, כגון למידת נושא חדש, פיתוח מיומנות כלשהי או שיפור נקודות בעייתיות עדיין יכולים וצריכים להישאר.
אם המדיניות הארגונית מרשה, אפשר גם להוסיף יעד צוותי. יעד זהה שיופיע לכל אנשי הצוות ובסופו יינתן לכל אחד ואחת ציון זהה על סמך העמידה המשותפת בו. יש להיזהר בקביעת יעד כזה לצוות שעדיין אינו מגובש, כיון שאז אי עמידה בו יכולה להסתיים במרמור והטלת האשמות בין חברי הצוות.
בנוסף יעדים מסורתיים שהם אישיים לחלוטין, כגון למידת נושא חדש, או פיתוח מיומנות כלשהי עדיין יכולים להישארץ
אצלי זה עבד. לאחר שנה לא פשוטה שבה פרוייקטים קמו והתבטלו, לוחות זמנים ותכולה שהשתנו על בסיס שבועי, הגעתי לתהליך הערכות העובדים והמטרות שהצבתי היו שם. עדיין תקפות, עדיין רלוונטיות ועדיין מאפשרות הערכה אמיתית וכנה על הביצועים של השנה האחרונה.
יש לכם שיטה אחרת? רעיונות לעוד יעדים אג'יליים? אשמח לשמוע.
רוב התגובות אומרות משהו בסגנון של "באג'יל אין הערכות עובדים", "אתם לא צריכים הערכות עובדים, תשנו את השיטה", "הערכות עובדים זה גרוע, יש שיטות הרבה יותר טובות ליצירת מוטיבציה".
עכשיו, יכול להיות שהם צודקים. ויכול להיות שזה גם עובד להם. הבעיה היא שבחברות גדולות (כמו בחברה שבה אני עובד ), אתה לא ממש יכול ללכת נגד התהליך. אתה יכול לנסות להסביר את ההגיון ואולי אפילו לשכנע כמה אנשים בכירים אבל בסופו של דבר תצטרך לבצע תהליך הערכות עובדים וקביעת יעדים.
כשזה קרה לי, עמדו בפני שתי ברירות:
האפשרות הראשונה, לבצע הערכת עובדים וקביעת יעדים כמו בעבר. מה שאומר שבדף היעדים יופיעו משפטים כגון "מהנדס X אמור לפתח תוכנה Y עד לתאריך Z" או "מהנדס X אמור לתמוך בפרוייקט W ולהביא אותו לייצור עם K באגים". מה שיקרה בעקבות כך הוא שבשנה הבאה בעת הערכות העובד אנו נעבור על הדף ונגלה שתוכנה Y בכלל נדחתה לשנה הבאה, ושהתוכן שלה השתנה ב 180 מעלות לעומת הדרישה המקורית או שפרוייקט W בכלל בוטל והוחלף בפרוייקט אחר. או ששום דבר לא השתנה אבל כחלק מהתהליך האג'ילי מהנדס אחר בכלל עבד בפועל על המשימה.
האפשרות השניה, לחשוב על יעדים מסוג חדש. יעדים שייתמכו בתהליך האג'ילי. כאלו שלא יישתנו או יישברו עם כל שינוי בפרוייקט זה או אחר.
אתם מנחשים באיזו אפשרות בחרתי?
אני מודה שזה לא היה פשוט. לשנות סגנון חשיבה בהקשר הזה בהחלט הצריך ניעור של התאים האפורים אבל בסופו של תהליך הגעתי למספר יעדים שאותם הצבתי לאנשים:
1. תרומה אקטיבית להליך השיפור המתמיד - ממהנדס שהוצבה לו מטרה כזו אני מצפה שלא רק יגיב לבעיות אלא שייבצע פעולות פרואקטיביות לשיפור התהליכים בצוות. לדוגמא לקחת אחריות על נושא בעייתי מסויים ולפעול לפתירתו. זה יכול להיות ע"י פיתוח כלי, הקמת קבוצת עבודה, וכו..
2. תרומה לשיפור העבודה השיתופית בצוות - כאן אני מצפה מהמהנדס לפעול לשיפור זרימת המידע בקבוצה (הדרכות, תחזוקת Wiki, שיתוף אנשים בין משימות ועוד...
3. שיפור הנגישות האישי - אני מניח שכולכם מכירים את מהנדס מהסוג שמפחדים לפנות אליו. ואם כבר פונים אז זה "בדחילו ורחימו". מהנדס כזה אני מצפה שישפר את הנגישות אליו. הוא יכול ליזום פניה ולהציע את עזרתו לאחרים, הוא יכול להתנדב לעשות code review ועוד... כל מה שבסופו של דבר יוריד את מפלס החרדה או הייראה של הסובבים אותו ויאפשר לדבר איתו בגובה העיניים. (ואל תגידו שצריך לפטר מישהו כזה. ברוב המקרים הוא הכוכב של הצוות וחבל לאבד אותו)
4. תרומה לאווירה הכיפית בצוות - אמנם בסופו של דבר אנחנו באים לעבוד אבל צריך גם שיהיה כיף. יש אנשים שנולדו לארגן, ולתרום לאווירה בצוות ואין סיבה שהם לא יתוגמלו על כך. זה יכול להתבטא בארגון "יום צוות", או אפילו ארוחת צהריים שבה כולם אוכלים ביחד (ומסתבר שזה לא טריוויאלי כמו שזה נשמע)
יעדים מסורתיים שהם אישיים לחלוטין, כגון למידת נושא חדש, פיתוח מיומנות כלשהי או שיפור נקודות בעייתיות עדיין יכולים וצריכים להישאר.
אם המדיניות הארגונית מרשה, אפשר גם להוסיף יעד צוותי. יעד זהה שיופיע לכל אנשי הצוות ובסופו יינתן לכל אחד ואחת ציון זהה על סמך העמידה המשותפת בו. יש להיזהר בקביעת יעד כזה לצוות שעדיין אינו מגובש, כיון שאז אי עמידה בו יכולה להסתיים במרמור והטלת האשמות בין חברי הצוות.
בנוסף יעדים מסורתיים שהם אישיים לחלוטין, כגון למידת נושא חדש, או פיתוח מיומנות כלשהי עדיין יכולים להישארץ
אצלי זה עבד. לאחר שנה לא פשוטה שבה פרוייקטים קמו והתבטלו, לוחות זמנים ותכולה שהשתנו על בסיס שבועי, הגעתי לתהליך הערכות העובדים והמטרות שהצבתי היו שם. עדיין תקפות, עדיין רלוונטיות ועדיין מאפשרות הערכה אמיתית וכנה על הביצועים של השנה האחרונה.
יש לכם שיטה אחרת? רעיונות לעוד יעדים אג'יליים? אשמח לשמוע.
עמית, אהבתי מאוד את התובנה שלך לגבי קביעת יעדים. באופן כללי, בלי שום קשר לאג'ייל, אני מעדיף (בתור עובד, עדיין לא מנהל) יעדים שיקדמו הן את הארגון והן את העובד. יעדים כמו "לסיים את פרוייקט X" אלו יעדים ברורים מאליהם לטעמי, בשביל זה לקחו את העובד. אני הרבה יותר מעדיף לקבוע יחד עם המנהל שלי יעדים שגם יתרמו לארגון וגם יתרמו לי אישית.
השבמחקהייתי כן מתמקד ביעדים קצת יותר ספציפיים ברוח השיטה האג'יילית.
לדוגמא:
1. מתכנת מתחיל יחסית שרוצה להתקדם יכול לקבל לדוגמא משימה - לעשות לפחות code-review אחד בשבוע. זה יגרום לו לעשות משהו שהרבה מתחילים מפחדים (רוב הסיכויים שאחרי שהוא יתחיל הוא גם יעשה יותר מאחד בשבוע). זו משימה שגם מפתחת את העובד וגם תורמת לארגון.
2. מתכנת ששואף להתקדם להיות ארכיטקט (או מוביל טכנולוגי או כל שם אחר) - לתת לו יעד של להביא הצעה/יוזמה טכנולוגית לשיפור תהליכים (לדוגמא - מעבר לטכנולוגיה חדשה שתקל על העבודה, לדוגמא - לכתוב סקריפטים שיקלו על מהירות הפיתוח וכו' וכו'). שוב - התרומה פה היא גם לעובד וגם לארגון.
3. בנאדם שרוצה יותר להתבלט בארגון יכול באמת לארגן אירועים כפי שציינת (אם הקטע החברתי זה הקטע שלו). או אולי להפגש עם לקוחות ולייצג את הארגון, או לייחצ"ן את העבודה של הצוות החוצה (נגיד במייל סיכום שבועי, או בלוג צוותי, או רשת חברתית פנימית אם יש וכו').
4. מישהו שרוצה לקבע לעצמו מעמד כמומחה טכנולוגי בתחום מסוים (סתם דוגמא - מומחה security או מומחה UI וכו') - יכול לתת הרצאות בנושא, יכול לארגן האקאת'ונים בנושא, לעזור לאנשים שצריכים עזרה בנושא.
יש עוד מיליון דוגמאות לדברים שאפשר לעשות. היופי זה שאלו דברים שמרימים גם את האינדיבידואל וגם את הארגון, הם פחות רגישים לשינויים של פרוייקטים או מבני-צוותים ואולי הכי חשוב *הם לא ברורים מאליהם*. זה אומר שהעובד צריך לשאוף אליהם יותר בשביל עצמו ופחות בשביל הארגון, על מנת לקדם את הקריירה שלו. אין מוטיבציה כמו הרצון להגשים מטרה של עצמך (זה לרוב הרבה יותר משמעותי מלהגשים מטרה של הבוס שלך).
אין לי אלא להסכים :) תודה על התגובה
השבמחקמעניין אגב - מי אמור לבצע הערכות בעולם הסקראם? - האם הסקראם מאסטר? מנהל הקבוצה אם נדרש כזה עדיין? החברים ל-cycle?
השבמחקשאלה טובה. אני חושב שזה תלוי במבנה הצוות. אם יש עדיין ראש צוות אז זה באחריותו. אני יודע שבחברות שאין ראש צוות אלא רק ראש קבוצה אז ראש הקבוצה מבצע את ההערכות תוך התייעצות עם הסקראם מאסטר והמובילים הטכניים.
השבמחק