مدل قیمت‌گذاری طراحی سایت؛ Fixed، T&M، Capacity و Hybrid

دو پیشنهاد برای یک سایت فروشگاهی روی میز است: اولی «۹۰۰ میلیون تومان، ثابت و تحویل چهارماهه»؛ دومی «تیم سه‌نفره، ماهانه ۲۴۰ میلیون تومان». عدد اول ارزان‌تر به نظر می‌رسد، اما محتوا، مهاجرت داده، اتصال حسابداری و تست بار را خارج از Scope گذاشته است. عدد دوم سقف دارد، ولی خروجی ماه نخست و معیار توقف روشن نیست. مقایسه این دو عدد بدون مقایسه تعهد، ریسک، فرض، کیفیت و هزینه کل تصمیم مالی نیست.

مدل قیمت‌گذاری تعیین می‌کند عدم‌قطعیت و انگیزه‌ها میان کارفرما و مجری چگونه توزیع شوند. Fixed price برای Scope روشن می‌تواند مناسب باشد؛ Time & Materials برای کشف و تغییر انعطاف می‌دهد؛ Capacity/Retainer دسترسی مستمر به تیم را می‌خرد؛ و Hybrid بخش‌های متفاوت پروژه را با قرارداد متفاوت کنترل می‌کند. هیچ‌کدام ذاتاً ارزان‌تر، امن‌تر یا Agileتر نیست.

چهار محور را از هم جدا کنید

رایج‌ترین خطا این است که «ثابت، مرحله‌ای یا زمان‌ومواد» را سه گزینه هم‌رده بدانیم. مرحله‌ای معمولاً شیوه پرداخت یا تحویل است، نه مبنای قیمت. یک قرارداد Fixed price می‌تواند ۳۰٪ پیش‌پرداخت و سه Milestone داشته باشد؛ T&M نیز می‌تواند ماهانه یا پس از هر Sprint صورتحساب شود.

نوع رابطه قراردادی نیز جداست: ممکن است یک MSA برای قواعد عمومی و چند SOW برای Work packageها داشته باشید. نام سند به‌تنهایی تعیین نمی‌کند چه ریسکی منتقل شده است.

«قیمت سایت» را به تصمیم خرید تبدیل کنید

قبل از مدل قیمت، Baseline بسازید: مسئله کسب‌وکار، کاربران، مسیرهای حیاتی، سامانه‌های موجود، محدودیت زمانی، نیازهای امنیت/دسترس‌پذیری/SEO، مالک محتوا و معیار موفقیت. سپس Scope را به Workstreamهای قابل برآورد تقسیم کنید:

• Discovery، پژوهش و معماری اطلاعات؛
• طراحی UX/UI و Design system؛
• Frontend، Backend، CMS و پنل؛
• Integration، Payment، SMS، CRM/ERP و Analytics؛
• Content، ورود داده و Migration؛
• Security، Accessibility، Performance و SEO QA؛
• Hosting، License، ابزار ثالث و محیط‌ها؛
• آموزش، Launch، Warranty، Support و Exit.

برای فهم Driverهای هزینه و ساخت Quote هم‌سطح، ابتدا راهنمای هزینه طراحی سایت از Scope تا Estimate را بخوانید. «تعداد صفحه» بدون Template، State، Integration و Content responsibility واحد برآورد کافی نیست.

ریسک واقعاً منتقل نمی‌شود؛ قیمت‌گذاری می‌شود

در Firm fixed price، مجری ریسک Cost overrun ناشی از Scope توافق‌شده را بیشتر می‌پذیرد و معمولاً Contingency آن را داخل قیمت می‌آورد. کارفرما همچنان ریسک Definition ناقص، تأخیر تصمیم، Dependency خودش، Change request و محصول نامتناسب با بازار را دارد. قرارداد ثابت، عدم‌قطعیت را ناپدید نمی‌کند.

به‌عنوان یک مرجع مفهومی، نه قانون ایران، FAR آمریکا درباره Fixed-price contract قیمت قطعی را مدلی می‌داند که هزینه واقعی مجری مبنای تعدیل آن نیست و برای Specification نسبتاً قطعی و برآورد واقع‌بینانه مناسب‌تر است. همین منبع وجود Fixed price قابل تعدیل و مدل‌های Incentive را هم نشان می‌دهد؛ «Fixed» همیشه یک شکل ندارد.

