לצאת ממשבר

30 ביוני 2011

אחד הדברים שמעסיקים אותנו כמנהלים זה איך להמנע ממשבר,
אבל לפעמים אנחנו נכנסים לתפקיד חדש, הישר לתוך משבר שעשוי למוטט את החברה.
לפני שאנחנו רצים להתמודד עם המשבר רצוי שנבין קודם כל את המצב, את החומרה ובמה נכון לטפל ראשון ובמה אחרון (ולפעמים לאן לא להכנס).
אז איפה אנחנו נמצאים ומה אפשר לעשות?
מתברר שלא חייבים להמציא את הגלגל, ובתחום הניהול נעשה מחקר רב על מקורם של משברים ואופן הניהול הנכון שלהם. לפי פרופ' אברהם כרמלי, תהליך משברי כולל חמישה שלבים, שע"י ניהול נכון אפשר לסיים את המשבר בכל אחד מהם. ניהול כושל והגעה לשלב החמישי יובילו לסוף חייה של החברה.
עיוורון ארגוני: השלב הראשון – משהו קורה, אבל אנחנו מתעלמים ממנו
הסממנים הם בד"כ סממנים איכותיים ולא כאלו שניתן לראות אותם בדוחות הכספיים. לכן לא תבחינו עדיין בנטישת לקוחות ו/או בבעיות מכירה עקב איכות מוצר נמוכה. זאת מכיוון שהחברה חיה על תהילת העבר והלקוחות עדיין מוכנים לספוג תקלות, שירות קלוקל ומוצר מיושן. כמנהלים חדשים או ותיקים תוכלו לזהות שאתם בשלב הזה על בסיס הסימנים הבאים:
  1. סובלנות בחברה לחוסר ביצוע.
  2. עודף כ"א/אבטלה סמויה, מבנה ארגוני לא מעודכן ו/או ריכוז סמכויות במטה.
  3. פרוצדורות מגושמות שאין מאחוריהן תוכן.
  4. חוסר במטרות ברורות.
  5. בעיות תקשורת קשות בין גופים שונים כדוגמת מכירות, שיווק ופיתוח (רוצים לדעת יותר? קראו את הפוסט דע את האוייב).
דרכי התמודדות המומלצות הן פיתוח מנגנונים של ארגונים שחסינים לכשל:
  1. שיחות עם האנשים והבנה של הלך הרוח.
  2. פיתוח מחויבות עובדים וערכי חברה כמו מחויבות ללקוחות, מחויבות לקוד איכותי, מאובטח, מונחה ביצועים ופשוט!
  3. בניית מערכת חיסונית כדוגמת Code Review (רוצים לדעת יותר איך עושים Code Review נכון? העיפו מבט בפוסט אז מה היה לנו?), בדיקות אוטומטיות ומערכת ניטור שמודדת מדדים עסקיים כדוגמת זמינות השירות, מספר הבאגים והמקור שלהם ולא רק את ניצולת ה – CPU של השרתים.
  4. בדיקה שאתם באמת עושים שימוש בכלי הפיתוח הנכונים.
  5. בניית מודיעין עסקי וחיפוש איומים אקטיבי, לא רק בפאן העסקי של מתחרים חדשים, אלא גם של טכנולוגיות חדשות (לדוגמה האם HTML5 מהווה איום על מודלים ה – Mobile Apps שאנחנו מתבססים עליו? ראו בפוסט אסטרטגיה זאת לא מילה גסה). זיכרו! האיום האמיתי על הפירמה שלכם מגיע משולי השוק (ה – Early Adapters) ולא מהמתחרים הרגילים שלכם.
  6. מבנה פתוח, שיתחקר במהירות ובפתיחות באגים ובעיות בייצור, יטפל בהן במהירות (כולל בדיקות אוטומציה) ויתן להן מענה מיידי בייצור אם אפשר (איך עושים את זה? Continuous Deployment זאת התשובה).
