בלוג > מאמרים

10 סיבות נפוצות לגלישת פרויקטי פיתוח מוצרים

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

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

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

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

פעולות שעשויות לעזור:
כאשר מנהל הפרויקט מחויב לבנות, לעדכן ולפעול עפ"י גנטים מפורטים, הוא חייב להקדיש לניהול הפרויקט את תשומת הלב הנדרשת כדי להגדיר ולעקוב אחרי הנושאים הנכללים בהם (משימות, משאבים, תקציב וכדומה) ו/ואו להעסיק אחר/ים שיסייעו לו בנושא זה. החובה לבנות תכנון מלא של הפרויקט ולעקוב אחריו באופן מעקב שוטף, אינה מאפשרת להתעלם מן "הנקודות הקשות" למנהל. במקרים של מנהלים צעירים, גנטים אלו יוכלו לסייע למנהלים שלהם לזהות שגיאות או נושאים חסרים.
3. לא מוגדרות מטרות ברורות לטווח הבינוני והארוך
   זאת תופעה נפוצה בפיתוח מוצרי מדף. לעתים קרובות ממציאים את המוצר "תוך כדי הליכה". בעוד שפרויקטים עבור לקוח ספציפי מוגדרים בדרך כלל טוב יותר בחוזה בין הצדדים, בפיתוח מוצרי מדף נמצא לעתים קרובות שהכיוון הכללי אינו מוגדר היטב. בדיקה מעמיקה יותר תמצא שלקבוצות שונות בחברה יש כיוונים שונים, שאינם מתואמים ביניהם. הבעיה קשה במיוחד כאשר מדובר במטרות לטווח ארוך ואף בינוני.
   
   פעולות שעשויות לעזור:
   בניית לוח זמנים מפורט לפרויקט מחייבת את כל הגורמים המעורבים לענות על שאלות קשות, הנוגעות לתוכניות לטווח הארוך ולצרכי הפרויקט. קיום תוכנית כזאת מאפשר לכל הגורמים המעורבים בפרויקט להבין את מטרותיו ואת מידת הגיבוש שלהן.
4. המשמעויות השיווקיות אינן מוכרות לכל העובדים
   לעתים קרובות נמצא שלאנשי הפיתוח יש הבנה טובה ומעמיקה של ה"משבצת" עליה הם אחראים. ככל שמתרחקים מ"משבצת" זאת, ההבנה הולכת ומתערפלת. לעתים קרובות אנחנו מוצאים אצל אנשי הפיתוח הבנה מוגבלת של המשמעויות השיווקיות, הנוכחיות והעתידיות, של המוצר אותו הם מפתחים. הם אינם מקבלים מידע שוטף על סקרי השוק שעורכת החברה. לעתים קרובות הם אינם מכירים את צרכי ודרישות הלקוחות, אלא את איפיון הדרישות מן המוצר, כפי שעובדו ע"י גוף השיווק. מאחר וחלק מן האיפיון מתבצע בפועל ע"י גופי הפיתוח, התוצאה היא שלעתים קרובות, חלקים מן המוצר אינם תואמים את ציפיות הלקוח.
   
   בדרך כלל המפתחים גם אינם מיודעים בכיווני ההתפתחות המתוכננים למוצר, ולכן לעתים קרובות נמצא שתכנון המוצר מתאים לגירסתו הבסיסית, אך המעבר לגירסאות המתקדמות יותר דורש תכנון וביצוע מחדש של חלקים ממנו ("למה לא אמרתם מראש שזה צריך להתחבר גם ל...?").
   
   בחלק מן המקרים המידע לא מועבר מתוך כוונה (סודות מסחריים של החברה), אך במרביתם זאת רק בעיה של חוסר זמן ותשומת לב.
   
   פעולות שעשויות לעזור:
   
   • שיתוף העובדים בתוכניות העבודה (=גנטים) הראשוניות של ה-road map של המוצר, יעזור להם להבין אותו יותר ולשאול את השאלות הנכונות.
   • שיתוף מידע שיווקי ברמות שונות מאפשר לעובדים (בהתאם להרשאות הניתנות לכל אחד) להתעדכן באופן שוטף באספקטים שיווקיים שונים, ללא צורך במאמץ הדרכה נוסף מצד גוף השיווק.
