سه پیشنهاد برای ساخت سایت گرفته‌اید و نمی‌توانید هیچ‌کدام را با دیگری مقایسه کنید. یکی صفحه‌ها را شمرده، یکی امکانات را و سومی فقط یک عدد نوشته است. ریشه مشکل معمولاً جای دیگری است: تصمیم‌هایی که پیش از درخواست قیمت گرفته نشده‌اند. این راهنمای سفارش طراحی سایت همان تصمیم‌ها را به ترتیب درست جلوی شما می‌گذارد، از هدف و نوع سایت تا قرارداد و تحویل.
- نوع سایت را از مسیر خرید یا درخواست مشتری انتخاب کنید، نه از ظاهر نمونه‌کارها.
- برای هر امکان ضروری، نتیجه‌ای بنویسید که هنگام تحویل بتوان آن را آزمود.
- بودجه ساخت را از نگهداری، خدمات دوره‌ای و توسعه آینده جدا کنید.
- پیشنهادها را فقط پس از یکسان‌کردن محدوده و مسئولیت‌ها مقایسه کنید.
- انتشار سایت بدون انتقال دسترسیها، آموزش و پذیرش مکتوب، تحویل کامل نیست.
راهنمای سفارش طراحی سایت؛ از کدام تصمیم شروع کنیم؟
از هدف شروع کنید، نه از رنگ، قالب یا فناوری. سفارش طراحی وب سایت در اصل یعنی توافق بر سر یک نتیجه قابل‌آزمون و محدوده‌ای که آن نتیجه را می‌سازد. تا این توافق نباشد، هر بحثی درباره ظاهر یا ابزار روی هواست.
فرض کنید یک شرکت تأمین تجهیزات صنعتی می‌خواهد سایتش را از نو بسازد. مدیرعامل در جلسه اول می‌گوید «فروش آنلاین هم داشته باشیم». جزئیات که باز می‌شود، معلوم می‌شود قیمت هر سفارش به تعداد، زمان تحویل و شرایط پرداخت بستگی دارد. پس کار اصلی سایت فروش نیست؛ گرفتن استعلامی است که ارزش پیگیری داشته باشد.
همین یک تشخیص نیمی از تصمیم‌های بعدی را عوض می‌کند. سبد خرید و درگاه پرداخت از فهرست بیرون می‌روند. فرم استعلام دقیق، صفحه محصول کامل و پیگیری سریع تیم فروش جایشان را می‌گیرند.
پیشنهاد من این است که خروجی این مرحله را در یک جمله بنویسید:
«این سایت برای [مخاطب] ساخته می‌شود تا [کار اصلی] را انجام دهد.»
در مثال بالا جمله این می‌شود: «این سایت برای مسئولان خرید کارخانه‌ها ساخته می‌شود تا استعلام کامل و قابل‌پیگیری ثبت کنند.» کنارش یک اقدام اصلی و یک نشانه موفقیت هم بنویسید. اینجا اقدام اصلی ارسال فرم استعلام است. نشانه موفقیت هم استعلام‌هایی است که تیم فروش واجد شرایط می‌داند. اگر نتوانستید فقط یکی را انتخاب کنید، هنوز برای گرفتن قیمت زود است.
برای سفارش طراحی سایت چه تصمیم‌هایی باید بگیریم؟
برای سفارش طراحی سایت، اول هدف کسب‌وکار و اقدام اصلی مخاطب را مشخص کنید. بعد نوع سایت، روش ساخت، امکانات ضروری، بودجه ساخت و نگهداری و زمان انتشار را انتخاب کنید. پیش از قرارداد هم مسئولیت محتوا، مالکیت حساب‌ها، معیارهای پذیرش و حدود پشتیبانی باید روشن شود. آن‌وقت پیشنهادها قابل مقایسه‌اند و تحویل قابل آزمون.
ترتیب این تصمیم‌ها مهم است، چون هر کدام روی قبلی بنا می‌شود. جابه‌جایشان کنید و برآوردی می‌گیرید که روی حدس ساخته شده است:
مدل فروش پیش از امکانات: تا ندانید مشتری خرید می‌کند یا استعلام می‌دهد، فهرست امکانات معنا ندارد.
امکانات پیش از برآورد: مجری فقط برای چیزی می‌تواند قیمت بدهد که تعریفش روشن باشد.
معیار پذیرش پیش از قرارداد: اگر معلوم نباشد «تمام‌شده» یعنی چه، قرارداد از چیزی محافظت نمیکند.
برای هر تصمیم یک مسئول و یک خروجی مکتوب هم تعیین کنید. مجری فنی می‌تواند گزینه‌ها و پیامدهایشان را توضیح دهد. اما نمی‌داند کدام گروه مشتری برایتان سودآورتر است، یا تیم فروش‌تان روزی چند درخواست را می‌تواند پیگیری کند. این‌ها تصمیم تجاری‌اند و صاحبشان شما هستید.
تصمیم | مسئول اصلی | خروجی |
|---|---|---|
هدف و اقدام اصلی | مدیر کسب‌وکار | جمله هدف و نشانه موفقیت |
نوع سایت و مسیر فروش | مدیر فروش یا بازاریابی | مسیر مشتری از ورود تا اقدام |
روش ساخت | مدیر کسب‌وکار با مشورت مجری | ابزار انتخاب‌شده و دلیل آن |
امکانات نسخه اول | نماینده پروژه | فهرست اولویت‌دار با معیار پذیرش |
بودجه و زمان | مدیرعامل و مدیر مالی | سقف بودجه ساخت و نگهداری |
اگر هنوز می‌پرسید برای سفارش سایت چه کنیم وقتی همه‌چیز روشن نیست، جواب من یک جدول سه‌ستونه است. ستون اول تصمیم‌های قطعی، ستون دوم فرض‌ها و ستون سوم مواردی که بررسی می‌خواهند. مثلاً اگر نمی‌دانید اتصال سایت به نرم‌افزار انبار شدنی است یا نه، جایش ستون سوم است. بودجه‌ای که مجهولات را پشت یک عدد دقیق پنهان کند، دیر یا زود به اختلاف می‌رسد.
کدام نوع سایت با مسیر فروش شما سازگار است؟
نوعی که با کار اصلی مشتری‌تان جور باشد، نه نوعی که صفحه بیشتر یا ظاهر جذاب‌تری دارد. برای انتخاب، از خودتان بپرسید مشتری دقیقاً در سایت چه می‌کند. اعتماد می‌کند و تماس می‌گیرد، مشخصات را مقایسه می‌کند، می‌خرد یا وقت رزرو می‌کند؟
نوع سایت | کار اصلی مشتری | مناسب وقتی که |
|---|---|---|
شرکتی | شناختن شرکت، اعتماد و تماس | فروش با جلسه و مذاکره انجام می‌شود |
کاتالوگی | دیدن مشخصات و ثبت استعلام | قیمت به شرایط هر سفارش وابسته است |
فروشگاهی | انتخاب، پرداخت و پیگیری سفارش | قیمت ثابت است و موجودی قابل مدیریت |
خدماتی | رزرو، ثبت‌نام یا درخواست مشاوره | خدمت به زمان یا ظرفیت محدود بستگی دارد |
قاعده‌ای که معمولاً به آن تکیه می‌کنم ساده است. اگر قیمت یا شرایط سفارش به مذاکره بستگی دارد، کاتالوگ با فرم استعلام از سبد خرید مناسب‌تر است. در چنین کسب‌وکاری سبد خرید یا خالی می‌ماند، یا سفارش‌هایی می‌گیرد که تیم فروش باید یکی‌یکی لغوشان کند.
فروش مستقیم حساب دیگری دارد. آنجا سایت فقط ویترین است و پشتش موجودی، پرداخت، ارسال و رسیدگی به سفارش باید کار کند. پیش از سفارش روشن کنید موجودی را چه کسی به‌روز می‌کند و پرداخت ناموفق و مرجوعی با کیست. طراحی سایت برای کسب و کار فروشگاهی جای عملیات فروش را نمی‌گیرد؛ فقط آن را به مشتری نشان می‌دهد.
حالت ترکیبی هم پیش می‌آید. فرض کنید فروشنده قطعات یدکی ۳۰۰ قلم کالای استاندارد با قیمت ثابت دارد و قطعه سفارشی هم می‌سازد. اینجا مدل ترکیبی منطقی است: اقلام استاندارد با خرید آنلاین، سفارش‌های سفارشی با استعلام. شرطش این است که دو مسیر برای مخاطب کاملاً روشن باشند. دکمه «افزودن به سبد» و دکمه «درخواست قیمت» نباید روی یک صفحه با هم رقابت کنند.
سایت تک‌صفحه‌ای، صفحه فرود یا سایت کامل؟
جواب به دو چیز بستگی دارد: چند پیشنهاد مستقل دارید و مخاطب از کجا می‌آید. اول دو اصطلاح را از هم جدا کنید، چون زیاد با هم قاطی می‌شوند.
صفحه فرود (Landing Page) صفحه‌ای است برای یک ورودی یا کمپین مشخص که فقط یک اقدام از مخاطب می‌خواهد. سایت تک‌صفحه‌ای اما یک ساختار است: همه بخش‌های سایت روی یک صفحه بلند پشت هم می‌آیند. پس سایت تک‌صفحه‌ای لزوماً صفحه فرود نیست و صفحه فرود هم لزوماً تنها صفحه سایت نیست.
یک پیشنهاد مشخص با تبلیغات هدفمند: صفحه فرود.
معرفی ساده، کم‌محتوا و با یک خدمت: سایت تک‌صفحه‌ای.
چند خدمت که هر کدام مخاطب و توضیح مستقل دارند: سایت چندصفحه‌ای.
این گزینه‌ها همیشه جایگزین هم نیستند. یک سایت کامل می‌تواند برای هر کمپین صفحه فرود جدا داشته باشد. رایج‌ترین ترکیب در پروژه‌های شرکتی هم همین است: سایت اصلی برای اعتبار و جست‌وجو، صفحه‌های فرود برای تبلیغات.
این قاعده‌ها نقطه شروع‌اند، نه حکم قطعی. اگر می‌خواهید از جست‌وجوی گوگل مشتری بگیرید، هر خدمت به صفحه مستقل با محتوای کافی نیاز دارد. سایت تک‌صفحه‌ای برای چنین هدفی معمولاً تنگ است. اگر هم قصد دارید مقاله و راهنما منتشر کنید، از اول ساختاری انتخاب کنید که جای رشد داشته باشد.
سایت‌ساز، وردپرس یا توسعه اختصاصی؟
هیچ‌کدام همیشه بهتر نیست. انتخاب درست به این بستگی دارد که فرایندهای شما چقدر با الگوهای رایج فرق دارند. اول تعریف‌ها:
سایت‌ساز (Website Builder): ابزاری آنلاین با اجزای آماده که بدون برنامهنویسی صفحه می‌سازد. شروعش سریع است، اما به مرزهای همان ابزار محدود می‌مانید.
سیستم مدیریت محتوا (CMS): نرم‌افزاری که ویرایش متن، تصویر و صفحه‌ها را بدون دست‌زدن به کد ممکن می‌کند. وردپرس شناخته‌شده‌ترین نمونه آن است و با افزونه‌ها گسترش پیدا می‌کند.
توسعه اختصاصی: ساخت سایت یا بخشی از آن بر اساس نیاز ویژه شما، با کدی که برای همین پروژه نوشته می‌شود.
به جای پرسیدن «کدام بهتر است؟»، این چهار معیار را کنار هم بسنجید:
معیار | راهکار آماده‌تر کافی است اگر | بخش اختصاصی لازم می‌شود اگر |
|---|---|---|
تفاوت فرایندها | فرایندها شبیه الگوی رایج‌اند | قیمت‌گذاری یا تأیید خاصی دارید |
اتصال به سامانه‌ها | اتصالها کم و استاندارند | باید با نرم‌افزار داخلی داده رد و بدل شود |
توان نگهداری | تیم فنی داخلی ندارید | تیم یا مجری ثابتی برای نگهداری دارید |
انتقال داده | خروجی استاندارد داده کافی است | کنترل کامل ساختار داده را می‌خواهید |
از هر مجری این سه سؤال را هم بپرسید:
ویرایش روزانه محتوا را چه کسی و چطور انجام می‌دهد؟
راهکار به چه افزونه، سرویس یا شخصی وابسته است؟
اگر روزی بخواهیم از این راهکار خارج شویم، چه هزینه یا محدودیتی داریم؟
یک خطای رایج این است که فناوری را با مدل فروش یکی بگیریم. فروشگاهی یا شرکتی بودن به‌تنهایی روش ساخت را تعیین نمیکند. فرض کنید قیمت هر سفارش اول باید تأیید کارشناس فروش را بگیرد و بعد تأیید مدیر مالی را. این منطق چندمرحله‌ای پیش از انتخاب ابزار بررسی فنی می‌خواهد. شاید افزونه آماده جوابگو باشد؛ شاید بخشی از کار اختصاصی شود.
امکانات ضروری را چگونه از خواسته‌های آینده جدا کنیم؟
با تعریف نسخه اول؛ یعنی کوچک‌ترین مجموعه امکاناتی که کار اصلی مشتری را کامل و قابل‌اعتماد انجام می‌دهد. کوچک یعنی امکانات کمتر، نه کیفیت کمتر. حذف آزمون یا امنیت برای جا شدن در بودجه صرفه‌جویی نیست. بدهی‌ای است که بعداً با بهره پس می‌دهید.
فهرست خواسته‌ها را به سه دسته تقسیم کنید و کنار هر مورد یک دلیل تجاری بنویسید:
دسته | تعریف | نمونه در سایت استعلام |
|---|---|---|
ضروری برای انتشار | بدون آن کار اصلی انجام نمی‌شود | ارسال درخواست و رسیدن آن به مسئول فروش |
قابل‌تعویق | ارزش دارد اما کار اصلی را متوقف نمیکند | پیشنهاد هوشمند محصول مشابه |
نیازمند بررسی | شدنی بودن یا ارزشش هنوز معلوم نیست | اتصال به نرم‌افزار انبار |
بعد برای هر امکان یک معیار پذیرش بنویسید؛ شرطی که با آزمون معلوم می‌کند آن امکان درست کار می‌کند یا نه. «فرم حرفه‌ای» معیار پذیرش نیست. این یکی هست: فرم شش فیلد دارد و شماره موبایل را اعتبارسنجی می‌کند. پیام هم‌زمان به ایمیل فروش و پنل مدیریت می‌رسد. اگر ارسال شکست بخورد، فرم خطای روشن نشان می‌دهد و داده‌های کاربر را پاک نمیکند. محک من ساده است: معیاری خوب است که یک نفر غیرفنی هم بتواند با آن بگوید «قبول» یا «رد».
مرز تغییر خواسته و رفع نقص را هم از همین مرحله بکشید. نقص یعنی چیزی که طبق معیار پذیرش کار نمیکند و رفعش جزو تعهد است. تغییر یعنی خواسته تازه‌ای که در معیارها نبوده است. بدون این مرز، فهرست «بعداً» آرام‌آرام به تعهدات مبهم نسخه اول راه پیدا می‌کند.
بپرسید اگر این امکان در روز انتشار نباشد، مشتری هنوز می‌تواند کار اصلی‌اش را کامل کند؟ اگر پاسخ مثبت است، آن را نامزد نسخه بعد کنید؛ مگر اینکه الزام قانونی یا عملیاتی دیگری داشته باشد.
محتوا و ساختار صفحات را چه زمانی آماده کنیم؟
پیش از طراحی ظاهر. دست‌کم فهرست صفحه‌ها و هدف هر صفحه باید قبل از اولین طرح روشن باشد. در خیلی از برنامه‌ها محتوا آخر کار می‌آید؛ در هر راهنمای سفارش سایت معمولی هم جایش معمولاً ته فهرست است. دردسر از همین‌جا شروع می‌شود. محتوا هم فقط متن نهایی نیست؛ تصویر محصول، جدول مشخصات، اطلاعات تماس و نام دسته‌بندی‌ها هم محتوا هستند.
مسئول تهیه، بازبینی و تأیید محتوا را از هم جدا کنید. کسی که متن را می‌نویسد معمولاً بهترین فرد برای تأیید نهایی‌اش نیست. اگر محتوا هنوز آماده نیست، دست‌کم از هر نوع صفحه یک نمونه واقعی و نماینده به طراح بدهید.
دلیلش را در یک صحنه آشنا ببینید. طراح صفحه محصول را با متن آزمایشی و عنوان‌های سه‌کلمه‌ای می‌چیند و همه‌چیز مرتب به نظر می‌رسد. بعد عنوان واقعی می‌رسد: «شیر کنترل فشار پنوماتیک دوطرفه با بدنه استیل». جدول مشخصات هم به جای چهار سطر، بیست سطر دارد. طرح در موبایل به‌هم می‌ریزد و یک دور اصلاح به پروژه اضافه می‌شود.
برای تحویل محتوا، این قالب کوتاه را برای هر صفحه پر کنید:
نام صفحه
مخاطب اصلی
اقدامی که از مخاطب انتظار دارید
دارایی‌های لازم: متن، تصویر، جدول یا فایل
مسئول تأیید
اگر سایت قبلی دارید، انتقال محتوا را جدا بررسی کنید. تعداد صفحه‌ها و محصولات و کیفیت داده‌ها را پیش از برآورد به مجری بگویید. واردکردن محتوا را هم خودبه‌خود جزو قرارداد فرض نکنید؛ گاهی کاری چندروزه است که در هیچ پیشنهادی نیامده است.
بودجه ساخت و هزینه‌های پس از راه‌اندازی
بودجه سایت سه بخش دارد: ساخت اولیه، هزینه‌های دوره‌ای و توسعه آینده. بیشتر غافلگیری‌ها از دو بخش آخر می‌آید. اگر فقط عدد ساخت را مقایسه کنید، ارزان‌ترین پیشنهاد ممکن است در دو سال گران‌ترین از آب دربیاید. در این راهنمای سفارش طراحی سایت عمداً عدد نمی‌دهم، چون قیمت بدون محدوده معنایی ندارد.
هزینه ساخت را بیشتر از تعداد صفحه، این عوامل تعیین می‌کنند:
تنوع الگوی صفحه‌ها: صد صفحه محصول با یک قالب، از ده صفحه با ده قالب متفاوت ساده‌تر است.
منطق کسب‌وکار: قیمت‌گذاری پلکانی، تأیید چندمرحله‌ای یا سطوح دسترسی کاربران.
اتصالها: درگاه پرداخت، نرم‌افزار حسابداری، انبار یا سامانه پیامک.
انتقال داده از سایت یا فایل‌های قبلی.
تولید محتوا: نویسندگی، عکاسی و آماده‌سازی مشخصات.
سطح آزمون: تعداد دستگاه‌ها، مرورگرها و سناریوها.
به هزینه مالکیت هم فکر کنید؛ یعنی مجموع هزینه داشتن و استفاده از سایت در تمام عمرش. دامنه، میزبانی، مجوز قالب و افزونه‌ها، خدمات جانبی مثل پیامک و نگهداری در این حساب می‌آیند. حتی هزینه خروج یا انتقال به مجری دیگر هم جزو آن است.
از هر پیشنهاد بخواهید چهار چیز را جدا بنویسد: اقلام شامل قیمت، اقلام خارج از قیمت، فرض‌ها و شیوه محاسبه تغییرات. پیشنهادی که این‌ها را ندارد، عملاً عددی بی‌تعریف است.
بودجه کم است؟ دامنه نسخه اول را کوچک کنید، نه مالکیت حساب‌ها و آزمون مسیرهای اصلی را. برای جزئیات بیشتر، مقاله بودجه‌بندی هزینه طراحی سایت شرکتی را ببینید.
اگر حجم انتقال محتوا یا وضعیت اتصال به سامانه قبلی معلوم نیست، برای آن بخش بررسی جداگانه بخواهید. عدد قطعی روی مسئله نامشخص، ابهام را برطرف نمیکند.
زمان‌بندی پروژه و مسئولیت‌های کارفرما
برنامه زمانی قابل‌اتکا را روی خروجی‌هایی بچینید که می‌توانید تأییدشان کنید، نه روی تعداد هفته‌ها. هر مرحله یک دروازه تأیید دارد و مرحله بعد تا عبور از آن شروع نمی‌شود:
نیاز و محدوده: سند محدوده و فهرست امکانات تأییدشده.
ساختار و طرح: نقشه صفحه‌ها و طرح صفحه‌های کلیدی.
توسعه: نسخه قابل‌استفاده روی محیط آزمایشی.
آزمون: اجرای سناریوهای پذیرش و رفع نقص‌های مسدودکننده.
انتشار: انتقال به دامنه اصلی و بررسی پس از انتشار.
انتقال: تحویل دسترسیها، مستندات و آموزش.
برای هر مرحله سر سه چیز توافق کنید: ورودی لازم از طرف شما، مسئول تأیید و مهلت پاسخ‌گویی. مدتی که مجری برای ساخت اعلام می‌کند، همیشه فرض‌هایی درباره سرعت پاسخ شما دارد. اگر بازخورد طرح دو هفته طول بکشد، تاریخ انتشار هم دو هفته عقب می‌رود.
برای همین یک نماینده تصمیم‌گیر معرفی کنید. او بازخورد مدیر فروش، بازاریابی و مدیرعامل را جمع می‌کند و یک نسخه یکپارچه به مجری می‌دهد. وقتی سه نفر نظرهای متناقض را مستقیم بفرستند، تیم اجرا یا حدس می‌زند یا منتظر می‌ماند.
بیشتر تأخیرهایی که در برنامه‌ها می‌بینم از وابستگی‌های پیش‌بینی‌نشده می‌آیند. نمونه‌های رایجش دسترسی به سامانه قدیمی، محتوای نهایی و فعال‌شدن درگاه پرداخت است که روند اداری خودش را دارد. این‌ها را پیش از قطعی‌کردن تاریخ انتشار فهرست کنید. در نیاسا هم برنامه را با همین دروازه‌ها می‌چینیم و وابستگی‌ها را از جلسه اول کنار تاریخ‌ها می‌نویسیم.
پیشنهاد تیم‌های طراحی را چگونه مقایسه کنیم؟
اول یک محدوده مشترک برای همه بفرستید. بدون آن، مقایسه مبلغ نهایی گمراه‌کننده است. اگر به یکی گفته‌اید «سایت شرکتی» و به دیگری فهرست امکانات داده‌اید، دو قیمت برای دو پروژه متفاوت گرفته‌اید. اگر از این راهنمای سفارش طراحی سایت فقط یک کار را انجام می‌دهید، همین باشد.
بعد پیشنهادها را با این معیارها کنار هم بگذارید:
معیار | چه چیزی را نگاه کنید |
|---|---|
فهم مسئله | هدف شما را با کلمات خودش درست بازگو کرده است؟ |
فرض‌ها | چه چیزهایی را مسلم گرفته و آن‌ها را نوشته است؟ |
خارج از محدوده | کدام کارها صریحاً در قیمت نیست؟ |
فرایند تأیید | چند دور بازخورد و در کدام مراحل؟ |
روش تحویل | چه دسترسی، فایل و مستنداتی تحویل می‌دهد؟ |
پیشنهادی که فرض‌هایش را نوشته، از پیشنهاد ارزان‌تری که درباره‌شان سکوت کرده قابل‌اعتمادتر است.
در نمونه‌کار به ظاهر بسنده نکنید. بپرسید تیم دقیقاً کدام بخش را انجام داده، مسئله آن پروژه چقدر به مسئله شما شبیه است و سایت الان در چه وضعی است. نمونه‌کار زیبا سند کیفیت نگهداری نیست.
اگر جای کارفرما بودم، اولین سؤالم از هر تیم این بود: یکی از مسیرهای اصلی را از اقدام کاربر تا ثبت داده برایم توضیح دهید. مثلاً وقتی کسی فرم استعلام را می‌فرستد، پیام کجا ذخیره می‌شود و به دست چه کسی می‌رسد؟ اگر ایمیل نرسید، چه اتفاقی می‌افتد؟ جواب روشن به این سؤال از یک فهرست بلند فناوری‌ها ارزش بیشتری دارد.
برای فهرست کامل‌تری از سؤال‌ها، مقاله پرسش‌های کلیدی از شرکت‌های طراحی وب را ببینید. نمونه پروژه‌ای که تیمی نشانتان می‌دهد، باید با اجازه کارفرمایش و همراه داده مستند باشد، نه یک ادعای کلی.
قرارداد چگونه از تصمیم‌ها محافظت می‌کند؟
با ثبت مکتوب همان تصمیم‌هایی که تا اینجا گرفته‌اید. قرارداد خوب سند تازه‌ای نیست؛ خلاصه دقیق توافق‌های قبلی است و این اجزا را دارد:
خروجی‌های هر مرحله
استثناها و موارد خارج از محدوده
مسئولیت‌های هر طرف، از جمله تأمین محتوا و مهلت پاسخ‌گویی
نقاط پرداخت و ارتباطشان با تأیید مراحل
شرایط پذیرش و مسیر رسیدگی به اختلاف
معیار تأیید هر مرحله را روشن بنویسید. سکوت کارفرما یا یک «خوبه» در پیام‌رسان، بدون توافق قبلی، پذیرش رسمی نیست. اگر قرار است سکوت پس از مهلتی مشخص به معنی تأیید باشد، این را صریح در قرارداد بیاورید.
برای درخواست تغییر یک روال سه‌قدمی پیشنهاد می‌کنم. اول شرح تغییر را مکتوب کنید. بعد اثرش را بر هزینه و زمان برآورد کنید. آخر سر، پیش از اجرا تأیید بگیرید.
یک موقعیت معمول را در نظر بگیرید. محدوده تأیید شده و طراحی جلو رفته است. حالا مدیر مالی می‌خواهد هر سفارش خودکار در نرم‌افزار حسابداری ثبت شود. این نقص اجرا نیست، چون در محدوده نبوده؛ تغییر خواسته است و باید همان روال بالا را طی کند. اما اگر فرم سفارشِ داخل محدوده داده را ناقص ذخیره کند، نقص است و رفعش جزو تعهد مجری است.
این بخش جایگزین مشاوره حقوقی نیست. برای نگارش دقیق بندها، راهنمای نگارش قرارداد طراحی سایت را بخوانید و متن نهایی را به مشاور حقوقی‌تان نشان دهید.
مالکیت دامنه، داده و دسترسیها با چه کسی است؟
باید با کسب‌وکار شما باشد. اما هر جزء را جداگانه بررسی کنید، چون تحویل یکی به معنی تحویل همه نیست. از میان نکات سفارش طراحی سایت، این یکی از همه کم‌دیده‌تر است. این پنج مورد را جدا بپرسید:
حساب دامنه و میزبانی: به نام چه کسی ثبت شده و ایمیل بازیابی‌اش مال کیست؟
دسترسی مدیریتی سایت: حساب مدیر اصلی دست کیست؟
داده‌ها: سفارش‌ها، فرم‌ها و اطلاعات مشتری کجا ذخیره می‌شوند و چطور از آن‌ها خروجی می‌گیرید؟
فایل‌های طراحی: فایل منبع طرح‌ها را می‌گیرید یا فقط خروجی تصویری؟
کد: حق استفاده و انتقال کد اختصاصی با کیست؟
پیشنهاد من این است که حساب‌های اصلی و راه‌های بازیابی‌شان زیر کنترل خود کسب‌وکار بماند. به مجری دسترسی متناسب با نقشش بدهید، نه لزوماً رمز حساب مالک. آن‌وقت اگر روزی همکاری تمام شد، لازم نیست برای پس‌گرفتن دامنه خودتان مذاکره کنید.
حق استفاده از کد اختصاصی را هم از مجوز ابزارها و اجزای ثالث جدا کنید. قالب یا افزونه تجاری مجوز خودش را دارد و مجری نمی‌تواند مالکیت کاملش را به شما بدهد. پس مالکیت کامل همه اجزا را پیش‌فرض نگیرید؛ بپرسید کدام بخش مال شماست.
شرایط خروج را از همان ابتدا توافق کنید: خروجی داده در قالب قابل‌استفاده، مستندات استقرار، امکان انتقال به میزبان دیگر و حذف دسترسی‌های غیرضروری. یک نکته امنیتی ساده را هم فراموش نکنید. رمزها را در فایل مشترک یا پیام گروهی نفرستید. انتقال امن و آزمون ورود مستقل شما بخشی از تحویل است.
چه زمانی بازطراحی بهتر از ساخت سایت جدید است؟
وقتی داده، نشانی صفحه‌ها و زیرساخت فعلی هنوز به کار می‌آیند. در این حالت اصلاح هدفمند را پیش از بازنویسی کامل بررسی کنید. عوض کردن ظاهر همیشه ساخت دوباره نمی‌خواهد.
اگر معماری سایت یا روش مدیریتش جلوی کار اصلی را گرفته، حساب فرق می‌کند. مثلاً هر تغییر قیمت برنامه‌نویس لازم دارد، یا سایت بدون بازنویسی به سامانه فروش وصل نمی‌شود. اینجا هزینه نگه‌داشتن وضع موجود را با هزینه یک انتقال سنجیده مقایسه کنید.
پیش از هر تصمیمی، فهرستی از دارایی‌های فعلی تهیه کنید: صفحه‌ها، اتصالها، داده‌ها و صفحه‌هایی که از جست‌وجو ورودی می‌گیرند. سؤال اول این نیست که چه چیزی باید عوض شود.
سؤال اول این است که چه چیزی نباید از دست برود.
اگر نشانی صفحه‌ها عوض شود، به نگاشت نشانی قدیم به جدید و هدایت دائمی (Redirect 301) نیاز دارید. هدایت دائمی به مرورگر و موتور جست‌وجو می‌گوید صفحه برای همیشه به نشانی تازه رفته است. این کار خطر افت ورودی را کم می‌کند، اما هیچ‌کس نمی‌تواند تضمین کند که افت صفر باشد.
فرض کنید سایتی کاتالوگی دارید که صفحه‌های محصولش سال‌ها از جست‌وجو مشتری آورده‌اند، اما فرم استعلامش ضعیف است. مشکل این سایت ساختار نیست؛ نقطه تبدیل است. بازطراحی فرم و مسیر استعلام احتمالاً هم ارزان‌تر از ساخت دوباره تمام می‌شود، هم کم‌خطرتر است.
معیارهای آزمون سایت را چگونه تعیین کنیم؟
معیار پذیرش را به سناریو وصل کنید: چه کسی، روی چه دستگاهی، چه کاری می‌کند و نتیجه درست چیست. مثلاً «مسئول خرید با گوشی اندرویدی فرم استعلام را با یک فایل پیوست می‌فرستد و ایمیل تأیید می‌گیرد.» سناریویی به این روشنی جایی برای بحث «به نظرم کار می‌کند» باقی نمی‌گذارد.
این موارد را صریح در محدوده آزمون بیاورید:
فرم‌ها و پیام‌های خطا، از جمله ورودی نادرست و قطع اینترنت
نمایش موبایل روی چند اندازه صفحه رایج
کار با صفحه‌کلید بدون ماوس و خوانایی متن
سطح دسترسی کاربران پنل مدیریت
مسیرهای اصلی از ورود تا اقدام نهایی
در سایت فروشگاهی، پرداخت ناموفق، پرداخت تکراری، تغییر موجودی وسط خرید و ثبت سفارش را متناسب با محدوده پروژه بیازمایید. در سایت شرکتی مهم‌ترین آزمون ساده‌تر است: درخواست واقعاً به دست مسئول فروش می‌رسد یا نه؟
سرعت را هم در شرایط توافق‌شده بسنجید؛ یعنی دستگاه، نوع اتصال، صفحه مورد آزمون و وضعیت محتوا از قبل معلوم باشد. امتیاز یک ابزار سنجش سرعت به‌تنهایی معیار پذیرش نیست، چون با هر اجرا و هر شبکه فرق می‌کند.
بعد خطاها را بر اساس اثرشان دسته‌بندی کنید. در گزارش آزمون، همین سه سطح برای تصمیم‌گیری کافی است:
سطح خطا | تعریف | تصمیم |
|---|---|---|
مسدودکننده | مسیر اصلی را متوقف می‌کند | پیش از انتشار حتماً رفع شود |
جدی | کار انجام می‌شود، اما با دردسر یا خطر داده | پیش از انتشار یا با تاریخ رفع مکتوب |
کم‌اثر | ظاهری است یا در مسیر فرعی | با توافق مکتوب پس از انتشار |
روز تحویل چه چیزهایی باید دریافت و تأیید شود؟
فهرست مشخصی از دسترسیها، فایل‌ها و مستندات، به‌علاوه یک آزمون استفاده مستقل. ولی اول تحویل را از انتشار جدا کنید. باز شدن سایت روی دامنه یعنی انتشار، نه پایان انتقال مسئولیت.
سایت وقتی تحویل شده که تیم شما بدون حضور مجری بتواند اداره‌اش کند.
فهرست تحویل دست‌کم این‌ها را دارد:
دسترسی‌های توافق‌شده، با آزمون ورود از طرف خودتان
فایل‌های طراحی و کد، طبق قرارداد
نسخه پشتیبان کامل و محل نگهداری آن
مستندات استقرار و راهنمای مدیریت محتوا
جلسه آموزش برای کاربران پنل
فهرست مسائل باز با مسئول و تاریخ رفع
تماشای آموزش کافی نیست. از نماینده خودتان بخواهید در همان جلسه یک محتوای واقعی را ویرایش کند و یک درخواست آزمایشی را تا صندوق تیم فروش دنبال کند. هر جا گیر کرد، مستندات یا آموزش همان‌جا کم دارد.
نسخه پشتیبان را هم فقط به صرف وجودش تأیید نکنید. یک بار بازیابی‌اش را روی محیط آزمایشی امتحان کنید و بنویسید پشتیبان‌ها کجا نگهداری می‌شوند و مسئولشان کیست. پشتیبانی که هیچ‌وقت بازیابی نشده، فقط یک فرض است.
آخر کار صورت‌جلسه پذیرش را امضا کنید. موارد باز، مسئول رفع هر کدام و تاریخ شروع دوره پشتیبانی باید در آن بیاید. همین یک برگه بعدها جلوی بحث‌های «قرار بود» را می‌گیرد.
پشتیبانی پس از انتشار چه مرزهایی دارد؟
مرز اصلی بین چهار نوع کار است که معمولاً همه را «پشتیبانی» صدا می‌زنیم. اگر از هم جدایشان نکنید، هر درخواستی به بحث رایگان یا پولی بودن می‌کشد.
نوع کار | یعنی | نمونه |
|---|---|---|
رفع نقص | چیزی که طبق محدوده توافق‌شده کار نمیکند | فرم استعلام ایمیل نمی‌فرستد |
نگهداری دوره‌ای | کارهای جاری برای سالم ماندن سایت | به‌روزرسانی، پشتیبان‌گیری، بررسی سلامت |
ورود محتوا | افزودن یا ویرایش محتوا به جای تیم شما | بارگذاری بیست محصول تازه |
توسعه | قابلیتی که پیش‌تر نبوده است | افزودن باشگاه مشتریان |
کانال اعلام مسئله، ساعت پوشش، سطح فوریت و مسئول پیگیری را هم مشخص کنید. حواستان باشد زمان پاسخ با زمان رفع یکی نیست. «ظرف دو ساعت پاسخ می‌دهیم» یعنی مسئله را دیده‌اند، نه اینکه حلش کرده‌اند.
مسئولیت به‌روزرسانی، بررسی سلامت، پشتیبان‌گیری و تمدید دامنه و میزبانی را به نام یک نقش یا یک طرف قرارداد بنویسید. کاری که «همه» مسئولش باشند، معمولاً همان روزی که باید، انجام نمی‌شود.
تکلیف اختلال سرویس‌های ثالث را هم روشن کنید. اگر درگاه پرداخت یا سرویس پیامک از کار بیفتد، تیم پشتیبانی بررسی می‌کند که مشکل از سمت سایت نباشد و با سرویس‌دهنده پیگیری می‌کند. رفع خود اختلال اما از کنترل آن تیم خارج است.
برای همین به وعده پشتیبانی نامحدود دل نبندید. فهرست مکتوب خدمات شامل و خارج از پشتیبانی خیلی قابل‌اتکاتر است. کنارش یک مسیر جدا هم برای درخواست توسعه تازه تعریف کنید.
تأیید دریافت گزارش اختلال، به معنی حل آن نیست. در توافق پشتیبانی، زمان پاسخ اولیه را از فرایند بررسی و رفع مسئله جدا کنید.
نتیجه سایت را پس از انتشار چگونه بسنجیم؟
با همان شاخصی که در بخش اول برای موفقیت تعیین کردید: درخواست معتبر، رزرو تکمیل‌شده یا خرید موفق. بازدید به‌تنهایی نتیجه کسب‌وکار نیست. سایتی با بازدید کمتر و استعلام بهتر، از سایت پربازدیدِ بی‌مشتری موفق‌تر است.
برای سنجش به ثبت رویداد (Event Tracking) نیاز دارید؛ یعنی ثبت یک اقدام مشخص کاربر، مثل ارسال فرم یا لمس شماره تماس. پیش از اینکه به گزارش‌ها تکیه کنید، خودتان چند بار فرم را بفرستید و ببینید همان تعداد در گزارش آمده یا نه. این عادت را هیچ‌وقت کنار نمی‌گذارم، چون گزارشی که آزموده نشده، تصمیم اشتباه را با اعتمادبه‌نفس پشتیبانی می‌کند.
در سایت استعلام، سه عدد را از هم جدا کنید:
درخواست‌های ثبت‌شده
درخواست‌هایی که تیم فروش مناسب پیگیری می‌داند
درخواست‌هایی که به قرارداد رسیده‌اند
فاصله عدد دوم و سوم معمولاً به سایت ربطی ندارد؛ به سرعت و کیفیت پیگیری فروش برمی‌گردد. پس بدون مبنای مقایسه، تغییر فروش را به پای طراحی ننویسید. تبلیغات تازه، فصل فروش و تغییر در تیم پاسخ‌گویی هم روی عدد اثر می‌گذارند.
برای اولین مرور عملکرد، یک مالک گزارش تعیین کنید و جلسه را با فهرست تصمیم‌های قابل اقدام ببندید. مشاهده‌ای مثل «کاربران موبایل فرم را نیمه‌کاره رها می‌کنند» تا وقتی به اولویت اصلاح با مسئول مشخص تبدیل نشود، فقط یک خبر است.
چگونه درخواست برآورد قابل بررسی ارسال کنیم؟
تصمیم‌های این راهنمای سفارش طراحی سایت را در یک متن کوتاه جمع کنید و برای همه تیمها یکسان بفرستید. این الگو را کپی کنید و پر کنید:
هدف سایت: جمله «این سایت برای … ساخته می‌شود تا …»
مخاطب اصلی: چه کسی و با چه نیازی
مسیر اصلی: اقدامی که مخاطب باید انجام دهد
نوع سایت پیشنهادی: شرکتی، کاتالوگی، فروشگاهی، خدماتی یا ترکیبی
امکانات ضروری نسخه اول: با معیار پذیرش هر کدام
اتصالها: سامانه‌هایی که سایت باید به آن‌ها وصل شود
وضعیت محتوا: آماده، نیمه‌آماده یا نیازمند تولید
سایت فعلی: نشانی و آنچه باید حفظ شود
محدودیت بودجه: سقف ساخت و نگهداری
تاریخ هدف: و دلیل آن تاریخ
موارد نامعلوم را صریح بنویسید؛ «نمی‌دانیم» خودش اطلاعات مفیدی است. در همان درخواست از مجری بخواهید در پاسخش فرض‌ها، پرسش‌های باز، خروجیها، موارد خارج از محدوده و مراحل تأیید را مشخص کند.
یک نمونه فرضی چندخطی:
«ما تأمین‌کننده تجهیزات اندازه‌گیری صنعتی هستیم. سایت باید به مسئولان خرید کارخانه‌ها کمک کند مشخصات حدود ۱۵۰ محصول را ببینند و استعلام کامل ثبت کنند. قیمت قطعی آنلاین نداریم، چون به تعداد و زمان تحویل بستگی دارد. استعلام‌ها باید به ایمیل فروش و پنل مدیریت برسند. اتصال به نرم‌افزار انبار را برای نمایش موجودی می‌خواهیم، اما شدنی بودنش نیازمند بررسی است. متن صفحه‌های اصلی آماده است و عکس محصولات نیمه‌کاره.»
این فقط درخواست اولیه است، نه پرونده کامل سفارش. اگر می‌خواهید مدارک و دارایی‌ها را هم کامل آماده کنید، مقاله ملزومات آماده‌سازی برای ساخت سایت کمکتان می‌کند.
اگر دوست دارید این متن را با ما هم در میان بگذارید، نگاهی به خدمات طراحی سایت نیاسا بیندازید و هدف و محدوده اولیه را برایمان بفرستید. در گفت‌وگوی اول، فرض‌ها و پرسش‌های باز را با هم مرور می‌کنیم تا هر پیشنهادی که بعد از آن می‌گیرید، روی تصمیم‌های روشن بنا شده باشد.
هدف سایت، امکانات ضروری و وضعیت فعلی کسب‌وکارتان را در یک شرح کوتاه جمع کنید. با این اطلاعات، گفت‌وگو درباره محدوده کار و روش اجرای مناسب دقیق‌تر پیش می‌رود.
Frequently asked
6آیا برای سفارش سایت باید زبان برنامهنویسی را انتخاب کنیم؟
نه؛ ابتدا هدف، مسیر مشتری، امکانات و محدودیتهای نگهداری را مشخص کنید. از تیم فنی بخواهید روش ساخت پیشنهادی را با توجه به همین نیازها توضیح دهد و هزینه توسعه، نگهداری و انتقال را روشن کند.
اگر بودجه محدود باشد، کدام امکانات را حذف کنیم؟
قابلیتهایی را عقب بیندازید که نبودشان مسیر اصلی مشتری را ناقص نمیکند. برای مثال، در سایت استعلام میتوان پیشنهاد خودکار محصول را به آینده موکول کرد؛ اما ثبت درست درخواست، مدیریت دسترسی و آزمون فرم نباید حذف شود.
آیا آماده نبودن محتوا مانع شروع پروژه است؟
همه محتوای نهایی لازم نیست از روز اول آماده باشد، اما ساختار صفحات و نمونه محتوای واقعی باید روشن شود. مسئول تهیه محتوا و موعد تحویل آن را مشخص کنید؛ تأخیر محتوا می‌تواند طراحی، آزمون و انتشار را جابه‌جا کند.
قیمتهای متفاوت طراحی سایت را چگونه مقایسه کنیم؟
ابتدا محدوده مشترکی برای تیمها بفرستید. سپس خروجیها، تعداد الگوهای صفحات، اتصالها، انتقال محتوا، آزمون، مالکیت دسترسیها و پشتیبانی را همسان بررسی کنید. مبلغ پایینتر ممکن است بخشی از کار مورد نیاز شما را شامل نشود.
تحویل سایت با انتشار آن چه تفاوتی دارد؟
انتشار یعنی سایت در دسترس کاربران قرار گرفته است. تحویل یعنی علاوه بر آزمون و پذیرش خروجی، دسترسیها، فایل‌های توافق‌شده، آموزش، مستندات و مسئولیت پشتیبانی هم منتقل و ثبت شده‌اند.
برای سایت فعلی، بازطراحی بهتر است یا ساخت دوباره؟
ابتدا مشخص کنید مشکل از ظاهر و مسیر کاربر است یا از محدودیت زیرساخت و مدیریت. اگر بخش‌های موجود قابل استفاده‌اند، اصلاح هدفمند را بررسی کنید. ساخت دوباره باید برنامه مشخصی برای انتقال داده، حفظ نشانی‌های ارزشمند و کنترل ریسک انتشار داشته باشد.