קיפאון: השלב השני – משהו קורה, אנחנו מבינים את זה, אבל יש 1001 סיבות למה אף אחד לא מטפל בזה (רמז… אם כולם טוענים שאצלנו זה שונה, אתם בשלב הזה)
בשלב הזה יותר מדי אנשים מבינים שמשהו פשוט לא הולך טוב. בד"כ אלו יהיו "האנשים הפשוטים": אנשי המכירות בשטח, אנשי התמיכה ששומעים את צעקות הלקוחות והמהנדסים שחשופים לטכנולוגיות האחרונות. הבעיה שמשהו תוקע את הרצון לביצוע הפעולה. בין הסממנים תוכלו למצוא:
  1. שינוי לרעה בדוחות פיננסים: ירידה במכירות, מלאי שגדל ועליה בימי אשראי לקוחות.
  2. "אצלנו זה שונה": אם יותר מדי אנשים חוסמים את הביצוע כי "אצלנו זה שונה", "אנחנו עובדים שונה לחלוטין מהתעשייה", "הטכנולוגיה שבחרנו הרבה יותר טובה ולכן אי אפשר לבצע א, ב, ג…" אז כנראה שאתם שם.
    ירידה בהתנדבות העובדים כולל הליכה מוקדם וירידה בשעות החודשיות (לא, לא חייבים להשאר עד 22:00 כל יום, אבל כשקשה למצוא אנשים ב – 17:00 ויש מגמה, אז משהו לא הולך טוב, והבעייה לא אצלהם, אלא אצלכם).
  3. איטיות בתגובה בכלל ההחלטות בחברה (כל פיפס צריך לעבור 5 ועדות, ואף אחד לא לוקח אחריות).
  4. נטייה להישאר מחויבים לאופן ההתנהלות הקיים על בסיס הצלחות העבר.
  5. חוסר יכולת לגייס לגיטימציה בארגון לביצוע שינוי
הדרך הנכונה לתגובה היא החזרת האינסטיקטים לארגון:
  1. מה היה קורה אם היינו עושים אחרת? נסו להוציא מהאנשים שלכם דרכים לפתור בצורה שונה את הבעיות ע"י סיעור מוחות בשיטת איפכא מסתברא. האם למרות הכל ניתן לבצע דברים בצורה דומה לאחרים? האם החסמים הבלתי אפשריים, הם כן אפשריים?
  2. היכולת להגיב ומהירות התגובה הן קריטיות ליציאה מתהליך המשבר. לכן שנו את מהירות התגובה של הארגון, וקודם כל את מהירות התגובה של קבוצת הפיתוח. לפי שיטתה של פייסבוק גיוס אנשים במהירות פנומנאלית הוא חלק מרכזי בתרבות הארגונית שלה. אם גיוס הוא בעייתי (כי זה יתקע במשאבי אנוש או בכל מקום אחר), התמקדו במקומות שיש לכם השפעה מלאה עליהם ויכולים לייצר רוח של שינוי: סגירת באגים מרוכזת, מתן מענה מהיר יותר לבקשות לבדיקות התכנות, סגירת Features במהירות רבה יותר על חשבון מספר ה – Features או סגירת פניות מדרג ד'.
תגובה מוטעית: השלב השלישי – החלטנו כבר לפעול, אבל הבעיטה יצאה דרדל'ה
בשלב הזה המצב חמור מספיק עד כדי שאפילו גדולי הספקנים בחברה הבינו שאי אפשר להמשיך ככה. הבעייה הקשה בשלב הזה היא שדווקא כשהחלטתם לזוז קדימה, יש סיכוי טוב שתעשו את ההחלטה הגרועה ביותר. למה? הסיבה פשוטה, אם עד עכשיו התגללתם בלי יכולת לקחת החלטות, בלי יכולת לעשות שינוי או לפתור את הבעיות, יש סיכוי טוב שכמנהלים אתם די מנותקים מהשטח (כאמור האנשים הפשוטים כבר הבינו כבר לפני שני שלבים שיש בעיות). סביר מאוד שהפתרונות הנכונים לא אצלכם וההמלצות שקיבלתם די "מכובסות" אחרי שהם עברו את כל הבירוקרטיה ושלל התנגדויות שלמדנו עליהן בשלב הקודם. ובכלל, אם נהיה כנים, ביצוע של החלטות מהפכניות הוא לא ב – DNA של החברה. אז אם אתם רצים לקחת החלטות וגיליתם שההחלטה כוללת את אחד הסממנים הבאים אז אתם בדרך לקבל את ההחלטה הלא נכונה:
  1. ההחלטה כוללת ריכוז סמכויות למטה החברה.
  2. אתם עושים כל מאמץ לשמור על חשאיות של המהלך.
  3. ההחלטה נלקחת תחת לחץ.
  4. חשיבה קבוצתית.
