תפריט

מנהל פרויקט, האם אתה עוזר למנכ"ל שלך לישון טוב בלילה?

 

שאלתם את עצמכם פעם, מה יאפשר למנהל שלכם לישון בלילה? להיות רגוע? לתת בכם אמון?…Good Night

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

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

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

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

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

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

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

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

יותר מזה- אני שקוף איתך המנהל ואם יהיה משהו- אתה תדע, אני לא עומד להפתיע אותך בהפתעות לא נעימות.

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

מטרת ניהול סיכונים בפרויקט, על פי ה PMBOK , היא להגדיל את ההסתברות להתרחשות אירועים חיוביים ואת השפעתם, ולהקטין את הסתברותם של אירועים שליליים בפרויקט ואת השפעתם. כלומר- לבוא ולבחון את כל הארועים שעשויים או עלולים לקרות ולשבש לנו את היכולת לעמוד ביעדי הפרויקט.

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

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

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

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

כדי לאפשר למנהל שלנו לישון טוב בלילה, אנחנו צריכים לנהל את הסיכונים בשוטף, ביומיום, ולא רק מסקר סיכונים אחד למישנהו, ולודא שכל פעם שיש סיכון חמור/ אדום- אנחנו מיידעים את המנהל שלנו ומביאים לו יחד את האלטרנטיבות להפחתת הסיכון. בדרך זו נמנע מהמנהל להיות מופתע לרעה, ונאפשר לו לישון טוב יותר בלילה.

Picture source - http://www.goodnight.quotesms.com/images/Good-Night.jpg

Galit Yaskerevitz-Tietz גלית יסקרביץ-טיץ, מייסדת ומנכ

גלית יסקרביץ'-טיץ PMP

סגנית נשיא לקשרי תעשיה ומימשל ב PMI ישראל

מנכ"לית חברת Leadera

ליצירת קשר - This e-mail address is being protected from spambots. You need JavaScript enabled to view it.

איך בוחרים ספר טוב בניהול פרויקטים – טיפים והמלצות- חלק א'

את הסקירה הקודמת בנושא כתבתי לפני 10 שנים! יצאתי לבדוק מה התחדש בשוק הספרים למנהל הפרויקטים המתחיל. לשמחתי, למדף הספרים בעברית הצטרפו 2 ספרים נוספים שלא היו בזמנו ולכן הסתקרנתי לבחון אותם. כמו-כן, הצטרפו ספרים רבים באנגלית וכן ספרים לניהול פרויקטי אג'יל (גם הם באנגלית) אשר הסקירה עליהם תופיע במאמר הבא.

להלן חלק א' המרכז את ה- PMBOK ואת הספרים בעברית.

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

רבים מהארגונים פונים כיום ל- PMBOK (Project Management Body of Knowledge) של ה-PMI כמקור ידע יחידי, אולם, למרות היתרונות הברורים הגלומים בגוף הידע, המכיל את כל תיאורית ניהול הפרויקטים, קיימת עדיין דרישה לספרים משלימים, אשר יכסו חומר אשר לא מקבל דגש מספיק ב- PMBOK.

בשוק קיימים כיום ספרים רבים בתחום ניהול הפרויקטים אותם ניתן לחלק לשלוש קטגוריות עיקריות:

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

ספרים סמי-תיאורטיים המלווים בדוגמאות רבות ו-Study Case רבים להדגמה. ספרים אלה נותנים דגש על ה"איך" לנהל פרויקטים. העיסוק בספרים אלה יהיה עיקרו של המאמר המובא להלן.

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

בבואי לסקור ספרים מומלצים בתחום הספרים הסמי-תיאורטיים בדקתי מספר נושאים הנראים לי כחשובים למנהל הפרויקט המתחיל (שימו לב שאלו דברים שנראים לי חשובים – ייתכן ויש דברים נוספים אשר הינם חשובים לאנשים אחרים ולא יקבלו דגש להלן). הנושאים העיקרים שנבחנו:

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

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

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

