Posts tagged ‘צוות’

תמיד מאשימים את ה-ש.ג. ובצדק.

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

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

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

כמובן שדוגמת ביה”ס היא לא מושלמת, אבל היא מתאימה.

מידי פעם, מישהו מחליט על שינוי, שינוי תהליך, שינוי בשיטות עבודה, מעבר לסקראם, שינוי לצוותים מנוהלים עצמאית, מעבר ל-TDD, מנסים CI, לנסות Pair programming, וכדומה.
אין לי סטטיסטיקה אבל לפי ניסיוני לפחות בחצי מהמקרים השינוי לא מצליח בטווח הארוך, צוות הסקראם מפסיק לעשות רטרוספקטיבות ודיילי, ראש הצוות בסוף כן אומר לצוות מה ואיך לעשות, כותבים בדיקות אחרי הקוד ולא לפניו, הבילד אדום במשך ימים שלמים ואף שבועות, וכו’.

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

איך שומרים על שינוי, או, איך שומרים עלינו מעצמינו?

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

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

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

עמוד נח.

צוותי פיצ’ר – Feature teams

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

component_teamרוב הארגונים שאני פוגש עדיין עובדים במבנה צוותים שמבוסס על מודול או קומפוננט. המונח המקצועי הוא Component team.
כלומר, במצב שבו יש מספר קומפוננטות במערכת, למשל: GUI, BL, SERVER, INFRA אז כל צוות הוא מומחה בקומפוננט מסוים. קלאסי.

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

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

נתחיל מדף חלק – יום 0 של הפרויקט.
יש לנו רשימת פיצ’רים לגירסה הקרובה, חמישה במספר. הפיצ’רים הללו לא דורשים רמת מאמץ זהה מכל הצוותים, יש פיצ’רים שדורשים יותר עבודה ב-Gui ויש כאלה שיותר עבודה ב- Server וכו’. הנה דוגמא: הטבלה מציגה עבור כל פיצ’ר את התפלגות המאמץ באחוזים לפי מודול.

מספר פיצ’ר A B C D
1 20 30 50 0
2 40 20 0 40
3 0 80 20 0
4 50 0 50 0
5 20 0 70 10

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

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

מה האפשרות שרוב הארגונים לא שוקלים (אולי כי הם לא מכירים אותה) לשנות את המבנה של הצוותים כך שלא יהיה מאורגן לפי מודולים אלא לפי איזורים פונקציונאליים, או כפי שקוראים למבנה הזה בשפה המקצועית: צוותי פיצ’ר -  Feature teams.

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

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

באופן אישי אני לא מצליח להבין ארגונים שלא רוצים לעבוד למבנה כזה, אבל, זה לא הדבר היחיד שאני לא מבין… :)

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

שיטת הקבנוס

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

פיתוח תשתיות תוכנה – INFRA
פיתוח Backend
פיתוח Business logic
פיתוח Frontend
פיתוח UI
בדיקות.

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

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

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

kabanosדוגמא להמחשה:
אם יש לי דרישה לניהול מאגר לקוחות, ניתן
לחלק אותה למשל ל-3 דרישות קטנות יותר: 
1. הוספת לקוח 
2. עדכון פרטי לקוח
3. מחיקת לקוח.

ברור שקשה מאוד לבצע את השינוי הזה מבלי לשנות במידה מסוימת מבנה ארגוני,רצוי מעבר ל-Feature teams או לפחות שינוי בתפיסת עבודה.
בשביל שצוות יהיה מסוגל לספק פיצ’ר E2E יש לדאוג ולעזור לו לפתח ידע E2E, דבר שדורש שינוי פרסונלי במבנה הצוותים או מתן זמן חסד כדי להשלים את עקומת הלימוד, אבל היתרונות של שיטה זו שווים די הרבה, למשל:
– צמצום עד כדי ביטול של צווארי בקבוק.
– מעורבות גבוהה יותר של הצוותים בפן העסקי של המוצר.
– שקיפות גבוהה יותר לגבי התקדמות מצב הפרויקט.
– הקטנת כמות העברת הידע בין הגורמים ובכך יצירת פחות “אי הבנות”.
– פחות משימות שלא מושלמות בספרינט אחד.
– יכולת טובה יותר לתעדף את הפיצ’רים ובכך באופן פוטנציאלי להגדיל ROI.
– ועוד הרבה.

טוב, חסרים שני חלקים לפאזל הזה:
1. הסבר מקיף יותר על Feature teams.
2. הצד המעשי של איך מחלקים פיצ’ר.

בפוסטים הבאים….

את מי כן הייתי מעסיק ?

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

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

היא מגיעה לראיון עבודה, אמנם – יש לה ניסיון חיים מרשים, אבל כבר מההתחלה יש לה ביקורת, היא שואלת שאלות מתחכמות כגון “מה?! אין לכם בדיקות אוטומטיות? מה אתם בעידן האבן?”, משדרת ציניות ואולי אפילו התנשאות “נראה לי שאתם ממש צריכים מישהי כמוני כדי להציל את הספינה הטובעת שלכם”.
אם קרה ועדיין לא נמאס לכם ממנה והחלטתם לתת לה צ’אנס נוסף ולהתקשר לממליצים, יש סיכוי שתשמעו דברים כמו: “היא ממש טובה טכנית, אבל מבחינה אישית היא קצת קשה” או “על כל דבר יש לה דעה – זה יכול ממש לערער את המצב רוח של כולם”. בקיצר – לא נראת מציאה גדולה הגברת.

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

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

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

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

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

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

אני לא הייתי מעסיק את סופרמן

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

מכירים אותו ?

אני די משוכנע שאתם מכירים אותו.

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

imageאני לא הייתי מעסיק אותו.

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

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

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

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

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

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

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

מנהיגים מנצחים

תודה לאילן קירש על ההשראה והלינק

עוד סרטון מבית היוצר של דן פינק… גדול

תמריצים ובונוסים בצוותי סקראם.

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

בדיון עלו מספר טענות בעד ונגד:

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

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

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

clip_image002

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

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

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

תמריצים מגבירים מוטיבציה? כנראה שלא…

ישיבות או לא להיות

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

clip_image002באופן קלאסי ישיבה מתחלקת לשלושה חלקים:

– הכנת השטח.
– איסוף נתונים
– עיבוד הנתונים.

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

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

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

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