Posts tagged ‘עבודת צוות’

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

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

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

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

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

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

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

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

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

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

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

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

מכירים אותו ?

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

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

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

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

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

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

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

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

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

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

חבל על הזמן…

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

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

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

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

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

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

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

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

נ.ב.
אחרי שקראתי את הפוסט הבנתי שעקב ריבוי הדמויות והמידע (יחסית לרמת הפירוט) אפשר לפרש את הישיבה בכל מיני צורות וצבעים, כוונתי היתה הפשט, בבקשה אל תניחו הנחות אלא התבססו על העובדות.
ואולי אכתוב עוד אחד כזה על ישיבת R&D…. אולי.

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

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

לשבור את הקיר

clip_image002[4]

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

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

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

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

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

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

איך שואלים “למה”?

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

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

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

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

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

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

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

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

במקום לשאול: “למה בחרת בדיזיין הזה?”
אפשר לשאול: “מה היו השיקולים לבחור דוקא בדיזיין הזה”
אפשר לשאול: “מה היתרונות של אלטרטיבה א’ מול אלטרנטיבה ב’?”

במקום לשאול: “למה לא הספקת לסיים את המשימה?”
אפשר לשאול: “אילו דברים הפריעו לך לסיים את המשימה?”
וכדומה…

אז הנה לכם כלי פשוט וקל שיכול לעשות שינוי משמעותי.

מוכנים להשתתף בניסוי ?

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

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

1. לדעתך, מהם המאפיינים הטיפוסיים לתרבות הלאומית שלך ? (במילים אחרות: בהשוואה לאחרים התרבות שלי היא…..)

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

3. איזה יתרונות יש לתרבות שלך בהקשר לאג’ילסקראם ובמיוחד לצוותים מנוהלים עצמאית. (במילים אחרות: בתרבות שלי אנחנו…. וזה מהווה יתרון לעבודה מוצלחת בסקראם)

4. איזה חסרונות יש לתרבות שלך בהקשר לאג’ילסקראם ובמיוחד לצוותים מנוהלים עצמאית. (במילים אחרות: בתרבות שלי אנחנו…. וזה מהווה קושי לעבודה מוצלחת בסקראם)

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

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

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

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

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

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

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

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

איך זה מרגיש ?

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

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

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

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

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

אז איך זה מרגיש לעבוד בסקראם ?

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

אז אני יודע שזה מתיימר מאוד, אבל לפי ניסיוני המעשי, ככה זה מרגיש.

שיטה עם ערכים

לא הרבה אנשים מכירים את העובדה שכמו ל”מניפסט האג’ילי” גם לסקראם (Scrum) יש 5 ערכים, הערכים האלו מוזכרים בספר הראשון שנכתב על המתודולוגיה שנקרא “Agile software development with Scrum”, הספר נכתב ע”י מייק בידל וקן שוובר (Mike Beedle & Ken Schwaber) ובו מצאו לנכון הכותבים להקדיש מקום לערכים הבסיסיים שעליהם מבוססת השיטה.

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

clip_image002[4]

כעת אציג בפניכם את חמשת הערכים:

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

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

Openness – פתיחות: כפי שכבר ציינתי בעבר, אחד המאפיינים הבולטים של סקראם הוא השקיפות, סקראם דואג שכל הנתונים שידועים על הפרויקט יהיו נגישים לכולם, הבסיס בתהליך אמפירי שבבסיסו
“בחינה והתאמה” (Inspect & Adapt) בנוי על כך שכל הנתונים, החסרונות והיתרונות, ידועים לכל. הפתיחות דורשת מכל אחד מהאנשים שהוא חלק מהפרויקט לומר תמיד את האמת, גם היא לא נעימה וע”י כך להיות מסוגלים לבצע התאמות למציאות ולא להחביא את המציאות מאחורי ערימה של מסמכים ותוכניות, לכן בסקראם כל הישיבות (מלבד הרטרוספקטיבה) פתוחות לכולם (לצפייה), לכן בסקראם נהוג שה-“Sprint backlog” וה-“Sprint burndown chart” נמצאים על הקיר במקום גלוי. בסקראם לא אמור להיות שום מידע שמוסתר בכוונה תחילה מכל שיקול שהוא.

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

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

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