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