על הקשיחות המזיקה של התלות Finish-to-Start
תכניות העבודה הפרויקטאליות שזורות בתלויות לוגיות בין הפעילויות השונות הנדרשות לביצוע התכנית. התלות הנפוצה ביותר, הטבעית ביותר הוא התלות Finish-to-Start בין שתי פעילויות, תלות האומרת שפעילות B יכולה להתחיל לאחר שפעילות A תסתיים.
קו התפר הזה בין פעילות A לפעילות B מהווה מוקד התעניינות לעוסקים בנושא. תיאוריות ושיטות רבות בניהול פרויקטים משתמשות בקו התפר הזה לצרכיהן. בין אם התלות מהווה חלק מהנתיב הקריטי של הפרויקט, בין אם היא מהווה חלק מהשרשרת הקריטית של הפרויקט, ובין אם היא מהווה מרכיב בשיטה סטטיסטית כגון סימולציית מונטה-קרלו המנסה לחזות את הנתיבים הקצרים ביותר או הארוכים ביותר של הפרויקט.
הנחה אחת, גלויה או סמויה, משותפת לרבים מהעוסקים בשיטות ניהול ובניהול בפועל של פרויקטים והיא שקו התפר הוא בעל קשיחות טוטאלית. כלומר, אם סיום פעילות A מתעכב, פעילות B תתחיל בודאי מאוחר יותר ולכך יהיו השלכות (דחייה כמובן) על מהלך הפרויקט כולו.
אז נכון שאם הפרויקט מורכב מקידוח בסלע (A) ולאחריו יציקת בטון לתוך הקדח (B) אזי יש רגליים להנחת הקשיחות הטוטאלית הזו. אולם, ככל שהפרויקט נעשה מורכב יותר ויותר נפתחות דרגות חופש המאפשרות לעקוף את הנחת היסוד הזו ולהתייחס לקו התפר כקו בעל גמישות, ולעתים גמישות עצומה.
וכאשר נניח שהקו גמיש, הוא בידינו כחומר ביד היוצר (בין אם היוצר הוא מנהל הפרויקט, מבצע המשימה, הלקוח או בעל עניין אחר). ניתן יהיה להעלות רעיונות רבים לניצול הגמישות הזו בכדי להחזיר פרויקט המתקשה לסיים את שלב A במועד למסלול תקין ולסיום הפרויקט כולו במועד הנדרש.
אבקש להדגים בעזרת פרויקט פיתוח מופשט. נניח שהפרויקט הוא פיתוח מערכת תאורה חדשה ובה שני מרכיבים חדשים: בית מנורה ונורה. הממשק בין השניים הינו חדש (לא סטנדרטי). הדרישה מן הנורה היא להפיק כמות אור מסוימת, הדרישה מבית המנורה היא לאחוז את הנורה בחיבור מכני חדש ולהזרים זרם חשמלי נתון למנורה. הזרם לבית המנורה מסופק ממקור חיצוני. תכולת העבודה על הפרויקט תפורק למשימות הבאות: תכן ראשוני של המערכת, תכן מפורט של הנורה ובית המנורה, תכן מתקני בדיקה, המערכת, אינטגרציה (בדיקת ממשקים) ולסיום ניסוי (בדיקת ביצועים).
אנו נתמקד בתלות Finish-to-Start שבין סיום התכן המפורט (A) של הנורה, של בית המנורה, ושל מתקני הבדיקה, לבין האינטגרציה (B). זוהי תלות אופיינית בפיתוח מערכות, תלות המחייבת סיום פיתוח של כל המרכיבים וכל מתקני הבדיקה טרם הכניסה למעבדת האינטגרציה לבדיקת ממשקים. ככל שהמערכת מורכבת ממספר גדול יותר של מרכיבים כך גדל הסיכוי שאחד או יותר מן המרכיבים יתעכבו ולא יגיעו לשלב האינטגרציה במועד הנדרש. ומצד שני, המורכבות מקפלת בתוכה סיכוי פוטנציאלי לפתרונות יצירתיים.
נניח אם כך שהפרויקט התקדם וביום בו צריכה להתחיל אינטגרציה מבררים את הסטטוס ומתברר שאף אחד מהמרכיבים אינו מוכן. נדרשת עוד תקופת זמן (PERIOD) אחת לסיום הפיתוח של כל המרכיבים.
הברירה הפשוטה היא לדחות את מועד תחילת האינטגרציה ולהתפזר להמשך עבודות. הברירה המורכבת יותר אך יחד עם זאת המתגמלת יותר היא לבחון מה הושלם, מה חסר ולהתחיל בבדיקות האינטגרציה אותן ניתן לבצע גם אם הפיתוח לא הושלם עד קוצו של יוד. התעקשות של מי מאנשי הצוות (ובכלל זה אנשי אינטגרציה, מנהלים או הלקוח) שלא להתחיל באינטגרציה לפני שהגורמים המפתחים סיימו את כל הבדיקות מממשת את פוטנציאל הנזק החבוי בתלות הקשיחה Finish-to-Start. ההתעקשות תעלה ביוקר, בדחייה של מועד סיום הפרויקט. גמישות בהתייחסות לקו התפר הזה, איתור אפשרות לתחילת בדיקות בנושאים שניתן כבר לבדוק למרות שהפיתוח לא הסתיים תאפשר התקדמות של הפרויקט ותיצור סיכוי טוב לסיום הפרויקט במועד, תוך התגברות על הפער שנפתח בלוחות הזמנים.
עמידה עיקשת על עקרון הגמישות היכן שניתן תביא תועלת לפרויקט. התקשחות והיצמדות לתלות המתוכננת של Finish-to-Start תגרע מן היכולת לסיים את הפרויקט בהצלחה. |
תגובות (4)
נא להתחבר כדי להגיב
התחברות או הרשמה
/null/text_64k_1#
אורן,
אני חושב שאחכה לפוסט שלך בכדי להבין את נקודת המבט שלך על השפעת ההתפלגות של זמן הביצוע של תת-משימה על מהלך הפרויקט.
העלית את הנושא של הפילוג הסטטיסטי של משך ביצוע תת משימה ועל כן אקדים ואומר שאני לא חסיד גדול של השימוש בניתוח סטטיסטי לניהול הפרויקטים. הסיבה לכך היא שאיני רואה תרומה מספיק גדולה של הניתוח הסטטיסטי לקידום בפועל של לוחות הזמנים של הפרויקט. מה שאני מחפש, תיאורטית ומעשית, הוא שיטות וגישות המאפשרות עמידה בלוחות זמנים גם במקרים בהם הניתוח הסטטיסטי מציג תחזית קשה. ואני מחפש דוקא שיטות דיסקרטיות ולא סטטיסטיות. שיטות המתקשרות ללוגיקה של ביצוע העבודה.
אז זהו. אחכה בסבלנות לפוסט.
תודה רבה!
אכן הגישה האופטימית ניתנת וראויה להרחבה מעבר לתחום התעשיה. פוליטיקה? בהחלט אפשרות! זה יגיע עם הזמן.
חלק חשוב של הסיפור פה הוא אופן ההתפלגות של זמן הביצוע של תת-משימה. זה נראה ככה:
כלומר יש איזה מינימום שאי אפשר לרדת מתחתיו, אבל אין מקסימום, לפחות תיארוטית, אלא זנב ארוך. בגרף שבדוגמא, המינימום הוא יומיים, הממוצע הוא 4 ימים ו-98% מהמקרים העבודה תסתיים תוך 8 ימי עבודה, אבל יש גם את הפרייקט ההוא שבו זה לקח חודש... ההתפלגות הזאת יוצרת כמה תופעות מענינות אם לא מתייחסים אליה נכון (והאמת היא שבדיוק התכוונתי לכתוב על זה פוסט בפורום מו"פ)אבל אם לנסות לסכם הכל בכמה משפטים אז קודם כל, סכום של התפלגוית כאלה הוא התפלגות דומה אבל עם שונות גדולה יותר וככה יוצא שככל שהפרוייקט מתקדם הזמן עלול יותר ויותר להמרח והסיכוי לחזות מתי יגמר כל שלב הולך וקטן. הדרך הטובה ביותר לעצור את המריחה היא לשים דד-ליין (וכמו שכבר אמרנו אם רוצים, לעמוד בדד ליינים זו לא אגדה). דבר מעניין נוסף הוא שהדרך הטובה ביותר להקטין את השונות של התפלגות כזאת היא להגדיל את המינימום בלי להגדיל את הממוצע. כלומר אם מחליטים שאין לבצע את השלב בפחות ב-3 ימים במקום בשניים ןמנצלים את היום העודף כדי להתכונן יותר טוב, בממוצע נצליח עדיין לבצע את השלב ב-4 ימים אבל השונות תקטן מאוד.
מרתק. הגישה האופטימית נפלאה בעיני ומשמחת. לתחושתי אפשר להרחיבה מעבר לתחום התעשיה.
אוי, פתאום חשבתי על פוליטיקה. מצריך הרבה אומץ!