אז איך עושים את זה נכון?
  1. ביצוע של התהליך בצורה חשופה: האנשים למטה כבר הבינו שיש בעייה, והידיעה שפועלים לשינוי דווקא תפיח רוח חדשה באנשים שבקו הראשון. המטרה היא בניית אסטרטגיה ברורה, ותוכנית מתגלגלת שתביא אתכם לשמה (כן בדיוק כמו שלמדנו בתהליך הבנייה של מערכת ענן).
  2. מתן תחזיות ריאליות לעובדים: כולם כבר רואים את הבעיות בדוחות הכספיים, בתגובות של הלקוחות ובניתוק של ההבטחות מהרבעונים הקודמים מהשטח. לכן תשמרו את האופטימיות למקום אחר ותנו תחזיות ריאליות שתוכלו לעמוד בהן. זאת אולי ההזדמנות האחרונה שלכם לשמור על אמון מצידם.
  3. שמירת ערוצים פתוחים מול דרג הביצוע: אתם צריכים לבנות ערוצים שיסייעו לכם להעביר את המסר למטה ולוודא שאתם מקבלים את המידע האותנטי מלמטה: Standup יומי, מיילים מסודרים ותוכנית שתציג את ההתקדמות. חישפו מדדים מרכזיים והציגו אותם. לדוגמה אם אתם חברת פרסום שלא מסוגלת להתמודד עם מספר הצפיות בפרסומות שלה: הציגו גרף עם מספר הצפיות בכל דקה. אם אתם צריכים טיפים נוספים לעבודה בצורה שטוחה, תוכלו ללמוד רבות מגוגל.
  4. ביצוע פעולות בצורה מסודרת ויצירת טקסים: בצעו קודם כל את הדברים הבסיסיים נכון: אם יש באגים רבים, ודאו שאתם עושים Code Review, ואם אנשים לא מדלוורים: עשו שימוש בלוח מחיק לניהול המשימות. הטקסים ישמשו אתכם ליצירת רוח חדשה ויצירת הצלחות קטנות.
הגעה למצב משבר: השלב הרביעי – דקה 90, אתה עובד את קו האמצע, עובר אחד, עובר שניים…
זהו, זאת ההזדמנות האחרונה לשנות, האם אתם יכולים? אם כן, תזכרו לעד. אם לא? תצטרכו לחתום בעונה הבאה בקבוצה אחרת. הסממנים לשלב הזה הם:
  1. כאוס ארגוני.
  2. ניסיונות לביצוע צעדים של Back to basics: אחרי התגובה המוטעיית בשלב הקודם הנטיה תהיה לבצע רגרסיה לאחור.
  3. עובדים, ספקים ולקוחות מצמצמים מחויבות ואף נוטשים.
על מנת להתמודד עם המצב הזה אתם נדרשים לבצע תהליכים חדים על מנת ליצב את הספינה ולהשיט אותה לחוף מבטחים:
  1. שינוי ארגוני אגרסיבי מהפכני (ולא אבולוציוני), אם לא הצלחתם עד עכשיו להחליט ולבצע את הצעד הנכון, אתם צריכים מישהו שיוכל לקחת החלטה נכונה ולבצע אותה. זה ידרוש שינוי אגרסיבי.
  2. שינוי של תפיסות, כ"א והנהלה על מנת לעקור מהשורש את התפיסות הקודמות. בד"כ בשלב הזה מביאים מנהלים חדשים, ולכן אם גוייסת כמנהל פיתוח ומשהו לא מריח טוב, כנראה שאתה בשלב הזה. אין לך הרבה מרחב טעויות, תחשוב מהר, תבצע בזהירות ובמהירות.
  3. הקפידו על שימור אגרסיבי של כישרונות וחיתוך שומנים.
