בעקבות אירוע | אג'ייל? גם בבית ספרנו
אם מנהל פרויקטים, תוכניתן, או אפילו רפרנט שיווק בבית תוכנה ממוצע יידרש להטמיע עקרונות Agile בעבודתו, הוא יבין – ולו חלקית – במה דברים אמורים. אם תפנו בדרישה זהה למהנדס אזרחי, לעומת זאת, ותציעו לו לעבוד אג'ילית, הוא יחשוב שהגעתם אליו מהירח. תורת ה-Agile, הדוגלת בגמישות מחשבתית, ב'ראש פתוח' ובהרבה הגיון בריא, התפתחה דווקא בעולם התוכנה, הידוע כעולם סכמטי ונוקשה. דווקא מתוך הנוקשות (ואולי כתוצאה ממנה), חל בעשור האחרון שינוי מחשבתי, אשר הביא לנכונות מצד ארגונים בינוניים וגדולים להטמיע את התורה ולסטות משיטות העבודה המסורתיות.
כנס PMI השנתי, שהתקיים השבוע, התאפיין בריבוי מנהלי פרויקטים שאינם דווקא מתחום ההייטק, אלא מתחומים יצרניים ופרויקטליים – תשתיות, בניה, תחנות כח ועוד. דווקא הם, המחויבים לפעול בנוקשות תקציבית ולהקפיד על לוחות הזמנים שנקבעו, גילו עניין ב-Agile ותהו בינם לבין עצמם מדוע לא הגיעו מתודולוגיות אלו גם אליהם.
ובאמת, למה לא? האם פרויקטים קשיחים, שאינם מתחום התוכנה, אינם יכולים להסתייע באג'ייל?
נכון, בפרויקטי תוכנה ניתן לעשות שימוש מיטבי במתודולוגיות ה-Agile וליהנות מיתרונותיה המובהקים של השיטה. עם זאת, ייתכן מאד שגם בפרויקטי תשתית הגיע הזמן להטמיע צורות חשיבה, סגנונות התנהגות וכלי ניהול שיקלו על כאבי הלידה והצמיחה של מנהלי הפרויקט ומבצעיו. הרעיון, למעשה, הוא פשוט: לקחת תהליכים בתוך הפרויקט ולהחיל עליהם מתודולוגיות אג'יליות.
ניקח לדוגמה את שלב הדרישות בפרויקט – ללא קשר לשאלה האם מדובר בתחנה גרעינית, תוכנה חדשה או משחק לפייסבוק. עפ"י השיטה הנהוגה כיום, מנהל הפרויקט יכול להכין במשך שבועיים מסמך דרישות מפורט לקבלן המשנה, לקבל תגובה מפורטת לאחר כשבוע, להכניס שינויים בהתאם – וכבר חלף לו חודש. אם נאמץ, לעומת זאת, את הגישה האיטרטיבית, ניתן לחלק את התהליך למקטעים קצרים יותר, איטרטיביים ושיתופיים. מנהל הפרויקט ישקיע מספר ימים מועט יחסית למסמך הראשוני (שעליו כבר ניתן להגיב), קבלן המשנה יגיב גם הוא תוך ימים ספורים בלבד – וכשמנהל הפרויקט "יתכוונן" ויכין מסמך עדכני ומפורט בהתאם לתגובות, יגדלו הסיכויים שיקלע למטרה ויציג מסמך הגיוני ונכון יותר.
בנוסף, מכיוון שמוטיבים אג'ילים רבים ישימים הן בצד "הרך" של ניהול הפרויקט והן בצד "הקשיח" והמדיד שלו, ניתן להטמיעם גם בפרויקטים מעולמות תוכן שונים. לדוגמה:
תקשורת שוטפת – קשר בינאישי רציף ושיתופי יוביל בהכרח לתיאום ציפיות מוצלח יותר ולמניעת קונפליקטים פוטנציאליים (בין אנשי הביצוע השונים ובין הספק ללקוח).
תגובה לשינויים – "שועלי פרויקטים" ותיקים מעידים, כי נוקשות ללא גמישות היא בעוכריו של הפרויקט – וכי פרויקטים רבים נעצרו וניזוקו ללא יכולת זו.
הדגמה מתמדת של תוצרים – עיקרון זה יבטיח כי במועד סיום הפרויקט, התוצאה שתתקבל תהיה משביעת רצון וכי לא יתגלו ליקויים בלתי-צפויים שלא נחזו או נתגלו מראש.
לסיכום: גם אם גישת ה-Agile צמחה מתחום ההייטק והתוכנה, עדיין ניתן ליישם מתודולוגיות רבות גם בתחומים אחרים, ולשפר את הפרויקט ואת יכולת העמידה ביעדיו. אז נכון – לא חייבים ליישם הכל, יש לבחון (בגמישות) איזה עיקרון מתאים לכל פרויקט ואיזה לא – ואין צורך לעשות כל בוקר stand-up meetings באתר קידוח נפט.
ובעצם…למה לא?
