Posts tagged ‘failure’

הגודל כן קובע

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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