Posts in עבודת צוות

זה לא עבודת צוות כש…

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

Team Spirit starring Superman

זה לא עבודת צוות כשמרגישים שזה לא עבודת צוות.

למה? מי? איך? מה? ניתוח דרישות ״אפקטיבי״

המוצר שלנו יכול להיות מורכב ממיליון פיצ׳רים שמפותחים מעולה, בזמן קצר ואפילו ללא באגים אבל כל זה לא שווה גרוש אם אף אחד לא משתמש בפיצ׳רים הללו, הסטטיסטיקה מראה שרק כ-35% מהפיצ׳רים שאנחנו כותבים נמצאים בשימוש משמעותי ותורם ערך ללקוחות שלנו. בתור ארגון שמנסה לתת מקסימום ערך ללקוחות שלו האחריות שלנו היא לא לקבל כל דרישה כמובן מאליו, אותו דבר נכון גם לצוות פיתוח שמקבל דרישות מאנשי השיווק או המכירות, האם מה שאתם מבקשים באמת יעזור לנו להגשים את החזון העסקי של המוצר/החברה/הלקוח.
בסדנא של גויקו אדזיק שהשתתפתי בה אחד הנושאים שהוא נתן כ״בונוס״ זה Effect mapping. 
זו שיטה לניתוח דרישות שמנסה לעזור לענות לשאלה האם אנחנו מפתחים את הדבר הנכון? או במילים אחרות האם ההנחות העסקיות שלנו עומדות במבחן המציאות.

איך עושים את זה?

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

השאלה הבאה היא מי יכול לעזור לי להשיג את המטרה הזאת, למשל במקרה הנ״ל גולשים מזדמנים, פרסומאים, גולשים קבועים וכו׳

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

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

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

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

תחילה נשאל מי הם ה״שחקנים״ שיכולים לעזור להגיע ליעד העסקי הזה:
1. לקוחות שכבר קונים בחנות – לקוחות קיימים.
2. מנהל החנות 
3. אנשים שמתדלקים בתחנת הדלק
4. אנשים שעוברים באיזור התחנה.
5. אנשים שגרים באיזור התחנה.

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

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

effectmapexample

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

לסיכום

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

יש לנו הרבה מה ללמוד מפקידות קבלה

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

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

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

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

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

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

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

מעניין למה?

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

הגודל כן קובע

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

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

 

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

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

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

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

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

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

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

שיטת הקבנוס

כמעט ברור וטריוויאלי שהדרישות שאנו מקבלים לפיתוח הן גדולות מידי בשביל לתכנן ולהוציא לפועל ב”חתיכה אחת”. לכן רוב הארגונים מחלקים את הדרישות ליחידות ביצוע קטנות יותר.
אז 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אני לא הייתי מעסיק אותו.

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

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

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

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

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

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

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

חבל על הזמן…

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

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

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

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

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

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

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

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

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

לשבור את הקיר

clip_image002[4]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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