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