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