ספרים המלווים בדוגמאות רבות- כל המרבה הרי זה משובח. הדוגמאות וה- Case Study הם נשמת אפו של כל ספר לניהול פרויקטים בפרט וכל ספר לימוד בכלל. הנחת הבסיס הינה שמנהל הפרויקטים לא מתעניין רק בתיאוריה היבשה ומעוניין לדעת כיצד לממש את התיאוריה בפועל. דוגמאות של בעיות ומקרים בהם מתלבטים מנהלי פרויקטים ב"עולם האמיתי" בליווי פתרונות מנומקים או כיווני פעולה מסייעים רבות להבנת החומר הנלמד והטמעתו.

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

ספרים שיכולים להכין למבחני ההסמכה – מבחני ההסמכה של ה- PMI למנהל פרויקטים מוסמך (PMP-Project Management Professional) הינם חלק בלתי נפרד מהסמכה של מנהל פרויקט בחו"ל (בעיקר בארה"ב) והם תופסים תאוצה גוברת גם בישראל (במיוחד בחברות בעלות אוריינטציה אמריקאית או שעובדות רבות עם ארה"ב). היום כבר ידוע שלימוד אך ורק של ה- PMBOK אינו מספק בדרך-כלל ונדרשים ספרים נוספים, קורס הכנה המנוהל ע"י מס' חברות בארץ ו/או ספר הכנה ייעודי למבחן (למשל ספרה המצוין של Rita Mulcahy שמכין למבחני ה- PMP וה- CAPM).  על כן, קיים יתרון גדול בלימוד מספר שהינו גם ספר לימוד של תיאוריות ניהול הפרויקטים, אולם מאפשר בסיומו גם, כערך מוסף,  לגשת למבחני ההסמכה ל- PMP. ספרים אלה בדרך-כלל מלווים בשאלות ופתרונות המייצגים את השאלות במבחן. חלקם אפילו מבצעים קישור בין הפרק בספר לבין הפרק המתאים ב- PMBOK, דבר המאפשר התמצאות טובה בין 2 הספרים.

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

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

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

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

הספר מציג בשפה ברורה וקולחת את כל תיאורית ניהול הפרויקטים תוך מתן דוגמאות רבות. יתרונו הגדול של הספר הינו היותו כתוב בעברית, זהו יתרון לא מבוטל, במיוחד למי שהשפה האנגלית לא שגורה בפיו ועדין רוצה לשלוט ברזי תורת ניהול הפרויקטים. חסרונו של הספר שהוא סובל, לטעמי, מאקדמיות יתר וכתוב בצורה פחות קולחת, ועם חישובים רבים, דבר שמקשה על קריאה שוטפת שלו ומתאים יותר לסטודנטים בתחום. כמו כן, שלמרות היותו ספר מקיף, לא ניתן להסתמך עליו כספר יחיד ללימוד תורת ניהול הפרויקטים ומומלץ להצטייד בספר נוסף, במיוחד אם רוצים לגשת לבחינת ה- PMP.

 

 

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

 - את הספר "להיות מנהל פרויקט" של חמוטל וייס ודניאל ציטר קראתי מכריכה לכריכה ונהניתי! הספר מחולק ל- 3 פרקים עיקריים: תכנון, בקרה ותקשורת.

Book2הוא מעודכן בחידושים בתחום, קל לקריאה, צבעוני ומאיר עיניים. הספר אינו ספר מתודולוגי (לא מתמקד בלהסביר את התיאוריה) אלא מתמקד יותר במשימות שמנהל הפרויקט צריך לעשות על מנת לנהל את הפרויקט. כספר בסיסי למנהל הפרויקט המתחיל זה ללא ספק ספר מצוין, מה שגם שבאתר של כותבי הספר (http://he.beingaprojectmanager.com/) ניתן להוריד ללא תשלום טפסים, תבניות ומסמכים שונים אשר יכולים לשמש את מנהל הפרויקט בעבודתו. 

הספר קיים גם באנגלית, לכאלה שרוצים ספר ידידותי לניהול פרויקטים ונדרשים להכיר במסגרת עבודתם דווקא את המושגים הלועזיים בניהול פרוייקטים (למסתפקים בעברית – בסוף בגרסה העברית, קיים מילון מושגים בסיסי של מושגי ניהול פרוייקטים באנגלית).הספר מתרחק ממתודולוגיה, כך שהוא קל יותר לקריאה אבל משאיר תחומים שונים שאינם מכוסים בספר (ניהול בעלי עניין, ניהול איכות, ניהול משאבים וכן מיומנויות רכות למיניהן- אשר אזכורים שלהם אולי מפוזרים בספר אולם אינן מרוכזים ומוסברים באופן מיוחד). הדבר לא מאפשר למנהל הפרויקט שרוצה להיבחן לבחינת ה- PMP להסתמך על הספר הזה לבדו. את הספר מלווים גם  מספר קטן של דוגמאות (Study Case) וכולי תקווה שבמהדורות עתידיות יינתן מקום לדוגמאות רבות יותר וסבוכות יותר על קשיים שמנהל הפרויקט עשוי להיתקל בהם, דוגמאות על פרויקטים שכשלו/הצליחו ופתרונות שונים שמנהל הפרויקט יכול להשתמש בהם.

 - ספר חדש נוסף בעברית הינו סיפרה של פנינה זינגר "ניהול פרויקטים The Practical Approach ", גם ספר זה מתמקד יותר במתן כלים פראקטיים למנהל book 3הפרויקטים בעבודה היומיומית של ניהול הפרויקטים ופחות במתודולוגיה. ניתן למצוא את הספר גם בקישור הבא: http://www.projects.org.il/ניהול-פרויקטים-the-practical-approach.  הספר מכיל 3 פרקים עיקריים- פרק תכנון, פרק ביצוע, מעקב ובקרה ופרק מיומנות רכות והוא מתובל בעשרות דוגמאות של עשה/אל תעשה ורשימות תיוג ("צ'ק-ליסטים") אשר לפי דעתי נותנים לו ערך מוסף ייחודי. פרק מיומנות רכות הינו פרק חיוני מאד לכל מנהל פרויקט מתחיל ואהבתי את המקום המרכזי שקיבל בספר הזה. גם הספר הזה, כמו הספרים הקודמים שתוארו לעיל, אינו יכול לשמש כספר הכנה למבחן ה-  PMP או ה- CAPM (הוא אינו מקיף את כל הנושאים הנדרשים למבחנים) והוא קצת פחות מסודר ומתודי מספרם של וייס וציטר, מה שמקשה על מנהל פרויקטים, לאחר שקרא קריאה ראשונה של הספר, לחזור ולהתעמק בנושא מסוים. אין בספר רשימת מושגים באנגלית או אינדקס שמאפשרים גישה קלה לנושא מסוים.

סקר קצר שערכתי בין עוקבי הבלוג שלי ומשתתפי קבוצות הלינדקין בעברית שמתעסקים בניהול פרויקטים גילה שהספרים החדשים מוכרים על ידי מנהלי הפרויקטים בארץ, ומקבלים מקום של כבוד לצד ה- PMBOK וספרם הותיק של שטוב וגלוברזון.

לסיכום – אהבתי את קפיצת המדרגה שעברה ספרות ניהול הפרויקטים בעברית ושהספרים החדשים מדברים בשפה נגישה ומחוברת לאנשים ולא בשפה אקדמית. אני חושב שמנהלי פרויקטים מתחילים ומי שרוצה להיכנס לתחום, יעדיף לקרוא ספר בעברית, שהיא שפה יותר נגישה עבורם. הספרים לא יכולים לשמש כחומר בלעדי לבחינות ה- CAPM או ה- PMP אבל בהחלט מקיפים את מירב החומר שמנהל פרויקט מתחיל צריך בשביל לנהל פרויקטים קטנים ובינוניים ויכולים לשמש כקפיצת מדרגה למי שרוצה להמשיך בתחום ולהתמקצע.

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

גיא שלפר  PMP, PgMP, PfMP

מנהל פורטפוליו, משרד הביטחון

www.ThePMGuy.com

ליצירת קשר : This e-mail address is being protected from spambots. You need JavaScript enabled to view it.

פייסבוק : https://www.facebook.com/thepmguy

גוף הידע בניהול פרויקטים – גרסה 6 ממש כאן! 

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

PMBOK

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

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

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

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

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

Talent Traiangle

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

פרוט השינויים

עשרת הפרקים העוסקים בתחומי הידע בניהול פרויקטים עברו "מתיחת פנים", כאשר כל פרק כולל בפתיח שלו הסבר נרחב על:

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

לב ליבם של הפרקים נשארו תהליכי ניהול הפרויקטים אשר מורכבים מה- ITTO : ראשי תיבות של קלטים לתהליך (Inputs) , טכניקות וכלים (Tools and Techniques) ופלטים מהתהליך (Outputs). ה- ITTO עברו רוויזיה על מנת ליצור אחידות לכל אורך המסמך ומובנות גדולה יותר למשתמש. לדוגמה, כל מסמכי הפרויקט הרלוונטיים אוחדו תחת "מסמכי פרויקט" בקלטים לכל תהליך, כלים שונים המשמשים לאיסוף מידע, במקום להיות כלים נפרדים, אוחדו לתת פרק אחוד "איסוף מידע" בכל תהליך וכדומה. בנוסף, התווסף נספח המכיל פירוט על כל הכלים והטכניקות שבשימוש בתוף גוף הידע.

השינויים העיקריים בפרקי תחומי הידע מפורטים להלן:

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

פרק ניהול התכולה – עיקר השינויים הינם ביצירת הבחנה בתפקידים של מנתח עסקי (פונקציה חדשה ש- PMI נותן לה חשיבות ואפילו גוף ידע משלה)  ומנהל פרויקטים וכיצד הם עובדים יחדיו.

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

פרק ניהול העלויות – נשאר ללא שינוי.

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

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

פרק ניהול התקשורת  -  הורחב על מנת לכלול גם רשתות חברתיות ומיומנות תקשורת חדשות.

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

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

פרק ניהול בעלי עניין – עיקר השינויים בתוספת של כלים וטכניקות חדשות.

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

 

גיא שלפר  PMP, PgMP, PfMP

מנהל פורטפוליו, משרד הביטחון

www.ThePMGuy.com

ליצירת קשר : This e-mail address is being protected from spambots. You need JavaScript enabled to view it.

 

הסתירה המובנית (Dissonance) של ניהול הפרויקט

 

פרויקטים מותנעים ומבוצעים בארגונים, כאמצעי להשגת ערך מוסף ותרומה למען מטרה מוגדרת.Disonance

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

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

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

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

תעשיות רבות ושונות המייצרות מוצרים ושירותים (כגון: טלקום, IT, תוכנה וחומרה, כלי רכב, בניה, פרמצבטיקה וכו')מתבססות במוקד פעילותן על פונקציית מנהל הפרויקט.

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

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

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

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

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

 

איך עושים זאת נכון?

זו אינה תעלומה. הספונסר של הפרויקט, המשקיע את הכסף של הארגון למאמץ מוגדר ונתון, שואף להשגת הערך המוסף שאותו הוא מבקש, בהסתברות המקסימלית.

יש להחיל את הדברים הבאים:

1. הגדרת תפקיד מנהל הפרויקט כתפקיד ניהולי ומנהיגותי בארגון.

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

3. הדרכה שוטפת לאוכלוסיית מנהלי הפרויקט על מנת לאפשר קיומה של זרוע ביצוע מעורה ועדכנית המסוגלת לענות על

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

4. מיון ובחירה של האנשים הטובים ביותר בארגון המתאימים להוביל מאמץ נתון. הפעלת "מסנן" לפני מינוי של אדם לתפקיד

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

    לבדיקת התאמה של אותו אדם על ידי הארגון.

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

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

6. שמירה על שביעות רצון גבוהה של אוכלוסיית מנהלי הפרויקט בארגון, שכן הם הגורם המבדיל (Game changer) בין

    השגת הערך המוסף הנדרש ואי השגתו.

 

להלן מספר דוגמאות:

  • הגדרת מסלול קידום בחברה, יחד עם ארגון ה-HR, שבו חובה להוכיח הישגים מוצלחים של ניהול פרויקטים כדי להיות מועמד לקידום (בעיקר בארגונים שבהם פרויקטים הם "קו הייצור" של העסק כמו בארגוני פיתוח מוצר או ארגוני שירות).
  • מנהל הפרויקט נותן לבעלי העניין בפרויקט ציונים על תפקודם בפרויקט. שקלול ציונים אלו כקלט משמעותי במסגרת תהליך ההערכה השנתית של עובדים בארגון. (יושרה ואתיקה הם אחד ממבחני ההתאמה שמנהל הפרויקט צריך לעבור טרם קבלת הפרויקט, כדי למנוע מצב של שימוש לא מושכל בכוח).
  • מנגנון להצגת תמונת מצב המשקפת את ביצועי הפרויקט להנהלה הבכירה (KPIs - אבני דרך, תקציב, היקף...). מנגנון כזה, מפתח תלות חזקה בין מנהלי הפרויקטים להנהלת הארגון (מהווה מכשול כאשר הפרויקט לא עומד ביעדים).
  • בארגונים בהם פרויקטים הינם חלק מעסקי הליבה - יש לשים את המיקוד הנכון על מנהל הפרויקט ולהגדיר את שאר הפונקציות בארגון כ"פונקציית שירות", הנותנות שירותים למנהל הפרויקט. משמעות הדבר היא כי ההנהלה הבכירה דורשת דין וחשבון בראש ובראשונה ממנהל הפרויקט, אולם תובעת גם אחריות מפונקציות השירות השונות התומכות המנהל הפרויקט (במידה ומנהל הפרויקט מדווח על שיתוף פעולה לקוי או שירות שאינו משביע רצון מצד פונקציות אלה).
  • קביעת פונקציה מרכזית בארגון (CPO-Chief Program/Projects Officer) הקובעת את מדיניות ניהול הפרויקטים. כיצד פרויקטים מתוכננים, מבוצעים ומבוקרים בארגון. לפונקציה זו תהיה אחריות וסמכות להגדיר מדיניות לגבי מתודולוגיית ניהול הפרויקט בארגון. כלומר, מתן כלים כדי להסביר כיצד הפרויקט מנוהל (בהיבט התהליכי) ובנוסף כיצד לנהל ולהציג את תוצאות הפרויקט בפועל. פונקציה זו תסייע בהגדרת ה- KPIs שהוזכרו לעיל.
  • דבר אחרון, מנהל הפרויקט, כפונקציה "משנה משחק" בעמדת הנהגה, ראוי ליהנות מהטבות סוציאליות נאותות, שכן הצלחתו קשורה ישירות לתוצאות העסקיות של הארגון

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

 

בועז עוגן, PMP

This e-mail address is being protected from spambots. You need JavaScript enabled to view it.

אתגר ניהול הדרישות בעולם האג'ילי

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

בחזרה בזמן, בעולם ה Waterfall הכללים היו מאד ברורים ופשוטים –
בתחילת הגרסה, אנשי המוצר היו לוקחים פרק "זמן נכבד" בכדי לאסוף את המידע הרלוונטי ולבנות את מסמכי הדרישות. זמן נכבד נוסף היה מושקע ב"עיכול הדרישות", התאמות/הבהרות נדרשות, וכיו"ב אל מול בעלי העניין
למעשה, שלב הפיתוח לא החל לפני ששלב הדרישות הסתיים, אך משהחל – התלות שלו במנהלי המוצר הייתה נמוכה וזאת תוך שהוא מתבסס על כך שהדרישות לא ישתנו במהלך הפיתוח.
 
במעבר לאג'ייל העניינים החלו קצת להסתבך -
התבנית הפופולרית ביותר שאומצה (Scrum) התמקדה ברמת הצוות, הדרישות הפכו ל Backlog Itemsוהצוות נדרש להתמקד בספרינט אחד בכל פעם. אך ראייה צרה זו אובחנה מהר מאד כחלקית, שכן חסרה את הראייה הרחבה בכל מה שקשור לגרסאות גדולות של תכולה. דבר זה יצר אתגר לא פשוט עבור מנהלי המוצר
מקורו של אתגר זה הוא במספר כוחות אשר דוחפים את הנושא לכיוונים שונים -
אנשי הפיתוח בצוותי האג'יל – אלו הם אנשי ה R&D של הצוותים.
אנשי צוות אלו דוחפים לקבל את דרישות התכולה הבסיסית בהקדם האפשרי, וזאת על מנת
לאפשר להם לתכנן ארכיטקטורה, POC, שלבי design, וכו' ברמה מוקדמת כמה שיותר
לפני תחילת הספרינטים.
אנשי הבדיקות בצוותי האג'ייל – אלו הם אנשי ה QA של הצוותים.
אנשי צוות אלו דוחפים לקבל את דרישות התכולה ברמת פירוט רחבה כמה שניתן,
וזאת על מנת שיוכלו לייצר תסריטי בדיקות מלאים, ווידוא כיסוי מלא של פונקציונאליות, וכיו"ב
גם הם שואפים להיות מוכנים ברמה כמה שיותר יסודית לפני תחילת הספרינטים.
אנשי צוות המוצר – אלו הם אנשי הצוות אשר כותבים בעצמם את דרישות המוצר
אנשי צוות אלו דוחפים לשחרר את דרישות התכולה ברמה "מספקת" בהקדם  מתוך התובנה שככל שתהליך הפיתוח יחל מוקדם יותר, כך ישנו סיכוי שיותר תכולה תספיק להיכנס לגרסה.
 
התגברות על האתגר
אחד הדברים היפים של מתודולוגיית אג'יל הינו שהיא לא רק מאפשרת גמישות, אלא שהיא
בעצמה גמישה מאד בצורת ההטמעה שלה.
יכולות להיות עשרות ואף מאות צורות שונות של הטמעת המתודולוגיה בארגונים שונים, כל ארגון בהתבסס על הצרכים שלו, על האילוצים שלו, ועל היכולות שלו.
מסיבה זו, הגישה שאציג תישאר גם היא ברמה הבסיסית, ותספק גמישות בהטמעה.
שלב ההתכנות
השלב הראשון והחשוב ביותר נקרא שלב ההיתכנות.
בשלב זה מוודאים אנשי המוצר את ההיתכנות של הדרישות החדשות לא בסופן, אלא תוך כדי הכתיבה. עבודה זו נעשית בעיקר מול אנשי הפיתוח ומאפשרת קבלת פידבק מהיר על היתכנות הדרישות, משמעות ראשונית ברמת המוצר, והנחיות מצד אנשי הפיתוח לאזורים שבהם הם מצפים לקבל הגדרות.
למעשה, נוכל להסתכל על שלב זה בצורה בה אנשי הפיתוח הם הלקוח של אנשי המוצר, אשר מספקים להם את הדרישות. 
מעגלי פידבק מהירים, וסנכרון עם הלקוח – הלא הם בבסיסו של האג'יל מניפסטו.
יצירת מסגרת
השלב השני, הינו שלב יצירת מסגרת הדרישות.
כפי שציינתי בתחילת המאמר, ישנו הכרח להבנת ההקשר (context) הכולל של הדרישות. אנשיי צוות הסקראם חייבים להבין את התמונה המלאה -  הפונקציונאליות העיקרית הנדרשת, לפני שייצאו לדרך. הדבר ישפיע על הארכיטקטורה של הפתרון, על תפיסת הבדיקות וכיו"ב.
דבר זה נעשה ע"י יצירת ראשי פרקים לדרישות הכוללות -  אלו הם ה Backlog Items של הדרישות אשר נקראות בעולם האג'יל - Epics.
יצירת Flow Scenarios
השלב השלישי הינו שלב המעבר על התרחישים המרכזיים.
גם כאן, מתוך הצורך בהבנה נכונה של התמונה המלאה של הדרישות, וסנכרון בין כוונת אנשי המוצר לאנשי צוות הסקראם - מבצעים מעבר על התרחישים המרכזיים עוד לפני שהחל שלב הפיתוח. הצורה החזקה ביותר הינה ע"י ויזואליזציה של התרחישים (wireframes). 
מסכים אלו משמשים את הצוותים לאחר מכן כ reference לכל אורך הגרסה.
הרחבת רמת פירוט הדרישות
השלב הבא מתייחס להרחבת רמת הפירוט של הדרישות.
אם עד כה התמקדנו בראשי פרקים ובמסגרת, עתה נדרשת הרחבה של רמת פירוט הדרישות, אשר תאפשר לצוות הסקראם לייצר את התכולה הנדרשת. ככלל אצבע על מנת להבטיח שצוותי הסקראם לא ימתינו לדרישות - דרישות "מורחבות" צריכות להיות מוכנות כ 1-2 ספרינטים מעבר לספרינט הנוכחי.
שינויים וסגירה של תכולה
שתי הערות אחרונות קשורות לנושא ניהול שינויים, וסגירה של התכולה. מתודולוגיית אג'יל נוצרה כמובן מתוך הצורך לתמוך בשינויים, ואך טבעי הוא שמנהלי המוצר יאהבו גמישות זו. יחד עם זאת חשובה ההבנה שישנו מחיר להכנסת השינויים, מחיר זה יתבטא ביכולת לסיים את שאר הדרישות שנותרו עד המועד המתוכנן. הדרך הנכונה לבצע זאת הינה ע"י התייעצות עם צוותי הסקראם בדבר העלות הצפויה המוערכת של השינויים, לפני קבלת ההחלטה.
המשך ישיר אשר קשור לנושא הינו סגירת תכולה (החל מרמת PBI). מתודולוגית אג'יל מתבססת על התקדמות ע"ב ערך (Value). התקדמות זו הינה אפשרית רק כאשר ניתן לאשר תכולה חלקית, לחתום אותה, ולהמשיך הלאה. יכולת זו צריכה להיות מובנת ולהתאפשר ע"י מנהלי המוצר.
 
שורת סיכום
ניהול דרישות נכון בעולם האג'ילי מחייב איזון בין  רבדים שונים – עליו לספק מסגרת ברמה המוקדמת ביותר שניתן ע"מ - לזהות מכשולים, לבחון תאוריות, ולתעדף נכון את סדר התכולה.  עליו לספק את רמת הפירוט הנדרשת בזמן הנדרש, עודף רמת פירוט עלול להפוך ללא יעיל כאשר לא כל התכולה תיכנס למסגרת הזמן שהוקצב. ולבסוף – ניהול השינויים בדרישות צריך להיות בצורה חכמה, לתזמן אותו בזמן הנכון ובכמות הנכונה תוך הבנת המשמעות על הגרסה כולה.
 
 
Profile Image
 
יוגב טל, עורך המגזין
מנהל פרויקטים בכיר (PMP) בחברת Observeit
Agile / Lean Coach
Email: This e-mail address is being protected from spambots. You need JavaScript enabled to view it.