Fixed price چه زمانی مناسب است؟

وقتی خروجی، Acceptance، داده و وابستگی‌ها روشن‌اند؛ نمونه مشابه دارید؛ تصمیم‌گیرندگان در دسترس‌اند؛ و تغییر بنیادین محتمل نیست، قیمت ثابت می‌تواند Budget certainty خوبی بدهد. نمونه‌ها: Landing page با Design system موجود، مهاجرت محدود و شمارش‌شده، یا سایت معرفی استاندارد با Content آماده.

قرارداد ثابت باید این موارد را صریح کند:

• Deliverable و حالت‌های آن، نه فقط Feature name؛
• Acceptance test و Dataset/Browser/Device هدف؛
• Assumption، Dependency و مسئول هر ورودی؛
• Exclusionها و Serviceهای ثالث؛
• تعداد/مرز Revision و تعریف Defect؛
• Change request با اثر زمان/قیمت/ریسک؛
• قواعد Delay، Suspension، Termination و Handover؛
• شرایط تعدیل برای بازه طولانی یا هزینه ارزی.

Fixed price بدون Scope قابل آزمون معمولاً به یکی از سه چیز منجر می‌شود: Contingency بزرگ، پیشنهاد غیرواقعی برای بردن قرارداد، یا نزاع دائمی درباره داخل/خارج Scope.

Milestone مدل قیمت‌گذاری نیست

Milestone یک نقطه کنترل و پرداخت است. می‌تواند در Fixed، T&M یا Hybrid استفاده شود. Milestone سالم به Evidence متصل است، نه صرفاً تاریخ یا عبارت مبهم «اتمام ۵۰٪ پروژه».

برای هر Milestone، Reviewer، Deadline بازخورد، روش ثبت Nonconformity و زمان اصلاح را تعیین کنید. «رضایت کامل کارفرما» معیار قابل آزمون نیست؛ «انطباق با Acceptance criteria پیوست» قابل رسیدگی‌تر است.

Time & Materials چه چیزی می‌خرد؟

در T&M، کارفرما زمان نقش‌های توافق‌شده و هزینه مستقیم مواد/خدمات مجاز را می‌پردازد. این مدل انعطاف برای Backlog متغیر و Discovery می‌دهد، اما Outcome یا Budget نهایی را خودبه‌خود تضمین نمی‌کند. تعریف رسمی FAR از T&M نیز آن را Hours با نرخ ثابت به‌علاوه Material واقعی توصیف و نبود Incentive ذاتی کنترل هزینه را گوشزد می‌کند؛ این چارچوب قانون ایران نیست، اما Trade-off را خوب روشن می‌کند.

قرارداد T&M بالغ باید Rate card، Seniority، حداقل/نحوه گردکردن زمان، کار Billable و Non-billable، هزینه Third-party، Approval و Timesheet evidence را مشخص کند. «اعتماد کنید، آخر ماه فاکتور می‌زنیم» Governance نیست.

Forecast at completion = Cost to date
                       + Remaining backlog forecast
                       + Known risk allowance

Burn variance = Actual burn - Planned burn

گزارش هفتگی بهتر است Outcome/Deliverable، زمان مصرف‌شده بر حسب Workstream، Blocker، Forecast، Change و تصمیم لازم را نشان دهد؛ Activity log خام جای پیش‌بینی نیست.

Capped T&M: سقف، ضمانت Scope نیست

Not-to-exceed cap مانع عبور هزینه بدون تأیید می‌شود. این سقف نمی‌گوید همه Backlog حتماً در همان مبلغ تمام می‌شود. قرارداد باید رفتار نزدیک سقف را تعیین کند: هشدار در ۷۰/۸۵٪، Reforecast، کاهش Scope، توقف، افزایش Cap یا انتقال به Work package بعدی.

اگر مجری موظف باشد هر Scope مبهمی را زیر Cap تحویل دهد، در عمل Fixed price بدون قیمت‌گذاری ریسک ساخته‌اید. اگر کارفرما هر لحظه Priority را عوض کند ولی Deadline/Scope/Cap ثابت بمانند، Constraint ناسازگار است. حداقل یکی باید قابل تغییر باشد.

Dedicated team یا Capacity subscription

