מנהיגים ברשת שולחן העבודה למנהלים בישראל
מאת: אורי אלוני
פורסם לראשונה פברואר 2001
הסטטיסטיקה מראה שרק 37% מפרוייקטים מסתיימים במועד המתוכנן, יותר ממחצית מהם יעלו יותר מן התקציב המתוכנן, וכ- % 40 מהם יבוטלו לפני שיושלמו. איפה אנחנו מפספסים? מר גדי שווץ – מנכ"ל כלנית-כרמון, מתווה נתיב עוקף כשלון:
תהליך פרוייקט לפיתוח תוכנה, הוא היום כמעט קלאסי. הלקוח היוזם בא לבית תוכנה ומבקש לפתח עבורו ישום שיתן לו פיתרון מחשובי לבעייה מסויימת. במקרה הטוב הוא גם מכין מה שנקרא 'מסמך יזום', שבו הוא מפרט את דרישותיו. אולם במקרה הרע – וזה מה שקורה בדרך כלל – הלקוח לא יודע בדיוק מה הוא רוצה. יש לו רעיון, אבל הוא לא יודע לפרט אותו בדרך מקצועית ומובנת למתכנת.
"זה כמו שמישהו בא לקבלן, ואומר לו: אני רוצה שתבנה לי בית ולאחר שהקבלן בנה את הבית, שואל הלקוח: אבל איפה החניה? אומר לו הקבלן: אבל לא אמרת לי שאתה צריך גם חניה, ולכמה מכוניות. שואל הלקוח: ומה עם שער הכניסה לחצר, איפה הוא יהיה? אומר הקבלן: לא אמרת לי שאתה רוצה שער בכניסה ולא אמרת לי היכן בדיוק אתה רוצה את שער הכניסה… בקיצור: הלקוח אפילו לא ידע מה הוא צריך לדרוש…"
ככל שפרוייקט נמשך זמן רב יותר – כך קטנים סכויי הצלחה שלו
כששלב הייזום הסתיים בהצלחה (או לא…) מגיע שלב האפיון. נסו לשאול יזמים ומנהלי פרוייקטים של פיתוח, כמה זמן דורש שלב האפיון. ההערכות יהיו בין 3 ל- 6 חודשים. מה שמעניין הוא שזו בדיוק התשובה הנכונה, מכאן שהזמן הממוצע הוא כ-4 עד 4 וחצי חודשים. לאחר שבית התוכנה השלים את האפיון וכרך אותו בחוברת עבת-כרס – הוא מעביר את החומר ללקוח, כדי שזה יעבור עליו ויאשר, או יעיר את הערותיו.
הסטטיסטיקה מראה שהתהליך הזה בלבד לוקח כחודשיים. מדוע? כי ברוב המקרים הלקוח לא מבין בכלל מה כתוב באפיון, והוא דוחה את הקריאה, ולבסוף חותם על אישור רק משום שלוחצים עליו שהפרוייקט מתאחר. ברוב המקרים הוא עושה זאת מבלי שקרא כלל את החומר. בין כך ובין כך – התוצאה אחידה: חלפו בין 5 חודשים לחצי שנה, ועדיין לא נעשה אפילו צעד ממשי אחד לקראת קו ההתחלה המעשית.
במקום זאת עובר הלקוח לשלב הבא, שהוא שלב העיצוב ותקן המערכת. בדיקה סטטיסטית מגלה שהשלב הזה ימשך חודש עד שלושה חודשים. שכן אם הלקוח לא הבין את מסמך האפיון, שנכתב בסיגנון כללי מאד – אין שום סכוי שהוא יבין את מסמך העיצוב, שנועד לתוכניתנים, ואופיו הרבה יותר טכני. אז בשביל מה המגישים ללקוח מסמך שכזה? כדי שבמקרה הצורך, אם ללקוח תהיה טענה שבדיעבד – אפשר יהיה לומר לו: הנה, אתה בעצמך חתמת!
נתיב המהמורות
התוצאה העגומה המידית היא: הפרוייקט כבר נמשך 7 או 8 חודשים, ולא נכתבה לו אפילו שורת קוד אחת! והנה, במזל טוב, החלה כתיבת התוכנית, ובסיומה היא נמסרת ללקוח כדי שזה יכול להריץ את כל התסריטים הנדרשים לו ולבדוק שהכל פועל כשורה. אולם רוב הלקוחות אינם יודעים כיצד להכין את התסריטים שהם זקוקים להם, והבדיקה היחידה שמורצת על היישום החדש היא רק זו של בית התוכנה, שבודק אם הכל מתפקד לפי הקוד.
אך בכך לא הסתיים נתיב המהמורות. הצומת הבא הוא ההטמעה, שגם בו זרועים מוקשים רבים, למשל: התנגדות שיש בחוגים מסויימים בכל צוות עובדים, לשנוי דרכי עבודה. אלה שלא מוכנים ללמוד דברים חדשים, יאשימו, בדך כלל, את המערכת החדשה כ'לא בסדר', יקטרו על כל צעד ושעל, ואם מחוסר ידע כיצד לתפעל את המערכת, גם יגרמו להפלתה – תתרחב בארגון התחושה שאכן יש פה כשלון בסיסי.
גדי שווץ, שחקר את המבנים הארגוניים המקובלים בבתי תוכנה לגבי פרוייקטי פיתוח עוד בשנים בהם כיהן כמפקד מערכות מיחשוב שונות בצה"ל, מחלק הפעם את המסקנות ליותר מ'שלושת החלקים' המקובלים בז'רגון הצבאי.
המבנה הקלאסי – לדבריו – הוא המבנה ההירארכי: ראש פרוייקט ומתחתיו בסדר יורד, מנתחי מערכות, מעצבים ותוכניתנים. מבנה מקובל אחר הוא המבנה המטריציוני, שבו מצוותים מנתחים, מעצבים ותוכניתנים השייכים לגופים אחרים – אד הוק לצורך פרוייקט חדש. כל אחד משני המבנים סובל מחסרונות אחרים: "המבנה ההירארכי סובל מחוסר יעילות. שכן מצד אחד כשאין פרוייקט בעבודה, התוכניתנים מובטלים. מצד שני ראש הפרוייקט לא יכול לקבל חיזוק, כי הוא מוגבל לצוות הקיים שעליו הופקד. במבנה המטריציוני קשה לראש הפרוייקט לגייס תוכניתנים טובים ממאגר הארגון, שכן מי שאחראי עליהם ביומיום מעוניין, באופן טבעי, לשמור אותם לעצמו.
לאחר ניתוח כל סוגי המבנים הארגונים, הגיע שווץ למסקנה שהפתרון הוא במבנה משולב. וכך זה נראה: מתוך צוות מנתחים קיים, בוחרים בראש פרוייקט, העומד למעשה בראש 'מפעל ייצור'. כאשר מתקבל פרוייקט חדש, יש בידיו את מלוא הגמישות להציב כל תוכניתן בעמדה המתאימה לו, ממש כפי שמפקד בצבא מחליט כמה חיילים דרושים לו לביצוע משימה ומה יעשה כל אחד מהם. כאשר נוצרת דרישה לתגבור הכוח – שוב יכול 'מנהל המפעל' למשוך עוד עובדים מאלה העומדים לרשותו. במילים אחרות: הוא המחליט הן לגבי כוח האדם, הן לגבי גודל הסד"כ.
מעורבות הלקוח
כמו בתורת הלחימה – יגיד שווץ – אחת המטרות החשובות היא לסיים את המשימה בזמן הקצר ביותר. מחקרים מראים בברור שככל שפרוייקט נמשך זמן רב יותר – כך קטנים סכויי הצלחה שלו וזה בדיוק הפוך מהדעה לפיה כמה שנותנים לפרוייקט יותר זמן, הוא ייצא יותר טוב. פרוייקט שמתמשך יתר על המידה, מתחיל להתמסמס, דברים שנראים ללקוח חיוניים בהתחלה, פתאום כבר לא חשובים או לא רלוונטיים. במקרים אחרים בא מנכ"ל חדש, וקובע שמה שהחליט זה שלפניו היה פשוט אידיוטי וכן הלאה וכן הלאה…
כדי לקצר את משך הפיתוח, צריך שהלקוח יהיה מעורב אישית מה שיותר. יש לערוך ישיבות בנוכחותו, לסכם במשותף דברים ולהתקדם. חשוב ששלב האפיון יערך כסיעור-מוחות עם הלקוח, ואז יהיה לו ברור מה קורה ומה יקרה בשלבים הבאים. בדרך זו, ניתן לקצר את שלב האפיון משלושה-ארבעה חודשים – לחודש
קישורים נוספים שנמצאו בידי מנהיגים ברשת:
EPM – מערכת ארגונית כוללת לניהול ובקרת תוכניות עבודה ופרויקטים
מתוך: /http://www.calanit-carmon.com
|
מנהיגים ברשת |
| © כל הזכויות שמורות ל"מנהיגים ברשת" מאי 2002. החומר מותר לשימוש אישי בלבד. אין לעשות בחומר שימוש מסחרי/עסקי ו/או להפיצו בכל דרך שהיא (להוציא באמצעות יצירת קישור למאמר ספציפי ולעמוד הבית במקביל) מבלי לקבל רשות מפורשת בכתב מהנהלת האתר |
מאמרים נוספים בנושא ניהול פרוייקטים