הסכמות עבודה צוותיות.

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

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

clip_image002

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

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

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

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

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

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

לסיום אני רוצה לתת מספר דוגמאות להסכמות “נכונות” ו-“לא נכונות” לדעתי:
נכונות
– לכתוב תיעוד מעל כל פונקציה שאורכה עולה על 5 שורות.
– לכתוב תיעוד מעל כל מחלקה.
– לכל פונקציה public יש לכתוב לפחות שתי unit tests – הצלחה וכישלון.
– כל אחד מבצע לפחות יום אחד בשבוע pair programming.

לא נכונות
– לתעד את הקוד יותר.
– לכתוב יותר בדיקות.
– להגביר שיתוף ידע בין אנשים.

Comments are closed.