در این مدل، کارفرما ظرفیت یک تیم یا چند Role را در بازه می‌خرد، نه فهرست Feature قطعی. برای Product مستمر، چند Integration و Backlog پویا مناسب است. قرارداد باید ظرفیت را عملیاتی تعریف کند:

• ترکیب نقش‌ها، Seniority و درصد تخصیص؛
• روز/ساعت کاری، تعطیلات، مرخصی و On-call؛
• جایگزینی فرد، Ramp-up و Knowledge transfer؛
• مالک Product backlog و Cadence تصمیم؛
• Carryover یا انقضای ظرفیت مصرف‌نشده؛
• حداقل تعهد، Notice کاهش/افزایش و Exit؛
• سنجه Flow و Outcome، نه Utilization صددرصد.

خرید ۱۶۰ ساعت نام یک نفر با خرید Outcome تیم یکسان نیست. Context switching و تخصیص هم‌زمان به چند مشتری باید شفاف باشد.

Retainer پشتیبانی با Capacity توسعه یکی نیست

Retainer می‌تواند دسترسی به Support، Maintenance، Monitoring و تغییرات کوچک را پوشش دهد. تعریف Incident، Severity، Response، Restore target، ساعت پوشش، کانال درخواست، سقف و Exclusion ضروری است. SLA نباید وعده مبهم «پشتیبانی ۲۴/۷» باشد.

هزینه Patch، Backup، Restore drill، License، Monitoring، Incident و توسعه تکاملی را در بودجه سالانه ببینید. راهنمای هزینه پشتیبانی سایت و SLA این سبد را از Ticket reactive جدا می‌کند.

Value-based pricing چه زمانی قابل دفاع است؟

در Value pricing، قیمت فقط از ساعات تولید مشتق نمی‌شود؛ ارزش اقتصادیِ مسئله برای مشتری نیز وارد مذاکره می‌شود. این مدل نیازمند Outcome، Baseline، Alternative، Time horizon و دامنه نفوذ راهکار است. «سایت برای شما میلیاردها می‌ارزد» بدون Evidence قیمت‌گذاری ارزشی نیست.

ارزش بالقوه با ارزش قابل انتساب فرق دارد. فروش تحت تأثیر محصول، قیمت، برند، رسانه، عملیات، موجودی و تیم فروش است. اگر Bonus بر Conversion باشد، Data access، Attribution rule، Seasonality، Paid media، Guardrail کیفیت Lead و تغییرات خارج کنترل مجری باید روشن باشند.

Outcome-based و Incentive: سنجه می‌تواند بازی شود

پرداخت نتیجه‌ای وقتی مناسب‌تر است که Metric قابل اندازه‌گیری، تحت نفوذ معنادار مجری و مقاوم در برابر Gaming باشد. پرداخت بر تعداد Lead می‌تواند Lead بی‌کیفیت بسازد؛ پرداخت بر سرعت صفحه ممکن است Feature یا Analytics لازم را حذف کند. یک Metric اصلی با Guardrailهای کیفیت، امنیت، دسترس‌پذیری و درآمد خالص تعریف کنید.

Fee = Base fee
    + Incentive × Verified incremental outcome

Subject to:
  quality guardrails
  attribution window
  data completeness
  agreed exclusions and cap

Outcome contract بدون Baseline و Counterfactual، اختلاف را از Scope به Attribution منتقل می‌کند.

Hybrid معمولاً طبیعی‌ترین پاسخ است

پروژه سایت چند نوع عدم‌قطعیت دارد؛ لازم نیست یک مدل بر همه تحمیل شود:

راهنمای Contracting for Agile دولت بریتانیا نیز بر انتخاب زمینه‌ای و امکان ترکیب اجزای Fixed و T&M تأکید دارد. آن را الگوی حقوقی ایران ندانید؛ برای فهم رابطه Agile delivery و Commercial model استفاده کنید.

Discovery پولی هزینه اضافی نیست

Discovery باید ابهام را به Decision artifact تبدیل کند: Journey، Content/data inventory، Integration map، Non-functional requirements، Risk/assumption log، Prototype، گزینه معماری، Delivery plan و Estimate range. گزارش زیبا بدون کاهش عدم‌قطعیت، Discovery موفق نیست.

