رفتن به محتوا
ARTINEXT

BIM و Revit

توسعه پلاگین رویت چقدر هزینه دارد؟

پلاگینی که فقط یک دکمه به نظر می‌رسد، بر اساس همان دکمه قیمت‌گذاری نمی‌شود، بلکه بر اساس هفته‌ها کاری که پشت آن دکمه انجام شده است.

استودیوی سامانه‌های دیجیتالانتشار: به‌روزرسانی:

تیمی که دامنه، معماری و هزینه‌ی پلاگین‌های اختصاصی رویت را برای دفاتر معماری، سازه و تأسیسات تعریف و اجرا می‌کند.

فهرست مطالب
  1. پاسخ کوتاه
  2. چه عواملی قیمت را تعیین می‌کنند
  3. سه شکل متفاوت از کار پلاگین
  4. کدام جریان‌های کاری ارزش خودکارسازی دارند
  5. اسکریپت Dynamo، افزونه‌ی API یا APS
  6. هزینه‌ی پس از تحویل
  7. زمان جبران هزینه
  8. خرید افزونه‌ی آماده یا ساخت اختصاصی
  9. تعریف دامنه‌ی اولین پروژه
  10. آنچه برآورد باید مشخص کند
  11. جمع‌بندی
  12. پرسش‌های متداول

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

پلاگینی که نام شیت‌ها را در یک تمپلیت اصلاح می‌کند، پروژه‌ای کاملاً متفاوت از پلاگینی است که داده‌ی زنده را از Autodesk Construction Cloud به یک داشبورد مدیریتی منتقل می‌کند. هر دو «پلاگین» نامیده می‌شوند، اما حجم کار آن‌ها قابل‌مقایسه نیست.

یکی از ابزارهای خود ما فرآیندی را که حدود ۲ هفته و گاهی نزدیک به ۱ ماه طول می‌کشید، به حدود ۱۰ دقیقه و یک دکمه تبدیل کرد. در زمان تحویل، کسی آن ۲ هفته را نمی‌بیند؛ آنچه دیده می‌شود همان دکمه است و همان دکمه با قیمت مقایسه می‌شود. رابط کاربری ساده، حاصل فشرده‌شدن یک مسیر طولانی است، نه نشانه‌ی کم‌عمق‌بودن ابزار. قضاوت درباره‌ی هزینه‌ی یک ابزار بر اساس سادگی ظاهر آن، دقیقاً برعکس واقعیت است.

میز کار توسعه‌دهنده با دو مانیتور در شب، برای نوشته‌ای درباره‌ی هزینه‌ی توسعه پلاگین رویت

چه عواملی قیمت را تعیین می‌کنند

چند نفر در حال بررسی نقشه‌ی فنی روی میز، پیش از برآورد هزینه‌ی یک پلاگین

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

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

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

سه شکل متفاوت از کار پلاگین، سه بودجه‌ی متفاوت

بررسی پلان معماری و نمودار روی میز کار، برای سه شکل متفاوت از پروژه‌های پلاگین رویت

این فهرست، فهرست قیمت نیست؛ روشی است برای تشخیص اینکه پروژه‌ی شما پیش از هر برآوردی به کدام شکل نزدیک‌تر است. سه شکل در پروژه‌های پلاگین رویت بیشتر از بقیه دیده می‌شوند:

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

کدام جریان‌های کاری رویت ارزش خودکارسازی دارند

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

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

  • تنظیم شیت‌ها و ویوها: ساخت، شماره‌گذاری و تغییر نام شیت‌ها و ویوها بر اساس فهرستی که دفتر از پیش در Excel نگه می‌دارد.
  • تبدیل CAD به Revit: ساخت دیوارها، کف‌ها، ترازها و بازشوهای بومی از روی نقشه‌های هماهنگ‌شده‌ی CAD، به‌جای بازترسیم دستی خطوط.
  • انتقال مدل سازه: تبدیل خروجی ETABS به اسکلت بومی Revit، همراه با گزارش تمام اعضایی که تبدیل نشده‌اند.
  • کنترل کیفیت مدل: اجرای قواعد نام‌گذاری، پارامترها و ویوتمپلیت‌های دفتر به‌صورت تست خودکار، به‌جای چک‌لیستی که کسی باید آن را بخواند.
  • خروجی اسکجوال‌ها و مقادیر: انتقال داده‌ی اسکجوال‌ها به Excel در قالبی که تیم برآورد واقعاً از آن استفاده می‌کند.

