علل اصلی شکست پروژه‌های نرم‌افزاری

این مقاله به بررسی علل اصلی شکست پروژه‌های نرم‌افزاری می‌پردازد. ولی از آنجا که مسایل مطروحه مبتلابهِ تمام فعالیت‌های مهندسی می‌باشد، توجه به این مطالب برای عموم مهندسان مفید و مهم است. این مقاله پس از بررسی لزوم چنین بحثی به تبیین مصادیق شکست پروژه پرداخته سپس به طرح علل آن، که هدف مقاله است، می‌پردازد. نهایتاً با توجه به علل مطروحه به یک نتیجه‌گیری کلی می‌رسد.

۱) مقدمه

از آنجا که بیشتر پروژه‌های نرم‌افزاری به نوعی با شکست مواجه می‌شوند و این مطلب را آمار تأیید می‌کند، نیاز به بررسی علل و عوامل شکست در پروژه‌ها معلوم می‌گردد. در یکی از مقاله‌های مورد استفاده‌ی تحقیق حاضر که توسط لورین جی. می نوشته شده است، با یک بررسی آماری جامع و انجام یک سلسله مصاحبه با مدیران و مشاوران پروژه‌های نرم‌افزاری و مقایسه و تحلیل آنها، مقاله‌ای فراهم آورده است که در آن به گفته‌ی خود وی راه حل ارائه نکرده است و تنها سعی در تحلیل علل و عوامل شکست در پروژه‌ها و معرفی آنها نموده است.
این مقاله با توجه به اهمیت رعایت اصول طراحی، که در فازهای مختلف توسعه‌ی نرم‌افزار مورد توجه است، بر این بخش از چرخه‌ی حیات نرم‌افزار تأکید و توجه خاص داشته و سعی در اثبات اهمیت و حساسیت مرحله‌ی طراحی در توسعه‌ی سیستم‌های نرم‌افزاری د
ارد.

۲) شکست چیست؟

ابتدا لازم می‌نماید که بدانیم شکست در یک پروژه به چه معناست. شکست در پروژه‌های نرم‌افزاری در هر یک از چهار مورد «هزینه»، «زمان»، «کیفیت» و «دست‌یابی به اهداف» مطرح می‌گردد؛ بدین معنا که اگر پروژه‌ای با صرف هزینه‌ی بیشتر یا زمان بیشتر یا با کیفیت پایین‌تر انجام گردد، علی‌رغم به پایان رسیدن پروژه، آن را توأم با شکست می‌دانیم.

۱-۲) آمــار

طبق آماری که نویسنده به دست آورده است تنها یک ششم پروژه‌های نرم‌افزاری تعریف شده (۶۷/۱۶%) در زمان معین و با هزینه‌ی پیش‌بینی شده به پایان رسیده است. یک سوم پروژه‌ها (۳۳/۳۳%) فوراً متوقف گردیده و نیمه‌ی باقی‌مانده مورد بحث این مقاله است؛ که از این میان به طور متوسط پروژه‌ها با صرف ۸۹/۱ برابر بودجه (%۱۸۹+) و ۲۲/۲ برابر زمان (%۲۲۲+) انجام شده و تنها به ۶۱/۰ مشخصات تعریف شده دست یافته‌اند(۶۱% اهداف).

بنابراین حساسیت این مطالعه و لزوم اتخاذ تدابیری جهت بهبود این وضعیت کاملاً مشهود است. لازم به ذکر است که آمار فوق تنها از یک جامعه‌ی آماری نمونه به دست آمده و ارقام و اعداد در دنیای واقعی قطعاً بیش از اینهاست، چرا که این مطالعه تنها بر مبنای پروژه‌های دفاعی نیروی هوایی ایالات متحده‌ی آمریکا انجام گردیده است.

مطالعات انجام شده مبین این نکته است که ریشه‌ی بیشتر علل شکست، در پیش از اولین خط کد نوشته شده یافته شده است، یعنی «طراحی». البته این موضوع را با شرح جزئیات بیشتر می‌توان کالبدشکافی نمود و جنبه‌های مختلفی را متذکر گردید که همگی در حیطه‌ی طراحی می‌گنجد.

