מדוע פרויקטים נכשלים והאם אפשר למנוע זאת?
גויקו אג'יץ', גורו עולמי לנושא אג'ייל והתנהגות ארגונית, מנה בכנס אג'ייל של אנשים ומחשבים את הסיבות שבגינן שליש מהפרויקטים לא מגיעים לסיומם או, חמור מכך, מתגלים כלא יעילים לאחר סיומם
גויקו אג'יץ', גורו עולמי לנושא אג'ייל והתנהגות ארגונית, התארח היום (ג') בכנס אג'ייל של אנשים ומחשבים, והיה אחד מדוברי המפתח באירוע. בדבריו הוא התייחס לנתון מוכר בעולם הפרויקטים: שליש מהם נכשלים, לא מגיעים לסיומם או, החמור מכל, מתגלים לאחר תקופה כלא יעילים, על אף שהושקעו בהם כספים רבים. הדובר הביא שורה של דוגמאות מפרויקטים גדולים שנכשלו בגלל סיבות שונות.
הדוגמאות הללו מוכיחות שאנחנו, בישראל, לא לבד. הסטטיסטיקה נכונה גם פה, ואצלנו, מאחר שאנחנו מדינה קטנה יחסית, כל כשלון של פרויקט מהדהד בווליום ענק ומקבל כותרות ענק. הסיבות הן די דומות: בדרך כלל פרויקט נופל בגלל פער בין ציפיות הלקוח למה שיכול לתת הספק, או, יותר נכון, להבטחות שהוא מפזר ללקוח. במקרים רבים, הפתרון שהוצע ללקוח לא ממש התאים לו, והספק לא היה מספיק ערני כדי להתריע או לבצע את השינויים.
סקר של ארגון PMI העולמי שנערך בשנה שעברה אישש את העובדה הידועה, שלפיה העדר שיתוף פעולה מספיק בין הביזנס ל-IT מביא בדרך כלל לתוצאה שלא מתאימה ללקוחות הסופיים, ולהפיכת המוצר לפיל לבן.
על פי רוב, הדברים מסתיימים שם ולא מגיעים לבית המשפט. מספר הארגונים שמגישים תביעות נגד ספקים על מוצר שלא ממש הוכיח את עצמו הוא יחסית מועט. הם נרתעים לעשות זאת משום שהמשמעות היא שהארגון נכשל בבחירת הספק או הפרויקט, ובזה אף אחד לא רוצה להודות.
האם האג'ייל ימנע כישלונות בפרויקטים?
תפיסת האג'ייל מסתמנת, על פי ההמלצות של מנהלי הטכנולוגיות, כאחד הפתרונות שעשויים לצמצם את אחוז הכישלונות בפרויקטים. המאפיין המרכזי בתפיסה זו הוא אוטומציה מוגברת בכתיבת הקודים של התוכנות המהוות בסיס לפרויקט, לצד יישום מתודלוגיית ה-DevOps. שתיהן ביחד נותנות מענה לאחת הסיבות העיקריות לכישלון פיתוח תוכנה: טעויות אנוש של כותבי קודים, או, במילים אחרות, הגורם האנושי.
אג'יץ' הזכיר שלוש פעולות שבעזרתן ניתן לצמצם את שיעור הכישלונות בפרויקטים: האחד הוא הגברת הבקרה בזמן אמת. הכוונה היא לייצר כלים ולהשתמש בהם, כמו כלי אנליטיקה, כלי בקרה ומערכות דיווח. ככל שמקדימים לאתר את הכישלון, כך מונעים אחר כך את הוויכוחים. דבר נוסף שצריך לעשות הוא: לעולם לייצר חלופה לפרויקט. אין כמעט דבר כזה שיש פתרון אחד לאתגר או לפרויקט. ככל שהפרויקט הוא קריטי ונוגע ליותר אנשים, חובה שתהיה במגירה תכנית ב', שזמינה להפעלה רגע אחרי שמגיעים למסקנה שהחלופה הראשונה נכשלה. זה דבר שמעט מאוד ארגונים עושים.
הדבר השלישי שניתן לעשות על מנת למנוע כישלונות נוגע לגורם האנושי: הן הלקוח והן הספק צריכים לוודא שהפרויקט אמנם מתאים ללקוח ושהספק יכול להתחבר אליו, להיות חלק ממנו ומחויב אליו. בכך נוצרת שותפות אמת בין שני הצדדים, שמבוססת על שקיפות ועל תיאום ציפיות. זה לא אומר שלא יהיו משברים, אבל כשמערכת היחסים טובה ומבוססת על אמון, גם המשבר החמור ביותר מגיע לידי פתרון. קרוב לוודאי שאחת הסיבות המרכזיות לתביעות של לקוחות נגד ספקים היא כישלון בקשר האנושי והאישי בין הגורמים הרלוונטיים.
השורה התחתונה: ניהול פרויקט והבאתו לקו הסיום תלויים בהרבה מאוד גורמים, שצפים כל הזמן על פני השטח. שם המשחק הוא היכולת לזהות, לפקח ולתקן במהירות, כדי שרגע אחרי שמרימים כוסית לסיום הפרויקט, כל הוויכוחים והתקלות יישכחו כלא היו.
תגובות
(0)