הסגירה: השלב החמישי – האחרון שיוצא שיכבה את האור
במצבים האלו בד"כ כבר אבדו כל התקוות והמנהלים שמובאים תפקידם הוא למכור את שאריות החברה או לסגור אותה. הסממנים למצב הזה הם:
  1. אובדן תקווה אצל כל המעורבים בחברה.
  2. נטישה מוחלטת, הכישרונות האחרונים עוזבים, ספקים דורשים תשלום במזומן או שמסרבים לעבוד עם החברה ולקוחות שוקלים פעמיים לפני שהם מוכנים להפגש איתך.
  3. ההנהלה החדשה שהובאה רק לפני מספר חודשים סולקה בבושת פנים.
  4. בעלי החברה מוכנים למכור את שאריות נכסי החברה ו/או להכנס לפירוק.
בשלב זה למנהל הפיתוח כבר יש מעט מה לעשות, ובד"כ זה יכלול מירוק של חלון הראווה על מנת שניתן יהיה למכור את הפטנטים ו/או קבוצת הפיתוח לחברה אחרת:
  1. קשה למצוא מנהלים טובים לשלב הזה.
  2. המדד להצלחה: סגירה שקטה עם מינימום נזקים. בשלב הזה הרפתקאות לא יתקבלו בברכה.
  3. אם אתה מאמין בחברה וחושב שיש עוד תקווה… זה הזמן לערוך Management Buy Out: לקנות את החברה ולהרים אותה מחדש. יש הרבה אנשים ששרפו את החסכונות שלהם ככה, ויש גם כמה שזכו בתהילת עולם (וסידרו את הנכדים שלהם בדרך :-)
השורה התחתונה
חכם לא נכנס למצבים שפיקח יודע לצאת מהם, ולכן מומלץ מאוד לבנות את החברה וקבוצת הפיתוח שלך כך שהם יהיו חסינים למשבר ע"י בניית מערכת חיסונית. אבל לעיתים אין לנו את הבחירה, וצריך לעשות את הדברים הנכונים על מנת להשיב את הגלגל אחורה כדי שנוכל להקים את אותה מערכת חיסונית. טיפ אחרון: לא כל סימן למשבר הוא משבר, ולכן הזהרו מלהכניס את הארגון שלכם למשבר, רק כי אתם חושבים שיש משבר…
עברתם משבר? עשיתם את הדברים הנכונים? ראיתם איך נכנסים למשבר? הובלתם יצירה ממשבר? רוצים לשתף אותנו? יש לכם טיפ נוסף? אני פה בשבילכם…
נהנית מהפוסט? הרשם לבלוג הפתוח למנהל הפיתוח כדי להנות מעדכונים חדשים ישירות לדוא"ל!
ממשיכים לפתח,
משה קפלן Follow MosheKaplan on Twitter
עדכונים ותגובות של קוראים
הטיפ של נאוה שלו
נושא חשוב ומאמר מעניין. המאמר מתאר את האכזבה של מנהלים כאשר הם באים לתפקיד חדש ומתברר שהם צריכים לנהל משבר. כמובן זה מראה על תהליך גיוס לא סדור: לתפקיד כזה חשוב לבחור את האדם הנכון כמו גם לתאם ציפיות ולראות האם מנהל מעוניין למלא תפקיד כזה.
בכול מקרה יש בתפקיד כזה הרבה אתגר ויכולת לפיתוח הכישורים ולהזנקת הקריירה.
תשובה והרחבה
נאווה אכן קלעה לחלוטין שלעיתים נוצר פער ציפיות בין גיוס המועמד לבין המציאות בשטח.
לעיתים זה לא נעשה לגמריי במודע (החברה נמצאת עדיין בשלב הראשון – עיוורון או בשני – חוסר יכולת לבצע פעולה ולכן אין לה יכולת לשדר למועמד את המסרים הנכונים).
אם החברה כבר נמצאת במודעות שהיא בשלב שלוש והילך, והיא לא משדרת את המציאות, היא למעשה ביודעין מבטיחה לעצמה כישלון בגיוס שהוא מרכיב קריטי בביצוע מושלם של השלב השלישי (ביצוע הפעולה המתקנת), הרביעי (ניהול המשבר – ההזדמנות הכמעט אחרונה) או החמישי (סגירת העסק). זאת מכיוון שהחברה תביא אנשים לא נכונים עם ציפיות לא נכונות, ולכן יהיה לך מאוד קשה לבצע את המהלך הנכון,
נ"ב אם המשבר שלכם כולל בעיות מערכת ואתם לא יודעים אם מדובר על בעיה בתקשורת, ב – Web, בשרתים או בתשתיות? ב – 12/7 אני עורך סמינר מיוחד בשם Where the H#$& is My Performance Bottleneck במסגרת ה -  Expert Days 2011. מדובר סדנה בת יום אחד שבה נכנס לקרביים של מערכת Web ונבין איפה הבעייה יכולה להיות ואיך מוצאים אותה. בין הנושאים שנדבר עליהם: תקשורת בין הדפדפן לשרת, הדפדפן, שרת האפליקציה, בסיס הנתונים ותשתיות השרתים. למי זה רלוונטי? לכל מי שמנהל מערכת Web (שזה בעצם כולם) ורוצה להבין מה יכול להשתבש, ואיך מזהים במהירות את צוואר הבקבוק במערכת ומשחררים אותו.
נ"ב 2 באותה מסגרת אני עורך גם סדנה בת יום אחד שבה נדון באיזו שיטת ניהול פרויקט מתאימה לכם (התשובות תלויות במי שישתתף ביום הזה ולכן צפויות הפתעות!): הסמינר הפתוח למנהל הפיתוח: מנהלים פרויקט פיתוח. מה ההבדל בינה לבין הבלוג? אנחנו נדבר על הפרויקטים שלכם ונראה מה מתאים לכם. אם נשבר לכם מתאוריה זה המקום.

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. (*) שדות חובה מסומנים

