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