למה ניהול סיכונים לא מעניין אף אחד

27 באוגוסט 2010


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


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


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


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

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



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

  2. דרישות: ניתוח המצב העתידי שאתם שואפים אליו.

  3. פערים: ניתוח הפערים בין הרצוי למצוי.

  4. חלופות: הצגת מספר חלופות כולל משמעויות עלות, זמן וכ"א על מנת לסגור את הפערים.

  5. המלצה: הצגה של המלצה ברורה כיצד לסגור את הפער.

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

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



  1. הציגו את החלופות השונות בצורה של טבלה.

  2. הגדירו מספר פרמטרים בצורה דומה לזו של מכרז.

  3. תנו הסבר וכימות לכל אחד מהפרמטרים.

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

בטבלה המצורפת תוכלו לראות כיצד אותו חבר מימש את השיטה הזאת. במקרה הזה מדובר על דילמה כיצד לממש מנגנון עדכון נתונים מהשרת למערכת המשלבת מבחר Clients בפלפורמות סלולאריות (Nokia, BlackBerry, Android, iPhone ואחרות) ובפלטפורמה אינטרנטית מסורתית (דפדפן :-) . הפתרונות כוללים 1) התבססות על מנגנון דגימה מדי מספר דקות על בסיס HTTP (בדומה למנגנון העדכונים של פייסבוק), 2) על שרת שמחזיק TCP Conncections פתוחים לאורך זמן, או על 3) שימוש בפתרונות Push יעודיים שקיימים בפלטפורמות הסלולאר המובילות. בטבלה מפורטים עלויות הפיתוח, העלויות השוטפות של תעבורת רשת ושרתים והסיכונים השונים.
ניתוח חלופות לפיתוח מערכת COMET ל - WEB, iPhone, Android, RIM, Blackberry, Long Polling, TCP Connections and Push
לבסוף צריך להציג המלצה. ברגע שהצגתם בצורה טובה את החלופות האפשרויות והסיכונים המתלווים להם בצורה גרפית פשוטה, למנהל יהיה קל מאוד לקבל החלטה. באופן די מפתיע הוא גם יתחשב בסיכונים שהצגתם (בניגוד למה שאולי אתם חושבים, מנהלים לא ממש אוהבים סיכונים וברגע שמציגים להם פיתרון טוב הם ישמחו לקחת אותו). במקרה הזה לא תתפלאו שההנהלה של אותו חבר בחרה בפתרון הראשון של מנגנון Poliing כפתרון קצר טווח להגעה לשוק, ופיתוח מנגנוני Push יעודיים בהמשך לכל פלטפורמה כפתרון הארוך טווח על מנת לצמצם עלויות. פתרון ה – TCP Connection הוגדר כבעל סיכונים גדולים מדי, ויתרונות מעטים מדי יחסית למאמץ.

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

יש לכם הצעות נוספות? נתקלתם במקרים דומים? יש לכם פתרון טוב יותר? שתפו אותנו 


נהנית מהפוסט? רישום לבלוג הפתוח למנהל הפיתוח יבטיח לכם עדכונים חדשים ישירות לדוא"ל!


ממשיכים לפתח,


משה קפלן

Follow MosheKaplan on Twitter

נ"ב מתעניינים למה כל כך הרבה חברות גדולות הופכות את המוצרים שלהם ל – Open Source? אתם מוזמנים לקרוא את הניתוח שלי בבלוג האנגלי על נושאי ענן וביצועים


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

כתיבת תגובה

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

2 תגובות

  1. ripper2342 בספטמבר 2010 ב 7:46

    רק עניין צדדי אחד:
    Long Polling לא אומר שצריך להיות 5 דקות ב-User Experience. התגובה היא עדיין מיידית.

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

    בפייסבוק, אתה מקבל הודעות צ'ט רק כל 5 דקות? לא, נכון?

    להגיב
  2. Moshe Kaplan2 בספטמבר 2010 ב 8:26

    שלום רון,

    נחמד להפגש שוב :-)
    אני שמח שמישהו לפחות מנסה לקרוא את התוכן של הטבלה :-) .
    אז כן, התוכן של העמודה Long Polling מתייחס לדגימה של השרת אחת למספר דקות, ללא השהיית תגובה בשרת.
    Long Polling אמיתי (או COMET בשפת העם ;-) מחייב להחזיק את המענה בשרת עד שתהיה הודעה להחזיר למשתמש.
    למתעניינים קצת הדגימה בפייסבוק עומד על אחת ל – 55 שניות, וההתעדכנות היא אכן כמעט מיידית. המחיר הוא הרבה פחות משתמשים על כל שרת (למתעניינים: http://www.facebook.com/note.php?note_id=14218138919).
    נ"ב אם תבחרו את הפתרון הזה, רצוי מאוד שתעשו את זה עם פתרון להתמודד עם מספר Threads רב (מי אמר Erlang?).

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

    להגיב