اسکریپت Dynamo، افزونه‌ی API یا APS، هزینه صرف کدام می‌شود

دست‌ها روی لپ‌تاپ در حال نوشتن کد، برای انتخاب میان اسکریپت Dynamo، افزونه‌ی Revit API و APS

اگر جریان کاری همین حالا با نودهای Dynamo قابل‌ساخت است، اسکریپت Dynamo کم‌هزینه‌ترین مسیر است. داخل رویت اجرا می‌شود، به نصب جداگانه نیاز ندارد و تیم شما می‌تواند آن را باز کند و تغییر دهد. ماکرو نیز در همین بازه‌ی هزینه قرار می‌گیرد، اما به یک فایل یا یک دستگاه محدود است و اشتراک‌گذاری آن دشوار است.

افزونه‌ی Revit API کدی کامپایل‌شده به زبان C# و بر پایه‌ی .NET است که رابط کاربری و فایل نصب مستقل دارد. این مسیر زمانی ارزش ساخت دارد که جریان کاری به رابط کاربری کامل، دسترسی‌هایی فراتر از نودهای Dynamo یا توزیع میان اعضای تیمی نیاز داشته باشد که نباید برای استفاده، گراف را باز کنند.

Autodesk Platform Services که پیش‌تر Forge نام داشت، زمانی کاربرد دارد که اتوماسیون باید بدون بازکردن رویت اجرا شود یا تعداد فایل‌ها بیشتر از توان پردازش یک دستگاه دسکتاپ باشد. راهنمای خود Autodesk برای برآورد هزینه‌ی Design Automation API، هزینه‌ی پردازش Revit را ۶ Cloud Credit در ساعت اعلام کرده است؛ پیش از آنکه فرض کنید ابزار ابری همیشه گزینه‌ی گران‌تر است، این عدد را در نظر بگیرید.

هزینه‌ی پس از تحویل، هر نسخه‌ی جدید رویت

رویت هر سال نسخه‌ی جدیدی منتشر می‌کند و افزونه‌ای که برای یک نسخه کامپایل شده است، الزاماً در نسخه‌ی بعدی اجرا نمی‌شود. در بیشتر سال‌ها تغییرات کوچک است، اما همیشه این‌طور نیست.

Revit 2025 نمونه‌ی روشن آن است. API این نسخه از .NET Framework 4.8 به .NET 8 منتقل شد و افزونه‌هایی که برای Revit 2024 و نسخه‌های پیش از آن ساخته شده بودند، پیش از اجرا باید دوباره کامپایل و در بخش‌هایی بازنویسی می‌شدند. دفتری که هم‌زمان با دو یا سه نسخه‌ی رویت کار می‌کند، به پلاگینی نیاز دارد که برای همه‌ی آن‌ها ساخته شده باشد و این تصمیم باید در ابتدای کار گرفته شود، نه پس از اولین به‌روزرسانی ناموفق.

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

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

پلاگین چه زمانی هزینه‌ی خود را جبران می‌کند

ساعت شنی کنار لپ‌تاپ روی میز چوبی، برای محاسبه‌ی زمان بازگشت هزینه‌ی پلاگین

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

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

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

چه زمانی خرید افزونه‌ی آماده بهتر از ساخت اختصاصی است

نمای بالای یک پیاده‌رو با خطی منشعب، برای تصمیم میان خرید افزونه‌ی آماده و ساخت اختصاصی

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

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

بیشتر برآوردهای سریع به یک شکل انجام می‌شوند: فرآیند در یک تماس تلفنی توضیح داده می‌شود، در زمانی کوتاه‌تر از بازشدن یک مدل بزرگ رویت. برآوردی که بر اساس یک توضیح شفاهی ارائه شود، دقیق‌تر از همان توضیح نیست. اگر به عددی قابل‌دفاع نیاز دارید، کار را با بررسی فایل‌های واقعی شروع کنید.