خروجی Discovery باید قابل انتقال باشد و قرارداد ادامه را خودکار نکند. اگر نتیجه نشان داد WordPress، سایت‌ساز یا راهکار آماده مناسب‌تر است، مسیر باید امکان تغییر داشته باشد. برای مقایسه گزینه‌های Build، راهنمای وردپرس در برابر طراحی اختصاصی و برای Vendorهای SaaS مقایسه Wix، Squarespace و Shopify مفیدند.

Scope باید State و کیفیت را ببیند

«طراحی صفحه محصول» مشخص نمی‌کند Empty state، Out-of-stock، Variant، خطای قیمت، Mobile، RTL، Skeleton، SEO metadata، Schema، Analytics، Permission یا Accessibility داخل است. یک Deliverable card بسازید:

Capability: Product detail
Actors: guest, customer, editor
States: loading, available, unavailable, error, stale
Data: product, variant, stock, price, content
Dependencies: ERP, search, image CDN, payment
Quality: p75 performance, WCAG target, security, SEO
Acceptance: journeys + test data + evidence
Owner inputs: content, policy, credentials, sign-off

Scope فقط Feature نیست؛ Quality attribute و Operations بخشی از محصول‌اند. اگر مقیاس مهم است، Workload/Quota و Failure را پیش از قیمت بسنجید؛ راهنمای مقیاس‌پذیری و Workload چارچوب آن را می‌دهد.

Acceptance باید سریع، عینی و نسخه‌دار باشد

برای هر خروجی Acceptance criteria، محیط، داده تست، Evidence، Reviewer و مهلت بازخورد تعیین کنید. بازخورد باید به Criterion یا Defect قابل بازتولید اشاره کند. تغییر سلیقه پس از تأیید Design و نقص انطباق با Design تأییدشده یک چیز نیستند.

قرارداد باید رفتار سکوت، بازخورد متعارض چند ذی‌نفع، Acceptance مشروط و Defect پس از پذیرش را روشن کند. عبارت‌های حقوقی مثل پذیرش ضمنی را از Template خارجی Copy نکنید؛ وکیل آشنا با قرارداد فناوری و قانون حاکم باید متن نهایی را بررسی کند.

Change control را به ابزار تنبیه تبدیل نکنید

Change request باید تغییر واقعیت را قابل تصمیم کند، نه اینکه هر سؤال را صورتحساب تازه بسازد. Workflow پیشنهادی:

1. درخواست با علت، ارزش و Deadline ثبت شود.
2. Baseline و Requirement قبلی مشخص شود.
3. اثر بر Scope، زمان، هزینه، کیفیت و Dependency برآورد شود.
4. گزینه‌ها ارائه شوند: Swap، Add، Defer یا Reject.
5. شخص مجاز تصمیم و Budget source را تأیید کند.
6. Contract/Backlog/Forecast و Acceptance version به‌روزرسانی شوند.

در T&M، تغییر Backlog ممکن است Change order رسمی قیمت نخواهد، اما Forecast و Priority را تغییر می‌دهد. در Fixed scope، Swap هم باید هم‌ارزی Effort/Risk داشته باشد.

Estimate عدد قطعی نیست؛ Distribution است

برای Workstreamها Range و Confidence بدهید. P50 یعنی حدود نیمی از سناریوها زیر آن‌اند؛ P80 محافظه‌کارانه‌تر است. Contingency برای Known uncertainty داخل Baseline، و Management reserve برای Unknown/decision مدیریتی جدا نگه داشته می‌شود.

Expected effort ≈ Σ(work package range)
                + integration uncertainty
                + rework/coordination allowance
                + risk contingency

TCO horizon = Build
            + licenses/infra
            + content/data
            + support/security
            + change and exit cost

Point estimate بدون Assumption و تاریخ اعتبار، دقت کاذب می‌سازد. Quote باید Expiry و شرایط Re-estimate داشته باشد.

قیمت و پرداخت در ایران: واحد و تعدیل را صریح کنید

در قرارداد و Invoice دقیقاً مشخص کنید مبلغ ریال است یا تومان و هر تبدیل چگونه انجام می‌شود. برای هزینه ارزی License/Cloud/API، Currency source، تاریخ/بازه نرخ، دامنه نوسان، Cap، Evidence و حق جایگزینی Vendor را تعریف کنید. «نرخ روز» بدون منبع و زمان، قابل اختلاف است.

