הגעתם לישיבת בורד, הצגתם סיכונים ואת אף אחד זה לא עניין?
אחד המתכנתים משגע אתכם באופן קבוע שהרכיב המפותח מאוד כולל הרבה מאוד סיכונים בתוכו? שמתם לב שגם אתכם זה פחות עניין?
למה בעצם?
האם ניהול סיכונים הוא לא אחד מהתפקידים החשובים ביותר של המנהל?
למה רק בחברות מעטות ניהול סיכונים מבוצע בצורה מסודרת?
למה אנחנו נתקלים בזה בד"כ רק בהצגה של סקרים של פרויקטי ענק?
חבר טוב שמעורב בימים אלו בסטארט אפ חדש נתקל בתופעה הזאת ושיתף אותי בלבטים האלו.
אז למה זה קורה?
רב הצפת הסיכונים בארגונים ישראלים דווקא מגיעה מלמטה, זאת אומרת רב האזהרות מגיעות מהערות של אנשים מלמטה.
ברמות הגבוהות יותר, בעיקר מחפשים את הפתרונות ופחות את הבעיות. מה שהמנהלים שלכם מחפשים בשורה התחתונה זה את ההצלחה, ולכן הם רוצים שתגיעו אליהם עם רשימת הפתרונות לבעיות ולא עם רשימת הבעיות. המנכ"ל/בורד בד"כ רוצים שיציגו להם את הבעייה לעוסה ויאפשרו להם להחליט. בשביל לחשוב הם משלמים לכם משכורת יפה...
האם זה בגלל הישראליות?
אין ספק שזה קשור לאופי הישראלי של תכל'ס ו - "יהיה בסדר", אנחנו בהחלט מוטי נטייה להתמודד עם מה שאנחנו יכולים להתמודד איתו, ופחות נוטים ל - "חפירות". יש בהתנהלות הזאת לא מעט חסרונות, אבל ככל הנראה גם לא מעט יתרונות.
איך מתמודדים עם זה?
מנסיוני בעבר בייעוץ לחברות תוכנה וגופים גדולים בשוק הישראלי, הצפייה בהנהלה שכאשר אתה מציג בעייה קודם כל תציג תהליך חשיבה סדור שיאפשר קבלת החלטה. התהליך הזה כולל 5 שלבים שיוצגו בצורה תמציתית וברורה:
- רקע: ניתוח הרקע והסיבות להווצרות הבעייה (המהדרין ינקטו בשיטות כמו ניתוח פורטר במקרה הצורך).
- דרישות: ניתוח המצב העתידי שאתם שואפים אליו.
- פערים: ניתוח הפערים בין הרצוי למצוי.
- חלופות: הצגת מספר חלופות כולל משמעויות עלות, זמן וכ"א על מנת לסגור את הפערים.
- המלצה: הצגה של המלצה ברורה כיצד לסגור את הפער.
הצגה בצורה הזאת תאפשר להנהלה לקחת החלטה עסקית מושכלת, ללא צורך בלימוד פרטי הפרטים של הנושא, על בסיס מיצוי הידע הקיים בארגון (אשר בד"כ מצוי בדרגים הטכניים).
אז איך מציגים בצורה מיטבית?
הפתרון הוא פשוט, קודם כל מתחילים עם אוסף החלופות:
- הציגו את החלופות השונות בצורה של טבלה.
- הגדירו מספר פרמטרים בצורה דומה לזו של מכרז.
- תנו הסבר וכימות לכל אחד מהפרמטרים.
- תנו ציון לכל אחת מהחלופות. כדי לא להעמיס על הקוראים, אל תבצעו את הניקוד בצורת מספרים אלא צבעו כל אחד מהתאים בצבע בסקלה מירוק לאדום.
בטבלה המצורפת תוכלו לראות כיצד אותו חבר מימש את השיטה הזאת. במקרה הזה מדובר על דילמה כיצד לממש מנגנון עדכון נתונים מהשרת למערכת המשלבת מבחר Clients בפלפורמות סלולאריות (Nokia, BlackBerry, Android, iPhone ואחרות) ובפלטפורמה אינטרנטית מסורתית (דפדפן :-). הפתרונות כוללים 1) התבססות על מנגנון דגימה מדי מספר דקות על בסיס HTTP (בדומה למנגנון העדכונים של פייסבוק), 2) על שרת שמחזיק TCP Conncections פתוחים לאורך זמן, או על 3) שימוש בפתרונות Push יעודיים שקיימים בפלטפורמות הסלולאר המובילות. בטבלה מפורטים עלויות הפיתוח, העלויות השוטפות של תעבורת רשת ושרתים והסיכונים השונים.
לבסוף צריך להציג המלצה. ברגע שהצגתם בצורה טובה את החלופות האפשרויות והסיכונים המתלווים להם בצורה גרפית פשוטה, למנהל יהיה קל מאוד לקבל החלטה. באופן די מפתיע הוא גם יתחשב בסיכונים שהצגתם (בניגוד למה שאולי אתם חושבים, מנהלים לא ממש אוהבים סיכונים וברגע שמציגים להם פיתרון טוב הם ישמחו לקחת אותו). במקרה הזה לא תתפלאו שההנהלה של אותו חבר בחרה בפתרון הראשון של מנגנון Poliing כפתרון קצר טווח להגעה לשוק, ופיתוח מנגנוני Push יעודיים בהמשך לכל פלטפורמה כפתרון הארוך טווח על מנת לצמצם עלויות. פתרון ה - TCP Connection הוגדר כבעל סיכונים גדולים מדי, ויתרונות מעטים מדי יחסית למאמץ.
השורה התחתונה
תעשו את רשימת הסיכונים ותציגו את הפתרונות האפשריים ואז יתייחסו אליכם.
יש לכם הצעות נוספות? נתקלתם במקרים דומים? יש לכם פתרון טוב יותר? שתפו אותנו
נהנית מהפוסט? רישום לבלוג הפתוח למנהל הפיתוח יבטיח לכם עדכונים חדשים ישירות לדוא"ל!
ממשיכים לפתח,
משה קפלן
נ"ב מתעניינים למה כל כך הרבה חברות גדולות הופכות את המוצרים שלהם ל - Open Source? אתם מוזמנים לקרוא את הניתוח שלי בבלוג האנגלי על נושאי ענן וביצועים