دامنه‌ی اولین پروژه‌ی پلاگین را چگونه تعریف کنیم

دفترچه‌ی طراحی با یادداشت‌های دستی و خودکار، برای مستندکردن فرآیند پیش از درخواست برآورد

برآورد دقیق از بررسی فرآیند واقعی به دست می‌آید، نه از خلاصه‌ای از آن. پیش از هر برآورد جدی، چهار مورد باید آماده باشد:

  1. شرح مرحله‌به‌مرحله‌ی فرآیند دستی فعلی، همراه با بخش‌هایی که در آن‌ها خطا رخ می‌دهد.
  2. یک یا دو فایل پروژه‌ی واقعی که ابزار روی آن‌ها اجرا خواهد شد.
  3. افرادی که از ابزار نهایی استفاده می‌کنند و نسخه‌های رویتی که با آن‌ها کار می‌کنند.
  4. اینکه ابزار فقط داخل رویت کار می‌کند یا باید با سامانه‌ی دیگری تبادل داده داشته باشد.

برآورد قیمت باید چه مواردی را مشخص کند

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

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

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

جمع‌بندی

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

پرسش‌های متداول

توسعه پلاگین رویت واقعاً چقدر هزینه دارد؟

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

توسعه پلاگین رویت چقدر زمان می‌برد؟

ابزار تک‌منظوره سریع‌ترین مسیر ساخت است. ابزاری که چند نوع پروژه را پوشش می‌دهد یا باید روی پروژه‌های واقعی تست شود، زمان بیشتری می‌برد و هر یکپارچه‌سازی بیرونی این زمان را افزایش می‌دهد. پاسخ دقیق به همان عواملی بستگی دارد که قیمت را تعیین می‌کنند.

تفاوت اسکریپت Dynamo و افزونه‌ی Revit API چیست؟

اسکریپت Dynamo داخل محیط Dynamo و رویت اجرا می‌شود و وقتی جریان کاری با نودها قابل‌ساخت است، مسیر سریع‌تر و کم‌هزینه‌تری است. افزونه‌ی Revit API کد کامپایل‌شده با رابط کاربری و فایل نصب مستقل است و زمانی ارزش ساخت دارد که به رابط کامل، دسترسی عمیق‌تر یا توزیع در کل تیم نیاز باشد.

Autodesk Platform Services چه زمانی از افزونه‌ی دسکتاپ مناسب‌تر است؟

زمانی که اتوماسیون باید بدون بازکردن رویت اجرا شود یا تعداد فایل‌ها بیشتر از توان یک دستگاه دسکتاپ باشد. Autodesk هزینه‌ی Design Automation API را بر اساس زمان پردازش و با Cloud Credit محاسبه می‌کند، نه با مبلغ ثابت.

آیا به‌روزرسانی‌های رویت به هزینه اضافه می‌کند؟

ممکن است. رویت هر سال نسخه‌ی جدیدی منتشر می‌کند و در Revit 2025، API به .NET 8 منتقل شد، در نتیجه افزونه‌های قدیمی پیش از اجرا باید دوباره کامپایل می‌شدند. از ابتدا مشخص کنید ابزار از کدام نسخه‌ها پشتیبانی می‌کند و به‌روزرسانی آن بر عهده‌ی چه کسی است.

آیا خرید افزونه‌ی آماده ارزان‌تر از ساخت اختصاصی است؟

اغلب بله و این را از ابتدا می‌گوییم. اگر افزونه‌ای که در Autodesk App Store وجود دارد مسئله را حل می‌کند، همان را بخرید. ساخت اختصاصی زمانی توجیه دارد که جریان کاری آن‌قدر به استاندارد دفتر شما وابسته باشد که ابزار آماده‌ای با آن سازگار نباشد.

پیش از درخواست برآورد، چه چیزی باید آماده باشد؟

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

آیا تعداد کاربران پلاگین روی هزینه اثر می‌گذارد؟

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

بازگشت به بالا

قدم بعدی

اولین چیزی که می‌خواهید تغییر کند چیست؟

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

اگر فقط به‌دنبال یک قالب آماده یا پلاگین پیش‌ساخته هستید و نمی‌خواهید فرآیندتان بررسی شود، احتمالاً جای درستی نیامده‌اید.