מהו ניהול פרויקט היברידי ואיך תוכלו ליישם אותו בפרויקט שלכם?
על שילוב בין אג'יל וניהול פרויקטים קלאסי, בחיפוש אחר מתודולוגיה "אחת" (אם היא בכלל קיימת…) –
מבוסס על מאמר שהתפרסם ב MPUG (1) ושיחות עם מנהלים המנסים לגשר על הפער
'אג'ילי' היא מילת באזז פופולארית בניהול פרויקטים ומגמה מתרחבת בארגונים רבים עם סיפורי הצלחה, וגם אכזבה. המושג "אג'יל" בהקשר פרויקטאלי, נולד בעולם התוכנה, אולם הגישה מיושמת בארגונים שונים, אם כי אינה מתאימה לכלל התעשיות. "אג'יל" או בתרגמו העיברי, זמיש, מתייחס כאן בערבוביה לשני מושגים: מחד גישת חשיבה גמישה המכוונת את מי שפועל לפיה לתגובה מהירה, ומאידך, מתודולוגיה ושיטה סדורה לניהול פרויקטים. נזכיר כדוגמא את Scrum, Scrum XP, DSDM, ועוד.
השיטה האג'ילית רווחת בפרוייקטי מחקר, פיתוח תוכנה, IT ושיווק (3). ולאורך השנים התחדדו נקודות בהן השיטה אינה נותנת מענה מספק, בעיקר בנוגע לחיזוי ותכנון קדימה. איך משלבים כשיש צורך ב "גם וגם"? על כך מנסה לענות המאמר שלפניכם.
ניהול פרויקט אג'ילי – לא תמיד הגישה המנצחת
על אף הפופולריות של השיטה האג'ילית, ישנם מי שמוכנים לומר שהשימוש בה מוגבל. נקודות הקושי, כמובן לצד החוזקות והתועלות, עולות למשל כאשר המוצר מורכב מחומרה ותוכנה, או כשנדרשת אינטגרציה רחבה הכוללת רכש ועוד היבטים לוגיסטיים, כאשר יש חוזה המחייב דיווח על תאריכי יעד, ועוד מקרים אמיתיים איתם מתמודדים ארגונים.
הקושי נעוץ בכך שלקוחות, משקיעים, ספונסרים ובעלי עניין מבקשים לקבל תחזית, ואת זה השיטה האג'ילית אינה מספקת. מדובר בשיטה לא מתחייבת בכל הקשור לסיום הפרויקט בהיבטי זמן או תקציב. למעשה, בשיטה האג'ילית לא מתחייבים כלל לסיים את "המוצר". הפער עולה כאשר בעלי השפעה בארגון יתקשו לקבל את אי הודאות המובנית, וידרשו תשובות לגבי צפי סיום הפרויקט או היקף ההשקעה הכוללים.
כל זה לא אינו מעיד כי השיטה האג'ילית אינה טובה; ניהול אג'ילי מתאים במצבים בהם הידע מצומצם (למשל, סביבות מחקר ופיתוח), או כשלקוחות מתקשים לנסח דרישות. כאן השיטה מתגלה כמועילה מאוד, מובילה תהליך למידה תוך כדי פעולה, ועוזרת לייצר ידע חדש.
גישה היברידית – השאלה, היברידי עם מה?
יותר ויותר ארגונים העובדים בשיטה אג'ילית, מעידים כי הם משלבים בתהליכי העבודה עוד שיטות ניהול "משלימות", כמענה לצורך מהשטח. המחשבה הראשונה שאולי עלתה אצלכם היא שילוב שיטת המפל; כלומר, לייצר תכנון של כל שלבי הפרויקט, ולשלב סבבים אג'יליים בתוכם. מאחר ושיטת המפל הפוכה כמעט מהגישה האג'ילית, נוצרות סתירות המקשות על היישום, כפי שמעידים מי שניסו את השילוב. כאן מתגלה תובנה אחרת כהיברידיות יעילה, אולי מעט מפתיעה: שילוב הגישה האיג'ילית וטכניקת הנתיב הקריטי.
הנתיב הקריטי (Critical Path), הוא כלי בניהול פרויקטים המסתכל על שרשרת הפעילויות החשובות התלויות זו בזו בפרויקט, באופן שכל שינוי בתאריך אחת הפעילויות יגרום לשינוי במועד סיום הפרויקט(2). אם מתבצעות בפרויקט פעולות לא תלויות במקביל, יכולים להתקיים מספר נתיבים, כאשר הנתיב הקריטי יוגדר להיות הנתיב הארוך ביותר בפרויקט.
בשונה מהשיטה האג'ילית, הנתיב הקריטי מנבא סיום פרויקט בצורה ברורה, ולכן שילוב שני הכלים מאפשר מחד עבודה בשיטה גמישה, ומאידך יצירת לו"ז מוגדר. כך אפשר גם לנהל את הצוות על פי עקרונות אג'יליים, וגם לעבוד מול מנהלים, לקוחות ובעלי עניין עם מסגרת לוחות זמנים, תחזית ותקציב שעונים על הצורך ומצמצמים את אי הודאות.
אג'יל ונתיב קריטי – שניהם יחד בלו"ז אחד – איך עושים את זה?
נשמע פחות טבעי? בהחלט אפשרי, אם כי דורש כמה התאמות ופשרות. לצורך השילוב, יש לתת מענה למספר נקודות. הרעיון הוא לייצר "תרגום" שנותן לארגון בסיס טוב לקבל החלטות ניהוליות, ולצוותים המשך עבודה אג'ילית. זה אולי ייתפס כפשרה עבור מי שבא מהצד האג'ילי של הדברים, אולי להיפך. כך או כך, זוהי פרקטיקה שעובדת. "דרך אמצע" אם תרצו. וגם אם לא תאמצו אותה, מוצגת כאן דרך פעולה שונה שאולי תפתח ערוצי חשיבה אחרים.
נקודה 1: WBS
כדי לנתח נתיב, צריך למפות ראשית את התכולה הידועה. ניהול התכולה בפרויקט אג'ילי נעשה למעשה על ידי חלוקה של המשימות או סיפורי הלקוח לסבבים השונים (ספרינטים), יחד עם Backlog למשימות שטרם שובצו. לעומת זאת בפרויקט קלאסי, נבנה עץ תכולה (WBS) המחלק את התוצרים במבנה היררכי. כדי לאפשר שימוש בשתי השיטות חשוב לייצר מצב בו ניתן לראות את כלל התכולה. לכן, כל משימה "אג'ילית" חשוב שתתויג (בין אם בספרינט או ב )Backlog. עד כאן, סביר ולא מאוד מסובך.
נקודה 2: משך
רמת הסיבוך כבר עולה. הגישה האג'ילית מדגישה את עצמאות הצוות לטפל במשימות מקצה לקצה, תוך שיתוף והיכרות המקדמים את יעילותו ויכולתו לייצר תוצרים (Velocity) – אין התייחסות למשך הזמן של המשימה, הצוות מגדיר תכולות לספרינט ומבצע אותן יחד. מאידך, לחישוב נתיב קריטי חייבים משך. ברוח הפשרה יש למצוא דרך "לתרגם"; על בסיס ההערכה האג'ילית (נקודות), ולפי גודל הצוות, מגדירים פקטור חישובי למציאת משך. למשל: עבור 4 אנשי צוות, וספרינט של שבועיים (נניח 40 שעות בשבוע לעובד) הכולל 200 נקודות ß כל נקודה תהייה שוות ערך ל 1.6 שעות. ניתן כמובן לעדכן ולהתאים את הפקטור לפי הצורך. פשרה, כבר אמרנו?!
נקודה 3: לקשור או לא לקשור?
עוד נקודה מורכבת. בגישה האג'ילית לא מקובל לייצר או לזהות תלויות בין משימות. מאידך, יצירת שרשת קריטית מחייבת זיהוי הקשרים הללו. לכן, שוב – מתפשרים. הצוות מסייע לזהות את התלויות בין המשימות והתכולות, כך שמי שאחראי על הניתוח יכול לבנות מודל. עם זאת, הצוות לא נדרש לנהל אותן.
ניהול פרויקט היברידי – לסיכום
הגישה ההיברידית המוצגת כאן, מאפשרת שילוב בין שתי גישות ניהול מצוינות, מה שיכול בהחלט לתת מענה ארגוני לקשיים העולים מ ניהול פרויקטים אג'ילי בלבד. כמובן שיש לממש את העקרונות הללו בתוכנה המתאימה, וזה כבר עניין טכני לפעם אחרת (מוזמנים לפנות אלינו ונשמח לסייע). דרך האמצע המוצגת, מאפשרת למנהלים ראייה מתכללת, ולצוות עבודה גמישה. זוהי גישה שעונה על כאבים ארגוניים יומיומיים, ואשר בעזרת חשיבה קצת אחרת, נכונות וכמה פעולות תרגום שאינן מורכבות מדי – מציעה פתרון אפשרי, או לפחות הצצה על דרך חשיבה שונה.
רפרנסים:
(1) https://www.mpug.com/waterfall-should-have-never-existed-part-1/
(2) https://www.hcp.co.il/critical-path/
(3) https://www.qagile.pl/wp-content/uploads/2020/06/14th-annual-state-of-agile-report.pdf