برای قرارداد بلندمدت می‌توان Review period یا فرمول تعدیل بر اساس شاخص/محرک توافق‌شده داشت؛ کف، سقف، Notice و اثر بر Work packageهای قبلاً پذیرفته‌شده را روشن کنید. این بند باید متناسب با قانون حاکم و با مشاوره حقوقی/مالیاتی نوشته شود؛ این مقاله متن حقوقی آماده نیست.

Tax و Invoice را به آخر مذاکره موکول نکنید

قیمت شامل یا بدون مالیات/عوارض، تکلیف کسورات، نوع Invoice، زمان صدور، اطلاعات طرفین و پرداخت بانکی باید صریح باشد. الزامات مالیاتی و سامانه مودیان می‌توانند با نوع شخص و تاریخ تغییر کنند؛ حسابدار یا مشاور مالیاتی باید وضعیت روز هر دو طرف را تأیید کند. از درج نرخ یا نسخه عمومی بدون Snapshot خودداری کنید.

همچنین مشخص کنید هزینه License، Domain، Hosting، SMS، Payment fee و سرویس خارجی با Markup، At-cost یا مستقیماً توسط کارفرما پرداخت می‌شود و Evidence آن چیست.

پرداخت را به Cash flow و Evidence متصل کنید

پیش‌پرداخت می‌تواند رزرو ظرفیت و هزینه شروع را پوشش دهد؛ Milestone پرداخت را به Evidence نزدیک می‌کند؛ Holdback کوچک ممکن است انگیزه Handover بسازد، اما Holdback بزرگ یا نامحدود جریان نقدی مجری را مخدوش می‌کند و در قیمت Risk premium می‌آورد.

Late payment، توقف کار، حفظ/انتقال دسترسی و Restart lead time را با وکیل روشن کنید؛ هیچ طرفی نباید با قطع ناگهانی Production یا نگه‌داشتن دارایی حیاتی به‌عنوان اهرم مبهم روبه‌رو شود.

مالکیت فکری، License و دسترسی‌ها

«مالک سایت» عبارت کافی نیست. تفکیک کنید:

• کد و طراحی اختصاصی پس از کدام پرداخت و با چه حقوقی منتقل می‌شود؛
• Background IP، Library و ابزار عمومی مجری چیست؛
• Open-source و Commercial license چه محدودیتی دارند؛
• Font، Image، Video، Plugin، Theme و Dataset متعلق به چه کسی‌اند؛
• Domain، Hosting، Repository، Analytics، Search Console و Accountها به نام چه کسی‌اند؛
• Portfolio/case-study و استفاده از نام/داده مشتری چه رضایتی می‌خواهد؛
• در پایان، Export، Credential rotation و حذف داده چگونه انجام می‌شود.

قانون تجارت الکترونیکی ایران که در WIPO Lex منتشر شده، Data message، امضای الکترونیکی و ارزش اثباتی سوابق الکترونیکی را به رسمیت می‌شناسد و در ماده ۶۲ به حقوق آثار و نرم‌افزار در مبادلات الکترونیکی می‌پردازد. تفسیر و متن روز را وکیل ایرانی بررسی کند؛ ثبت Version، فرستنده، زمان، تأیید و نگهداری امن Evidence در هر حال کار عملی معقولی است.

Integration و هزینه پنهان Third party

عبارت «اتصال به CRM» می‌تواند از Embed یک فرم تا Sync دوطرفه با Webhook، Retry، Mapping، Consent و Reconciliation متغیر باشد. برای هر Integration، Source of truth، Object/field، Direction، Trigger، Volume، Rate limit، Error/retry، Security، Sandbox، SLA، Owner و Exit را ثبت کنید.

راهنمای یکپارچه‌سازی سایت و Data contract کمک می‌کند هزینه Integration قبل از Quote آشکار شود. دسترسی‌ندادن کارفرما یا مستندات ناقص Vendor نیز Dependency قراردادی با اثر زمان است.

Warranty، Defect و توسعه جدید

Warranty باید مدت، Scope، Severity، محیط و شرط بازتولید داشته باشد. Defect یعنی خروجی با Requirement/Acceptance پذیرفته‌شده منطبق نیست؛ تغییر Requirement یا سازگاری با نسخه جدید سرویس ثالث لزوماً Defect نیست. از سوی دیگر، برچسب «Change» نباید برای فرار از اصلاح نقص واقعی استفاده شود.

