ניהול פרויקטים
דעות בנושא ניהול אפקטיבי של פרויקטים ומשימות.
פוסטים פופולאריים
-
על הקשיחות המזיקה של התלות Finish-to-Start
13/7/08 | 995 צפיות
-
האם כדאי היה להשקיע במטוס מעבדה להסרת סיכוני הפיתוח?
2/8/08 | 842 צפיות
-
אפקט הפחד
17/9/08 | 1407 צפיות
-
טיפול פרואקטיבי ב Buffer בתכניות העבודה
5/6/08 | 1315 צפיות
-
גורמי הצלחה בפרויקטים
3/2/10 | 1183 צפיות
-
הצלחת פרויקט מחייבת מבט מרוכז קדימה
8/7/08 | 997 צפיות
פוסטים אחרונים
- גורמי הצלחה בפרויקטים 3/2/10
- זיהוי אי-וודאויות שיטתי 1/11/08
- סיכון קטן סיכון גדול 22/10/08
- העברת סיכון לצד שלישי 11/10/08
- ניהול תקציב Top-Down 4/10/08
- חשיבות האיזון בסעיפי ההסכם 20/9/08
זיהוי אי-וודאויות שיטתי
ניהול סיכונים בפרוייקטי פיתוח מתחיל בתהליך זיהוי הסיכונים בפרויקט. בפתח הדיון אני מבקש להחליף את המילה "סיכונים" ב"אי-וודאויות", החלפה שמאפשרת ראייה ברורה יותר של האתגר העומד בפני צוות הפרויקט ועוקפת את הסתירה הפנימית הטבועה במונח "ניהול סיכונים", סתירה אליה התייחסתי בדיון קודם. אם כך, הפוסט הנוכחי עוסק בתהליך זיהוי אי-הוודאויות בנושא פיתוח המוצר בפרויקטים.
היעד של פרוייקט פיתוח הוא להגיע בתום הפעילות למוצר, בדרך כלל אב-טיפוס, העונה על סט דרישות המפורטות במפרט הדרישות. בכדי לתת מענה לדרישות כולן מוגדר במהלך הפיתוח מוצר או מערכת המורכבים ממיגוון של מרכיבים, חלקם מוצרי מדף, חלקם הרחבת מעטפת הביצועים ופיתוח נוסף של מרכיב קיים, חלקם פיתוח מאלף עד תו. את כל אלה מכלילים יחד למוצר או למערכת אחת בה הם צריכים "לנגן" יחד, להתאים זה לזה בכל המימשקים, גיאומטרי, חשמלי, תוכנה וכדומה ולספק את הביצועים הנדרשים.
ברגע יציאתו של הפרויקט לדרך אנו נמצאים במצב של אי-וודאות. יש לנו אי-וודאות באשר ליכולתנו לענות על כל הדרישות בתום תהליך הפיתוח. הואיל ואת המענה לדרישות אנו בונים על ידי צירוף המרכיבים הרי שכעקרון תיתכן אי-וודאות באשר ליכולתו של כל מרכיב ומרכיב לתת מענה לדרישות שנגזרו עבורו וזאת בנוסף לאי-הוודאות באשר ליכולת להכליל ולשלב את המרכיבים בהצלחה.
מצב זה מאפשר להציע גישה שיטתית לזיהוי אי-הוודאויות בפיתוח המוצר. על פי הגישה המוצעת יש לפרוש את רשימת כל מרכיבי המוצר קרי, פריטי חומרה, אלגוריתמים, תוכנה או כל פריט אחר המרכיב את המוצר. עבור כל מרכיב ומרכיב יש לבדוק את מידת הוודאות של האיש הרלונטי מצוות הפרויקט ביכולת של הפריט לענות על הדרישות ממנו, בין אם מדובר בדרישות טכניות (דרישות ביצועים, דרישות פיזיות) ובין אם מדובר בדרישות תכניתיות (אי-וודאות במועד אספקה, מחיר, רשיונות יבוא או מענים אחרים בנושאי רגולציה). את חוות הדעת הטובה יותר כדאי לקבל מגורמי הפיתוח האחראים לפיתוח המרכיב עצמו. על רשימת הוודאויות בפיתוח של כל מרכיבי המוצר יש להוסיף גם את אי-הוודאויות בהכללת המוצר ובביצועים הכוללים שלו, אי וודאות שקיימת במרבית הפרויקטים אם לא בכולם.
דוגמה
הבה נניח שאנו מפתחים אופניים עם מערכת הנעה חשמלית. בכדי לזהות את אי-הוודאויות באופן שיטתי, נפרוש את רשימת מרכיבי האופניים והדרישות מהם ונבדוק את אי-הוודאות בפיתוח כל אחד ואחד מן המרכיבים. נוכל לראות שבחלק מן המרכיבים יש לנו אי-וודאות לגבי היכולת לספק את הדרישות ובחלק אחר אין אי-וודאות.
גלגלים - נדרש משקל קטן מ 1.5 ק"ג - אי-וודאות ביכולת להשיג משקל נמוך שכזה. מנוע - נדרש משקל קטן מ 1 ק"ג ומומנט גדול מ X קג"מ - אי-וודאות ביכולת להשיג משקל קטן ומומנט גדול. מצמד - נדרשת הצמדה מיידית - קיים מוצר מדף עונה על הדרישות, אין אי-וודאות. מצבר - נדרש משקל קטן מ-600 ג"ר ומשך פעולה של 20 דקות - אי-וודאות ביכולת לספק ביצועים במשקל הנדרש, קיים מצבר דומה במשקל 700 ג"ר, הפער אינו גדול. הכללה - נדרשת תאימות מכנית בין כל החלקים - אי-וודאות בהתאמה מכנית באזורים קריטיים ביצועים - נדרש להגיע למהירות מקס. 50 קמ"ש - אי-וודאות ביכולת להשיג ביצועים שכאלה.
ניתן לראות מן הדוגמה שסריקה שיטתית של כל מרכיבי המוצר מאפשרת זיהוי אי-הוודאויות הדורשות, כל אחת בנפרד, תכנית להסרתן במסגרת תכנית הפיתוח. |
תגובות אחרונות
-
כבשת הרעש
בתגובה על גורמי הצלחה בפרויקטים
-
agileman
בתגובה על זיהוי אי-וודאויות שיטתי
-
שמעון זיירמן
בתגובה על העברת סיכון לצד שלישי
-
פיני יחזקאלי
בתגובה על טופי וקייסי
-
גנאדי
בתגובה על סיכון קטן סיכון גדול
-
ק י צ י
בתגובה על אהבה גדולה
תגובות (17)
נא להתחבר כדי להגיב
התחברות או הרשמה
/null/text_64k_1#
בהחלט, אני מתכוון לזיהוי אותו חלק מאי הוודאויות הניתן לזיהוי. כנגדו אנו מפעילים תכניות פעולה למען מיגור הסיכון (risk mitigation). אתה מתייחס בצדק לאותו החלק של אי הוודאויות אותו לא ניתן לזהות - אני מסכים אתך: הוא קיים ויתממש, ברגע הכי לא צפוי, כך נראה.
שבוע טוב גם לך!
שמעון
מן הסתם, אתה מתכוון שזיהוי חלק מאי הוודאויות, שהרי, ככל שנתאמץ, נוכל רק להקהות את עטוקצן של התוצאות הבלתי צפויות והלא מתוכננות...
רק בריאות ושבוע נפלא
פיני
מן הסתם, אתה מתכוון שזיהוי חלק מאי הוודאויות, שהרי, ככל שנתאמץ, נוכל רק להקהות את עטוקצן של התוצאות הבלתי צפויות והלא מתוכננות...
רק בריאות ושבוע נפלא
פיני
ניר שלום,
אכן הטכניקה הזו משמשת חברות וארגונים רבים. אני לא אוהב אותה. הסברים מפורטים וטכניקה חליפית - ראה במאמר שצירפתי לתגובתי הקודמת.
בברכה
שמעון
היי שמעון,
אכן יש טכניקה כזאת...מבטיח להביא אותה בהזדמנות הקרובה.
בגדול יש לאתר את הסיכונים הניהוליים החיצוניים, הטכניים והטכנולוגיים...לתת משקל לכל אחד מהסיכונים (1 - 5) להוסיף לכל סיכון את העלות הכספית שלו באם יתממש.
להתרכז רק בסיכונים שקיבלו את הציון הגבוה ביותר בשקלול, לתת לכל סיכון גורם אחראי, ליצור ישיבות שבועיות כדי לוודא שהסיכונים מטופלים, לטפל בסיכונים ע"י תוכנית מגירה...
על קצה המזלג :)
אני מציע להציץ במצגת שהכנתי לכנס האיכות ה-10 בנושא גישה דטרמיניסטית לניהול הסיכונים בפרויקט.
המצגת מציגה גישה חדשה לניהול סיכונים, גישה באמצעותה ניתן לעקוף את הבעייתיות שבהערכת הסיכוי לכשל, ערך הכשל וכיו"ב ענינים קשים להערכה.
יש חשיבות יתרה לדעתי בהתמקדות בניהול הסיכונים ב(מילוי ה)דרישות. ראשית, המשמעות של אי-עמידה בדרישה היא כבדה יותר במונחים של עלות התיקון, עקב זמן הסבב הגדול. ניתן לדמות את הפיתוח לסדרה של מעגלים, אחד בתוך השני, כאשר המעגל של דרישה שמזרים הלקוח בתחילת הפרוייקט נסגר כאשר נבדק מילוי הדרישה בסיום הפיתוח.
שנית, עקב ה-Visibility של הדרישות (לעומת שיקול תכן כזה או אחר), ל-"ברוך" כזה יש לעיתים משמעות לא פשוטה ביחסי ספק-לקוח. פרדוקסלית, יש מקרים שדווקא "סיפור גבורה" על "כיצד איתרנו ברגע האחרון אי-מילוי דרישה מינורית ושרפנו לילות כדי להשלים את החסר לפני האספקה" משפר את היחסים (וכמובן מוביל לתיאוריות קונספירציה על הסיבה האמיתית לאי-מילוי הדרישה...).
לגבי הטכניקה של שיקלול גורמי סיכון: אני חלוק עם עצמי ביחס לתועלת שבשיטה זו. מצד אחד, היא מסייעת לנטרל את השיקולים הרגשיים מתהליך תעדוף הקצאת המשאבים לסילוק גורמי הסיכון (אלה שהתממשו כמובן), אך לעיתים מודל השקלול עלול "לטעות" עקב מידע לא מלא על גורמי הסיכון (וכולנו יודעים עד כמה חסר המידע שאנו מסוגלים לעבד במצבי לחץ, לא משנה כמה חזקים המחשבים על שולחננו...).
פיני שלום ותודה!
ניר שלום, ברוך הבא לקפה!
אכן, אני מתייחס לסיכוני הגדרת הדרישות בפיתוח המוצר. יש לנו אי ודאות באשר לשאלה האם נוכל למלא אחר כל הדרישות או אולי לא נצליח לעמוד בהשגת מי מהדרישות.
ניר, אתה מזכיר טכניקה של שקלול סיכונים וגידורם ככלי להקטנת אי הודאות בפרויקט. תוכל לפרט בנושא זה?
ציינת ניהול סיכוניםן בהיבט הדרישות של פיתוח המוצר.
אני מכיר ניהול סיכונים (ולעניות דעתי השם הזה טוב יותר מהשם "אי וודאות" :)
אם כי שניהם אומרים את אותו הדבר לבסוף.
ניהול סיכונים בפרוייקט תוכנה מחולק לשניים, סיכוני היתכנות, וסיכוני עלות..שקלול של הסיכונים וגידורם יבטיח ויקטין את אי הוודאות בפרויקט.
ניהול הסיכונים שציינת בפוסט הזה מתייחס לסיכוני הגדרת הדרישות בפיתוח המוצר..לא?
מצויין. תודה שמעון.
פיני
לטל תודה על הפירגון וליואב תודה על התגובה המפורטת.
יואב, אתה מדגיש במספר מקומות את הקושי במודל ואת העלות העודפת שלו. קשה לי להתחבר להערכתך זו. באשר לעלות העודפת של המודל, הרי היא קטנה יחסית להוצאה הכוללת על הפרויקט, כך לפחות למיטב ניסיוני. באשר להסתבכות המודל עד לרמה שאינה ניתנת לפתרון - איני שותף לחוויות שכאלה. באשר לדוגמה שהבאת, אני סבור שאת הערכת אי הוודאויות יש לבצע על ידי כל אנשי הצוות הפרויקטי, כל אחד בתחומו. אי הודאות של המעריכים השונים אמנם קיימת והשיטות לניהול אי הוודאויות מפצות גם על כך.
אשמח להמשיך לדון בנושא. השדרוג אותו אתה מציע נדרש מן הסתם, השאלה היא איפה כדאי לגעת. האם תוכל לתת לנו קצה חוט?
שמעון שנה טובה,
הכיוון הוא נכון, והכרחי במובן שיש לדרוש מההנהלה הבכירה הכרה ופעולה בכיוון כימות גורמי אי-הודאות, ובניית מענים למקרים של "בריחת" המערכת ממעטפת המותרת במהלך הפרוייקט.
אני מדגיש "בכיוון", שכן לדעתי, מהר מאד מסתבך המודל ברמה שלא ניתנת לפתרון לפי השיטות הסטנדרטיות. לדוגמא, מי אמר שרק גורם אחד מוסמך לבצע את הערכת אי-הודאות? ומה נאמר על אי-הודאות של אותו גורם בההערכה שלו (כלומר, איכות ההערכה שלו, שמבוססת על מקצוענותו, נסיונו בדומיין ובפרוייקט, וכו')?
קיימות גם השפעות הדדיות בין תתי-מערכות שיש לקחת בחשבון, וכאן אני נזכר בדבריו של המורה שלי לפיזיקה מהתיכון, שהסביר לנו שמכניקה של גוף צפיד יחיד קל לחקור. השפעה הדדית של שניים זה כבר לאוניברסיטה. שלושה גופים זה כבר מחשב-על. והרי כל פרוייקט שמכבד את עצמו מורכב מעשרות תתי-מערכות עם השפעה הדדית שרמתה היא פונקציה של כמות הממשקים שהגדיר הארכיטקט...
אי-הודאות היא גם פונקציה של טווח הזמן. אם נשווה את ניהול הפרוייקטים לניהול השקעות, הערכת תוחלת תשואת מנייה מסויימת יכולה להיות שונה משמעותית אם מדובר במסחר תוך יומי, מסחר למספר ימים (Swing), או "השקעת ערך" לטווח ארוך.
חוץ מזה, את גורמי אי-הודאות יש לעדכן ללא הרף, מה שמטיל עומס (שבוודאי לא מתוקצב) על הפרוייקט, ומגדיל את גורם השגיאה, שכן כל עדכון כזה צובר את השגיאות של קודמיו.
באלביט היינו משתמשים באפליקציה שהייתה מבוססת על תורת האילוצים של גולדרט. מהר מאד האפליקציה קרסה ולא הצליחה "לספק את התוצרת" ל-IPT השבועי.
לגבי הדיון עם צחי על פרוייקטים "שלא נוגעים בהם עם מקל" (ניסוח שלי) - זה רק מוסיף על הסיבוך כאשר נכנסים שיקולים אסטרטגיים (שלא לומר "פוליטיים") כאשר לעיתים הופך גורם אי-ודאות למנוטרל, כאשר מתקבלת החלטת "override" ע"י גורם הנהלה. זו פרורגטיבה של האחרונה להחליט כך, אך יש (א) לבצע אז שינוי במודל שיתחשב בהחלטה כזו, ו-(ב) ידאג לנטר את המציאות ולהתריע כאשר זו טופחת על פנינו ("הקונספציה").
לסיכום, אני לא רואה כיוון אחר, אך את הדרך להגיע לשם יש לשדרג באמצעים שיעלו את התרומה של מודל זה, ויורידו את העלות העודפת שלו.
שנה מלאת אהבה,
מאמן אישי לזוגיות
acoach4u.co.il
לצחי שלום ותודה על התגובה,
אני מסכים אתך שיש פרוייקטים שעדיף לא לגעת בהם, מדובר בפרוייקטים בהם צפוי הפסד ברור ושאין בכוונת ההנהלה להשקיע את סך ההפסד לצורך יצירת נכסים עתידיים.
יש בכל זאת עניין שראוי להתייחסות בהקשר לכך: במקרים רבים מאד היכולת להעריך בצורה מדויקת את עלויות הפרויקט היא ממש לא טובה. יש אי-ודאות גדולה בהערכת העלויות. ואז נשאלת השאלה כיצד מקבלים החלטה לגבי היציאה לביצוע הפרויקט בתנאי אי-ודאות שכאלה? אנו יודעים שאנשי השטח ימליצו לגורם המחליט אחת מהשתיים, לקבל את הפרויקט (היות והם מעונינים בו) כי יש סיכוי טוב שהעלות תהיה קטנה יחסית, או לדחות את הפרויקט (היות והם לא מעונינים בו) כי יש סיכוי טוב שהעלות תהיה גדולה יחסית. אנו יודעים גם שהגורם המחליט יחליט אחת מהשתיים, לקבל את הפרויקט (היות והוא מעונין בו) או לדחות את הפרויקט (מהסיבה ההפוכה). המסקנה מכאן היא שאי הודאות הזו, האופיינית כל כך, תנוצל על ידי כל הצדדים המעורבים לתמיכה בצד שלהם, לא חשוב מהו...
לגבי תגובות שלכם ,
לעיתים ישנם פרוייקטים שעדיף פשוט לא לגעת בהם ,לא מבצעים עבודה/פרוייקט לפני שלא עושים סקר או בדיקה אם
ניתן לא רק לקבל את הדרישות אלא גם לבצע כפי שהלקוח דורש (זה הרי ברור).
תמיד מומלץ לתחשב עלויות לפני אישור סופי של כל פרוייקט ולדעת האם כדאי לבצעו במחיר הנקוב כולל חישוב רווח נקי .
במקום אשר עבדתי בו למדתי איך מבזבזים כספים מיותרים על חשבון מקצועיות עובדים ע"י הוצאת עבודות לקבלני חוץ
כמו כן למדתי באותו מקום שברגע שכ - 20 אנשים אשר עובדים במפעל כולל המנכ"ל עובדים בשיטות תימכור וחישובי עלויות
אשר שונות זו מזו מקבלים בתוצאה הסופית הפסדים בצורה נהדרת !
הלוואי והייתי יכול לארגן לכם ביקור להתרשמות :-), הבעיה שזו התרשמות לרעה .
לאלעד שלום ותודה
אפתח בזה שאי הוודאות באשר ליכולתנו לענות על כל הדרישות יכולה להיות אחת משתיים. א) ייתכן שנגיע למצב שבמהלך ביצוע הפרויקט יתברר לנו שאיננו יכולים לתת מענה לדרישה, ב) ייתכן שנגיע למצב שמענה לדרישה יגזול יותר משאבי זמן וכסף (או פחות לעתים נדירות יותר) ביחס למתוכנן.
ולענין שמפריע לך והוא חוסר ההתייחסות לשאלה מי מהדרישות עדיין יהיו רלוונטיות בסוף הפרויקט. מנקודת הראות של המאמר, שאלה שכזו היא גורם אי וודאות כמו גורמי אי וודאות אחרים (אי וודאות ביכולת להשיג משקל רצוי, אי וודאות ביכולת להשיג ביצועים, אי וודאות בהתאמה מכנית וכדומה). גורם אי וודאות זה שייך לעולם התכניתי, אפשר בהחלט להוסיפו לרשימה שבדוגמה במאמר בצורה הבאה:
"מפרט דרישות - נדרש לתת מענה לכל (או ל X אחוז) הדרישות - אי וודאות ביציבות הדרישות לאורך זמן"
כלומר יש להתייחס לבעייה זו כאי-וודאות ולהציע דרכים להסרת אי-וודאות זו, כמו כל אי-וודאות אחרת.
אני מקוה שעניתי לשאלתך.
שמעון,
המאמר מעניין ונהנתי מאוד לקרוא אותו, אך יש לי שאלה, כתבת - "ברגע יציאתו של הפרויקט לדרך אנו נמצאים במצב של אי-וודאות. יש לנו אי-וודאות באשר ליכולתנו לענות על כל הדרישות בתום תהליך הפיתוח", ומה שלי טיפה מפריע, היא העובדה שלא התייחסת לשאלה איזה דרישות עדיין יהיו רלוונטיות בסוף הפרויקט. השקעת משאבים בעבודה על דרישות שמתגלות כלא רלוונטיות היא סיכון משמעותי ויש לה השפעה רבה על ה-ROI של הפרויקט.
מה דעתך בנושא, ואיך אתה מציע חהתייחס לבעיה שכזאת ?