معمولاً وقتي سازمان يا شرکتي نرم‌افزاري را سفارش مي‌دهد، هيچ‌گاه به اين موضوع فکر نمي‌کند که ممکن است قبل از تحويل گرفتن آن، نرم‌افزار او بميرد و از آن محصول نتواند استفاده کند. يا اگر نرم‌افزار را سالم تحويل بگيرد باز هم به اين موضوع فکر نمي‌کند که اين نرم‌افزار روزي مي‌ميرد.
سازمان‌هاي بزرگ هزينه‌هاي قابل‌توجهي را صرف خريد تجهيزات IT از سخت‌افزار گرفته تا نرم‌افزار و تجهيزات شبکه‌اي مي‌کنند و نکته قابل توجه اين‌که بيشترين درصد خرابي و مشکلات از آن نرم‌افزار است، اما به راستي چرا اين‌گونه است؟ چرا در اکثر پروژه‌هاي نرم‌افزاري کشورمان اين مشکل ديده مي‌شود؟ تجربه شخصي من براي پاسخ دادن به اين سؤالا‌ت، عدم توجه به هشت نکته مهم را دخيل مي‌داند:
1) يکي از مشکلات پروژه‌هاي نرم‌افزاري نداشتن برنامه کاري يا داشتن برنامه زمان‌بندي غيرحقيقي است. به عنوان مثال، در حالي که نظر کارشناسي اين است که مدت زمان اتمام پروژه با توجه به اجزاي آن چهار ماه طول خواهد کشيد، شما به عنوان مدير پروژه نرم‌افزاري نبايد قول بدهيد که پروژه دو ماه ديگر به اتمام مي‌رسد. اين کار باعث خواهد شد به دليل کمبود وقت کيفيت نرم‌افزار کم شود.
2) به‌کارگيري نرم‌افزاري که کيفيت پاييني داشته باشد حتماً با شکست روبه‌رو مي‌شود. تصور کنيد که روي اجزاي سيستم‌هاي نرم‌افزاري آزمايش کاملي صورت نگيرد و از روش‌هاي آزمايش مکرر در هنگام برنامه‌نويسي استفاده نشود. اگر نيازهاي کاربران (نه به صورت کامل بلکه جزئي) تغيير کند سيستم ديگر نمي‌تواند قابل استفاده باشد.
3) نبايد فکر کنيم اتفاق خارق‌العاده‌اي رخ مي‌دهد و کاربران سيستم همان‌گونه که ما به آن‌ها مي‌گوييم، با سيستم رفتار مي‌کنند. شايد ورود اطلاعات زياد و رفتارهاي مختلف کاربران در سيستم تأثير داشته باشد و باعث شود نتيجه خوبي از پروژه نگيريم.
4) اگر چه تغيير کلي نيازهاي کاربران پروژه نرم‌افزاري را با مشکل روبه‌رو مي‌کند، اما باور کنيد که کاربران نيازهاي جديدي خواهند داشت. بهتر است در پروژه‌هاي نرم‌افزاري از روش‌هاي آبشاري قديمي استفاده نکنيم و از روش‌هاي نوين مانند test driven development بهره بگيريم.
5) در پروژه‌هاي نرم‌افزاري از نيروهاي آزموده و حرفه‌اي استفاده کنيم. اگر چه نيروهاي غيرحرفه‌اي مي‌توانند برنامه‌هاي کوچکي توليد کنند، اما پروژه‌هاي نرم‌افزاري بزرگ هم به تخصص و تجربه زيادي نياز دارند. به صرف اين‌که فردي تنها تحصيلات دانشگاهي عالي در رشته نرم‌افزار دارد نمي‌توان گفت که مي‌تواند عضوي از تيم پروژه باشد. در انتخاب نيروهاي پروژه دقت کنيد، چون دليل از بين رفتن اغلب پروژه‌هاي نرم‌افزاري استفاده از نيروهاي غيرمتخصص است.
6) برخي از کاربران سيستم که خود به استفاده از سيستم راغب نبودند و سرپرستشان آن‌ها را مجبور مي‌کرد از سيستم استفاده کنند، در مقابل سيستم و نرم‌افزار مقاومت مي‌کردند و مي‌خواستند همچنان به صورت دفتري کار خود را انجام دهند، زيرا به نظر آن‌ها استفاده از سيستم‌هاي نرم‌افزاري حيطه وظايف آن‌ها را محدود مي‌کند و نمي‌گذارد آن‌ها در انجام وظايف کوتاهي کنند (يا به عبارتي از زير کار در بروند). شايد هم هنوز به نرم‌افزارها اعتماد ندارند و بر اين گمانند که مغزشان در امور محاسباتي از کامپيوتر بهتر کار مي‌کند.
7) کاربران اصلي سيستم در طول مراحل طراحي نرم‌افزارها حضور ندارند، به همين دليل است که وقتي نرم‌افزار آماده مي‌شود مي‌خواهند آن را تغيير دهند. کار آن‌ها مانند اين موضوع است که تنها اندازه‌هاي خود را به خياط بدهيم و بگوييم حوصله پرو را نداريم. حاصل کار شايد لباسي باشد که اندازهِ شما باشد، اما به احتمال خيلي زياد کارايي کافي را نخواهد داشت.
8) فرض کنيد نرم‌افزار عاري از اشکال است و در اختيار کاربر قرار مي‌گيرد. حال اگر کاربر به دليلي وقت خود را صرف ايرادگيري از سيستم کند يا اطلاعات مورد نياز را به آن وارد نکند پروژه نرم‌افزاري به نتيجه نخواهد رسيد. برخي از کاربران سيستم فکر مي‌کنند که وظيفه برنامه‌نويس وارد کردن اطلاعات به سيستم است.
در کشورهاي صنعتي درصد مشکلات پروژه‌هاي نرم‌افزاري بسيار کمتر از کشور ما است. تجربه به ما نشان داده که تقريباً بيست‌درصد از پروژه‌هاي نرم‌افزاري کوچک و حدود ده تا پانزده درصد از پروژه‌هاي نرم‌افزاري بزرگ مشکل دارند. در واقع اين پروژه‌ها آنقدر مشکل دارند که نمي‌توان آن‌ها را اصلاح کرد. جالب‌تر اين‌که برخي از مديران پروژه‌هاي نرم‌افزاري که پروژه‌‌هايشان با مشکل روبه‌رو مي‌شود، نمي‌خواهند اين واقعيت را بپذيرند که نرم‌افزارشان مرده است و ديگر نمي‌توان کاري برايش انجام داد.
به عنوان مثال، حدود دو سال پيش در يکي از سازمان‌هاي دولتي به وسيلهِ گروهي که تخصص نرم‌افزاري نداشته و تنها فني بودند سيستمي طراحي شد و تيم نرم‌افزاري مسئوليت اجراي آن را به عهده گرفت. بعد از آماده سازي محصول کاربر سيستم تغييرات زيادي در سيستم به وجود آورد که ساختار کلي آن را تغيير داد و هنوز بعد از اين همه مدت هيچ‌گاه سيستم عملياتي نشده است.
نمي‌توانيم تمامي اشکالات را به کاربر يا مدير پروژه نسبت بدهيم. به نظر من اگر بتوانيم تمامي هشت نکته‌اي را که در بالا اشاره شد، در نظر بگيريم، درصد کمتري از پروژه‌هاي نرم‌افزاري ما با شکست روبه‌رو مي‌شوند.
معرفي سايت مرتبط با اين مقاله