Security vulnerability، Data loss و Incident production ممکن است مسیر جدا از Defect UI داشته باشند. SLA پاسخ با زمان حل یکی نیست. Warranty رایگان نامحدود، هم غیرواقعی و هم عامل پنهان‌کردن قیمت است.

Exit باید از روز اول قیمت‌گذاری شود

پایان همکاری سناریوی شکست نیست؛ بخشی از Lifecycle است. Contract باید این دارایی‌ها را فهرست کند: Source repository و history، Build/deploy، Infrastructure/config، Database schema/export، Content/media، Design source، Documentation، Inventory/license، Runbook، Backup/restore evidence، Credential ownership و جلسه انتقال.

Termination for convenience/cause، Notice، پرداخت Work-in-progress، Refund، استفاده از Deliverable نیمه‌تمام، حذف داده و Support انتقالی به بررسی حقوقی نیاز دارند. اگر خروج فقط با بازنویسی کامل ممکن است، TCO Quote ناقص است.

ماتریس انتخاب مدل

اگر سازمان Product owner در دسترس، Backlog مرتب و تصمیم هفتگی ندارد، T&M انعطاف را به انتظار و Burn تبدیل می‌کند. اگر Specification هنوز کشف نشده، Fixed price دقت مصنوعی می‌سازد. Model fit به توان Governance دو طرف وابسته است.

دو Quote را هم‌سطح مقایسه کنید

یک Comparison sheet با Baseline مشترک بسازید. برای هر پیشنهاد، Included/Excluded/Assumed/Optional/Unknown را علامت بزنید و TCO ۲۴ یا ۳۶ماهه را محاسبه کنید. نرخ ساعتی پایین با تیم Junior، Rework، مدیریت زیاد یا Lock-in می‌تواند گران‌تر باشد.

Normalized bid = Initial build
               + excluded mandatory work
               + expected change allowance
               + 24/36-month run cost
               + migration/exit cost
               + risk-adjusted dependency cost

اگر میان تیم داخلی و پیمانکار مردد هستید، راهنمای تیم داخلی یا برون‌سپاری Demand، TCO، Governance و Exit را مقایسه می‌کند. برای معماری Headless نیز هزینه Build فقط بخشی از تصویر است؛ راهنمای TCO هدلس کامرس لایه‌های Platform، Integration و عملیات را باز می‌کند.

Red flagهای پیشنهاد و قرارداد

• قیمت قطعی پیش از Discovery برای Integration ناشناخته؛
• Milestone بر اساس درصد زمان، بدون Deliverable/Acceptance؛
• «تغییر نامحدود» یا «Warranty همیشگی» بدون قید؛
• T&M بدون Rate card، Timesheet، Cap و Forecast؛
• Capacity بدون تیم/Role/Availability/Replacement روشن؛
• همه چیز داخل است، اما Content/Data/License/Tax/Hosting نامشخص؛
• پرداخت کامل پیش از دسترسی به Repository/Environment/Evidence؛
• Domain و Accountهای اصلی به نام Vendor بدون Exit؛
• واحد پول یا فرمول هزینه ارزی مبهم؛
• مالکیت، محرمانگی، داده شخصی، توقف و حل اختلاف Copy/Paste شده‌اند.

نمونه انتخاب برای فروشگاه ایرانی

فروشگاه ۱۵هزار SKU، ERP قدیمی، دو PSP و کمپین نوروز دارد. Deadline تجاری مهم است، اما کیفیت داده و ظرفیت ERP ناشناخته‌اند. Fixed price کل پروژه پیش از اتصال آزمایشی ریسک بالایی دارد.

1. Discovery ثابت: Inventory، Mapping داده، Load sample، Payment journey، Content plan و Risk register.
2. Vertical slice با Cap: یک Category، Product، Cart، Payment و Order sync واقعی.
3. Build Hybrid: Work packageهای روشن Fixed؛ Integration/Backlog متغیر با Capacity و Cap ماهانه.
4. Launch milestone: Data reconciliation، performance، security، rollback و operational readiness.
5. Hypercare/Retainer: Severity/SLA و ظرفیت تغییر جدا.

