بیشتر پروژه‌های نرم‌افزاری نه به‌خاطر یک اتفاق بزرگ، بلکه به‌خاطر چند مشکل کوچک و قابل پیش‌بینی دیر تحویل می‌شوند: نیازهایی که روشن تعریف نشده‌اند، قابلیت‌هایی که در میانه کار اضافه می‌شوند، برآوردی خوش‌بینانه، و تصمیم‌ها و داده‌هایی که دیر از سمت کارفرما می‌رسند. خبر خوب این است که تقریباً همه این عوامل با برنامه‌ریزی درست، تحویل مرحله‌ای و کنترل تغییرات قابل مهار هستند. در این مقاله دلایل اصلی تاخیر در پروژه نرم افزاری، نشانه‌های هشدار هر کدام و کارهایی را که مجری و کارفرما برای جلوگیری از آن می‌توانند انجام دهند مرور می‌کنیم.
دلایل اصلی تأخیر در پروژه‌های نرم‌افزاری
۱. نیازهای مبهم
وقتی نیاز در حد یک جمله کلی تعریف شده باشد، مثل «سامانه باید گزارش‌های مدیریتی داشته باشد»، هر طرف برداشت خودش را دارد. اختلاف این برداشت‌ها معمولاً در زمان تحویل آشکار می‌شود؛ یعنی دیرترین و پرهزینه‌ترین زمان ممکن.
۲. گسترش تدریجی دامنه (Scope creep)
هر درخواست کوچک به‌تنهایی منطقی به نظر می‌رسد، اما ده‌ها تغییر کوچک بدون بازنگری در زمان‌بندی، برنامه را عملاً بی‌اعتبار می‌کند.
۳. برآورد کمتر از واقع
برآوردها اغلب فقط زمان برنامه‌نویسی را می‌بینند و تحلیل، آزمون، رفع اشکال، استقرار، آموزش و جلسات را از قلم می‌اندازند.
۴. تصمیم‌ها و داده‌هایی که دیر می‌رسند
تأیید طرح‌ها، پاسخ به پرسش‌های تحلیلی، دسترسی به سرور یا ارسال داده‌های نمونه اگر هفته‌ها طول بکشد، تیم یا منتظر می‌ماند یا بر اساس حدس کار می‌کند و بعداً باید دوباره‌کاری کند.
۵. غافلگیری در یکپارچه‌سازی و انتقال داده
اتصال به سامانه‌های دیگر، وب‌سرویس‌های بدون مستندات یا داده‌های ناسازگار سامانه قدیمی، از رایج‌ترین منابع کارهای پیش‌بینی‌نشده است.
۶. مشکلات نیروی انسانی
جابه‌جایی اعضای کلیدی تیم، کار هم‌زمان روی چند پروژه یا وابستگی کل دانش پروژه به یک نفر، سرعت کار را به‌طور ناگهانی کم می‌کند.
۷. فشرده شدن زمان آزمون
وقتی مراحل قبلی دیر تمام می‌شود، معمولاً از زمان آزمون کم می‌شود؛ نتیجه، اشکال‌هایی است که پس از تحویل پیدا می‌شوند و تحویل نهایی را باز هم عقب می‌اندازند.
جدول دلیل، نشانه و راهکار
| دلیل | نشانه هشدار | راهکار |
|---|---|---|
| نیازهای مبهم | سند نیاز وجود ندارد یا قابلیت‌ها معیار پذیرش ندارند | سند نیازمندی با معیار پذیرش برای هر قابلیت |
| گسترش دامنه | درخواست‌های جدید بدون ثبت و برآورد به تیم می‌رسد | فرایند کنترل تغییر و ثبت هر تغییر با اثر آن بر زمان و هزینه |
| برآورد خوش‌بینانه | برنامه زمانی هیچ حاشیه‌ای برای آزمون و رفع اشکال ندارد | برآورد بر اساس پروژه‌های مشابه و در نظر گرفتن همه مراحل |
| تأخیر در تصمیم‌ها و داده‌ها | فهرست پرسش‌های بی‌پاسخ کارفرما هر هفته طولانی‌تر می‌شود | یک تصمیم‌گیرنده مشخص و مهلت پاسخ توافق‌شده |
| یکپارچه‌سازی و انتقال داده | هنوز کسی داده یا وب‌سرویس سامانه قدیمی را واقعاً ندیده است | بررسی زودهنگام داده و رابط‌ها و آزمون انتقال در فازهای اول |
| نیروی انسانی | فقط یک نفر از بخشی از سامانه سر درمی‌آورد | مستندسازی، بازبینی کد و پوشش متقابل اعضای تیم |
| آزمون فشرده | آزمون فقط در پایان پروژه برنامه‌ریزی شده است | آزمون در هر مرحله و آزمون پذیرش تدریجی توسط کارفرما |
نرم‌افزار یا اپلیکیشن اختصاصی لازم دارید؟
شرکت نرم‌افزاری ژابیز پردا از ۱۳۸۰ برای سازمان‌ها نرم‌افزار سفارشی، اپلیکیشن موبایل و سامانه تحت وب می‌سازد.
درخواست دمو و مشاوره رایگانتماس: ۰۲۱-۹۱۳۰۲۴۲۷خدمات ژابیز پردا
راهکارهای عملی برای جلوگیری از تأخیر
- سند نیازمندی با معیار پذیرش: برای هر قابلیت بنویسید «چه زمانی می‌گوییم این کار تمام شده است». این سند مبنای برآورد، آزمون و تحویل است.
- تحویل مرحله‌ای و نسخه حداقلی (MVP): به‌جای یک تحویل بزرگ در پایان، نسخه‌ای کوچک اما قابل استفاده زودتر تحویل شود و بقیه قابلیت‌ها در فازهای بعدی بیایند.
- کنترل تغییرات: هر تغییر ثبت، برآورد و تأیید شود و اثر آن بر زمان‌بندی صریحاً پذیرفته شود؛ یا تغییر به فاز بعد منتقل شود.
- نمایش هفتگی یا دوهفتگی: دیدن نسخه در حال کار، سوءتفاهم‌ها را زود آشکار می‌کند؛ وقتی اصلاح هنوز ارزان است.
- یک تصمیم‌گیرنده واحد در سمت کارفرما: بازخوردهای متناقض از چند واحد، یکی از دلایل پنهان دوباره‌کاری است.
- فهرست ریسک‌ها: ریسک‌هایی مثل انتقال داده یا اتصال به سامانه دیگر از ابتدا فهرست و برای هر کدام اقدام پیشگیرانه تعریف شود.
برنامه‌ریزی زودهنگام انتقال داده نمونه خوبی از مدیریت ریسک است. در پروژه سامانه جامع آمار تولید ایمیدرو، انتقال کامل داده‌ها از سامانه قبلی بخشی از کار بود؛ چنین کاری اگر به روزهای آخر موکول شود، به‌راحتی تحویل را عقب می‌اندازد.
کارفرما چه کاری می‌تواند انجام دهد؟
بخش مهمی از زمان‌بندی پروژه در دست کارفرماست، نه فقط مجری:
- پیش از شروع، اولویت‌ها را مشخص کنید: کدام قابلیت‌ها برای نسخه اول ضروری است و کدام می‌تواند صبر کند.
- یک نماینده تام‌الاختیار با زمان کافی برای پروژه تعیین کنید.
- دسترسی‌ها، سرور، داده‌های نمونه و مستندات سامانه‌های موجود را در هفته‌های اول فراهم کنید.
- در جلسات نمایش شرکت کنید و بازخورد را مکتوب و یکجا بدهید.
- درخواست‌های جدید را از مسیر فرایند تغییر مطرح کنید و اثر آن بر زمان را بپذیرید یا آن را به فاز بعد بسپارید.
- زمان کافی برای آزمون پذیرش و آموزش کاربران در برنامه خود در نظر بگیرید.
اگر پروژه را به یک شرکت بیرونی سپرده‌اید، بخش بزرگی از این موارد در قرارداد تعیین می‌شود؛ نکات آن را در مقاله برون‌سپاری توسعه نرم‌افزار آورده‌ایم. برای پروژه‌های موبایل هم برآورد مراحل را در مقاله مدت زمان ساخت اپلیکیشن ببینید.
مدیریت پروژه نرم‌افزاری در ژابیز پردا
ژابیز پردا از سال ۱۳۸۰ بیش از ۱۰۰ سیستم اطلاعاتی برای سازمان‌های دولتی و خصوصی ساخته است. در پروژه‌هایمان کار را با تحلیل نیاز و سند معیار پذیرش شروع می‌کنیم، سامانه را در فازهای قابل استفاده تحویل می‌دهیم و تغییرات را با فرایند مشخص مدیریت می‌کنیم. برای فرایندهای سازمانی هم ابزارهای آماده‌ای مثل سامانه BPMS دریچه زمان ساخت را کوتاه‌تر می‌کند. فهرست کامل خدمات نرم‌افزاری ژابیز پردا را ببینید یا با شماره ۰۲۱-۹۱۳۰۲۴۲۷ تماس بگیرید.
پرسش‌های متداول
رایج‌ترین دلیل تأخیر پروژه نرم‌افزاری چیست؟
نیازهای مبهم و تغییرات کنترل‌نشده دامنه. این دو معمولاً با هم می‌آیند: وقتی نیاز از ابتدا روشن نیست، در طول کار مدام تکمیل و تغییر می‌کند.
اضافه کردن نیرو به پروژه عقب‌افتاده آن را جلو می‌اندازد؟
نه همیشه. نیروی جدید زمان می‌برد تا با سامانه آشنا شود و در کوتاه‌مدت از وقت اعضای فعلی هم می‌گیرد. کوچک کردن دامنه فاز فعلی اغلب اثر سریع‌تری دارد.
از کجا بفهمیم پروژه در خطر تأخیر است؟
اگر چند هفته است نسخه قابل نمایشی ندیده‌اید، فهرست پرسش‌های بی‌پاسخ بلند شده یا درخواست‌های جدید بدون برآورد به تیم می‌رسد، وقت بازنگری در برنامه است.