חשוב להדגיש שאני לא מתיימר לשלוט על התורה הזו, ומי שרוצה - ניתן למצוא חומר רב בספרים מקצועיים בנושא. אבל אני יכול לומר שאני בקיא בעיקרים ושהשתמשתי בה לא אחת.
דבר אחר - אני ניהלתי סוגים שונים של פרוייקטים, כרגע אני מתייחס יותר לפרוייקטי בדיקה. אם יש מנהל פרוייקטים בבדיקות - מה טוב. אם לאו - אז אני ממליץ למנהל הבדיקות או לראש הצוות
כל גרסה שמתוכננת כוללת בתוכה סיכונים, כשהתוצאה שלהם עלולה להיות:
בכדי שלא נגיע למצב הזה יש לתכנן בקפידה, להבין את כל הבעיות שקיימות, להערך מבחינות של הדרכה, תוכנה וכו'.
אם היינו חיים בעולם מושלם הכל היה עובד לפי התכנון, ואם לא עשינו טעות היינו מסיימים בזמן, באיכות ובתקציב שקבענו.
אבל אנחנו לא חיים בעולם כזה. כיוון שכך, עלינו להערך גם לדברים שעלולים להתרחש.
ניהול סיכונים הוא תמיד על פריטים (items) שליליים שיש סוכוי שיקרו אך אין וודאות לכך.
ברגע שסיכון הופך לבעייה אמיתית הוא עובר מ"ריסק" ל-open issue.
לפעמים אנשים לא מבינים למה צריך הרבה מסמכים, כמו מסמך ניהול סיכונים לדוגמא. ואני אומר: אם אתה לא יודע לייצר מסמך כזה תוך 30 ד', זה אומר שגם בראש אין לך תשובות, וצריך מסמך ולו לשם כך (וכמובן לשם מעקב).
איך נראה כזה מסמך?
אקסל תמיד עדיף, המספרים להלן הם שמות העמודים, ה-columns
1. ה-ID של הסיכון. כאן אתם יכולים להתפרע :-)
-----------------------------------------
2. רשימה של הסיכונים.איך קובעים מה הסיכונים?
אישית, הייתי עובר על מסמך תכנון הגרסה. על כל נושא שרשום הייתי מנסה לחשוב מה עלול לקרות, במסגרת ההיגיון, ורושם את זה בצד.
אח"כ הייתי מנסה לחשוב מנסיוני ומתייעץ עם אחרים (ר"צ בפיתוח, בדיקות, מהנדסי מערכת ועוד) בנוגע לדברים שהתרחשו, מסתכל על הגרסה מ"גבוה".
עם זאת, יש דברים שבד"כ חוזרים:
עיכוב בגרסה קודמת תעכב את הנוכחית, מעבדות שעלולות לקרוס, בעיות ועיכובים בקבלת חומרים מצד שלישי וכד'.
-----------------------------------------
3. הסתברות שהסיכון יתרחש.
4. חומרת הנזק אם הדבר יתרחש.מה עושים עם הסיכונים?
כמו בסיכוני תוכנה, מנסים לכמת את ההסתברות (1-5) שזה יקרה מול הנזק שזה עלול להוביל אליו (1-5).
למשל אי-קבלת חומר מצד שלישי בזמן זה עיקוב טוטאלי של הגרסה (5) אבל זה ספק מאוד אמין (3).
חשוב לי לציין שזו אינה מתימטיקה, ולאחר מתן הציון יש לעבור שוב, ולראות אם זה היגיוני!
לאחר מכן מכפילים את התוצאה ויש לנו את עצמת הסיכון.
5. עצמת הסיכון.
-----------------------------------------
מה עושים?
צריך תוכנית פעולה למניעת התממשותו של הסיכון, לשון אחר:
6. Mitigation
אם יש לנו בעייה עם צד שלישי, אולי כדאי להתחיל במשא ומתן עם חברה אחרת? אולי כדאי להעצים את הפיקוח עליו? אם עלולות להיות בעיות במעבדה אולי כבר כדאי לחדש חלק ממנה? וללדא שיהיו מספיק אנשים מקצועיים לתמיכה ועוד.
יש לוודא שחושבים על כמה שיותר פתרונות, ולהבין שהפתרון ימנע את הופעת הבעייה.
-----------------------------------------
ובכל זאת זה קרה?
7. Contingency plan
או fallback plan.
כלומר למרות כל מה שעשינו, הרע קרה. מה עושים? אפילו אם הסיכון נמוך יחסית, הוא עלול לקרות. אפשר לומר: אז למה לא לחשוב מה עושים כשזה יקרה (הדרך הכל-כך ישראלית)? התשובה היא כי:
א. אולי כבר לא יהיה מה לעשות באותה נקודה או שגם אם זה יקרה זה יעכב עד מאוד.
ב. כשדברים כאלה קורים, אפילו מנהלים בכירים נכנסין לפינות שלא לומר להיסטרייה וההחלטות שמתקבלות הן בד"כ שגויות ויותר בקטע של "תראה בוס אני עושה כל מה שאפשר (אפילו אם הוא מיותר)".
אז מה עושים? אם צד שלישי לא יספק אז אולי אפשר להתאים חלקים קיימים שיתפקדו במקום אלה שאמורים להגיע וכו'. להשתמש במעבדות של מישהו אחר שלא משתמש בהן באותו זמן.
חשוב: על סיכון של 2 לא הייתי שוכר חברה חיצונית שתכין את אותו חלק צד שלישי בנוסף לחברה הקיימת ולא הייתי רוכש מעבדה חדשה. צריך לזכור להיות בפרופורציות. מצד שני התעלמות מהסיכונים לא תבטל אותם.יש להתייחס כאן לעצמת הסיכון - בשביל זה חישבנו אותה.
-----------------------------------------
8. Due date לישיבת מעקב אחר הנושא.נראה ברור מאיליו.
-----------------------------------------
9. Due date שאחריו ברור שיש לנקוט אמצעים בפועל (כלומר ה-mitigations לא עזרו)
לפעמים באותו רגע אנו נוטים לומר "טוב אולי באמת זה יסתדר מחר כמו שהם מבטיחים" או ש"אולי הם יצליחו להפעיל את המעבדה". זהו זה: הגענו, לא קרה כלום: מפעילים את ה-contingency plan.
-----------------------------------------
10. אחראי.זה החלק הכי חשוב אולי. אם אין אחראי לא יקרה כלום.
-----------------------------------------
מי שכבר עושה את הטבלה, פעמים רבות אינו עוקב אחריה במהלך הגרסה. מיותר לציין שזה אולי עושה רושם טוב בתכנון על המנהלים, אבל זה יעשה עליהם רושם רע מאוד אם סיכונים שחשבת עליהם התממשו ולא תהיה לך תשובה.
דבר אחר - אני ניהלתי סוגים שונים של פרוייקטים, כרגע אני מתייחס יותר לפרוייקטי בדיקה. אם יש מנהל פרוייקטים בבדיקות - מה טוב. אם לאו - אז אני ממליץ למנהל הבדיקות או לראש הצוות
כל גרסה שמתוכננת כוללת בתוכה סיכונים, כשהתוצאה שלהם עלולה להיות:
- אי-עמידה בזמנים.
- אי-עמידה באיכות המצופה.
- חריגה כספית מהתקציב המתוכנן.
בכדי שלא נגיע למצב הזה יש לתכנן בקפידה, להבין את כל הבעיות שקיימות, להערך מבחינות של הדרכה, תוכנה וכו'.
אם היינו חיים בעולם מושלם הכל היה עובד לפי התכנון, ואם לא עשינו טעות היינו מסיימים בזמן, באיכות ובתקציב שקבענו.
אבל אנחנו לא חיים בעולם כזה. כיוון שכך, עלינו להערך גם לדברים שעלולים להתרחש.
ניהול סיכונים הוא תמיד על פריטים (items) שליליים שיש סוכוי שיקרו אך אין וודאות לכך.
ברגע שסיכון הופך לבעייה אמיתית הוא עובר מ"ריסק" ל-open issue.
לפעמים אנשים לא מבינים למה צריך הרבה מסמכים, כמו מסמך ניהול סיכונים לדוגמא. ואני אומר: אם אתה לא יודע לייצר מסמך כזה תוך 30 ד', זה אומר שגם בראש אין לך תשובות, וצריך מסמך ולו לשם כך (וכמובן לשם מעקב).
איך נראה כזה מסמך?
אקסל תמיד עדיף, המספרים להלן הם שמות העמודים, ה-columns
1. ה-ID של הסיכון. כאן אתם יכולים להתפרע :-)
-----------------------------------------
2. רשימה של הסיכונים.איך קובעים מה הסיכונים?
אישית, הייתי עובר על מסמך תכנון הגרסה. על כל נושא שרשום הייתי מנסה לחשוב מה עלול לקרות, במסגרת ההיגיון, ורושם את זה בצד.
אח"כ הייתי מנסה לחשוב מנסיוני ומתייעץ עם אחרים (ר"צ בפיתוח, בדיקות, מהנדסי מערכת ועוד) בנוגע לדברים שהתרחשו, מסתכל על הגרסה מ"גבוה".
עם זאת, יש דברים שבד"כ חוזרים:
עיכוב בגרסה קודמת תעכב את הנוכחית, מעבדות שעלולות לקרוס, בעיות ועיכובים בקבלת חומרים מצד שלישי וכד'.
-----------------------------------------
3. הסתברות שהסיכון יתרחש.
4. חומרת הנזק אם הדבר יתרחש.מה עושים עם הסיכונים?
כמו בסיכוני תוכנה, מנסים לכמת את ההסתברות (1-5) שזה יקרה מול הנזק שזה עלול להוביל אליו (1-5).
למשל אי-קבלת חומר מצד שלישי בזמן זה עיקוב טוטאלי של הגרסה (5) אבל זה ספק מאוד אמין (3).
חשוב לי לציין שזו אינה מתימטיקה, ולאחר מתן הציון יש לעבור שוב, ולראות אם זה היגיוני!
לאחר מכן מכפילים את התוצאה ויש לנו את עצמת הסיכון.
5. עצמת הסיכון.
-----------------------------------------
מה עושים?
צריך תוכנית פעולה למניעת התממשותו של הסיכון, לשון אחר:
6. Mitigation
אם יש לנו בעייה עם צד שלישי, אולי כדאי להתחיל במשא ומתן עם חברה אחרת? אולי כדאי להעצים את הפיקוח עליו? אם עלולות להיות בעיות במעבדה אולי כבר כדאי לחדש חלק ממנה? וללדא שיהיו מספיק אנשים מקצועיים לתמיכה ועוד.
יש לוודא שחושבים על כמה שיותר פתרונות, ולהבין שהפתרון ימנע את הופעת הבעייה.
-----------------------------------------
ובכל זאת זה קרה?
7. Contingency plan
או fallback plan.
כלומר למרות כל מה שעשינו, הרע קרה. מה עושים? אפילו אם הסיכון נמוך יחסית, הוא עלול לקרות. אפשר לומר: אז למה לא לחשוב מה עושים כשזה יקרה (הדרך הכל-כך ישראלית)? התשובה היא כי:
א. אולי כבר לא יהיה מה לעשות באותה נקודה או שגם אם זה יקרה זה יעכב עד מאוד.
ב. כשדברים כאלה קורים, אפילו מנהלים בכירים נכנסין לפינות שלא לומר להיסטרייה וההחלטות שמתקבלות הן בד"כ שגויות ויותר בקטע של "תראה בוס אני עושה כל מה שאפשר (אפילו אם הוא מיותר)".
אז מה עושים? אם צד שלישי לא יספק אז אולי אפשר להתאים חלקים קיימים שיתפקדו במקום אלה שאמורים להגיע וכו'. להשתמש במעבדות של מישהו אחר שלא משתמש בהן באותו זמן.
חשוב: על סיכון של 2 לא הייתי שוכר חברה חיצונית שתכין את אותו חלק צד שלישי בנוסף לחברה הקיימת ולא הייתי רוכש מעבדה חדשה. צריך לזכור להיות בפרופורציות. מצד שני התעלמות מהסיכונים לא תבטל אותם.יש להתייחס כאן לעצמת הסיכון - בשביל זה חישבנו אותה.
-----------------------------------------
8. Due date לישיבת מעקב אחר הנושא.נראה ברור מאיליו.
-----------------------------------------
9. Due date שאחריו ברור שיש לנקוט אמצעים בפועל (כלומר ה-mitigations לא עזרו)
לפעמים באותו רגע אנו נוטים לומר "טוב אולי באמת זה יסתדר מחר כמו שהם מבטיחים" או ש"אולי הם יצליחו להפעיל את המעבדה". זהו זה: הגענו, לא קרה כלום: מפעילים את ה-contingency plan.
-----------------------------------------
10. אחראי.זה החלק הכי חשוב אולי. אם אין אחראי לא יקרה כלום.
-----------------------------------------
מי שכבר עושה את הטבלה, פעמים רבות אינו עוקב אחריה במהלך הגרסה. מיותר לציין שזה אולי עושה רושם טוב בתכנון על המנהלים, אבל זה יעשה עליהם רושם רע מאוד אם סיכונים שחשבת עליהם התממשו ולא תהיה לך תשובה.
אין תגובות:
הוסף רשומת תגובה