۳) علل اصلی شکست پروژه‌ها

بنا بر این مطالعه می‌توان موارد زیر را به عنوان «دلایل اصلی عدم توفیق در پروژه‌های نرم‌افزاری» ذکر نمود:
• ضعف ورودی کاربر
• نیازمندی‌های مبهم
• تخمین دور از واقعیت برای هزینه و زمان
• ناهماهنگی در مهارت‌ها
• هزینه‌های پنهان
• شکست طراحی
• طبقه‌بندی ارتباطات
• معماری ضعیف
• تأخیر در اعلان شکست
در بخش‌های بعد هر یک از موارد بالا را تشریح خواهیم کرد.

۱-۳) ضعف ورودی کاربر

هنگامی که مشاهده شود که سیستم به نیازهای کاربر پاسخ نمی‌دهد به چنین موردی بر می‌خوریم. این ضعف در سیستم از آنجا ناشی می‌شود که داده‌های اولیه در طراحی از ناظران سطح بالا اخذ گردیده است، که اینان به طور معمول از سیستم استفاده نمی‌کنند. در اینجا به گفته‌ی «پاول هیویت»، مشاور مرکز پشتیبانی فنی نرم‌افزار (STSC) ، اشاره می‌کنیم:«پروژه‌ها با مشکل مواجه خواهند شد مگر اینکه کاربران آگاه طی هر فاز استخراج نیازمندی‌ها، طراحی محصول و ساخت، داده‌های ورودی با معنی به طراح بدهند. کاربر باید بپرسد: چگونه همه‌ی کارهایم را با سیستم انجام دهم؟ آیا سیستم ابزار درست و کارآمد را برای من تأمین می‌کند؟ باید چه چیز به سیستم بدهم و در مقابل چه به دست خواهم آورد؟».

نکته‌ی دیگر در این باره را «شاری لاورنس فلیگر»، رییس شرکت نرم‌افزاری Systems در واشینگتن دی سی بیان می‌دارد:«… با وجود این کاربر نباید به بخش تعیین نیازمندی‌ها بیش از حد نزدیک شود. چون باعث بروز تداخل (Conflict) می‌گردد. کاربران درباره‌ی آنچه می‌خواهند و تبعات آن فکر نمی‌کنند، اینان تنها به این می‌اندیشند که کارها چگونه انجام می‌شده‌اند و در آینده چگونه انجام خواهد شد.».

۲-۳) ابهام در نیازمندی‌ها

بیانات «ماریا داتیز» رییس Peripheral Visions در هوستون تگزاس، درباره‌ی تجربیاتش در این خصوص مفید است:«کارفرما درباره‌ی آنچه که برنامه باید انجام بدهد ایده‌ای کلی دارد و در آن زمان که پروژه در دست مطالعه و طراحی است، ایده‌هایش را پالایش و اصلاح می‌کند. بنابراین در هر مرحله طراحان ناچار به عقب‌گرد می‌شوند ونتیجه آنکه هزینه‌ی پروژه و کیفیت به سرعت از کنترل خارج می‌شود، که البته نهایتاً شرکت ما مقصر شناخته می‌شود! بنابراین باید از ابتدا scope به حد کافی باریک و محدود باشد.

همچنین باید از ابتدایک خط پایه‌ی پایدار (permanent baseline) برای نیازمندی‌ها بنا نمود. هر چند که در هر صورت نیازمندی‌ها به طور خزنده تغییر می‌کنند.».
به هر حال در طی ساخت محصول نیازهای واقعی خودشان را نشان می‌دهند. اگر معماری و فرآیندها به طور هم‌گام با یکدیگر تغییر نکنند، پروژه به زحمت می‌افتد. نیز اگر خطوط راهنمای بنا شده نتوانند تعیین کنند که چه نیازمندی‌هایی افزوده یا حذف شوند، یا تغییر کنند و چه کسی مسؤول این تغییر و برعهده گیرنده‌ی هزینه‌های مربوطه است، پروژه موفق نخواهد بود.

۳-۳) تخمین دور از واقعیت برای هزینه و زمان

