Posts in Lean – פיתוח תוכנה רזה

יום הכישלון הלאומי של פינלנד

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

נתחיל בשורה התחתונה:
במקום שבו אין מקום לכישלון אין יצירתיות.

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

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

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

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

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

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

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

מה אם המנהל לא מאפשר כישלון? אני מציע שתשלחו לו קישור לבלוג שלי ASAP… :)

תיכשלו! תיכשלו מהר. תיכשלו הרבה. תיכשלו לעיתים קרובות.

לסיום פנינה מאת תומס אדיסון:
I have not failed.  I’ve just found 10,000 ways that won’t work. 
~Thomas Edison~

מטריקות בע”מ

לפני כשבוע השתתפתי בקורס של יורגן אפלו בנושא ניהול ומנהלים בסביבה אג’ילית. שם הקורס הוא זהה לשם הספר שהוא כתב Management 3.0.

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

 photo

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

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

הוא כנראה צודק, אבל זה נושא אחר, בנושא הבטחתי לדבר על מטריקות, אז איפה הערך ללקוח איפה ? 😉

במסגרת הנושא יורגן הציג טבלה ובה שבע עמודות שמייצגות את הישויות שהארגון מייצר משהו עבורן, וכמו כן 7 פרספקטיבות של המשהו הזה, דברים כגון: זמן, כלים, ערך פונקציונליות ועוד, יורגן ביקש שנמצא KPI’s שונים בשביל למדוד את הדברים הללו.
לדוגמא: מדד לשימוש בכלים מהפרספקטיבה של האינדיבידואל יכול להיות “WTH(What the hell) Per minute” – למי שלא מבין, למדוד כמה פעמים בדקה אומר “מה לעזעזל?” מי שמשתמש בכלי מסוים.

photo

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

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

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

You get what you measure

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

בבקשה, לטובתכם, תשימו לב טוב טוב מה אתם מודדים, למה, והאם אולי כדאי לשקול להפסיק למדוד לפחות חלק מהדברים, אם לא את כולם.

איך מארגנים מסיבה לילדים?

תשאלו את דיוויד…

שיטת הקבנוס

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

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

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

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

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

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

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

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

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

כלים אג’ילים – יש דבר כזה?

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

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

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

נסקור את הסיבות לשימוש ב”כלים אג’ילים” שאני נתקל בהן:

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

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

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

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

עקרון חשוב ומנחה במניפסט האג’ילי (עקרון 5) הוא:

Build projects around motivated individuals, give the environment and the tools they need, and trust them to get the job done.

עקרון נוסף חשוב (עקרון 11) הוא:

The best architectures, requirements and design emerge from self-organizing teams

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

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

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

לסיום אני רוצה לצטט משפט מתוך ספר של בס וודה וקרייג לרמן:
If you automate a mess, you will get an automated mess.

כל אחד הוא מיוחד

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

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

imageולשמחתי חלק גדול מה-Product owners כבר הפנימו את הנקודה הזו והם מבינים, ועזבו רגע אסורמותר, שלא כדאי לשנות תכולה במהלך הספרינט. יופי !
עקב כך, אותם POs דואגים בין השאר לסדר את הבקלוג לפי עדיפות פיתוח אמיתית… כמעט.

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

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

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

חבל על הזמן…

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

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

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

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

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

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

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

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

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

לשבור את הקיר

clip_image002[4]

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

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

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

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

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

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

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

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

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

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

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

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

clip_image002

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

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

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

יצירתיות

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

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

clip_image002

אני מעוניין לחלוק איתכם רעיון שקיבלתי מ-Rachel Davies בכנס שהשתתפתי בו לאחרונה:
רייצ’ל מציעה (למען הסר ספק זה גם לא המצאה שלה) שיטה שהיא קוראת לה Gold cards או כרטיסי זהב.

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

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

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

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