5. לא לוקחים בחשבון חלק מן הפעילויות
   מנהלי פרויקטים רבים מסתפקים בתכנון כללי של הפרויקט שלהם. "הפרטים הקטנים" מפוזרים ברשימות שונות, בהתכתבויות e-mail עם גורמים שונים, בסיכומי דיונים וסתם בראשם של אנשים שונים בחברה. לעתים קרובות אני פוגשת מנהלי פרויקטים, שבגלל שמופעל עליהם לחץ מלמעלה לבנות תוכנית עבודה המתאימה ליעדי החברה, הם משמיטים ממנה חלק מן הפרטים במכוון, כי הוספתם תראה שלא ניתן לעמוד בתכנון ("אחר כך נראה מה לעשות עם זה"). במקרים אחרים, מנהלי פרויקטים שמים להם למטרה לבנות תוכנית עבודה מצומצמת בלבד, "כדי שיהיה קל לעדכן אותה".
   
   התוצאה היא שחלק מן הפרטים נשכחים ונזכרים בהם רק לקראת סיום הפיתוח, בזמן הבדיקות או עקב תלונת לקוח. זאת אחת הסיבות לכך שהמעבר בין "הפיתוח גמור ב-95%" לבין "הפיתוח גמור" אורך זמן רב כל כך - הרבה יותר מ-5%.
   
   פעולות שעשויות לעזור:
   בניית גנט מפורט לכל קבוצה בפיתוח, הכולל את כל הפעילויות, מספקת visibility לגורמים שונים בחברה - החל מן העובדים בקבוצה ועד להנהלת החברה - שעשויים למצוא בו פעילויות חסרות ואפילו פעילויות מיותרות. כאשר קיים גנט כזה, חשוב להקפיד לעדכן אותו בעקבות כל שינוי (דיון, e-mail וכדומה), כדי שישקף תמיד את התוכנית הנוכחית, ובכך יאפשר לגורמים המעורבים לבחון אותה. בכך יורד באופן משמעותי מספר הפריטים שנשכחו או שהשפעתם לא נלקחה בחשבון.
6. שינויים משמעותיים ותכופים בהגדרת המוצר, לא כולם הכרחיים
   כאשר גורמים בכירים בחברה / בפרויקט מחליטים על שינוי זה או אחר, לא תמיד הם מודעים למשמעויות המלאות שלו. לעתים "מלמעלה" זה נראה כמו "רוצים להוסיף רק עוד feature קטן, אבל מאד חשוב". ההתלהבות של מקבלי ההחלטות בחברה מן הרעיונות מן הרעיונות לשיפור, גורמת לשינויים תכופים בהגדרת המוצר, הגורמים להפרעות בפיתוחו.
   
   פעולות שעשויות לעזור:
   כאשר פיתוח המוצר מנוהל בעזרת גנט מפורט, המכיל את כל הפעילויות הדרושות להשלמתו, ניתן בקלות להראות את המשמעות של הוספת כל שינוי כזה. מניסיוני, כאשר מנהל הפרויקט מציג להנהלה את משמעותו המדויקת של כל שינוי שנדרש, בזמן ותקציב, מספר השינויים נוטה לרדת.
7. מהפכים גורמים לעצירת הפיתוח וזניחת הלו"ז
   שינויים משמעותיים מן הסוג שהוזכר בסעיף הקודם, גורמים בדרך כלל לעצירת הפיתוח לצורך התארגנות מחדש. בדרך כלל אל הודעת השינוי מתלווה לחץ מצד ההנהלה להמשיך ולהיצמד ללוחות הזמנים הקודמים, למרות השינוי. התוצאה היא, לעתים יותר מדי קרובות, שהעובדים מגדילים את מספר שעות העבודה ("יש המון מה לעשות"), אך ללא תוכנית עבודה ("עכשיו אין זמן לזה, כי אנחנו בלחץ. ממילא אין טעם לעדכן את הגנט, כי תכולת העבודה משתנה כל הזמן").
   
   למעשה, זאת אחת הסיבות לכך שברוב פרויקטי הפיתוח, ובעיקר בחלקים הקריטיים שלהם, קשה למצוא תוכנית עבודה עדכנית. דווקא בזמנים בהם תוכנית העבודה חיונית ביותר - היא איננה קיימת.
   
   פעולות שעשויות לעזור:
   כל שינוי בתכולת הפרויקט, צריך להתחיל מעדכון הגנט שלו, על מנת להבין את המשמעויות שלו. בהתאם לתוצאות המתקבלות יכול מנהל הפרויקט להחליט על העברת משימות בין אנשים או על הגדרת צורך בכוח אדם נוסף. רק אחרי דיווח להנהלה על משמעויות השינוי (זמן סיום הפרויקט, השפעות על תקציב וכוח אדם) וקבלת אישורה - יותנע השינוי. באופן זה יתבצע השינוי באופן מבוקר ויעיל.