پروژه‌های نرم‌افزاری همانند همه‌ی فعالیت‌های مهندسی دیگر، نیازمند تعیین حداقل هزینه و زمان هستند. یعنی یک نقطه‌ی مینیمم برای هزینه و زمان در هر پروژه وجود دارد که با مطالعه‌ی بیشتر روی آن حتماً مقدارش رشد خواهد داشت. «… اما خست به خرج دادن باعث طراحی‌های ضعیف، چگالی بالای عیوب، دوباره‌کاری و آزمون‌های بی‌پایان می‌گردد. نهایتاً پروژه با پول و زمان بیشتر و کیفیت بدتر انجام خواهد شد.». این گفته‌ی «رابرت گزلتر» مشاور نرم‌افزار شرکت فلاشینگ در نیویورک می‌باشد.

«کیپرز جونز» رییس مؤسسه‌ی تحقیقات بهره‌وری نرم‌افزار می‌گوید:«برای علاج این مشکل باید در تخمین هزینه و زمان پروژه از چند ابزار مختلف سود جُسته، پارامترهای عددی به دست آمده را ترکیب کرد تا به تخمینی واقعی‌تر دست یافت. حتی گاهی پیش از تعریف دقیق نیازمندی‌ها، برآورد لازم است.».

۴-۳) ناهماهنگی در مهارت‌ها

این مورد بیشتر در پروژه‌های دولتی مشهود بوده است و آن بدین خاطر است که در پروژه‌های دولتی قوه‌ی تصمیم‌گیری در دست اشخاصی است که خبره‌گی فنی ندارند.
پروژه‌هایی که به فناوری بالا متکی‌اند (High Tech) ، باید مدیرانی با مهارت‌های فنی بالا داشته باشند. اختیارات چنین طرح‌ها و پروژه‌هایی نیز باید در دست افرادی باشد که آگاهی فنی دارند و ریسک‌های فنی را می‌فهمند.
مجموعه‌ی مهارت‌ها برای مدیریت و برنامه‌نویسی از جدا می‌باشند. مدیریت پروژه‌های بزرگ نیاز به مهارت‌های عالی در «طرح‌ریزی»، «سازمان‌دهی»، «افق دید وسیع و عمیق» و «ارتباطات» دارد. استخدام افراد ماهر با حقوق بیشتر، از استخدام افرادی با حقوق کمتر که مدت‌ها طول می‌کشد تا صاحب تخصص شوند، به مراتب به‌صرفه‌تر است.
ماریا داتیز می‌گوید:«You get what you pay for! ، هر چه پول بدهی آش می‌خوری! اگر نمی‌توانی یهترین تکنسین‌ها(فنی‌ها) را استخدام کنی، بهترین مدیران را استخدام کن!».

۵-۳) هزینه‌های پنهان

ارزان تمام کردن، باعث بُروز هزینه‌های پنهان می‌شود. در تخمین هزینه و زمان باید متوجه هزینه‌های پنهان نیز بود. به عنوان مثال در نظر گرفتن تورم در تخمین هزینه‌ها مؤثر می‌باشد.

۶-۳) شکست طراحی

عدم طراحی جزئی و تعیین تکلیف برای افراد(به طور جزئی)، برای پروژه مشکل‌ساز می‌شود. برخی مدیران و پدیدآورندگان نرم‌افزار معتقدند به جای صرف وقت برای تعیین نیازمندی‌ها و طراحی و بررسی و… بهتر است به کار واقعی(کدنویسی و تست!) پرداخت، که سریع‌تر به نتیجه برسیم. اما مابین سرعت و پیشرفت تفاوت وجود دارد. در صورتی که طراحی مناسب باشد، هیچ نیازی به «قهرمان» نخواهد بود.

۷-۳) طبقه‌بندی ارتباطات

