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

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

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

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

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

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

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

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

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

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

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

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

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

4 Responses to “יום הכישלון הלאומי של פינלנד”

  1. יקיר says:

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

  2. תודה אלעד – פוסט מצוין!

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

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

    תודה,
    ליאור

  3. Elad Sofer says:

    ליאור ויקיר, תודה על הפירגון!

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

  4. Ilan says:

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