8. חוסר תאום בין פרויקטים / קבוצות
   פיתוח מוצרים בני ימינו הוא תהליך מורכב מבחינה ניהולית. בדרך כלל מתחלק פיתוח מוצר בין כמה קבוצות. קבוצה כזאת יכולה להיות מצוות פיתוח ועד לפרויקט שלם. חלק מן הקבוצות אינן שייכות לגוף הפיתוח בחברה, אלא לגופים אחרים, כמו שיווק, תפעול ואחרים. קבוצות אחרות הן חיצוניות לחברה.
   
   ברבות מן החברות אליהן הגעתי כדי לסייע בניהול הפרויקטים, מצאתי שהתאום בין פעולות הקבוצות נעשה בעל פה, בדרך כלל בדיוני מעקב, או בהתכתבות (e-mail). חיבור תוכניות העבודה של הקבוצות הראה תמיד על פערים בין התוכניות וההבנה של מנהלי הקבוצות השונות לגבי פעילויות משותפות, הן לגבי מועדן והן לגבי התכולה שלהן.
   
   פעולות שעשויות לעזור:
   
   • לוחות הזמנים צריכים לשקף את ההשפעות של פעילויות הנמצאות בקבוצות שונות ובפרויקטים שונים. כך ניתן לקבוע שפעילות כלשהי בפרויקט מסוים תוכל להתחיל רק אחרי שפעילות מסוימת בפרויקט אחר תסתיים.
   • לוחות הזמנים צריכים לשקף גם את התוכנית לשימוש במשאבים (אנשים, ציוד) והאופן שבו יחולק זמנם בין מספר פרויקטים, כך שניתן יהיה לזהות (ואף למנוע) מצב שבו אותו משאב הוקצה באותו זמן לשני פרויקטים שונים.
   הבנת ההשפעות ההדדיות של הקבוצות השונות מסייעת לפתור אי התאמות בין התוכניות של מנהלי הקבוצות השונות. בסופו של דבר מתקבלת תמונה אמיתית של מצב הפיתוח.
9. הזנחת פעילות הבדיקות
   לרוע מזלה של פעילות הבדיקות, נעשית מרביתה בשלבים האחרונים של הפרויקט, כך שהיא סובלת מן האיחורים של הפעילויות שלפניה. התוצאה היא שלעתים קרובות מופעל לחץ על הקבוצה האחראית על הבדיקות לקצר את הפעילות שלה, על מנת "לשחרר" את המוצר בתאריך מוקדם יותר. התוצאה היא שקבוצת הבדיקות מקבלת מוצר ראשוני מדי (למפתחים לא היה מספיק זמן לבדיקות שלהם) ויש לה מעט מדי זמן לזהות את הבעיות שבו. לכן, למרות שפורמלית המוצר "שוחרר" בתאריך מסוים, העבודה על תיקונו עדיין ממשיכה. בין המשמעויות של התנהלות כזאת: מוצרים בעלי איכות נמוכה, אנשי הפיתוח אינם מתפנים לפרויקטים הבאים לפי התכנון (עיכוב בפרויקטים אחרים) וגלישה בתקציב.
   
   פעולות שעשויות לעזור:
   כאשר גם לקבוצות הפיתוח וגם לקבוצת הבדיקות קיימות תוכניות עבודה מפורטות, ניתן לבצע ביניהן תאום, שיאפשר מקביליות מתוכננת מסוימת, שתקצר את משך הבדיקות מבלי לפגוע באיכות התוצרים.
10. אין (מספיק) ניהול סיכונים
    מעטים הפרויקטים המקיימים ניהול סיכונים משמעותי. בפועל, בחלק מן המקרים נבנית בשלב כלשהו רשימת סיכונים, אך ההתייחסות אליה בהמשך היא מינימלית. למרבית מנהלי הפרויקטים, למעט מנהלי פרויקטים גדולים במיוחד, אין עניין לייחד דיונים שוטפים נפרדים לנושא הסיכונים.
    
    מצד שני, כמובן שלא מומלץ להתעלם מן הסיכונים, שעלולים להשפיע באופן ניכר על מהלך הפרויקט. עבור המנהלים הבכירים רשימות הבעיות הפתוחות והסיכונים הם כלים חשובים להערכת הסיכוי של הפרויקט לעמוד בתוכניות שלו.
    
    פעולות שעשויות לעזור:
    הגדרת שיטות פשוטות ככל האפשר לניהול הסיכונים בפרויקט. במסגרת זאת חשוב להיערך מראש עם תוכניות לטיפול בהם.

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

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


נכתב ע"י רונית סנה
IntelliManage

 

שאלות ותגובות למאמר זה ניתן להעלות כאן