اگر قرار است برای ساخت نرمافزار سفارشی از چند شرکت پیشنهاد بگیرید، RFP باید به همه آنها یک مسئله، دامنه و معیار سنجش مشترک بدهد. سند خوب نه آنقدر مبهم است که هر فروشنده برداشت متفاوتی داشته باشد و نه آنقدر راهحل را از پیش دیکته میکند که جایی برای تخصص تیم اجرا نماند. نتیجه باید این باشد: پیشنهادها را بر اساس ارزش، ریسک، روش اجرا و هزینه کل مقایسه کنید؛ نه صرفاً یک عدد نهایی یا فهرستی از امکانات.
این راهنما یک الگوی اجرایی برای نوشتن RFP نرمافزار سفارشی است. میتوانید ۱۲ بخش اصلی آن را مستقیم به سند خود منتقل کنید، برای هر ادعا مدرک بخواهید و معیارهای پذیرش را پیش از انتخاب پیمانکار روشن کنید. اگر هنوز درباره مسیر کلی پروژه تصمیم نگرفتهاید، ابتدا راهنمای طراحی و ساخت نرمافزار سفارشی را بخوانید و سپس اطلاعات تصمیمگیری را در قالب زیر منظم کنید.
RFP نرمافزار چیست و چه چیزی نیست؟
درخواست پیشنهاد یا RFP سندی است که مسئله کسبوکار، نتیجه مورد انتظار، محدودیتها و روش ارزیابی پیشنهادها را بهصورت یکسان در اختیار تأمینکنندگان قرار میدهد. هدف آن گرفتن پاسخهای قابل مقایسه و کشف ریسکهای پروژه پیش از قرارداد است.
RFP «فهرست آرزوها» نیست. جملههایی مانند «سیستم مدرن، هوشمند و کاربرپسند باشد» نه قابل قیمتگذاریاند و نه قابل آزمون. همچنین RFP نباید یک طراحی فنی قطعی را بدون شناخت کافی تحمیل کند. شما باید نیاز، داده، محدودیت و نتیجه را دقیق تعریف کنید و از فروشنده بخواهید معماری، فرضها و انتخابهایش را توضیح دهد.
۱۲ بخش اصلی RFP نرمافزار سفارشی
۱. زمینه، مسئله و نتیجه کسبوکار
سند را با معرفی کوتاه سازمان، واحد سفارشدهنده و دلیل آغاز پروژه شروع کنید. وضعیت فعلی را با شواهد قابل مشاهده شرح دهید: کار در کدام مرحله متوقف میشود؟ چه دوبارهکاریهایی وجود دارد؟ چه اطلاعاتی دیر، ناقص یا ناسازگار به دست مدیر میرسد؟ از جملههای کلی مثل «افزایش بهرهوری» عبور کنید و نتیجه مطلوب را به شاخصی تبدیل کنید که بعداً قابل اندازهگیری باشد.
برای هر نتیجه، خط مبنا، هدف، روش اندازهگیری و مالک اندازهگیری را بنویسید. برای مثال: «زمان آمادهسازی گزارش سفارش از دو روز کاری به کمتر از دو ساعت برسد؛ زمان از ثبت درخواست تا تولید فایل نهایی در محیط عملیاتی اندازهگیری شود.» اگر خط مبنا هنوز معلوم نیست، همین را صادقانه ثبت کنید و اندازهگیری آن را جزو مرحله کشف قرار دهید.
۲. کاربران، نقشها و فرایند واقعی
نام نقشهای واقعی را بنویسید: کارشناس فروش، سرپرست، حسابدار، مشتری، مدیر سامانه یا کاربر مهمان. برای هر نقش، هدف، سطح دسترسی، تعداد تقریبی کاربران همزمان، دستگاه و شرایط استفاده را توضیح دهید. کاربری که پشت رایانه اداری است با تکنسینی که اینترنت ناپایدار و تلفن همراه دارد نیاز یکسانی ندارد.
فرایند موجود و فرایند مطلوب را مرحلهبهمرحله رسم یا توصیف کنید. ورودی، تصمیم، استثنا، تأیید، خروجی و مسئول هر گام باید معلوم باشد. فقط مسیر موفق را ننویسید؛ لغو، برگشت، اصلاح، تکرار، عدم دسترسی و تعارض دادهها نیز بخشی از کار واقعیاند.
نیازها را میتوان به صورت داستان کاربر نوشت: «بهعنوان سرپرست فروش، میخواهم درخواست تخفیف خارج از سقف را همراه سابقه تصمیم ببینم تا پاسخ مستند بدهم.» راهنمای رسمی نوشتن داستان کاربر و معیار پذیرش در GOV.UK تأکید میکند که نقش، نیاز و هدف باید روشن باشد. هر داستان مهم را به یک outcome و معیار پذیرش مرتبط کنید تا قابلیت ردیابی شکل بگیرد.
۳. دامنه، مرزها و موارد خارج از دامنه
دامنه را با ماژولها و فرایندهایی بنویسید که در این قرارداد تحویل میشوند، نه با واژههای مبهمی مانند «سیستم یکپارچه». برای هر ماژول، کاربران، ورودیها، خروجیها و وابستگیهای اصلی را ذکر کنید. محیطهای توسعه، آزمایش و عملیاتی و همچنین سازمان یا شعبههایی که مشمول پروژهاند نیز باید مشخص باشند.
یک فهرست صریح از out-of-scope بسازید. برای نمونه: «بازطراحی وبسایت عمومی، خرید سختافزار شعب و پاکسازی سوابق پیش از سال مشخص در این مرحله نیست.» مواردی را که احتمال دارد بعداً درخواست شوند در بخش «گزینههای آینده» قرار دهید، اما از فروشنده بخواهید اثر احتمالی آنها بر معماری را بیان کند.
۴. نیازمندیهای عملکردی قابل آزمون
از فروشنده بخواهید مقابل هر نیاز یکی از این وضعیتها را اعلام کند: موجود در هسته، نیازمند پیکربندی، نیازمند توسعه، متکی به سرویس ثالث، یا خارج از پیشنهاد. پاسخ بله/خیر کافی نیست؛ روش تحقق و محدودیت باید نوشته شود. برای قابلیتهای حساس، سناریوی پذیرش اضافه کنید؛ مانند «وقتی دو کاربر همزمان یک رکورد را ویرایش میکنند، سامانه تعارض را نمایش دهد و از بازنویسی بیخبر جلوگیری کند.»
۵. الزامات غیرعملکردی و کیفیت سرویس
غیرعملکردیها مشخص میکنند نرمافزار چگونه باید کار کند. عملکرد، دسترسپذیری سرویس، ظرفیت، مقیاسپذیری، سازگاری مرورگر، قابلیت نگهداری، مشاهدهپذیری و بازیابی را با شرایط آزمون تعریف کنید. عبارت «سرعت بالا» را به سناریو تبدیل کنید: حجم داده نمونه، تعداد کاربر همزمان، عملیات مورد آزمون، صدک یا حداکثر زمان پاسخ و محیط اندازهگیری.
۶. داده، کیفیت داده و مهاجرت
منابع داده را فهرست کنید: فایلها، پایگاههای داده، نرمافزار قبلی، اسناد اسکنشده یا سرویسهای بیرونی. برای هر منبع، مالک، قالب، حجم تقریبی، کیفیت، حساسیت، تناوب تغییر و نمونه قابل ارائه را ثبت کنید. مشخص کنید کدام داده مرجع است و در صورت اختلاف، کدام سامانه حقیقت نهایی محسوب میشود.
مهاجرت را به «انتقال داده» تقلیل ندهید. نگاشت فیلدها، پاکسازی، حذف تکراریها، قواعد تبدیل، اعتبارسنجی، مهاجرت آزمایشی، تطبیق نتایج، زمان توقف و برنامه بازگشت لازماند. اگر پروژه جایگزین سامانه قدیمی است، راهنمای نوسازی نرمافزارهای قدیمی به تفکیک ریسک داده، همزیستی دو سامانه و مهاجرت مرحلهای کمک میکند.
۷. یکپارچهسازیها و قراردادهای تبادل
برای هر اتصال، نام سامانه، مالک فنی، روش ارتباط، جهت جریان داده، تناوب، حجم، احراز هویت، محدودیت نرخ، محیط آزمایش و مسئول هزینه را بنویسید. اگر API مستند یا sandbox وجود دارد، لینک یا فایل آن را در پیوست بدهید. اگر وجود ندارد، این موضوع باید بهعنوان ریسک قیمت و زمان دیده شود.
رفتار در شکست را مشخص کنید: سامانه چند بار تلاش میکند؟ پیام در کجا نگهداری میشود؟ چه کسی هشدار میگیرد؟ آیا عملیات idempotent است؟ چگونه مغایرت شناسایی و دوباره پردازش میشود؟ پذیرش یکپارچهسازی فقط دریافت پاسخ ۲۰۰ نیست؛ کامل بودن داده، کنترل تکرار، ثبت رویداد و بازیابی از قطعی نیز باید آزمون شود.
۸. امنیت، حریم خصوصی و دسترسپذیری
نوع داده و سطح حساسیت آن را مشخص کنید و سپس کنترل متناسب بخواهید: مدیریت هویت، حداقل دسترسی، تفکیک نقشها، ثبت رویداد، رمزنگاری در انتقال و نگهداری، مدیریت رازها، پشتیبانگیری، پاسخ به رخداد و حذف یا نگهداری داده. از ادعای کلی «امن است» نپذیرید؛ مدرک، آزمون و مسئول اصلاح نقص را تعریف کنید.
چارچوب توسعه امن نرمافزار NIST SSDF برای گنجاندن شیوههای امنیتی در چرخه توسعه واژگان مشترکی میدهد. برای نرمافزار وب، استاندارد راستیآزمایی امنیت برنامه OWASP ASVS میتواند مبنای انتخاب کنترلها و آزمون باشد؛ اما سطح و الزامات متناسب را با تحلیل ریسک پروژه تعیین کنید و نسخه مرجع را در RFP بنویسید.
دسترسپذیری را هم به «پشتیبانی از افراد دارای معلولیت» محدود نکنید. سطح انطباق، صفحات و جریانهای مشمول، روش آزمون دستی و خودکار و مسئول رفع نقص را تعیین کنید. استاندارد WCAG 2.2 از W3C معیارهای قابل آزمونی برای ادراکپذیری، کارکردپذیری، فهمپذیری و استحکام ارائه میدهد. اگر داده شخصی پردازش میشود، هدف پردازش، حداقلسازی داده، نقشها، محل نگهداری و فرایند درخواست حذف یا اصلاح را نیز در محدوده قراردادی روشن کنید؛ بدون اینکه متن RFP را جایگزین بررسی حقوقی تخصصی بدانید.
۹. اقلام تحویلی، مالکیت فکری و تحویلگیری
خروجی پروژه فقط نسخه اجرایی نیست. کد منبع، مخزن و تاریخچه، اسکریپت استقرار، تعریف زیرساخت، طرح پایگاه داده، مستند API، راهنمای کاربر و مدیر، آزمونها، فهرست وابستگیها، صورتجلسه آموزش و برنامه انتقال دانش را صریح فهرست کنید. قالب فایل، زبان مستندات، سطح جزئیات و زمان تحویل هر مورد را بنویسید.
روشن کنید مالکیت چه چیزهایی منتقل میشود، مجوز اجزای از پیش موجود چیست، استفاده از کتابخانههای متنباز چگونه ثبت میشود و دسترسیهای فنی در پایان پروژه چگونه تحویل داده میشوند. درباره کد مشترک یا محصول پایه فروشنده، مرز بخش اختصاصی و حقوق استفاده باید در پیشنهاد آشکار باشد. این متن جای مشاوره حقوقی را نمیگیرد؛ هدف آن حذف ابهام پیش از ارزیابی قراردادی است.
۱۰. زمانبندی، حاکمیت و کنترل تغییر
بهجای یک تاریخ نهایی تنها، نقاط تصمیم را تعریف کنید: کشف و اعتبارسنجی دامنه، نمونه اولیه، نسخه قابل استفاده، آزمون پذیرش، آمادهسازی داده، راهاندازی و دوره تثبیت. وابستگی هر نقطه به تأیید یا ورودی مشتری را بنویسید. از فروشنده بخواهید برنامه را همراه فرضها، ظرفیت تیم، مسیر بحرانی و ریسکها ارائه کند.
نقشها را در یک جدول مسئولیت مشخص کنید: مالک محصول، نماینده کاربران، مدیر پروژه، مسئول امنیت، مالک داده و تصمیمگیر نهایی. تناوب گزارش، محتوای گزارش وضعیت، شیوه ثبت تصمیم و زمان پاسخ به پرسشها را تعیین کنید. راهنمای DDaT دولت بریتانیا نیز بر تعریف مسئله، خروجیها، معیارهای پذیرش، مدیریت ریسک و برنامه انتقال تأکید دارد.
۱۱. پذیرش، آزمون، بهرهبرداری و سطح خدمت
برای هر تحویل، تعریف Done و معیار پذیرش داشته باشید. مشخص کنید چه کسی آزمون میکند، داده و محیط آزمون را چه کسی فراهم میکند، نقصها چگونه درجهبندی میشوند، مهلت اصلاح چیست و چه شرایطی باعث رد یا پذیرش مشروط میشود. نیازمندی، آزمون و مدرک نتیجه باید قابل ردیابی باشند.
انواع آزمون را متناسب با ریسک انتخاب کنید: عملکردی، یکپارچهسازی، مهاجرت، کارایی، امنیت، دسترسپذیری، بازیابی و پذیرش کاربر. فروشنده باید خروجی آزمونهای خود را پیش از تحویل ارائه کند؛ مشتری نیز سناریوهای کسبوکار را مستقل بررسی کند. برای راهاندازی، معیار go/no-go، برنامه rollback و دوره پشتیبانی نزدیک پس از انتشار را بنویسید.
در بهرهبرداری، بین SLA و SLO تمایز بگذارید. SLO هدف عملیاتی قابل اندازهگیری مانند دسترسپذیری یا زمان پاسخ است؛ SLA تعهد توافقشده و پیامد نقض آن را مشخص میکند. ساعات پشتیبانی، کانال ثبت رخداد، شدتها، زمان پاسخ و بازیابی، نگهداری برنامهریزیشده، پایش، مالک هشدار، پشتیبانگیری و آزمون بازگردانی را در پیشنهاد بخواهید. عدد سختگیرانهای که نیاز واقعی یا امکان اندازهگیری ندارد، فقط هزینه را بالا میبرد.
۱۲. قالب پاسخ فروشنده، قیمت و مفروضات TCO
برای قابل مقایسه شدن پاسخها، یک قالب اجباری بدهید: خلاصه راهحل، جدول انطباق نیازها، معماری پیشنهادی، برنامه و تیم، پروژههای مشابه قابل راستیآزمایی، ریسکها، وابستگیها، استثناها، اقلام تحویلی، پشتیبانی و قیمت تفکیکی. از فروشنده بخواهید فرضهای خود را جداگانه بنویسد و پرسشها را تا یک تاریخ مشترک ارسال کند؛ سپس پاسخ پرسشهای غیرمحرمانه را همزمان در اختیار همه شرکتکنندگان بگذارید.
قیمت را به کشف، طراحی، توسعه، یکپارچهسازی، مهاجرت، آزمون، آموزش، استقرار، پشتیبانی و گزینههای آینده تفکیک کنید. مدل پرداخت، مالیات یا هزینههای ثالث، ارز و مدت اعتبار پیشنهاد باید آشکار باشد. برای برآورد واقعبینانهتر، عوامل هزینه نرمافزار سفارشی و بودجهریزی آن را در کنار قیمت اولیه بررسی کنید.
ماتریس ارزیابی پیشنهادها را قبل از دریافت پاسخ بسازید
وزنها را پیش از دیدن نام و قیمت پیشنهاددهندگان تعیین کنید. یک نمونه قابل تنظیم:
| معیار | وزن نمونه | مدرک مورد انتظار | |---|---:|---| | درک مسئله و تناسب راهحل | ۲۰٪ | پاسخ به outcomeها، محدودیتها و سناریوی نمونه | | پوشش نیازمندیها و کیفیت فنی | ۲۰٪ | جدول انطباق، معماری و رویکرد داده و یکپارچهسازی | | امنیت، کیفیت و آزمونپذیری | ۱۵٪ | کنترلهای منتخب، برنامه آزمون و نمونه خروجی کیفیت | | روش اجرا، تیم و حاکمیت | ۱۵٪ | نقش افراد، ظرفیت، برنامه و مدیریت ریسک و تغییر | | تحویلپذیری و پشتیبانی | ۱۰٪ | مستندات، انتقال دانش، SLA/SLO و برنامه خروج | | هزینه کل مالکیت | ۲۰٪ | قیمت تفکیکی، مفروضات و هزینههای دوره بهرهبرداری |
نمونه فشرده: RFP سامانه خدمات پس از فروش
فرض کنید شرکت میخواهد درخواستهای خدماتی را که اکنون از تلفن، پیامرسان و فایل صفحهگسترده میآیند یکپارچه کند. outcome نخست کاهش زمان تخصیص درخواست است؛ outcome دوم مشاهده تاریخچه کامل هر دستگاه توسط کارشناس مجاز. نسخه اول شامل ثبت درخواست، تشخیص مشتری و دستگاه، صف اولویت، تخصیص تکنسین، ثبت قطعه، تأیید مشتری و گزارش عملیات است. فروش اینترنتی قطعه و حسابداری کامل خارج از دامنهاند.
یک نیاز عملکردی قابل آزمون: «وقتی درخواست دارای سطح فوریت بالا ثبت میشود، سامانه آن را بر اساس منطقه و مهارت به صف مناسب بفرستد، زمان رویداد را ثبت کند و اگر تا ۱۵ دقیقه تخصیص نیافت به سرپرست هشدار دهد.» یک الزام غیرعملکردی: «در آزمون توافقشده با ۱۰۰ کاربر همزمان و داده نمونه تأییدشده، نمایش فهرست درخواستهای فعال برای دستکم ۹۵ درصد درخواستها کمتر از دو ثانیه طول بکشد.» این اعداد فقط مثالاند؛ در RFP واقعی باید از بار کاری و نیاز عملیاتی شما بیایند.
چکلیست نهایی پیش از ارسال RFP
- مالک هر تصمیم، outcome و داده مشخص است.
- وضعیت فعلی، خط مبنا و نتیجه مطلوب از هم جدا نوشته شدهاند.
- کاربران، فرایند اصلی و استثناها با نماینده کاربر واقعی مرور شدهاند.
- دامنه، خارج از دامنه، وابستگیها و مسئولیتهای مشتری شفافاند.
- هر نیاز مهم شناسه، اولویت و معیار پذیرش قابل آزمون دارد.
- حجم داده، کاربران همزمان و سناریوی کارایی برآورد شدهاند.
- نمونه داده و مستند یکپارچهسازی پس از حذف اطلاعات حساس آماده است.
- الزامات امنیت، حریم خصوصی و دسترسپذیری متناسب با ریسکاند.
- اقلام تحویلی، دسترسی مخزن، مستندات و برنامه خروج فهرست شدهاند.
- نقاط تصمیم، حاکمیت، کنترل تغییر و فرایند امضای پذیرش روشناند.
- قیمتها در قالب یکسان و با مفروضات TCO درخواست شدهاند.
- ماتریس امتیازدهی و معیارهای حذفی پیش از مشاهده پیشنهادها تصویب شدهاند.
- مهلت پرسش، روش پاسخ مشترک، تاریخ تحویل و مدت اعتبار پیشنهاد معلوم است.
خطاهایی که مقایسه را خراب میکنند
**الزامات غیرقابل آزمون:** «ساده»، «سریع» و «امن» بدون سناریو، آستانه و مدرک در زمان پذیرش قابل داوری نیستند.
**پنهان کردن کیفیت داده:** قیمت مهاجرت بر اساس فایل نمونه تمیز با واقعیت چند منبع ناسازگار تفاوت دارد. نمونه ناشناس اما نماینده واقعیت ارائه کنید.
**امتیازدهی بعد از دیدن پیشنهادها:** تغییر معیار پس از مشاهده قیمت یا نام فروشنده سوگیری ایجاد میکند. وزن و شواهد لازم را زودتر ثبت کنید.
از RFP قابل مقایسه تا پروژه قابل تحویل
یک RFP موفق باید سه پرسش را بیابهام پاسخ دهد: چه نتیجهای میخواهیم، موفقیت را چگونه میسنجیم و هر پیشنهاد چه فرض و ریسکی دارد. وقتی ۱۲ بخش بالا کامل باشند، جلسه فروش به گفتوگویی دقیق درباره trade-offها تبدیل میشود و انتخاب تیم اجرا قابل دفاعتر خواهد بود.
اگر میخواهید دامنه، معماری اولیه و معیارهای پذیرش پروژهتان پیش از استعلام بررسی شود، صفحه خدمات طراحی نرمافزار سفارشی ایزیساز را ببینید. برای شروع ارزیابی و ارسال خلاصه نیازها نیز میتوانید از فرم تماس و مشاوره پروژه استفاده کنید.