دو پیشنهاد با عنوان «تور مجازی ساختمان» ممکن است خروجی‌های کاملاً متفاوتی داشته باشند. یکی شامل چند تصویر پانوراما است و دیگری انتخاب طبقه، مدل واحدها، فرم درخواست و نگهداری سایت را هم پوشش می‌دهد. تا وقتی محدودهٔ کار یکسان نشده، مقایسهٔ عدد نهایی می‌تواند گمراه‌کننده باشد.

این مطلب تعرفهٔ ثابت اعلام نمی‌کند. هدف آن کمک به نوشتن یک درخواست روشن است تا بدانید بابت چه خروجی‌هایی هزینه می‌کنید و چه چیزهایی جداگانه محاسبه می‌شوند. برای درخواست مرتبط با پروژهٔ خودتان، صفحهٔ برآورد و تعرفه‌های اکسی‌واک را ببینید.

۱. وضعیت فایل‌های ورودی

وجود یک مدل سه‌بعدی لزوماً به معنای آماده‌بودن آن برای نمایش وب نیست. ممکن است لایه‌ها نامشخص باشند، بافت‌ها همراه فایل نباشند یا جزئیات بسیار زیادی برای کاربرد نهایی وجود داشته باشد. از طرف دیگر، نقشهٔ خوانا و هماهنگ می‌تواند دامنهٔ بازسازی موردنیاز را روشن‌تر کند. هنگام درخواست برآورد، فقط پسوند فایل را ننویسید؛ وضعیت و نسخهٔ آن را هم توضیح دهید.

تیم تولید باید مشخص کند چه مقدار مدل‌سازی از صفر، اصلاح مدل یا تبدیل خروجی لازم است. برای جلوگیری از ابهام، یک نمونهٔ کوچک از فایل‌ها و فهرست مدارک موجود ارائه کنید. چک‌لیست آماده‌سازی فایل کمک می‌کند اطلاعات اصلی جا نماند.

۲. تعداد فضاها و نوع تعامل

تعداد طبقات به‌تنهایی معیار کافی نیست. یک ساختمان با چند طبقهٔ تکراری ممکن است تیپ‌های محدودی داشته باشد، در حالی که پروژه‌ای کوچک‌تر چندین فضای کاملاً متفاوت دارد. مشخص کنید چند تیپ واحد، چند فضای مشاع و چند نقطهٔ پانوراما باید ساخته شود. بخش‌های بیرونی، بام و محوطه را نیز صریح بنویسید.

تعامل‌ها را با فعل توصیف کنید: کاربر طبقه را انتخاب کند، پلان واحد را ببیند، بین دو نما جابه‌جا شود یا درخواست ثبت کند. عبارت کلی «همهٔ امکانات» قابل ارزیابی نیست. اگر قابلیت خاصی در نمونهٔ مرجع دیده‌اید، لینک و توضیح همان بخش را همراه درخواست بفرستید.

۳. کیفیت بصری و بهینه‌سازی

کیفیت قابل قبول باید هم در تصویر و هم در عملکرد تعریف شود. مدلی که روی رایانهٔ تولیدکننده روان است، ممکن است روی گوشی مخاطب همان رفتار را نداشته باشد. مستندات WebGL در MDN بر توجه به حافظه، محدودیت دستگاه و هزینهٔ پردازش تأکید دارد. منبع: WebGL best practices. این ملاحظات می‌توانند بخشی مستقل از آماده‌سازی خروجی باشند.

برای برآورد روشن، دستگاه‌های هدف و نمونهٔ تصویری مطلوب را مشخص کنید. سپس بپرسید چه آزمون‌هایی داخل پیشنهاد قرار دارد: مرورگرهای مورد توافق، نمایش موبایل، بارگذاری اولیه، کنترل خطا و حالت جایگزین. انتظار «بالاترین کیفیت روی همهٔ دستگاه‌ها» بدون تعریف معیار، تعهدی مبهم ایجاد می‌کند.

۴. اصلاحات و تغییر دامنه

تعداد نوبت‌های بازبینی، نوع اصلاح مجاز در هر مرحله و مسئول تأیید را بنویسید. اصلاح یک نوشته با تغییر کامل پلان یکسان نیست. بهتر است هندسهٔ اولیه پیش از پرداختن به نور و متریال تأیید شود تا اصلاح ساختاری در انتهای کار به چند خروجی سرایت نکند.

یک جدول کوتاه از موارد داخل و خارج از پیشنهاد بخواهید. برای مثال، تولید مدل اولیه، طراحی رابط، ورود اطلاعات، میزبانی، اصلاح نقشه و افزودن فضای جدید هرکدام می‌توانند ردیف مشخص داشته باشند. این جدول لزوماً به معنای افزایش هزینه نیست؛ هدف آن روشن‌بودن مسئولیت‌هاست.

۵. تحویل، میزبانی و نگهداری

  • محل انتشار: دامنه و سرویس میزبانی متعلق به چه کسی است و چه مدت در پیشنهاد پوشش داده می‌شود؟
  • فایل‌های تحویلی: فقط لینک عمومی دریافت می‌کنید یا فایل‌ها و مستندات مشخصی هم تحویل می‌شوند؟
  • تغییر اطلاعات: چه کسی متن، مشخصات واحد یا تصاویر را به‌روز می‌کند؟
  • پشتیبانی: مدت، محدوده و مسیر گزارش مشکل چیست؟
  • انتقال: اگر محل میزبانی تغییر کند، چه خروجی و دسترسی‌ای برای انتقال لازم است؟

اگر فرم و حساب کاربری بخشی از پروژه است، گردش اطلاعات را هم توضیح دهید. چه کسی درخواست را دریافت می‌کند؟ مخاطب از کجا نتیجهٔ ثبت را می‌فهمد؟ این‌ها بخشی از تجربهٔ نهایی‌اند و نباید فقط در روز تحویل به آن‌ها فکر کرد.

الگوی آمادهٔ درخواست برآورد

«پروژهٔ ما یک [نوع ساختمان] در مرحلهٔ [وضعیت طراحی یا اجرا] است. برای [مخاطب] می‌خواهیم امکان [کارهای مشخص کاربر] فراهم شود. مدارک موجود شامل [فایل‌ها و نسخه] است. محدودهٔ نمایش [تعداد تیپ‌ها و فضاها] و دستگاه اصلی مخاطب [موبایل یا سایر دستگاه‌ها] است. مهلت موردنظر [تاریخ] است. لطفاً محدودهٔ تحویل، مراحل تأیید، اصلاحات، میزبانی و پشتیبانی را جداگانه مشخص کنید.»

پیش از انتخاب، از هر پیشنهاددهنده بخواهید همین شرح کار را مبنای پاسخ قرار دهد. سپس اختلاف‌ها را بررسی کنید؛ ممکن است تفاوت عددها از تفاوت محدوده آمده باشد. برای شروع، این اطلاعات را در فرم تماس اکسی‌واک ثبت کنید و در صورت نیاز، ابتدا نوع تجربهٔ مناسب پروژه را انتخاب کنید.

منابع و یادداشت تحریریه

  1. MDN — WebGL best practices؛ محدودیت‌های حافظه، دستگاه و پردازش

منابع در ۱۳ نوامبر ۲۰۲۶ بررسی شدند. چک‌لیست‌ها و مثال‌های بدون ارجاع، پیشنهادهای تحریریه‌اند؛ مثال‌ها گزارش عملکرد یک مشتری یا تضمین نتیجه نیستند.

سؤال یا نکته‌ای برای اصلاح این مطلب دارید؟

با تحریریه در میان بگذارید