برای این سناریو، مبلغ‌ها با تومان/ریال صریح، License ارزی با فرمول و Cap، موجودی/قیمت با Source of truth، و Cut-off تغییر Scope پیش از کمپین بسته می‌شوند. اگر Vertical slice نشان دهد ERP گلوگاه است، ادامه قرارداد بر اساس Evidence Rebaseline می‌شود.

چک‌لیست پیش از امضا

• مسئله، Outcome، Scope و Out-of-scope قابل فهم‌اند.
• چهار محور Scope/Compensation/Delivery/Payment جدا ثبت شده‌اند.
• Deliverable، State، Quality و Acceptance version دارند.
• Assumption، Dependency، Client input و Delay effect روشن‌اند.
• Estimate range، Confidence، Contingency و Quote expiry وجود دارند.
• Rate/Cap/Forecast یا Fixed/change mechanism کامل‌اند.
• ریال/تومان، هزینه ارزی، مالیات/Invoice و Third party مشخص‌اند.
• IP/License/Account/Repository/Data و Case-study permission روشن‌اند.
• Security، Privacy، Backup، SLA، Warranty و Incident تعریف شده‌اند.
• Suspension، Termination، Handover، Data deletion و Dispute path بررسی شده‌اند.
• وکیل و مشاور مالیاتی متن نهایی و وضعیت روز را بررسی کرده‌اند.

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

آیا پرداخت مرحله‌ای یک مدل قیمت‌گذاری است؟

معمولاً نه؛ Milestone یک Schedule پرداخت/کنترل تحویل است و می‌تواند روی Fixed price، T&M یا Hybrid قرار گیرد. نوع Pricing می‌گوید مبلغ چگونه محاسبه می‌شود؛ Milestone می‌گوید چه زمانی و با چه Evidence پرداخت می‌شود.

Fixed price برای کارفرما همیشه امن‌تر است؟

فقط وقتی Scope، Acceptance و Dependency نسبتاً روشن‌اند. در ابهام بالا، Risk premium، Exclusion، Quality trade-off یا Change dispute ایجاد می‌شود. Discovery یا Vertical slice محدود می‌تواند پیش از قیمت ثابت، عدم‌قطعیت را کم کند.

چگونه T&M را بدون چک سفید کنترل کنیم؟

Rate card، Backlog اولویت‌دار، Cap دوره‌ای، آستانه هشدار، Timesheet قابل ردیابی، گزارش Outcome، Forecast at completion و حق Stop/Reprioritize تعریف کنید. سقف هزینه را با تضمین تکمیل تمام Scope اشتباه نگیرید.

برای پروژه سایت در ایران قیمت را ریال بنویسیم یا تومان؟

هر کدام که طرفین توافق می‌کنند باید صریح، یکدست و همراه با روش تبدیل باشد؛ ابهام میان ریال و تومان ریسک جدی است. هزینه ارزی، مالیات و Invoice نیز با منبع/تاریخ/مسئول و تأیید مشاور حقوقی و مالیاتی روز تعریف شوند.

بهترین مدل برای پروژه‌ای با Scope نامعلوم چیست؟

اغلب یک Discovery محدود و پولی، سپس Capped T&M یا Capacity با Review gate مناسب‌تر از Fixed price کل پروژه است. پس از کاهش ابهام، بخش‌های پایدار را می‌توان Fixed کرد. توان Product ownership و Governance کارفرما نیز تعیین‌کننده است.

جمع‌بندی: مدل خوب، رفتار خوب می‌سازد

قرارداد قیمت‌گذاری فقط تقسیم پول نیست؛ Incentive، شفافیت و واکنش دو طرف به تغییر را طراحی می‌کند. Fixed برای قطعیت واقعی، T&M برای یادگیری کنترل‌شده، Capacity برای جریان مستمر، Retainer برای عملیات و Hybrid برای پروژه چندماهیتی ابزارهای متفاوت‌اند. Milestone را از Pricing جدا و هر پرداخت را به Evidence متصل کنید.

قدم بعدی این است: یک Quote موجود را بردارید و با چهار ستون Scope/Compensation/Delivery/Payment بازنویسی کنید؛ سپس Unknownها، هزینه‌های اجباریِ خارج‌شده، Acceptance، Currency/Tax، IP/Access و Exit را علامت بزنید. اگر هنوز نمی‌توانید دو پیشنهاد را روی یک Baseline بگذارید، هنوز زمان انتخاب Vendor نرسیده است.