تیم‌های درگیر کار طراحی و کدنویسی باید با یکدیگر مراوده داشته باشند. چون حین انجام کار همواره مشکلات مشابهی پیش می‌آید، به خصوص اگر تیم‌ها در سایت‌های مختلف کار کنند؛ وجود مراوده و تبادل اطلاعات و مبادله‌ی تجربیات بسیار حائز اهمیت بوده، از صرف هزینه و وقت اضافی جلوگیری می‌کند.
برای انجام این امر باید فردی وجود داشته باشد که به کل کار محیط بوده و این هماهنگی‌ها را انجام دهد. در عین حال باید جلسات متعدد، متناوب و مستمر داشته باشیم تا هر کس بداند جزء کوچکی را که می‌سازد در کجای این پیکره‌ی عظیم قرار می‌گیرد.
ضمناً در طی این جلسات مشکلات هر تیم بیان شده و احیاناً اگر این مشکلات را حل کرده‌اند راه‌حل‌ها را نیز به اطلاع دیگران رسانیده و اگر در تیم دیگری چنین مشکلی بروز کند آنها راه حل را پیشاپیش خواهند دانست و ناچار به تجربه کردن تجربیات نخواهند بود.
نتیجتاً سرعت کار بیشتر شده و قطعاً هزینه نیز کاهش می‌یابد. هزینه‌ی مذکور شامل پول و زمان می‌باشد.

۸-۳) معماری ضعیف

در بحث «معماری ضعیف» تمرکز این مقاله بر روی انعطاف‌پذیری معماری می‌باشد. مثلاً نمونه‌ی تجربی موجود در جنگ خلیج دیده شده است. موشک «پاتریوت» برای مقابله با موشک «اسکاد» طراحی نشده بود ولی نرم‌افزار قادر به تغییر ساختار(برای پشتیبانی از عملکرد جدید) بود.
در سوی دیگر این طیف، برنامه‌های «حفاظت متون حساس» هستند که به سیستم عامل وابسته‌اند.
در طراحی نباید پروژه چنان طرح‌ریزی شده باشد که به ساختار ویژه یا سیستم عامل خاصی چنان وابسته باشد که در پشتیبانی و به‌روزرسانی و افزودن بخش‌های جدید به سیستم دچار مشکل یا صرف هزینه‌ی گزاف شویم.
گزلتر در این باره می‌گوید:«نباید قایق بسیار زیبایی را در کارگاه ساخت که از در کارگاه بیرون نمی‌رود!»
ضمناً باید توجه داشت که: «اگر کارت را درست انجام دهی کسی نمی‌فهمد، ولی اگر اشتباه کنی … !»
بنابراین در معماری و طراحی ساختاری سیستم، باید حداقل‌ها را در نظر گرفته، وابستگی سیستم به platformهای سخت‌افزاری و نرم‌افزاری را به حداقل رسانید.

۹-۳) تأخیر در اعلان شکست

مورد دیگر در شکست پروژه‌های نرم‌افزاری آن است که پس از مشاهده‌ی برخی عوامل مشکل‌زا، اگر در زمان مناسب تدابیر مؤثر اتخاذ نگردد برخی مسایل جبران ناپذیر خواهند شد. لذا باید در زمان لازم موارد خاص را کشف و حل نمود و هیچ‌گاه در اعلان آنها تأخیر نکرد. چرا که اگر موردی که در آینده مشکل‌ساز خواهد شد به موقع دیده نشده و رفع نگردد، شاید هرگز به رفع آن موفق نشویم. ضمناً مشکل مزبور ممکن است باعث بروز اشکالات دیگر نیز بشود.

نتیجه‌گیری

علاوه بر موارد مذکور، مشکلات و موانع بسیار دیگری نیز موجودند. به گفته‌ی جونز:«راه‌های شکست بسیارند، در حالی که تنها راه‌های اندکی برای موفقیت وجود دارند.».
اما با توجه به همین موارد معدود که شرح آن رفت، می‌توان تا حدود بسیار زیادی از بروز مشکلات جدی در هر پروژه بالاخص پروژه‌های نرم‌افزاری پیش‌گیری نمود.
من حیث‌المجموع در انجام هر نوع فعالیت مهندسی صرف زمان هنگام طراحی و بررسی کلیه‌ی جوانب کار بسیار به‌صرفه‌تر است از صرف هزینه‌های گزاف در فازهای بعدی پروژه، به منظور اصلاح مشکلاتی که اساساً می‌توانست پیش نیاید

عالی بود(7)جالب نیست!(0)