ساعت ۱۴ است و کمپین نوروز باید نیمهشب فعال شود. Product میگوید «امشب Release میکنیم»، QA میگوید «دو روز دیگر برای تست لازم است» و Backend پاسخ میدهد «پرداخت تغییری نکرده». اگر جلسه روی قدرت صدا، دفاع از جایگاه QA یا تکرار موضعها بماند، نه تاریخ واقعاً فهمیده میشود، نه Evidence پرداخت و نه صاحب تصمیم. مهارت مذاکره در QA یعنی این بنبست را به یک تصمیم قابلبررسی تبدیل کنیم—نه اینکه طرف مقابل را شکست دهیم یا کیفیت را تضمین کنیم.
در این راهنما مذاکره چنین جریان دارد: Prepare → Authority → Interests/Constraints → Evidence/Unknowns → Options/Trade-offs → Agreement یا No-agreement → Record → Review. این مسیر برای Scope تست، زمان، محیط، وابستگی، اولویت کار و تصمیم Release طراحی شده است. مذاکرهٔ حقوق و تغییر قرارداد را نیز جداگانه و با مرز قدرت/قانون بررسی میکنیم.
پاسخ کوتاه: مذاکره در QA را چگونه پیش ببریم؟
- Decision و Deadline را قبل از دفاع از راهحل بنویسید.
- بپرسید چه کسی Decide میکند و چه کسی فقط Recommend یا Consult میشود.
- Position را از Interest، Constraint و Hard guardrail جدا کنید.
- Fact، Interpretation، Assumption و Unknown را در یک جمله مخلوط نکنید.
- Evidence را با Scope، نسخه، زمان، Population، Oracle و محدودیت ارائه کنید.
- حداقل Status quo و دو Alternative عملی بسازید؛ «زمان بیشتر» تنها گزینه نیست.
- BATNA را یک مسیر واقعی در صورت عدم توافق بدانید، نه تهدید یا Bluff.
- هر Concession را شرطی و بستهای کنید: «اگر X، آنگاه Y».
- توافق را با Scope، Owner، Deadline، Trigger، Rollback، Dissent و Review ثبت کنید.
- اگر Authority، ایمنی، قانون یا امکان رضایت معتبر وجود ندارد، مسئله را مذاکرهٔ عادی جا نزنید.
Intent جستوجو و مرز این راهنما
Intent اصلی کاربر عملی و شغلی است: «چطور مهندس تست دربارهٔ زمان، Scope، باگ، Release، منابع یا حقوق مذاکره کند؟» کلیدواژهٔ اصلی مهارت مذاکره برای مهندس تست است. عبارتهای مکمل شامل مذاکره در QA، مذاکره زمان تست، دفاع از ریسک نرمافزار، مذاکره Scope تست، BATNA برای تستر، مذاکره Release، مذاکره با مدیر محصول، مذاکره منابع QA، گفتوگوی اختلاف باگ، مذاکره حقوق تستر نرمافزار، درخواست افزایش حقوق QA، Negotiation Skills for QA، ثبت توافق تیم نرمافزار و مذاکره مبتنی بر Evidence هستند.
این مقاله جایگزین تحلیل و تست مبتنی بر ریسک، Triage و مدیریت نقص، پروتکل تعارض QA و Dev یا بازخورد قابلبررسی در تیم QA نیست. آن صفحات بهترتیب Risk evidence، وضعیت/اختیار Defect، تعارض پایدار و Claim دربارهٔ رفتار/کار را مالکاند؛ این صفحه مکانیک رسیدن به توافق تصمیمی را مالک است.
مذاکره چیست و چه چیزی نیست؟
مذاکره یک فرایند برای ساختن یا ردکردن توافق میان طرفهایی است که بخشی از هدفها، ترجیحات، اطلاعات یا محدودیتهایشان متفاوت است. خروجی سالم میتواند Agreement، توافق مشروط، Pilot، تصمیم موقت، Escalation، یا حتی No-agreement روشن باشد. موفقیت الزاماً گرفتن «بله»، بیشترین امتیاز، رضایت همه یا Win-win نیست.
| برداشت ناسالم | بازتعریف تصمیمی | خطر برداشت قدیمی |
|---|---|---|
| دفاع از ارزش QA | شفافکردن Decision evidence و Trade-off | تبدیل اختلاف فنی به هویت و منزلت |
| متقاعدکردن مدیر | ساخت گزینه برای صاحب اختیار | پنهانکردن Authority واقعی |
| QA باید مانع Release شود | QA Evidence/Recommendation میدهد؛ اختیار باید صریح باشد | Veto خیالی یا مسئولیت بدون قدرت |
| برد–برد همیشه ممکن است | گاهی Constraintها ناسازگارند و No-agreement معتبر است | فشار برای رضایت نمایشی |
| همدلی یعنی قبولکردن | فهم دقیق Interest بدون وعدهٔ موافقت | رضایت یا Concession کاذب |
| داده حرف آخر را میزند | Evidence ناقص، وابسته به Context و قابلاعتراض است | اقتدار کاذب عدد |
| سکوت یعنی توافق | Consent و Owner باید صریح ثبت شوند | تصمیم یتیم و بازگشت اختلاف |
چه چیزهایی قابل مذاکره نیستند؟
همهٔ اختلافها را نباید به میز معامله برد. الزام قانونی/قراردادیِ قابلاعمال، ایمنی فوری، رضایت معتبر، حریم خصوصی، تحریف Evidence، جعل نتیجه، انتقام، تبعیض، آزار، تهدید، افشای Secret/PII و حد حرفهای یا Guardrail مصوب ممکن است مسیر Formal، Legal، Security، Incident یا Protected reporting بخواهند. طرف ضعیفتر نباید برای حفظ امنیت یا حق پایه مجبور به «دادوستد» شود.
این راهنما مشاورهٔ حقوقی نیست. منبع Acas که بعداً دربارهٔ حقوق به آن اشاره میشود، مربوط به محیط کاری بریتانیاست و قانون ایران را تعیین نمیکند. قرارداد، سیاست سازمان، مقررات حوزه و مشاور واجدصلاحیت محلی مقدماند. همچنین اگر یک Incident فعال خسارت برگشتناپذیر میسازد، ابتدا Containment و مسیر Incident؛ مذاکرهٔ گزینههای بلندمدت بعد از کنترل.
گام صفر: Decision و Authority را روشن کنید
بسیاری از جلسهها قبل از شروع شکست خوردهاند، چون موضوع واقعی معلوم نیست: آیا دربارهٔ Disposition یک Defect، Priority، زمانبندی، Scope تست، پذیرش Residual risk، تغییر Definition of Done، بودجه، یا شرایط استخدام حرف میزنیم؟ اینها Owner یکسان ندارند. سؤال آغازین مفید این است: «در پایان این گفتوگو دقیقاً چه تصمیمی، تا چه زمانی و توسط چه نقشی باید گرفته شود؟»
Decision / deadline / effective period
Decision owner and delegated authority
Recommenders / evidence owners / consulted roles
Hard guardrails and formal escalation owner
What is already decided / genuinely open / explicitly out of scope
Default if no decision by deadline
Required record / review / expiryScrum Guide 2020 در Context خود Product Owner را پاسخگوی Ordering بکلاگ و Developers انجامدهندهٔ Sizing و برنامهٔ Sprint معرفی میکند؛ راهنما نقش مستقل «QA approver» تعریف نمیکند. از این نباید نتیجه گرفت که همهٔ سازمانها Scrum دارند، Product Owner مالک همهٔ Releaseهاست، یا الزامات Risk/Compliance حذف میشوند. Authority Map محلی، سیاست Release و مسئولیتهای حوزه را ثبت کنید.
| Decision | Evidence/Recommendation محتمل QA | Authority باید از کجا بیاید؟ | خروجی |
|---|---|---|---|
| Expected یا Defect | Repro، Oracle، version | Product/domain + engineering policy | Disposition |
| Severity | Impact scenario و Population | Severity policy / Triage owner | Severity با rationale |
| Priority | Risk و dependency evidence | Product/capacity authority | Order/service class |
| Scope/زمان تست | Work breakdown، baseline، uncertainty | Work owner + delivery authority | Forecast و scope |
| Release risk | Evidence pack و unknowns | Named release/risk owner | Go/Hold/Conditional |
| Tool/محیط/بودجه | Need، option، TCO و pilot | Budget/service owner | Fund/Pilot/Defer/Stop |
| حقوق/قرارداد | Role/terms/proposal evidence | Employer/HR/authorized manager | Written terms یا no change |
Position، Interest، Constraint و Guardrail را مخلوط نکنید
«دو روز Release را عقب بیندازید» Position است؛ شاید Interest آن گرفتن Evidence معتبر دربارهٔ duplicate payment باشد. «کمپین باید امشب باز شود» نیز Position است؛ شاید Constraint واقعی خرید رسانه یا تعهد شریک تجاری باشد، شاید هم فقط ترجیح. بهجای نسبتدادن انگیزه—«Product فقط سرعت میخواهد»—با سؤال و مدرک تفکیک کنید.
| نوع | پرسش | نمونه | آزمون |
|---|---|---|---|
| Position | چه راهحلی اکنون پیشنهاد میشود؟ | ۴۸ ساعت Delay | میتواند با Alternative عوض شود |
| Interest | چه Outcome/نیازی باید حفظ شود؟ | پرهیز از اثر مالی تکراری | چند راه ممکن دارد |
| Constraint | چه محدودیتی دامنهٔ گزینه را کم میکند؟ | رزرو رسانه برای نیمهشب | Source، owner و قابلیت تغییر |
| Guardrail | چه شرطی نباید نقض شود؟ | Release بدون owner و rollback ممنوع | Policy/authority صریح |
| Preference | چه چیزی مطلوب ولی قابلمعامله است؟ | یک Release واحد بهجای Scope split | با Trade-off تغییرپذیر |
| Unknown | چه چیزی هنوز اندازهگیری نشده؟ | رفتار timeout-after-commit در build | Discovery یا decision under uncertainty |
Interest را هم حدس نزنید. عبارتهایی مانند «اگر درست فهمیدهام، تاریخ کمپین یک Hard constraint است؛ چه قرارداد یا هزینهای آن را سخت میکند؟» امکان تصحیح میدهند. Active listening ابزار استخراج اطلاعات و کاهش سوءبرداشت است، نه نمایش همدلی، تشخیص احساس یا تعهد به Concession.
Negotiation Brief: قبل از جلسه چه آماده کنیم؟
Decision, deadline, trigger and default
Parties, authority, power/dependency and representation
Our interests / their stated interests / unverified interpretations
Hard constraints, soft constraints and their sources
Facts / interpretations / assumptions / unknowns
Evidence: build, population, window, oracle, confidence, expiry
Status quo + at least two alternatives
BATNA and conditions that make an agreement unacceptable
Trade-offs, concessions and reciprocal conditions
Privacy, legal, security, accessibility and safety boundaries
Proposed agreement record, owner, monitor, rollback and reviewBrief یک Script برای کنترل دیگران نیست. جاهای خالی را نگه دارید و فرضها را علامت بزنید. اگر طرف مقابل، Authority یا اطلاعات اساسی در جلسه روشن شد، Brief باید Update شود. ثبت «Interest طرف مقابل» بدون اینکه خودش تأیید کرده باشد، Fact نیست.
Evidence را برای تصمیم بسازید، نه برای ترساندن
عدد مشهور «رفع باگ در Production ده تا صد برابر گرانتر است» بدون منبع، نوع عیب، Cost boundary، زمان و Context یک اهرم معتبر نیست. حتی اگر Incident قبلی هزینه داشته، نمیتوان هر روز تست را مساوی همان خسارت فرض کرد. همچنین Bug count، Test count، Coverage خام و Automation hours بهتنهایی Outcome یا ریسک باقیمانده را ثابت نمیکنند. برای Governance معیارها به راهنمای KPI ضدبازی QA رجوع کنید.
Decision Evidence Claim
Decision and option affected
Risk statement: condition → event → impact
Observed fact and source/version/time
Population, sample or executed scope
Oracle and independence
Result, missing evidence and contradictory evidence
Interpretation and plausible alternatives
Uncertainty/confidence without fake precision
Cost/schedule estimate with assumptions and range
Expiry/change trigger
Evidence owner and reviewer| بیان ضعیف | بیان قابلبررسی |
|---|---|
| این Release حتماً خراب میشود | در build 6f2، سناریوی timeout-after-commit اجرا نشده و اثر مالی آن Unknown است |
| پوشش فقط ۶۰٪ است | از ۱۲ Risk scenario سطح A، هفت مورد Evidence معتبر دارند؛ duplicate callback و reconcile عقب ماندهاند |
| یک روز تست میلیونها تومان نجات میدهد | هزینهٔ یک روز تیم معلوم است؛ اثر پیشگیرانه و احتمال Incident هنوز برآورد معتبر ندارند |
| Automation نصف زمان را کم کرد | روی suite/version/window مشخص، elapsed از X به Y رسید؛ setup/triage/maintenance و تغییر Scope جدا هستند |
| این باگ حیاتی است | Condition، impacted population، مالی/ایمنی/داده و evidence confidence طبق Severity policy ثبت شدهاند |
BATNA چیست و در QA چگونه بدفهمیده میشود؟
Program on Negotiation دانشگاه هاروارد BATNA را Best Alternative to a Negotiated Agreement تعریف میکند: بهترین Alternative عملی اگر توافق حاصل نشود. این تعریف از ادبیات عمومی مذاکره میآید؛ دستورالعمل اختصاصی QA، تضمین نتیجه یا مجوز رفتار یکجانبه نیست.
در QA، «Release را متوقف میکنم» فقط وقتی BATNA است که اختیار واقعی آن را دارید. در غیر این صورت شاید Alternative شما این باشد: Evidence و Recommendation را ثبت کنید، Unknown را به Risk owner ارجاع دهید، Scope قابلاجرا را انجام دهید و تصمیم صاحب اختیار را با Guardrailهای مصوب دنبال کنید. BATNA باید feasible، تحت اختیار یا مسیر رسمی شناختهشده و از Bluff جدا باشد.
| مفهوم | معنا | نمونهٔ QA | خطا |
|---|---|---|---|
| BATNA | بهترین مسیر در نبود توافق | Escalate به Release owner با Evidence pack | تهدید ساختگی Hold |
| Proposed agreement | شرایط گزینهٔ مورد بحث | Scope split + canary + reconcile monitor | یکیگرفتن با BATNA |
| Reservation condition | مرزی که زیر آن توافق قابلقبول نیست | نبود named owner یا rollback | عدد دلخواه بدون authority |
| Status quo | آنچه بدون تغییر رخ میدهد | Release طبق برنامه و evidence ناقص | فرض اینکه «هیچ کاری» بدون پیامد است |
| Threat | هزینهای که به دیگری تحمیل میشود | افشای عمومی یا withholding کار | نامگذاری تهدید به BATNA |
Option بسازید؛ روی یک درخواست قفل نشوید
اگر QA فقط «دو روز بیشتر» و Product فقط «امشب» داشته باشد، مذاکره به تقسیم یک عدد تبدیل میشود. ابتدا Status quo را هم گزینه بدانید، سپس شکل مسئله را تغییر دهید: Scope split، Feature flag، Time-boxed discovery، Canary، traffic cap، manual reconcile، compensating control، وابستگی Mockشده، Defer یک جریان، Rollback یا Hold. هر گزینه باید از Hard constraint عبور کند و Evidence/Unknown خودش را داشته باشد.
Option Card
ID / decision / objective served
Included and excluded scope
Prerequisites and hard-constraint fit
Evidence available / unknowns
Expected benefits (not guarantees)
Risk and affected population
Cost, time, capacity and dependency range
Reversibility / blast radius / rollback
Owner / authority / monitoring
Trigger to adapt, stop or escalate
Expiry and next reviewNASA Risk-Informed Decision Making Handbook بر Decision alternatives، معیارها و عدمقطعیت در Context پروژههای NASA تمرکز دارد و خودش راهنما را غیرتجویزی میخواند. اینجا فقط اصل «Alternativeها را با Criteria و Uncertainty روشن مقایسه کنید» اقتباس میشود؛ روش NASA استاندارد جهانی مذاکرهٔ QA نیست و وزن/فرمول آن را نباید بیاعتبار به محصول روزمره منتقل کرد.
| Option family | چه زمانی بررسی شود؟ | پرسش Guardrail |
|---|---|---|
| Delay/Hold | Evidence ضروری با زمان فعلی تولید نمیشود | هزینه/اختیار Delay و Default چیست؟ |
| Scope split | بخش مستقل کمریسک قابل جداسازی است | Coupling و data migration واقعاً جداست؟ |
| Time-boxed discovery | یک Unknown تصمیم را غالب کرده | پس از Timebox چه کسی با چه Criteria تصمیم میگیرد؟ |
| Canary/limited population | اثر محدود و مشاهدهپذیر است | Rollback، consent و مالی/داده چگونه کنترل میشود؟ |
| Compensating control | Risk را حذف نمیکند ولی exposure را محدود میکند | Owner، مدت، toil و expiry چیست؟ |
| Defer one capability | هدف اصلی بدون آن قابلتحقق است | Flag/default و debt owner چیست؟ |
| Proceed with acceptance | صاحب اختیار residual risk را میپذیرد | آیا evidence/unknown/monitor/trigger ثبت شده؟ |
Trade-off را بدون امتیاز جعلی مقایسه کنید
جدول گزینه مفید است، اما جمعزدن نمرههای دلخواه به «بهترین گزینه» حقیقت نمیسازد. ابتدا Hard gateها را جدا کنید؛ سپس Cost، Schedule، Risk، Evidence، Reversibility، Customer impact، operational load و Opportunity cost را با واحد و عدمقطعیت خودشان نشان دهید. یک اثر مالی احتمالی را با امتیاز ۵ و یک خطر Privacy را با ۳ جمع نزنید، مگر مدل و Authority معتبر برای چنین Aggregateای وجود داشته باشد.
Hard gates: legal | safety | authority | consent | irreversible effect
Option A: evidence / unknown / time range / cost range / reversibility
Option B: evidence / unknown / time range / cost range / reversibility
Option C: evidence / unknown / time range / cost range / reversibility
Dominated options and reason
Trade-offs that only the decision owner may accept
Needed discovery before comparison
Decision deadline and defaultگفتوگو را چگونه باز و هدایت کنیم؟
- Purpose: «هدف، تصمیم دربارهٔ Scope نسخهٔ 6f2 تا ساعت ۱۷ است.»
- Authority: «Release owner چه کسی است و Finance چه Guardrailی دارد؟»
- Shared facts: build، deadline، completed evidence و Unknown را کوتاه مرور کنید.
- Interests/constraints: سؤال کنید؛ انگیزه را حدس نزنید.
- Correct: از طرف مقابل بخواهید داده یا برداشت شما را تصحیح کند.
- Options: Status quo و Alternativeها را با Non-scope نشان دهید.
- Trade: Concessionها را شرطی و متقابل بیان کنید.
- Check: توافق، مخالفت، ابهام و اختیار باقیمانده را جدا کنید.
- Record: قبل از پایان، Owner/Trigger/Review را با صدای بلند جمعبندی کنید.
| موقعیت | عبارت پیشنهادی | چرا بهتر است؟ |
|---|---|---|
| زمان ناکافی | با زمان فعلی Evidence سناریوهای A/B فراهم است؛ C/D Unknown میماند. دربارهٔ کدام Decision صحبت میکنیم؟ | Scope و Unknown را جایگزین «نیاز من» میکند |
| Constraint مبهم | آیا تاریخ Hard است یا ترجیح؟ Source و هزینهٔ تغییر چیست؟ | فضای گزینه را روشن میکند |
| اختلاف Fact | منبع من log نسخهٔ X است؛ چه Evidence متناقضی دارید؟ | هویت را از Claim جدا میکند |
| Concession | اگر Scope پرداخت ثابت و Flag قابل Rollback باشد، میتوانیم Regression کمریسک را تا ساعت ۲۰ جمع کنیم | شرط و مرز میسازد |
| فشار Deadline | میتوانیم تا ۱۵ دقیقه دیگر بین این سه گزینه تصمیم بگیریم؛ بدون owner/rollback هیچکدام قابل اجرا نیست | Urgency را از حذف Guardrail جدا میکند |
| عدم توافق | روی Option توافق نداریم؛ موارد مشترک، Dissent و مسیر Escalation را ثبت میکنم | توافق کاذب نمیسازد |
Concession بدهید، اما شرط و بسته را حفظ کنید
Concession یک عقبنشینی اخلاقی نیست؛ تغییر یک مؤلفه برای رسیدن به بستهٔ قابلاجراست. آن را تکتک و بیشرط ندهید. «Regression را کوتاه میکنیم» مبهم است؛ «اگر build تا ۱۴ ثابت بماند، flow گزارشگیری از Scope خارج و owner آن برای پنجشنبه ثبت شود، تیم payment scenarios A–D را تا ۲۰ اجرا میکند» قابلردیابی است.
- Concession چه Interestی را حفظ میکند؟
- در برابر چه تعهد، دسترسی یا Scope change داده میشود؟
- چه چیزی صریحاً واگذار نشده است؟
- اگر شرط رخ نداد، Default چیست؟
- آیا فرد وعدهدهنده اختیار و Capacity دارد؟
- آیا Concession، شبکاری یا حذف استراحت را پنهان میکند؟
- آیا اثر بر کاربر/تیم سوم بدون نماینده تحمیل شده است؟
بستهها را مقایسه کنید: زمان + Scope + Environment + Reviewer + Rollback، نه اینکه هر مؤلفه را جداگانه ببخشید. در نیاز فوری سازمان، اضافهکاری نباید Default خاموش باشد؛ Capacity، جبران، قانون/قرارداد، سلامت و امکان «نه» باید از مسیر مناسب بررسی شوند.
سناریوی ایرانی: مذاکرهٔ Release کمپین پرداخت نوروزی
سناریو ساختگی است. Marketplace ایرانی قرار است نیمهشب تخفیف نوروزی را فعال کند. تغییر ظاهراً فقط Promotion است، اما build جدید مسیر Checkout را نیز لمس کرده است. تبلیغات رزرو شده، محیط PSP از صبح ناپایدار بوده و تیم چهار ساعت تا Freeze فرصت دارد. QA ابتدا میگوید «Release باید ۴۸ ساعت عقب بیفتد»؛ Product میگوید «امکان ندارد».
۱. Decision و Authority
Decision: scope and conditions of build 6f2 release by 17:00
Release owner: named Operations Director under local policy
Ordering/campaign constraint owner: Product Owner
Financial guardrail owner: Finance-risk
Evidence owners: QA + Backend + SRE
Default at 17:00: previous stable campaign configuration remains
Hard gates: named owner, rollback, payment evidence, no real PAN/OTP
Out of scope: salary, blame, long-term test strategy۲. Facts، Unknowns و هویت تراکنش
- Fact: build `6f2` در Staging است؛ Promotion tests سبز هستند.
- Fact: PSP stub برای success/decline کار میکند ولی delay و duplicate callback ناپایدار است.
- Fact: Callback consumer در همین build Refactor شده؛ پس «پرداخت تغییر نکرده» دقیق نیست.
- Unknown: timeout-after-commit، retry کاربر و duplicate/late callback با هم اجرا نشدهاند.
- Unknown: Reconciler پس از backlog burst چقدر عقب میماند.
- Identity: Order ID، Payment Attempt ID، PSP Reference و idempotency key یک چیز نیستند.
- Oracle: UI یا پاسخ PSP بهتنهایی کافی نیست؛ Order، append-only Ledger، Outbox/consumer و Reconciliation مستقل بررسی میشوند.
مبلغ مرجع در Evidence، ریال (`IRR`) است و اگر UI تومان نشان میدهد conversion صریح ثبت میشود. رقمهای فارسی/عربی/لاتین، فاصله/Unicode، UTC و Asia/Tehran و نمایش شمسی جداگانه تست میشوند. دادهها Synthetic هستند؛ PAN، CVV2، OTP، شمارهتلفن واقعی، Token و log خام محرمانه وارد Brief یا ابزار AI نمیشوند.
۳. Interests و Constraints تأییدشده
| نقش | Interest بیانشده | Constraint با Source | نه بهعنوان Fact |
|---|---|---|---|
| Product | حفظ تاریخ کمپین | رزرو رسانه؛ تغییر creative تا ۱۸ ممکن | «Product کیفیت نمیخواهد» |
| QA | Evidence اثر مالی تکراری و بازیابی | ۴ ساعت + دو نفر؛ PSP واقعی ممنوع | «دو روز تنها راه امن است» |
| Backend | پرهیز از تغییر پرریسک آخر وقت | یک reviewer تا ۲۰ در دسترس | «کد حتماً درست است» |
| Finance-risk | یک اثر مالی برای هر intent معتبر | Ledger/Reconcile evidence لازم | «هر Unknown مساوی Hold است» |
| Operations | Rollback و On-call روشن | Canary/flag موجود؛ ظرفیت محدود | «Rollback بدون هزینه است» |
۴. گزینهها و مذاکرهٔ مشروط
| Option | Scope/زمان | Evidence/Unknown | Reversibility | وضعیت |
|---|---|---|---|---|
| A: Delay همهٔ Release | ۴۸ ساعت | Evidence گستردهتر محتمل؛ هزینه/ظرفیت نامعلوم | زیاد | با Hard date ناسازگار |
| B: Release همهچیز اکنون | صفر | Payment evidence و rollback ناقص | ضعیف | رد Hard gate |
| C: Scope split | Promotion مستقل؛ payment refactor پشت Flag | Evidence فعلی برای مسیر قدیمی + monitor | Flag/rollback | قابل بررسی |
| D: Discovery چهار ساعته | سه failure family سپس تصمیم ۱۷ | Unknownهای غالب را کم میکند | تا Decision بدون Production effect | قابل بررسی |
| E: Canary بدون owner | ۵٪ ترافیک | Monitor دارد | Rollback دارد | بهخاطر Owner رد |
پیشنهاد بستهای: «اگر Product تغییر Campaign را از payment refactor جدا و build تا ۱۴:۳۰ ثابت کند، QA/Backend تا ۱۶:۳۰ timeout-after-commit، duplicate callback و retry را با Ledger/Outbox/Reconcile بررسی میکنند. اگر هر Hard invariant شکست خورد یا Evidence تولید نشد، payment refactor پشت Flag میماند؛ Release owner ساعت ۱۷ دربارهٔ Promotion مستقل تصمیم میگیرد.» این توافق، Success را تضمین نمیکند؛ تصمیم، شرط و Default را روشن میکند.
۵. Agreement Record
Agreement ID: REL-6F2-01 / decided at / effective until
Decision and named authority
Parties consulted and unresolved dissent
Selected option / rationale / rejected alternatives
Included / excluded / deferred scope
Facts, evidence versions and explicit unknowns
Conditions precedent and reciprocal commitments
Owner / due time / dependency / capacity
Monitoring / thresholds / affected population
Rollback / stop / escalation trigger
Risk acceptance owner (if any)
Communication audience and privacy class
Review time / expiry / change trigger
Corrections and final closure evidenceآزمایش بازتولیدپذیر: موضع واحد در برابر Option set
برای ملموسکردن مکانیک قیود، یک اسکریپت قطعی با پنج گزینهٔ کاملاً ساختگی ساختم. چهار Hard constraint نیز از پیش توسط نویسنده تعریف شدند: تاریخ کمپین ثابت، Payment evidence الزامی، صاحب تصمیم نامدار و Rollback الزامی. هیچ دادهٔ واقعی پروژه یا مذاکرهکننده وارد نشده است.
HARD_CONSTRAINTS {"fixedCampaignDate":true,"paymentEvidenceRequired":true,"namedDecisionOwnerRequired":true,"rollbackRequired":true}
SINGLE_POSITION [{"id":"DELAY_ALL_48H","feasible":false,"violations":["FIXED_DATE"]}]
OPTION_SET [{"id":"DELAY_ALL_48H","feasible":false,"violations":["FIXED_DATE"]},{"id":"RELEASE_ALL_NOW","feasible":false,"violations":["PAYMENT_EVIDENCE","ROLLBACK"]},{"id":"SCOPE_SPLIT_GUARDED","feasible":true,"violations":[]},{"id":"DISCOVERY_4H_THEN_DECIDE","feasible":true,"violations":[]},{"id":"CANARY_NO_OWNER","feasible":false,"violations":["DECISION_OWNER"]}]
FEASIBLE_IDS ["SCOPE_SPLIT_GUARDED","DISCOVERY_4H_THEN_DECIDE"]تفسیر و محدودیت سختگیرانه
در همین ورودیهای نویسندهساخته، Position واحد `DELAY_ALL_48H` قید تاریخ را نقض کرد؛ Option set دو گزینهٔ عبورکرده از Gateهای تعریفشده ساخت. این فقط نشان میدهد چند Alternative میتواند فضای feasible را در این مدل باز کند. نشان نمیدهد C یا D در دنیای واقعی بهتر، امنتر، منصفانهتر یا پذیرفتنیتر است.
Optionها، Booleanها، Constraintها و قاعدهٔ feasible عمداً و بهصورت دایرهای توسط نویسنده تعیین شدهاند. اسکریپت کیفیت/صحت Evidence، احتمال/شدت، Cost، زمان واقعی، coupling، ترجیح، utility، فرصت، قانون، قدرت، اعتماد، فرهنگ، emotion، bias، accessibility، consent، bluff، مهارت گفتوگو، رفتار انسانی، اجرای توافق یا Outcome را نمیسنجد. خروجی نه الگوریتم Release، نه نمرهٔ مذاکرهکننده، نه Benchmark تیم و نه مبنای Hiring، Performance، Promotion، Pay یا Discipline است.
وقتی توافق حاصل نمیشود چه کنیم؟
No-agreement شکست اخلاقی نیست. شاید Alternativeها زیر Hard gate رد شوند، Authority حاضر نباشد، اطلاعات کافی تولید نشود یا Interests واقعاً ناسازگار باشند. توافق صوری که Owner ندارد یا هیچکس قصد اجرای آن را ندارد، از اختلاف روشن بدتر است.
No-agreement Record
Decision and deadline
Areas agreed / disputed / unknown
Options considered and gate/trade-off reason
Latest evidence and dissent
Current default and immediate guardrails
BATNA or formal escalation path
Named authority needed
Next evidence/action, owner and time
Communication / privacy / no-retaliation boundary
Review or closure conditionEscalation برای «بردن دعوا» نیست؛ باید نقص Authority، Constraint یا Risk decision را حل کند. Packet کوتاه بفرستید، نه dump چت و نه زنجیرهای که طرف مقابل را تحقیر کند. اگر اختلاف به الگوی تکراری رابطه/نقش تبدیل شد، از پروتکل تعارض استفاده کنید؛ اگر Safety/harassment/retaliation مطرح است، مسیر محافظتشده مقدم است و گفتوگوی مشترک اجباری نیست.
توافق را چگونه تحویل و بازبینی کنیم؟
- همان روز Summary را برای نقشهای درگیر بفرستید و فرصت Correction بدهید.
- Decision را از Recommendation و Dissent جدا برچسب بزنید.
- Ticket/ADR/Risk register مناسب را لینک کنید؛ چت خصوصی منبع یکتا نباشد.
- Scope و Non-scope را صریح کنید تا Silence به تعهد تبدیل نشود.
- هر Owner باید اختیار، ظرفیت و Deadline قابلفهم داشته باشد.
- شرطها، Thresholdها و Data source مانیتورینگ را نسخهدار کنید.
- Rollback rehearsal یا دستکم feasibility آن را قبل از اثر پرریسک بررسی کنید.
- در Review بپرسید کدام Assumption غلط بود؛ فرد را با Outcome پسینی قضاوت نکنید.
- Temporary control را با Expiry/Retire owner ببندید.
- اگر Summary اشتباه یا زیانبار بود، Correction/Repair را به همان مخاطبان برسانید.
مذاکرهٔ حقوق QA یک مسیر جداست
Release negotiation دربارهٔ یک تصمیم محصول است؛ حقوق، مزایا، عنوان، Scope نقش یا ساعت کار به قرارداد، بودجه، سیاست، انصاف و قدرت استخدامی مربوطاند. «من یک باگ پیدا کردم، پس فلان مبلغ خسارت را نجات دادم» Attribution معتبر نیست مگر Counterfactual و سهمها واقعاً قابلاثبات باشند. پروندهٔ حرفهای میتواند شواهد Task/Outcome/Scope را نگه دارد، اما برای ساخت آن از راهنمای پورتفولیوی شواهد QA با مرز محرمانگی استفاده کنید.
راهنمای Acas دربارهٔ درخواست افزایش حقوق در Context بریتانیا میگوید فرد میتواند دلایل درخواست را مطرح کند و تغییر توافقشده باید مکتوب شود. این منبع قانون ایران، حق قطعی افزایش، «بهترین زمان»، نرخ بازار یا نتیجهٔ درخواست را تعیین نمیکند. پیش از گفتوگو قرارداد، Collective agreement اگر وجود دارد، Salary band، review cycle، اختیار مدیر و مسیر HR/نماینده را بررسی کنید و برای حقوق محلی از منبع واجدصلاحیت استفاده کنید.
Compensation Proposal
Requested change: salary | title | scope | hours | benefits | review date
Current written terms and effective role scope
Evidence period and representative task/outcome packets
Attribution: own / shared / system / unknown
Comparator/source/date/geography/currency and limitations
Requested amount/range and effective date
Alternatives: staged change | scope correction | benefit | review milestone
Questions: band, criteria, budget owner, decision date and appeal/review
Confidential/private data boundary
Written agreement or written no-change rationale| شاهد مفید | محدودیت لازم | ادعای ناسالم |
|---|---|---|
| Scope نقش نسبت به قرارداد/level rubric | نسخه، مدت و فرصت انجام | من عملاً کار سه نفر را میکنم |
| Work sample و Decision evidence | سهم تیم/سیستم و محرمانگی | من بهتنهایی کیفیت را ساختم |
| Outcome قبل/بعد | Baseline، همزمانی تغییرها، عدم قطعیت | من X میلیارد خسارت را نجات دادم |
| Market source | تاریخ، شهر/Remote، level، currency و selection bias | این عدد «حقوق واقعی بازار ایران» است |
| افزایش مسئولیت پایدار | Authority/support/compensation alignment | اضافهکاری نشاندهندهٔ Seniority است |
در اقتصاد پرتورم یا چندنرخی، رقم سایتهای حقوق بهسرعت منقضی میشود؛ Currency، Net/Gross، بیمه/مالیات، قرارداد ریالی/ارزی، Remote/local، مزایا، ساعت، امنیت شغلی و تاریخ منبع را جدا کنید. دادهٔ همکار را بدون رضایت جمع یا افشا نکنید. یک «نه» ممکن است به بودجه، band، timing، اختلاف معیار یا قدرت مربوط باشد؛ از آن تشخیص ارزش انسان نسازید.
قدرت، رضایت و رفتار فریبنده
توصیهٔ عمومی «محکم مذاکره کن» وقتی کارمند و کارفرما، Vendor و خریدار، یا Junior و مدیر اختیار نابرابر دارند کافی نیست. هزینهٔ مخالفت، ویزا/مهاجرت، قرارداد موقت، تعدیل، پرداخت عقبافتاده، Caregiving و شهرت حرفهای میتواند BATNA را محدود کند. فرد نباید مجبور شود اطلاعات سلامت، خانواده، حقوق همکار، پیشنهاد شغلی یا شکایت محافظتشده را برای اثبات درخواست افشا کند.
- Bluff دربارهٔ اختیار، offer، deadline یا Evidence نسازید.
- Anchor کاذب، scarcity جعلی یا عدد Cost بیمنبع را تکنیک حرفهای ننامید.
- سکوت، خستگی، حضور در جلسه یا «باشه» مبهم را consent پایدار فرض نکنید.
- تهدید اخراج، رتبه، Public shame یا دسترسی برای گرفتن توافق، مسیر عادی نیست.
- در تصمیم پراثر، امکان زمان فکر، نماینده/حمایت، نسخهٔ مکتوب و پرسش فراهم کنید.
- پیشنهاد شفاهی حقوق/Scope را قبل از اتکا در متن دارای authority ثبت کنید.
- اختلاف یا گزارش ریسک را به «عدم همکاری» یا ضعف مذاکره تبدیل نکنید.
- در Safety/harassment/discrimination/retaliation، Formal/protected route و مشاورهٔ محلی را فعال کنید.
مذاکرهٔ Async، Remote و چندزبانه
| شرایط | روش | Guardrail |
|---|---|---|
| Async | Brief کوتاه + deadline + سؤالهای شمارهدار | Silence ≠ agreement |
| اختلاف Fact | Thread روی Artifact/version | خارجکردن شخص از عنوان Claim |
| Time zone | دو پنجره + record + handoff owner | فشار دائمی به یک منطقه زمانی ممنوع |
| فارسی/انگلیسی | Glossary برای Risk/Severity/Priority/Accept | Accent و fluency معیار credibility نیست |
| Accessibility | متن قبل جلسه، caption، زمان پردازش، channel جایگزین | سرعت پاسخ نشانهٔ competence نیست |
| حساس/خصوصی | کمینهسازی audience و retention | Screenshot/recording بدون policy/consent ممنوع |
| Urgent | Decision room با log زنده و owner | Urgency مجوز حذف correction نیست |
محدودیتهای عملی ایران را وارد Brief کنید
- تحریم، VPN، قطع/افت اینترنت یا تغییر دسترسی Cloud/Vendor ممکن است گزینهٔ ابزار را غیرعملی کند.
- پرداخت ارزی، License، Renewal، نرخ تبدیل و نبود Support را در TCO/Dependency ثبت کنید.
- تعطیلات رسمی، نوروز، شیفت On-call، شغل دوم و Caregiving ظرفیت را تغییر میدهند؛ کمبود ظرفیت را ضعف مذاکره ننامید.
- قرارداد و قانون کار/تجارت/حریم خصوصی را با مرجع محلی و نسخهٔ جاری بررسی کنید؛ منبع خارجی قانون ایران نیست.
- ریال مرجع و تومان نمایشی، تقویم شمسی، UTC/Asia-Tehran، Unicode و رقمهای فارسی/عربی/لاتین را در توافق فنی صریح کنید.
- بازار حقوق پراکنده و پرتورم است؛ Source/date/geography/currency/benefits و bias نمونه را ثبت کنید.
- جلسهٔ حضوری، تماس و متن ممکن است از نظر دسترسی یا امنیت برابر نباشند؛ channel جایگزین بدهید.
- Secret، log مشتری، PAN/OTP، اطلاعات قرارداد و حقوق فردی را برای «Evidence بیشتر» بیضابطه پخش نکنید.
استفاده از AI در آمادهسازی مذاکره
AI میتواند از یک Brief پاکسازیشده سؤال، Alternative، Trade-off یا Draft summary پیشنهاد کند؛ اما Authority، قانون، Intent، credibility و agreement را تعیین نمیکند. خروجی ممکن است تکنیک دستکاری، قانون خارجی، عدد حقوق ساختگی یا وعدهٔ Cost saving بسازد.
- از دادهٔ Synthetic یا حداقلسازیشده استفاده کنید؛ Secret/PII/حقوق/سلامت/شکایت/قرارداد خام نفرستید.
- Provider، retention، training use، region، access و deletion را طبق Policy بررسی کنید.
- AI را به Transcript miner برای emotion، personality، deception یا willingness تبدیل نکنید.
- پیشنهاد را با Source اصلی و نسخه بازبینی کنید؛ URL ساختگی را حذف کنید.
- Alternative تولیدشده را از نظر feasibility، owner، power و اثر بر طرف غایب کنترل کنید.
- Summary را برای Correction انسانی بفرستید؛ متن AI صورتجلسهٔ حقیقت نیست.
- از AI برای Anchor/Bluff/فشار شخصیسازیشده یا پیشبینی پذیرش استفاده نکنید.
- تصمیم پراثر و Risk acceptance باید صاحب انسانی نامدار داشته باشد.
تمرین مهارت مذاکره بدون آزمایش روی همکار
یادگیری با حفظکردن جملههای «قدرتمند» یا دستکاری جلسه واقعی کامل نمیشود. یک Work sample ساختگی بسازید: Roleها، Authority، اطلاعات نامتقارن، Hard constraint، Unknown و گزینهها را به افراد بدهید. Reviewer با Rubric، Claim/Question/Option/Record را بررسی کند؛ سپس Variant با Constraint تازه اجرا و پس از فاصله Recheck شود. این تمرین را میتوان با سیستم Taskمحور یادگیری مستمر تستر پیوند داد.
Practice Rubric (not a person score)
Decision/authority clarified before persuasion
Fact/interpretation/assumption/unknown separated
Interests asked and corrected, not inferred
At least status quo + two feasible alternatives
BATNA real and non-threatening
Hard gates separate from trade-offs
Conditional package and explicit non-scope
Agreement/no-agreement record complete
Power/privacy/accessibility boundary honored
Variant + delayed review + repair completedمعیارهای سالم برای سیستم مذاکرهٔ QA
| Signal | تعریف عملی | Countermetric/خطر |
|---|---|---|
| Authority clarity | درصد Decisionها با owner پیش از deadline | Owner صوری بدون اختیار |
| Option readiness | تصمیمهای دارای status quo + alternatives | Option count و ایدههای بیکیفیت |
| Unknown visibility | Unknownهای ثبت و ownerدار | پاداشدادن به Unknown count |
| Agreement executability | scope/owner/trigger/review کامل | Template completion بدون اجرا |
| Decision latency | توزیع intake تا تصمیم برحسب class | تصمیم سریع ولی بیEvidence |
| Reopen/repair | توافقهای بازشده و علت | پنهانکردن reopen برای KPI |
| Temporary-control expiry | کنترلهای بسته/تمدیدشده با دلیل | تمدید خودکار debt |
| Participation/access | امکان input/correction نقشهای affected | Attendance بهجای influence |
| Health/power signals | الگوی شبکاری، bypass، retaliation route | ردیابی فرد یا mood surveillance |
تعداد «برد»، درصد بلهگرفتن، Concession طرف مقابل، زمان صحبت، Interrupt، sentiment، confidence، charisma، حقوق نهایی، تعداد باگ پذیرفتهشده یا تعداد Releaseهای متوقفشده KPI مهارت فرد نیستند. Context، اختیار و Selection effect آنها را منحرف میکند و انگیزهٔ دستکاری میسازد. برای سرمایهگذاری ابزار/محیط نیز ادعا را به Portfolio بودجهٔ QA ببرید، نه اینکه در یک جلسه ROI قطعی اختراع کنید.
Cadence و Pilot سیروزه
| بازه | اقدام | خروجی |
|---|---|---|
| روز ۱–۵ | نمونهبرداری ۱۰ Decision بدون person ranking | ابهام Authority/Record/Unknown |
| روز ۶–۱۰ | تعریف واژگان و Negotiation Brief سبک | نسخه ۰٫۱ + privacy class |
| روز ۱۱–۱۵ | Tabletop ساختگی با Constraint متفاوت | Option/No-agreement/repair gaps |
| روز ۱۶–۲۲ | Pilot روی یک Class کمخطر | Agreement records + feedback |
| روز ۲۳–۲۷ | Review اجرا، reopen و temporary controls | اصلاح fields/authority map |
| روز ۲۸–۳۰ | تصمیم Adopt/Adapt/Stop | owner، scope، cadence و expiry |
جلسهٔ هفتگی برای خود مذاکره نسازید. Brief فقط برای Decisionهای با Trade-off واقعی استفاده شود. ماهانه نمونههای Reopen/Unknown/Authority و فصلی Power/privacy/metric gaming/قواعد منقضی مرور شوند. اگر Template بار اداری میسازد و تصمیم را بهتر نمیکند، ساده یا Retire شود.
۲۰ ضدالگوی مذاکره در تیم تست
- QA بهعنوان آخرین خط دفاع یا مالک انحصاری کیفیت.
- «مذاکره ضرورت است، نه انتخاب» بهعنوان قضاوت ارزش فرد.
- تبدیل Risk decision به دفاع از جایگاه و هویت QA.
- ورود بدون Decision، deadline و Authority.
- یک Position ثابت: «زمان بیشتر یا هیچ».
- حدسزدن Interest و نیت طرف مقابل.
- همدلی نمایشی برای گرفتن Concession.
- عدد ۱۰–۱۰۰ برابر هزینهٔ باگ بدون Context معتبر.
- ادعای تضمین پایداری، کیفیت یا جلوگیری از خسارت.
- Bug/Test/Coverage count بهعنوان اهرم قطعی.
- BATNA خیالی، Bluff و تهدید Hold یا Escalation.
- Win-win اجباری و پنهانکردن No-agreement.
- امتیازدهی دلخواه و جمعزدن Riskهای ناهمواحد.
- Concession بیشرط، بدون non-scope و owner.
- Silence یا خستگی بهعنوان توافق.
- واگذاری شب/تعطیلات برای حل Constraint سازمان.
- مخلوطکردن Triage، Feedback، حقوق و Release در یک جلسه.
- ادعای خسارت جلوگیریشده برای ارزش یا حقوق فردی.
- AI emotion/deception/personality analysis و transcript mining.
- توافق بدون Record، rollback، review، expiry و Repair.
چکلیست ۲۰نقطهای قبل از بستن توافق
- Decision، deadline و trigger مشخص است.
- صاحب اختیار نامدار و حاضر/قابلدسترسی است.
- Open scope و non-scope تفکیک شدهاند.
- Hard guardrail از Preference جداست.
- Positionها از Interestها جدا شدهاند.
- Interest طرف مقابل سؤال و تصحیح شده، نه حدس.
- Fact/Interpretation/Assumption/Unknown تفکیک شدهاند.
- Evidence نسخه، زمان، Population و Oracle دارد.
- Contradiction و limitation پنهان نشدهاند.
- Status quo و دستکم دو Alternative دیده شدهاند.
- BATNA feasible، واقعی و بدون Bluff است.
- Hard gate قبل از Trade-off بررسی شده است.
- Cost/time/risk با uncertainty خود نمایش داده شدهاند.
- Concessionها شرطی و متقابلاند.
- قدرت، رضایت، دسترسی و نمایندگی بررسی شدهاند.
- Privacy، Secret، PII و قانون/سیاست رعایت شدهاند.
- Scope/owner/dependency/capacity ثبت شده است.
- Monitor/trigger/rollback/escalation روشن است.
- Dissent، correction، review و expiry ثبت شدهاند.
- توافق به Artifact مرجع منتقل و به affected roles ابلاغ شده است.
جمعبندی: مذاکره یعنی ساخت تصمیم قابلپیگیری
مهندس تست با «شکار باگ»، لقب نگهبان کیفیت یا جملههای متقاعدکننده شریک تصمیم نمیشود. ارزش حرفهای در این Context از ساختن Claim محدود، آشکارکردن Unknown، فهم Authority و Constraint، ایجاد Alternative قابلاجرا، ثبت Trade-off و پیگیری تعهد میآید. گاهی نتیجه Release مشروط است؛ گاهی Discovery، Hold، Scope split، Escalation یا No-agreement.
برای گفتوگوی بعدی فقط یک Negotiation Brief یکصفحهای بسازید. اگر نمیتوانید Decision، owner، دو گزینه، Unknown و Default را بنویسید، هنوز زمان دفاع از راهحل نیست. پس از اجرا، Outcome را با اطلاعاتی که هنگام تصمیم موجود بود بازبینی کنید؛ نه با سرزنش پسینی.
پرسشهای متداول دربارهٔ مهارت مذاکره برای مهندس تست
چگونه به مدیر بگویم زمان تست کافی نیست؟
«کافی نیست» را به Decision evidence تبدیل کنید: Scope، build، Risk scenarioهای پوششدادهشده/نشده، Work estimate range، assumption، Capacity و Unknown را نشان دهید. سپس Status quo و گزینههایی مثل Scope split، Discovery timebox، Defer، Canary یا Delay را با owner/rollback ارائه کنید. زمان بیشتر را تضمین کیفیت معرفی نکنید.
اگر توسعه باگ را قبول نکرد، مذاکره کنم یا Escalate؟
ابتدا روشن کنید اختلاف دربارهٔ Repro/Fact، Expected behavior، Severity، Priority یا Release است؛ Owner هرکدام فرق دارد. Artifact و Oracle نسخهدار را مرور و Counterevidence را ثبت کنید. اگر Authority یا Standard روشن نیست، به Triage owner ارجاع دهید. Escalation بستهٔ کوتاه تصمیمی است، نه شکایت از شخص.
BATNA برای یک تستر نرمافزار چیست؟
بهترین مسیر عملی در صورت نرسیدن به توافق است. مثلاً ثبت Evidence/Unknown و Recommendation، اجرای Scope تحت اختیار، و ارجاع Risk به Release owner. توقف یکجانبه فقط با اختیار واقعی BATNA است. تهدید، Bluff یا کاری که اختیار/ظرفیتش را ندارید BATNA معتبر نیست.
بهترین زمان مذاکرهٔ افزایش حقوق QA چه زمانی است؟
زمان جهانی وجود ندارد. قرارداد، Salary review cycle، بودجه، تغییر پایدار Scope، availability صاحب تصمیم و سیاست سازمان مهماند. پیش از جلسه درخواست، دلیل، شواهد دورهٔ نماینده، Attribution، مبلغ/بازه، تاریخ اثر و Alternativeها را آماده کنید. موفقیت پروژه بهتنهایی حق یا نتیجهٔ قطعی نمیسازد؛ توافق را مکتوب کنید و برای قانون ایران راهنمای محلی بگیرید.
آیا مذاکرهٔ برد–برد همیشه بهترین نتیجه است؟
خیر. Optionهای خلاق میتوانند Interests بیشتری را پوشش دهند، اما Constraint، حق، ایمنی یا توزیع قدرت ممکن است ناسازگار باشد. No-agreement، Hold یا Formal route گاهی سالمتر از رضایت نمایشی است. نتیجه را با feasibility، guardrail، authority، اجرا و بازبینی بسنجید؛ نه با اینکه همه در جلسه لبخند زدند.
