RFP طراحی سایت سندی برای هم‌راستا کردن نیاز کسب‌وکار با پیشنهاد شرکت‌های اجراکننده است. این سند باید مسئله، کاربر، دامنه، محدودیت و روش انتخاب را روشن کند؛ نه اینکه فقط فهرستی بلند از امکانات یا سلیقه‌های بصری باشد.
این راهنما موضوع را در مرز کاربردی خودش بررسی می‌کند. برای تکمیل مسیر، مطالعهٔ مراحل طراحی سایت، انتخاب شرکت طراحی سایت و چک‌لیست طراحی سایت به تصمیم‌گیری دقیق‌تر کمک می‌کند. لینک‌ها به صفحات منتشرشده و مرتبط همین سایت متصل‌اند.
تعریف مسئله و دلیل شروع پروژه
مسئله را با وضعیت فعلی، اثر آن بر فروش یا عملیات و دلیل انتخاب زمان شروع توضیح دهید؛ عبارت‌هایی مثل سایت مدرن یا حرفه‌ای معیار پذیرش نیستند. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «تعریف مسئله و دلیل شروع پروژه» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
خلاصه کسب‌وکار و مخاطبان
معرفی کسب‌وکار باید محصول، بازار، مزیت رقابتی، ذی‌نفعان و محدودیت‌های برند را به اندازه‌ای روشن کند که پیمانکار زمینه تصمیم را بفهمد. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «خلاصه کسب‌وکار و مخاطبان» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
هدف‌های قابل سنجش
هدف‌ها را به رفتار قابل سنجش مانند درخواست مشاوره واجد شرایط، کاهش پرسش تکراری یا تکمیل بهتر فرم وصل کنید و خط پایه را ثبت کنید. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «هدف‌های قابل سنجش» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
سناریوهای اصلی کاربران
برای هر گروه کاربر، وظیفه اصلی، مانع، اطلاعات مورد نیاز و اقدام نهایی را بنویسید؛ پرسوناهای طولانی بدون شواهد ضرورت ندارند. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «سناریوهای اصلی کاربران» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
دامنه صفحات و محتوا
انواع صفحه و مسئول تولید، تأیید، ترجمه و ورود محتوا را مشخص کنید؛ تأخیر محتوا یکی از علت‌های اصلی عقب‌افتادن پروژه است. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «دامنه صفحات و محتوا» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
اولویت‌بندی قابلیت‌ها
قابلیت‌ها را به ضروری، مهم و قابل تعویق تقسیم کنید و برای هر قابلیت دلیل، مالک داده و معیار پذیرش بنویسید. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «اولویت‌بندی قابلیت‌ها» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
نیازهای فنی و امنیت
میزبانی، پشتیبان‌گیری، نقش‌های دسترسی، ثبت رخداد، به‌روزرسانی، مرورگر هدف و سطح دسترسی‌پذیری باید شفاف باشند. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «نیازهای فنی و امنیت» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
سئو و برنامه مهاجرت
فهرست URLهای ارزشمند، ریدایرکت، متادیتا، canonical، sitemap، ابزار تحلیل و رویدادهای تبدیل را در دامنه مهاجرت بیاورید. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «سئو و برنامه مهاجرت» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
بودجه و تفکیک هزینه
هزینه کشف، طراحی، توسعه، محتوا، مهاجرت، مجوز، میزبانی و پشتیبانی را جدا بخواهید تا عدد نهایی قابل مقایسه باشد. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «بودجه و تفکیک هزینه» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
زمان‌بندی و نقاط عطف
برنامه را به کشف، معماری، طراحی، توسعه، ورود محتوا، آزمون و انتشار تقسیم کنید و زمان بازخورد کارفرما را نیز منظور کنید. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «زمان‌بندی و نقاط عطف» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
قالب پاسخ شرکت‌ها
از پاسخ‌دهنده بخواهید برداشت از مسئله، روش، تیم، نمونه مرتبط، برنامه، قیمت، فرضیات، موارد خارج از دامنه و ریسک‌ها را یکسان ارائه کند. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «قالب پاسخ شرکت‌ها» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
ماتریس امتیازدهی
وزن درک مسئله، کیفیت راه‌حل، تجربه مرتبط، تیم، زمان، هزینه و پشتیبانی را پیش از دریافت پیشنهاد تعیین کنید. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «ماتریس امتیازدهی» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
قرارداد و مالکیت
مالکیت کد، طراحی، محتوا، حساب‌ها و مجوزها، دوره رفع نقص، SLA، روش تغییر دامنه و خروجی آموزش باید در قرارداد روشن شود. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «قرارداد و مالکیت» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
پرسش‌های جلسه ارزیابی
در جلسه بپرسید مهم‌ترین ریسک چیست، کدام فرض نیاز به اعتبارسنجی دارد، چه چیزی در قیمت نیست و تأخیر محتوا چه اثری دارد. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «پرسش‌های جلسه ارزیابی» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
خطاهای رایج در RFP
کپی فهرست قابلیت‌های پروژه دیگر، تمرکز صرف بر ظاهر، مخفی‌کردن محدودیت و تعیین فناوری بدون دلیل، پیشنهادهای غیرواقعی تولید می‌کند. برای تصمیم‌گیری، وضعیت موجود و محدودیت‌های همین پروژه را کنار این نکته ثبت کنید. نتیجه مطلوب را به زبان قابل مشاهده بنویسید تا تیم طراحی، محتوا و فنی برداشت مشترکی داشته باشند و اختلاف سلیقه جای معیار را نگیرد.
اقدام عملی در «خطاهای رایج در RFP» این است که یک نمونه واقعی را بررسی، مسئول اجرا را مشخص و معیار پذیرش را پیش از تغییر تعیین کنید. اثر تصمیم را پس از اجرا با داده مناسب بسنجید و تاریخ، فرضیه و یافته را مستند کنید. اگر نتیجه مطلوب نبود، علت را میان تعریف مسئله و کیفیت پیاده‌سازی تفکیک کنید؛ سپس اصلاح بعدی را محدود و قابل آزمون نگه دارید.
ماتریس امتیازدهی
در موضوع «ماتریس امتیازدهی» ابتدا باید وضعیت موجود و مسئلهٔ واقعی ثبت شود. تصمیمی که فقط بر سلیقه یا یک شاخص جدا تکیه کند، معمولاً اثر جانبی را پنهان می‌کند. ورودی‌ها، افراد درگیر، محدودیت فنی و نتیجهٔ مورد انتظار را کوتاه و روشن بنویسید تا برداشت اعضای تیم یکسان شود. هر ادعا را تا جای ممکن به داده، نمونهٔ قابل مشاهده یا نیاز مستقیم کاربر وصل کنید و اگر شواهد کافی ندارید، آن را به‌عنوان فرضیه نگه دارید.
قرارداد و مالکیت
در موضوع «قرارداد و مالکیت» ابتدا باید وضعیت موجود و مسئلهٔ واقعی ثبت شود. تصمیمی که فقط بر سلیقه یا یک شاخص جدا تکیه کند، معمولاً اثر جانبی را پنهان می‌کند. ورودی‌ها، افراد درگیر، محدودیت فنی و نتیجهٔ مورد انتظار را کوتاه و روشن بنویسید تا برداشت اعضای تیم یکسان شود. هر ادعا را تا جای ممکن به داده، نمونهٔ قابل مشاهده یا نیاز مستقیم کاربر وصل کنید و اگر شواهد کافی ندارید، آن را به‌عنوان فرضیه نگه دارید.
پرسش‌های جلسه ارزیابی
در موضوع «پرسش‌های جلسه ارزیابی» ابتدا باید وضعیت موجود و مسئلهٔ واقعی ثبت شود. تصمیمی که فقط بر سلیقه یا یک شاخص جدا تکیه کند، معمولاً اثر جانبی را پنهان می‌کند. ورودی‌ها، افراد درگیر، محدودیت فنی و نتیجهٔ مورد انتظار را کوتاه و روشن بنویسید تا برداشت اعضای تیم یکسان شود. هر ادعا را تا جای ممکن به داده، نمونهٔ قابل مشاهده یا نیاز مستقیم کاربر وصل کنید و اگر شواهد کافی ندارید، آن را به‌عنوان فرضیه نگه دارید.
خطاهای رایج در RFP
در موضوع «خطاهای رایج در RFP» ابتدا باید وضعیت موجود و مسئلهٔ واقعی ثبت شود. تصمیمی که فقط بر سلیقه یا یک شاخص جدا تکیه کند، معمولاً اثر جانبی را پنهان می‌کند. ورودی‌ها، افراد درگیر، محدودیت فنی و نتیجهٔ مورد انتظار را کوتاه و روشن بنویسید تا برداشت اعضای تیم یکسان شود. هر ادعا را تا جای ممکن به داده، نمونهٔ قابل مشاهده یا نیاز مستقیم کاربر وصل کنید و اگر شواهد کافی ندارید، آن را به‌عنوان فرضیه نگه دارید.
ماتریس ارزیابی پیشنهاد
| معیار | وزن | شاهد |
|---|---|---|
| درک مسئله | ۲۰٪ | بازگویی هدف و ریسک |
| روش اجرا | ۲۵٪ | مراحل و معیار پذیرش |
| تیم و تجربه | ۲۰٪ | نمونه مرتبط و نقش افراد |
| زمان | ۱۵٪ | برنامه و وابستگی‌ها |
| هزینه و تحویل | ۲۰٪ | تفکیک قیمت و مالکیت |
جمع‌بندی
در RFP طراحی سایت، نتیجه زمانی قابل مقایسه است که هر پیشنهاد براساس دامنه یکسان سنجیده شود. برای هر قابلیت، خروجی تحویلی، مسئول تهیه محتوا، وابستگی فنی و معیار پذیرش را بنویسید؛ سپس قیمت و زمان را در کنار فرضیات پیمانکار بررسی کنید. اگر یک پیشنهاد بخشی را «خارج از محدوده» و پیشنهاد دیگر همان بخش را شامل کرده باشد، مقایسه عدد نهایی گمراه‌کننده خواهد بود. نسخه نهایی RFP باید ابهام‌های پاسخ‌داده‌شده را نیز ثبت کند تا هنگام قرارداد، تعریف پروژه تغییر نکند.
