یکی از مشکلاتی که به شخصه در اکثر شرکت های ایرانی دیدم و یا از دوستان شنیده ام ضعف کیفیت پروژه های نرم افزاری است در نتیجه محصولاتی به وجود آمده اند همراه با مشکلاتی از قبیل توسعه ناپذیری یا توسعه پذیری سخت - هزینه ی بالای پشتیبانی - نارضایتی کاربر که باعث اعمال هزینه زیادی به شرکت های نرم افزاری شده اند .
به نظر من مهمترین دلایلی که باعث این اتفاق میشود در وهله اول مدیریت نادرست است که سعی دارد به هرشکلی هزینه های پروژه را کاهش بدهد و در نتیجه با استفاده از کمترین هزینه و یک تیم بی تجربه و کار نابلد پروژه خود را توسعه می دهد مثال این قضیه اکثر پروژه هایی هستند که در دنیای فریلنسر ها در حال توسعه هست (اگر دیدید در سایت های فریلنسری پروژه ای نظیر اسنپ را با 1 میلیون تومن دارند انجام میدن اصلا تعجب نکنید ) در وهله ی دوم تیم فنی با تجربه ای است که نمی تواند مزایای تحلیل های درستی را که انجام داده است در برابر هزینه هایی که این تحلیل به پروژه وارد میکند قرار بدهد ( یعنی کلا نمی تونه به مدیریت این ایده رو بده که یک تحلیل خوب ممکنه چقدر در اینده باعث کاهش هزینه های پروژه بشه به عنوان مثال بنده هر وقت جلسه گذاشتیم تا اهمیت یک معماری خوب رو به مدیر پروژه توضیح بدم اخر جلسه برداشتی که مدیر داشته این بوده معماری خوب = خوانایی بیشتر کد :| :) که البته دلایل این قضیه هم برای خودش قصه ای دیگه هستش )
یکی از این موارد بر میگرده به ورژن 1 پروژه تپ سی که تیم تپسی رو مجبور میکنه با صرف 3 ماه زمان پروژه رو برای ورژن 2 از اول بازنویسی بکنند
که یکی از اعضای خوب تیم تپ سی در موردش نوشته و میتونید اینجا بخونیدش
مواردی که ممکن هست باعث بهبود کیفیت پروژه نرم افزاری شما و کاهش هزینه های اتی پروژه بشود :
تست نرم افزار قبل از انتشار عمومی :
در گزارشی که IBM منتشر کرده هزینه رفع باگ بعد از انتشار نرم افزار 4 یا 5 برابر بیشتر از هزینه ای است که میتوانست قبل از انتشار عمومی صرف تست و بررسی و رفع باگ بشود برای تست قسمتی از عمل تست بر میگرده به تست هایی که خود توسعه دهنده میتونه انجام بده ولی قسمت اعظم تست به نظر من بر عهده افرادی غیر از توسعه دهنده باید باشه حال از قبیل یک تیم QC یا QAیا حتی مدیر محصول یا تمام کارمندان حاضر در یک پروژه و شاید لانچ نسخه بتا از پروژه تجربه ثابت کرده برنامه نویس ها معمولا در پیدا کردن باگ در پروژه خود ضعف دارند یا به عبارت دیگه کسی که خودش املا رو مینویسه غلط های خودش نمی بینه
تغیر مکرر خواسته ها :
یکی از ویروس هایی که یک نرم افزار با کیفیت رو به گند میکشه و نابود میکنه تغیر مکرر و بزرگ خواسته ها هست بگونه ای که تیم فنی تحلیل رو انجام میده و شروع به توسعه پروژه میکنه ولی در حین توسعه خواسته های نرم افزار مکررا تغیر میکنه به عنوان مثال یک سناریو بزرگ حذف یا اضافه میشه و این عمل چندین بار تکرار میشه به طوری که در نهایت پروژه ای که به عمل می آد چند صد کیلومتر از تحلیل اصلی فاصله گرفته
نبود ساختار کنترل کیفیت :
نبود ساختاری برای کنترل کیفیت پروژه در زمان توسعه ان باعث مشکلات متفاوتی میشه به عنوان مثال بعضی از افراد تیم مسیر اشتباهی رو برای توسعه پروژه انتخاب میکنند (به دلایل مختلفی از قبیل سو تفهام در فهم موضوع – کمبود دانش در رابطه با انجام موضوع مربوطه و ... ) و این مسیر اشتباه باید به وسیله ی یک لایه کنترل کیفیت در زمان توسعه و ابتدای انحراف تشخیص داده بشه شاید در توسعه نرم افزار یک سرپرست فنی برای هر بخش با انجام code review و جلسات تصمیم گیری گروهی بتونه این عمل رو انجام بده
پیچیده سازی بیش از حد مسئله :
به نوعی عمل over engineering که برنامه نویس سعی میکند به پیچیده ترین حالت ممکن یک مسئله ساده را حل کنید به عنوان مثال استفاده از یک فریم ورک و یا یک ابزار پیچیده برای انجام یک عمل ساده که دلیل این اتفاق ممکن است به خاطر نبود تجربه کافی یا متوجه نشدن نیاز ها پروژه باشد
داکیومنت سازی :
عمل داکیومنت سازی تاثیر مستقیمی بر نگهداری کد ها خواهد داشت و جدا از این مسئله باعث می شود که مراحل توسعه در ذهن توسعه دهنده ساختار یافته بشه و درک توسعه دهنده از کاری که انجام میده بیشر بشه البته به نظرم نیازی نیست که برای تمام مسائل یک پروژه داکیومنت تهییه بشود بلکه بیشتر قسمت های پروژه باید self-document باشه
تجربه نوشت :
سعی کنید ابتدای کار تحلیلتون رو به گونه ای انجام بدید که در حد منابع موجود و نیاز های موجود بیشترین انعطاف و چالاکی را داشته باشد تا در مقابل نیاز های اینده دچار مشکل نشود و با کمترین هزینه بتواند با نیاز های جدید وفق پیدا کند
...........
