10 סיבות מדוע כל כך הרבה פרויקטי תוכנה נכשלים
-יוזמת המדיה הדיגיטלית (DMI) של BBC נכשלה בגלל כישלון ניהולי ועיכוב באספקה. זה היה פרויקט שכולם שמו את עיניהם כי הוא נועד להפוך את ההפקה של BBC לדיגיטלית.
-מספר סיבות גרמו לכישלון ה-Virtual Case File (VCF) של ה-FBI אך ציפיות לא מציאותיות היו אחת הסיבות העיקריות. הפרויקט בזבז כ-104.5 מיליון דולר כספי משלם המסים.
-המערכת החדשה של הפד האמריקני השתוללה, בלילה הראשון שעלתה לאוויר והעבירה 28 מיליארד דולר כריבית לבנקים החברים הלא נכונים.
איך פרויקטי תוכנה מתוכננים היטב יכולים להיכשל? האם הם באמת תוכננו היטב? או כך לפחות חשבו. למרבה הצער, פרויקטים רבים נכשלים; למעשה זה הפך לאירוע שכיח כל כך שאנשים כמעט ולא מדברים עליו, דנים בו, מלבד האנשים שנאלצו לעבור את הכישלון. בשנת 2013 חשפה חברת Inotas, חברת ניהול פרויקטים, כי בכ -50% מהעסקים שהם סקרו היו כשלים בניהול פרויקטים. עכשיו 4 שנים, מאוחר יותר, הסיפור לא שונה בהרבה. מה גורם לפרויקטי תוכנה להיכשל? בדקנו כמה מהסיבות על סמך התצפיות שלנו, מה דעתך?
1. אי התאמת מטרות עסקיות לתוצאות הפרויקט
אפשר לומר שסדרי העדיפויות שונים עבור חברות שונות. עבור חברות מסוימות, ההתמקדות היא בהשגת יעדים עסקיים, ואילו עבור אחרות היא לספק את הפרויקט בזמן ובתקציב. זה הנסיעה בכביש שבו הם הולכים בדרך הלא נכונה והולכים לאיבוד. אם הן היעדים העסקיים והן תוצאות הפרויקט מתאימים זה לזה, רוב הסיכויים שהתוכנה לא תיכשל. אבל לעשות זאת היא משימה לא פשוטה בכלל.
2. לא מסוגל להבין מה לתעדף
אי יכולת לתעדף אילו פרויקטים חשובים. ראש הנהלת הפרויקט יושב עם בעלי העניין ושאר ראשי החברה המוסמכים להחליט על סדרי העדיפויות של הפרויקטים. לאחר מכן הם יקצו את המשאבים ואת כוח האדם, וישקלו את התקציב והזמן. לפעמים, דברים משתבשים תוך התאמת היעדים העסקיים לתוצאות הפרויקט, וזה יכול להיות גם בגלל שהם לא הצליחו לתקן את סדר העדיפויות שלהם.
3. דרישות מעורפלות
אחד הצעדים הראשונים בכל מחזור פיתוח תוכנה הוא להבין את דרישות הלקוח. אלא אם כן הדרישות מתארות בבירור ומתוקנות על ידי הלקוח, ייתכן ששניכם לא נמצאים במקום
אותו עמוד בסוף מחזור הפיתוח.
4. אילוצי זמן
מגבלות זמן לרוב מונעות מהמפתחים לקבל בהירות פרויקט מהלקוח, וזה עלול להוביל להרבה עיבודים מחדש והקצאת משאבים רבה יותר, תוך שיקוף של פרסום שלילי לחברה. אז רגע לפני שאתם ממש יושבים לפתח פרויקט, חשוב לבצע ניתוח דרישות ולוודא שלכולם, כולל הלקוח, ברור איך ייראה המוצר הסופי.
5. הערכת לוח זמנים לקויה
מפתחים הם בני אדם ויש גבול לכמה שעות הם יכולים לעבוד ביום. קבעו את הזמן בצורה הגיונית כך שהפרויקט יסתיים כצפוי והיזם עדיין יהיה בחיים כדי לקחת על עצמו פרויקט אחר.
6. לא מוכן לדחות את המועד
מנהלי הפרויקט ומחזיקי העניין חייבים להיות מתחשבים כאשר הם מכניסים את צוות המפתחים לעבודה. כן, יום עבודה נוסף מגדיל את ההוצאות, אבל זה ישתלם בטווח הארוך.
7. מתן טווח זמן מוזר לא מציאותי רק יעכב את הפרויקט
בניגוד למה שחושבים בעלי עניין ומנהלי פרויקטים, קביעת טווחי זמן לא מציאותיים רק תביא להפסדים כבדים לחברה. תכננו תמיד את הפרויקט בצורה כזו שהציפיות יהיו סבירות, בהתאם לכמות העבודה.
8. פער תקשורת
תקשורת לקויה היא הסיבה לכישלונות רבים בחיים. למעשה זה כל כך חשוב עבור כל מי שקשור לפרויקט, שמעבר לקורסים מקצועיים בנושא מיומנויות בין אישיות בהחלט יהווה נקודת יתרון. תקשורת ומסרים חייבים להיות משותפים כראוי, מכיוון שהשקפות ודעות סותרות עלולות להרוג פרויקט עוד לפני שהוא מוכן לטוס. מנהל הפרויקט אחראי לעמוד כמתווך בין כל מי שקשור לצוות. ודא שההודעות מגיעות לכולם, במיוחד כאשר מדובר במשהו הנוגע לתוצאות הפרויקט.
9. לא לקבל את האנשים הנכונים לתפקיד
איוש לא הולם הוא סיבה נוספת לכישלון הפרויקט. יש לך צוות של מפתחים טובים. אבל האם אתה חושב שהם סוג של "גודל אחד מתאים לכולם"? האם הם יכולים להתמודד עם כל סוג של פרויקט שמוקצה להם? ייתכן שיהיה עליך להקצות אנשים בהתאם לכישוריהם. קבוצה נכונה של אנשים, גם אם הם יקרים, יתגלה כמועילה. הרי שאסור לאיכות הפרויקט להיפגע. מפתחים לא יעילים או בינוניים יעכבו את הפרויקט בעוד שמפתח פי 10 ישמור את מושכות הפרויקט בידו.
10. בדיקה לקויה
מבחני התוכנה נכשלים. לאחר שהכל נעשה, אתה מבין שיש בעיית קידוד שעדיין לא תוקנה. אם אין לך אבני דרך המסדירות את שלב פיתוח הקוד, הפרויקט עלול להיכשל. אתה יכול ליזום בדיקות אוטומציה לפיה הבוחן יכתוב סקריפטים וישתמש בתוכנה אחרת כדי לבדוק את הפונקציונליות השונות של האפליקציה/תוכנה. הסוגים השונים של בדיקות תוכנה הם
- בדיקת יחידות
- בדיקת אינטגרציה
- בדיקה פונקציונלית
- בדיקת מערכת
- מבחן לחץ
- בדיקת ביצועים
- בדיקת שמישות
- בדיקת קבלה
- בדיקות רגרסיה
- גירסת בדיקה ניסיונית
זה גוזל זמן, אבל בהחלט שווה את המאמץ והזמן. באמצעות בדיקה ניתן להבין את איכות הפרויקט; זהו סוג של תהליך אימות ואימות.
סיכום
חשוב להבין תחילה את הפרויקט ולאחר מכן להקצות משאבים וכוח אדם. תן להם מספיק זמן לעבוד על הפרויקט, ומשאבים כאשר הם צריכים את זה. עקוב אחר העצות שהוזכרו לעיל וסביר להניח שתפגע במשכורת.
מילה אחרונה: ודא שדרישות המערכת מוגדרות ומוגדרות כראוי. אתה לא יכול להרשות לעצמך שיהוקים עם המערכת ברגע שהתוכנה מוכנה להתגלגל.
עוד קצת מידע….
Flickr.com/ Patrizio Cuscito
על המחבר: רימה עובדת כמנהיגת מחשבות ב-PHPBabu.