11 תגובות

  1. Moshe Kaplan3 ביולי 2011 ב 21:03

    הי,

    דוגמה קטנה מ – RIM מהימים האחרונים: http://it.themarker.com/tmit/article/15961
    אתם מוזמנים לנתח באיזה שלב של המשבר החברה נמצאת,

    ממשיכים לפתח,
    משה קפלן

    להגיב
  2. Rotem Bloom4 ביולי 2011 ב 9:12

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

    רותם

    להגיב
  3. יקיר5 ביולי 2011 ב 18:36

    משה,
    אני פשוט נהנה כל פעם מהבלוג שלך!
    כמובן שאני גם מעביר את זה הלאה לחבר'ה :)

    להגיב
  4. Moshe Kaplan5 ביולי 2011 ב 20:03

    תודה יקיר!

    ממשיכים לפתח,
    משה קפלן

    להגיב
  5. אמיתי7 ביולי 2011 ב 12:53

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

    תודה,
    אמיתי

    להגיב
  6. Moshe Kaplan7 ביולי 2011 ב 13:21

    שלום אמיתי,

    קודם כל תודה!

    הכוונה בחשיבה קבוצתית למונח מתחום הפסיכולוגיה בשם Groupthink http://en.wikipedia.org/wiki/Groupthink.

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

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

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

    אני מקווה שהבהרתי את העניין,

    ודבר אחרון, מזל טוב על האקזיט!

    ממשיכים לפתח,
    משה קפלן

    להגיב
  7. אמיתי דובו8 ביולי 2011 ב 19:49

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

    תודה על המזל"ט! :)

    אמיתי

    להגיב
  8. Moshe Kaplan9 ביולי 2011 ב 19:17

    הי אמיתי,

    אכן תרגום מעניין, אני לא יודע מי מהם יותר מוצלח :-)

    ממשיכים לפתח,
    משה קפלן

    להגיב
  9. Moshe Kaplan9 ביולי 2011 ב 19:19

    הי רותם,

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

    ממשיכים לפתח,
    משה קפלן

    להגיב
  10. Anonymous25 באוקטובר 2012 ב 10:54

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

    להגיב
  11. Moshe Kaplan25 באוקטובר 2012 ב 11:21

    שלום לאנונימי,

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

    ממשיכים לפתח,
    משה קפלן

    להגיב