QA میگوید «این باگ انتشار را متوقف میکند.» توسعه پاسخ میدهد «رفتار مورد انتظار است و روی محیط من بازتولید نمیشود.» مدیر محصول میگوید «کمپین فرداست؛ حلش کنید.» جلسهٔ فوری برگزار میشود، همه موضعشان را تکرار میکنند و یک ساعت بعد هنوز معلوم نیست اختلاف دربارهٔ Fact است، Requirement، Severity، Priority، اختیار انتشار یا اعتماد آسیبدیده. مشکل کمبود احترام نیست؛ تعارض به نوع و صاحب تصمیم درست Route نشده است.
این راهنما یک پروتکل عملی برای مدیریت تعارض بین QA و تیم توسعه ارائه میکند: ابتدا آسیب و کار فعال را مهار میکنیم، نوع اختلاف را تشخیص میدهیم، Fact/تفسیر/Unknown/منافع را جدا میکنیم، Authority و Policy درست را پیدا میکنیم، گزینهها و Trade-off را میسازیم، تصمیم و Dissent را ثبت میکنیم، تعهد اجرا و ترمیم رابطه را دنبال میکنیم و علت سیستمی تکرار اختلاف را اصلاح میکنیم. هدف حذف مخالفت نیست؛ هدف، مخالفتِ ایمن، سریع و تصمیمپذیر است.
خلاصه اجرایی: پروتکل تعارض QA و Dev
- تعارض را شخصی تعریف نکنید: بیشتر اختلافها از هدف، Policy، Evidence، نقش، ظرفیت یا وابستگی میآیند؛ شخصیت فقط یکی از احتمالهاست.
- Containment پیش از Consensus: در Incident یا خطر برگشتناپذیر، اول مشتری/داده/خدمت را محافظت کنید و بعد دربارهٔ علت مذاکره کنید.
- نوع اختلاف، Route را تعیین میکند: Product owner، Maintainer/Tech lead، Release/Risk owner، Service owner، Manager/HR یا Incident commander جایگزین هم نیستند.
- Fact را از Position جدا کنید: مشاهده، Evidence، تفسیر، فرض، Unknown، نیاز و پیشنهاد را در یک جمله مخلوط نکنید.
- Severity، Priority و Disposition متفاوتاند: پیامد، ترتیب کار و ماهیت Report سه تصمیم جدا با Authority متفاوتاند.
- جلسه درمان عمومی نیست: Sync فقط وقتی لازم است که ابهام/تعامل واقعی حل شود؛ خروجی باید در System of record ثبت شود.
- Escalation شکست نیست: وقتی Authority محلی نیست، Deadline/Customer pain نزدیک است یا بنبست تکرار میشود، Routing رسمی لازم است.
- همه تعارضها Win-win ندارند: گاهی صاحب اختیار یک Trade-off را انتخاب میکند؛ طرف مخالف میتواند Dissent ثبت و سپس در محدودهٔ امن Commit کند.
- Safety مسیر جدا دارد: آزار، تبعیض، تهدید، تلافی، افشای محرمانه یا سوءاستفاده از قدرت باید طبق Policy/HR/حفاظت Route شود؛ گفتوگوی مشترک اجباری پیشفرض نیست.
- Closure با «جلسه برگزار شد» نیست: تصمیم اجرا، Outcome/Guardrail بررسی، Commitment پیگیری و در صورت آسیب، Repair انجام میشود.
مرز این مقاله با فرهنگ، ارتباط و Defect management
- برای Signal→Ack→Decision→Closure در خطر کیفیت، ارتباط ریسک کیفیت مالک موضوع است.
- برای Incentive، رفتارهای تقویتشده و جریان خبر بد، فرهنگ کیفیت در نرمافزار را ببینید.
- برای Canonical defect، Triage، Severity/Priority/SLA و Verification، صفحهٔ مدیریت نقص نرمافزار مکمل است.
- برای ساخت گزارش قابلبازتولید، قالب گزارش باگ حرفهای را بخوانید.
این صفحه مالک خود Conflict protocol است: تشخیص نوع، مهار، انتخاب فرایند/Authority، تصمیم، ترمیم و پیشگیری از تکرار. «ارتباط بهتر» یکی از ابزارهاست، نه کل سیستم.
Dev سازنده و QA شکننده نیست
تقابل «توسعه سرعت میخواهد، QA کیفیت» سه آسیب میسازد: کیفیت را از طراحی/کد/عملیات جدا میکند، QA را Gatekeeper نهایی و Developer را متهم پیشفرض میسازد، و هر اختلاف فنی را جنگ هویت میکند. هر دو نقش به Outcome محصول کمک میکنند و هر دو ممکن است Fact، Risk یا Trade-off را اشتباه بفهمند.
| صورتبندی ضعیف | صورتبندی عملی |
|---|---|
| QA میخواهد محصول را بشکند | QA/QE برای خطر مشخص، Evidence و Challenge مستقل فراهم میکند. |
| Dev فقط سرعت میخواهد | Engineering امکانپذیری، سلامت کد، عملیات و هزینهٔ تغییر را نمایندگی میکند. |
| تعداد باگ موفقیت QA است | Outcome، کفایت Evidence، Prevention و Learning خروجی مشترکاند. |
| QA باید Release را تأیید کند | QA حدود Evidence را بیان میکند؛ Release/Risk owner تصمیم نامدار میگیرد. |
| کیفیت مسئولیت همه است | Contribution مشترک است، اما هر Decision و Control صاحب مشخص دارد. |
برای مرزبندی Contribution، Accountability، Gate و Risk acceptance، رهبری تضمین کیفیت و مالکیت همگانی را ببینید.
تعارض سالم، تعارض ناسالم و Safety event
| وضعیت | نشانه | پاسخ |
|---|---|---|
| Task/technical conflict | اختلاف دربارهٔ Fact، طراحی، Oracle، Trade-off یا Policy | Evidence، معیار، Authority و Decision |
| Process/role conflict | Owner، SLA، Queue، Gate یا Handoff مبهم | Operating model/Policy اصلاح و موقتاً Route |
| Relationship conflict | اعتماد آسیبدیده، تفسیر منفی پایدار، گفتوگوی دفاعی | فضای امن، Manager/میانجی مناسب، Agreement و Repair |
| Active incident | Customer/data/service اکنون در خطر است | Incident command، Contain، ارتباط؛ علت بعداً |
| Safety/conduct | آزار، تبعیض، تهدید، تلافی، تحقیر، سوءاستفاده قدرت | حفاظت، ثبت امن، HR/Policy/Formal route؛ نه اجبار به Face-to-face |
این دستهها تشخیص روانشناختی نیستند. یک مورد میتواند هم Technical و هم Relationship باشد. اگر Safety یا الزام قانونی محتمل است، فرد نباید برای «حل دوستانه» مجبور به مواجهه شود. راهنمای Acas دربارهٔ میانجیگری محیط کار نیز Mediation را داوطلبانه و محرمانه معرفی میکند و آن را برای همهٔ اختلافها—ازجمله Conduct/Pay/Dismissal—راهحل واحد نمیداند. Policy و قانون محل کار مقدماند.
۹ نوع تعارض و Route پیشنهادی
| نوع | پرسش | Authority/فرایند معمول | Artifact |
|---|---|---|---|
| Expected behavior | محصول چه رفتاری باید داشته باشد؟ | Requirement/Product authority با User/legal evidence | Requirement/acceptance decision |
| Fact/Oracle | واقعاً چه رخ داده و معیار درست چیست؟ | Joint reproduction/domain/data authority | Evidence bundle/experiment |
| Technical standard/design | کدام راه سلامت سیستم را بهتر حفظ میکند؟ | Maintainer/Tech lead/Architecture policy | ADR/Review decision |
| Risk/release | با Evidence فعلی، ریسک باقیمانده پذیرفتنی است؟ | Release/Risk owner | Decision/Risk acceptance |
| Priority/capacity | چه کاری اول و با چه Trade-off انجام شود؟ | Product + Engineering/capacity authority | Ordered backlog/Capacity decision |
| Role/service | چه کسی Owner، Backup، SLA یا Handoff است؟ | Operating-model/service owner | Team API/Service policy |
| Style/preference | Policy یا Principle الزامآور داریم؟ | Written guide؛ در برابری، ترجیح Author | Review comment/guide change |
| Relationship | چگونه اعتماد/تعامل کاری ترمیم شود؟ | Manager/voluntary mediator | Behavior agreement/follow-up |
| Safety/conduct | آیا حفاظت یا فرایند رسمی لازم است؟ | HR/Legal/Policy/Protection channel | Restricted formal record |
| Active incident | اکنون چه Containmentی Customer pain را کم میکند؟ | Incident commander | Incident timeline/action log |
این جدول حکم جهانی نیست؛ Authority map سازمان باید نسخهدار باشد. نکته این است که «مدیر پروژه میانجی بیطرف همهچیز» معمولاً Authority لازم برای Requirement، کد، Risk یا Conduct را همزمان ندارد.
چرخهٔ بسته تعارض: Detect تا Repair و Learn
Detect → Contain → Frame → Classify → Evidence → Route → Options/Trade-offs → Decide → Commit/Act → Verify → Repair → Learn/Policy change → Close/Reopen
- Detect: بنبست، تکرار موضع، Wait، لحن آسیبزا یا Customer risk را زود ببینید.
- Contain: در خطر فوری، Rollback/Feature flag/Scope split/Stop work را فعال کنید.
- Frame: موضوع و Boundaries را بدون نسبتدادن نیت بنویسید.
- Classify: نوعهای بالا و Safety flag را مشخص کنید.
- Evidence: Fact/Interpretation/Unknown/Need/Position را جدا کنید.
- Route: Policy، Authority، Facilitator و Deadline درست را بیابید.
- Options: حداقل دو گزینه و Trade-off/Reversibility بسازید.
- Decide: Owner تصمیم، Evidence، Dissent و Expiry را ثبت کند.
- Commit/Act: اقدام/Owner/زمان/Default و Guardrail معلوم شود.
- Verify: اجرای تصمیم و Outcome را بررسی کنید.
- Repair: اگر اعتماد یا رفتار آسیب دیده، ترمیم جدا از تصمیم فنی انجام شود.
- Learn: علت سیستمی و تغییر Policy/Tool/Capacity را پیگیری کنید.
گام اول: Containment و Stop condition
بحث طولانی در زمان آسیب فعال، هزینه را زیاد میکند. از قبل Stop condition بنویسید:
- هر برداشت تکراری، افشای Secret/PII یا Corruption داده → Incident/Containment.
- Build/Environment/Evidence identity نامعتبر → Decision کیفیت UNKNOWN، نه Pass/Fail.
- لحن تهدیدآمیز، توهین، تلافی یا افشای محرمانه → توقف جلسه و Safety route.
- دو چرخهٔ تکرار موضع بدون Evidence/Option جدید → Facilitator یا Authority escalation.
- Deadline تصمیم نزدیک و Owner غایب → Default policy و Escalation ازپیشتعریفشده.
- خستگی/برانگیختگی بالا → Pause زماندار؛ نه رهاکردن بیموعد.
Pause/Contain message «این گفتگو اکنون به تصمیم نزدیک نمیشود و Risk/relationship را بیشتر میکند. تا ساعت 14:00 تغییر/Release روی HOLD موقت است. N مالک جمعآوری Evidence، M مالک Route، و R صاحب تصمیم است. جلسه بعد فقط Fact/Unknown/Options را بررسی میکند.»
گام دوم: Conflict Card بنویسید
Conflict Card v1 ID / opened at / reporter / participants: Decision blocked / deadline / default: Observed behavior/event (not intent): Affected outcome / customer / system / relationship: Type(s) / Safety flag / incident flag: Facts + evidence + source/version/time: Interpretations / assumptions / unknowns: Positions (“راهحل من”): Underlying interests/needs/constraints: Policy/standard/requirement/authority: Options / trade-offs / reversibility: Facilitator / decision owner / escalation path: Decision / dissent / commitments / due: Verification / repair / follow-up / learning: Access/retention/confidentiality:
Conflict Card سند پروندهسازی علیه فرد نیست. دادهٔ شخصی، ادعای Conduct یا اطلاعات سلامت باید حداقلی و محدود باشد. Artifact فنی عمومی و Record رسمی HR را در یک Ticket باز مخلوط نکنید.
گام سوم: Fact، Interpretation، Position و Interest را جدا کنید
| لایه | نمونه | سؤال |
|---|---|---|
| Observation/Fact | در Build b417، callback دو بار با Event ID یکسان رسید. | منبع، نسخه، زمان و قابلیت بازتولید؟ |
| Interpretation | «سرویس Idempotent نیست.» | کدام Fact دیگر میتواند همین نتیجه را بسازد؟ |
| Assumption | PSP همیشه Event ID را ثابت نگه میدارد. | تأییدشده یا باید آزموده شود؟ |
| Unknown | رفتار callback هنگام timeout-after-commit معلوم نیست. | چه آزمایشی با چه موعدی Unknown را کم میکند؟ |
| Position | QA=HOLD؛ Dev=GO | راهحل اعلامشده چیست؟ |
| Interest/Need | جلوگیری از برداشت اضافه؛ حفظ کمپین؛ Rollback ساده | چه گزینههای دیگری این نیازها را پوشش میدهد؟ |
| Constraint | PSP sandbox رفتار تولید را ندارد. | واقعی، قراردادی یا خودساخته؟ |
بهجای «تو همیشه باگها را رد میکنی»، بگویید: «در سه Triage اخیر، ۸ Report بدون Joint reproduction با Cannot reproduce بسته شد؛ دو مورد بعداً در Production دیده شد. میخواهم Policy Evidence و Reopen را بررسی کنیم.» رفتار قابلمشاهده، اثر و درخواست مشخص، امکان تصمیم میسازد.
گام چهارم: Evidence contract را متناسب با اختلاف ببندید
| اختلاف | Evidence مفید | چیزی که کافی نیست |
|---|---|---|
| Cannot reproduce | Build/env/data identity، trace، joint replay، affected/unaffected scope | «روی سیستم من کار میکند» یا ویدئوی بینسخه |
| Expected behavior | Requirement/acceptance، user evidence، legal/business rule، decision history | ترجیح QA یا Dev |
| Severity/impact | Outcome، exposure، reversibility، data/security/customer evidence | تعداد کلیک یا صدای بلندتر |
| Priority | Value/Risk/urgency/dependency/capacity/options | Severity بهتنهایی |
| Technical design | Principle/ADR، benchmark، failure mode، maintainability/operation | عنوان شغلی یا سابقه بهتنهایی |
| Relationship | رفتار/زمان/اثر/الگو با حفظ حریم خصوصی | تشخیص شخصیت یا نقل شایعه |
Evidence قرار نیست هر اختلاف را «علمی» و بدون ارزشداوری کند. انتخاب Target، Risk appetite و Priority همچنان قضاوت است؛ Evidence فقط Boundaries و پیامد گزینهها را روشنتر میکند.
گام پنجم: Authority map و Escalation ladder
Level 0: self-resolution with policy/evidence (time-boxed) Level 1: facilitator / joint reproduction / pair review Level 2: domain authority (Product, Maintainer, Service owner) Level 3: cross-functional Release/Risk/Capacity decision owner Level 4: formal HR/Legal/Security/Incident process when applicable Escalate on: deadline, customer pain, authority gap, repeated deadlock, policy conflict, cross-team dependency, safety/conduct or irreversible harm.
Escalation باید شامل «Decision needed، deadline، Fact/Unknown، Options، recommendation و default» باشد؛ Forwardکردن زنجیرهٔ Chat و درخواست «لطفاً حل کنید» Routing نیست.
راهنمای رسمی Google Engineering Practices دربارهٔ اختلاف Code review پیشنهاد میکند ابتدا Consensus مبتنی بر Fact/Principle و Guide تلاش شود، در بنبست گفتوگوی Sync انجام و نتیجه دوباره در Review ثبت شود، سپس Tech lead/Maintainer/Engineering manager تصمیم دهد تا Change معطل نماند. این راهنما برای Code review است؛ همان Authority برای Requirement، Release risk یا Conduct الزاماً درست نیست.
گام ششم: گزینه و Trade-off بسازید
Option Card Option / owner: Outcome served / interest satisfied: Known risk / unknown / assumption: Scope / cost / time / dependency: Reversibility / rollback / expiry: Evidence required before/after: Guardrail / stop trigger: Who bears residual harm/cost?
- Fix before release: Risk کم، زمان/کمپین آسیب میبیند.
- Scope split: PSP/Feature/Segment پرخطر خاموش، ارزش محدود منتشر میشود.
- Canary/Feature flag: Exposure محدود با Monitoring/Rollback—اگر Risk برگشتپذیر باشد.
- Compensating control: Reconciliation دستی/خودکار، Support script یا rate limit تا Fix.
- Time-boxed risk acceptance: Owner/expiry/trigger و Residual risk روشن.
- Discovery: تصمیم کوتاه به تعویق و Unknown پرپیامد با آزمایش کاهش مییابد.
- Reject/Defer: Value کم یا Cost نامتناسب؛ دلیل و موعد بازبینی ثبت میشود.
«مصالحه» همیشه انتخاب میانه نیست. نصفکردن Target امنیت یا Correctness ممکن است غیرقابل قبول باشد. Option باید Hard constraint و کسانی را که هزینه/آسیب میبینند شفاف کند.
گام هفتم: تصمیم، Dissent و Commit
Conflict Decision CD-22 Decision / owner / authority basis: Options considered / rejected reason: Facts / unknowns / evidence limitations: Selected trade-off / affected parties: Dissent and unresolved concern: Actions / owners / due / default: Guardrail / rollback / risk acceptance expiry: Communication / access level: Verification / relationship follow-up / review date:
Commit به معنی ساکتشدن یا موافقت قلبی نیست. فرد میتواند Dissent ثبت کند و تصمیم مشروع را اجرا کند، مگر تصمیم غیرقانونی، ناایمن یا خارج از Authority باشد؛ در آن صورت مسیر حفاظت/اعتراض رسمی باقی میماند. «Disagree and commit» نباید برای خاموشکردن خبر بد یا دورزدن Gate مصرف شود.
گام هشتم: Repair را از حل فنی جدا کنید
ممکن است تصمیم فنی درست شود اما رابطه زخمی بماند. Repair کوتاه و مشخص باشد:
- Acknowledge: چه رفتار/اثر مشخصی رخ داد، بدون «اگر ناراحت شدی».
- Responsibility: سهم خود را بپذیرید؛ قصد خوب اثر بد را حذف نمیکند.
- Repair action: Correction عمومی/خصوصی متناسب، بازگرداندن Credit، حذف داده، تغییر Process یا حمایت.
- Future agreement: رفتار مشاهدهپذیر، Stop word، کانال و Escalation بعدی.
- Follow-up: یک تاریخ برای بررسی اجرای Agreement؛ نه نظارت دائمی.
Repair example «در Triage دیروز گزارش را قبل از شنیدن Evidence “بیارزش” نامیدم. این رفتار اعتبار کار و امنیت گفتوگو را آسیب زد. مسئولیتش با من است. تصمیم Ticket را با دادهٔ تازه اصلاح و در همان کانال Correction میکنم. از این پس Disposition فقط پس از Readiness check و یک سؤال Clarifying ثبت میشود. جمعهٔ آینده با هم بررسی میکنیم که این Agreement عملی بوده یا نه.»
Code review: شدت Comment و Authority را شفاف کنید
Commentهای Review را برچسب بزنید:
- Blocker/Required: Policy، Correctness، Security یا سلامت سیستم؛ دلیل و معیار مشخص.
- Question: Context/intent نامعلوم؛ پاسخ ممکن است Comment را حذف کند.
- Suggestion/Consider: Trade-off پیشنهادی؛ Author میتواند با دلیل مسیر دیگر را انتخاب کند.
- Nit/Optional: Polish یا ترجیح غیرالزامی؛ Merge را Block نمیکند.
- FYI: یادگیری/پیگیری آینده؛ اقدام این Change لازم نیست.
راهنمای Comment در Code review گوگل بر احترام، توضیح «چرا»، تمرکز روی کد نه شخص و صریحکردن شدت Comment تأکید میکند. Courtesy جای استاندارد را نمیگیرد؛ استاندارد مبهم نیز نباید با Comment شخصی اختراع شود. اگر تعارض تکرار میشود، Guide/ADR را اصلاح کنید.
تعارض روی Bug: چهار تصمیم را جدا کنید
| تصمیم | سؤال | نمونه Authority |
|---|---|---|
| Repro/Evidence readiness | Fact کافی برای Triage داریم؟ | QA/Dev pair یا Triage policy |
| Disposition/Expected | Defect، expected، duplicate، environment یا change؟ | Product/domain + technical evidence |
| Severity | پیامد بالقوه/مشاهدهشده چیست؟ | Cross-functional policy/domain |
| Priority/Service class | چه زمانی در برابر چه کاری رسیدگی شود؟ | Product/Risk/Capacity owner |
| Release decision | Residual risk این نسخه پذیرفتنی است؟ | Release/Risk owner |
Cannot reproduce پایان بحث نیست. Scope را به «در محیط/داده/نسخه X مشاهده نشد» محدود کنید؛ Evidence gap، Instrumentation یا Joint reproduction را برنامه دهید؛ و Closing/Reopen policy داشته باشید. «Not a bug» نیز باید Basis و Authority داشته باشد، نه ابزار دفاع از مالکیت کد.
Incident mode: اول Contain، بعد تعارض
- Incident commander اولویت و نقشها را تعیین میکند؛ Debate Architecture وارد Critical path نمیشود.
- QA، Dev، SRE و Support Observation را با Timestamp/Source ارائه میدهند؛ Fact و Hypothesis برچسب دارد.
- Rollback/Feature flag/traffic shift/Reconciliation طبق Trigger اجرا میشود.
- Decision log زنده است؛ Correction و Handoff ثبت میشود.
- پس از Stabilization، اختلاف فنی/نقشی/رابطهای به Route مناسب برمیگردد.
- Postmortem فرد را قربانی نمیکند، اما Action owner و Accountability را حذف هم نمیکند.
Google SRE دربارهٔ فرهنگ Postmortem، Blamelessness را با Ownership رسمی Action جمع میکند و Escalation برای کاهش Customer pain را خطا نمیداند. اقتباس این اصول برای تعارض روزمره نباید همهٔ اختلافها را Incident یا Postmortem کند.
نمونه ایرانی: اختلاف انتشار Checkout و PSP
در یک Marketplace فرضی، QA در Build ۶.۴ دیده است که پس از timeout-after-commit، تلاش دوباره گاهی سفارش دوم میسازد. Dev روی Sandbox بازتولید نمیکند و میگوید callback تکراری با Idempotency key دفع میشود. Product کمپین پایان ماه دارد. UI تومان نمایش میدهد، API/Ledger مقدار Canonical IRR ثبت میکنند و Reconciliation هر ۱۵ دقیقه اجرا میشود.
Frame و Classification
Decision blocked: Release 6.4 GO/HOLD/Scope split by 16:00 Asia/Tehran Observed: b417, PSP-A stub, duplicate order_id after retry; video alone lacks trace Types: Fact/Oracle + expected behavior + release risk + priority/capacity Not yet: relationship or conduct Outcome: duplicate order/charge, seller allocation, support load Unknown: PSP production callback identity after timeout-after-commit Authority: Product for expected outcome؛ Maintainer for mechanism؛ Release Owner for residual risk
Joint evidence
- attempt_id، payment_id، order_id، PSP reference، callback event_id و idempotency_key جدا ثبت شوند.
- Fault injection قبل/بعد Commit و callback تکراری/دیررس/خارج ترتیب اجرا شود.
- Oracle مستقل API، Order DB، Ledger، Outbox و Reconciliation بررسی شود.
- مبلغ ۱٬۰۰۰٬۰۰۰ IRR و نمایش ۱۰۰٬۰۰۰ تومان؛ ارقام ۱۲۳/۱۲۳/۱۲۳ و Unicode ی/ی، ک/ک تست شوند.
- Instant در UTC و عملیات Asia/Tehran؛ تاریخ شمسی فقط View، نه تغییر Window.
- Scope مشاهدهشده/آزمودهنشده و محدودیت Stub در Evidence bundle بماند.
Options و Decision
| گزینه | ارزش | ریسک/Guardrail |
|---|---|---|
| GO کامل | کمپین کامل | Unknown پرپیامد؛ رد |
| HOLD کامل | کمترین Exposure | هزینه کمپین/زمان؛ برگشتپذیر |
| Scope split به PSP-B | بخشی از ارزش | Canary ۵٪، duplicate=۰، unresolved_15m≤۰٫۱٪ |
| Manual reconciliation only | Release سریع | ظرفیت/تأخیر؛ برای duplicate charge کافی نیست |
Release owner با Dissent ثبتشدهٔ Sales، Scope split روی PSP-B را انتخاب میکند؛ PSP-A خاموش، Canary و Rollback trigger فعال و آزمایش تولید-ایمن برنامهریزی میشود. تصمیم «QA برد/Dev باخت» نیست. Fact gap با Pair evidence کم شد، Product رفتار مطلوب را بست و Authority ریسک Trade-off را پذیرفت.
Repair و Learn
در Triage، عبارت «این تست ساختگی است» اعتبار QA را آسیب زده و QA نیز «تیم Dev همیشه ریسک را پنهان میکند» نوشته است. هر دو عبارت Correction میشوند. تغییر سیستمی: Environment limitation در Bug template، Joint reproduction برای Critical Cannot-reproduce، Authority map برای Disposition/Release و Fault hook در Testability backlog اضافه میشود.
آزمایش قطعی: جلسه عمومی در برابر Routing نوعمحور
برای نشاندادن یک خاصیت محدود پروتکل، ۹ Conflict case ساختگی با Route مورد انتظارِ ازپیشتعریفشده در Node.js بررسی شد: Expected behavior، Technical standard، Release risk، Priority/capacity، Service ownership، Style preference، Relationship، Safety/conduct و Active incident. روش Generic همه را به «جلسه مشترک با Manager» فرستاد؛ روش Typed از جدول نوع→Authority استفاده کرد.
Runtime: Node.js 24.18.0 Cases: 9 fictional conflicts Generic manager-joint-meeting: matched predefined route: 1/9 unsafe joint-meeting route for Safety case: 1 Typed routing: matched predefined route: 9/9 unsafe joint-meeting route for Safety case: 0 Routes included: Product requirement authority؛ Maintainer/Tech lead؛ Release/Risk owner؛ Product+Engineering capacity authority؛ Service owner؛ written policy؛ Manager joint meeting؛ protected HR/Policy route؛ Incident commander.
مرز ادعای آزمایش
نتیجه بهدلیل اینکه Expected route و Rule typed را یک نویسنده تعریف کرده، تقریباً ساختاری و بدیهی است. این آزمایش ثابت نمیکند Classification درست بوده، Authority تصمیم خوب میگیرد، جلسه Generic همیشه بد است، مسیر Formal حتماً ایمن است یا تعارض انسانی حل/رابطه ترمیم میشود. Caseها ساده و تکبرچسبیاند؛ Power، Context، قانون، فرهنگ، احساس، سوگیری، چندنوعیبودن، کیفیت Facilitator و Outcome واقعی مدل نشدهاند. خروجی فقط نشان میدهد یک Route ثابت نمیتواند با Taxonomy ازپیشتعریفشده منطبق باشد و Safety case باید Exception صریح داشته باشد—نه Benchmark، الگوریتم HR یا ابزار تصمیم خودکار.
جلسه، Async یا Mediation؟
| روش | مناسب برای | شرط/خطر |
|---|---|---|
| Async artifact | Fact، Evidence، Option، تصمیم ساده | لحن/ابهام ممکن است رشد کند؛ Deadline لازم |
| Pair/joint reproduction | Fact/Oracle/Environment | نسخه/داده/زمان و نتیجه ثبت شود |
| Short facilitated sync | Trade-off چندطرفه یا بنبست | Agenda، type، owner، time-box، record |
| Domain authority review | Requirement، architecture، release risk | Authority و Basis شفاف |
| Voluntary mediation | Relationship breakdown با رضایت طرفین | محرمانگی، بیطرفی و تناسب؛ تصمیم فنی جدا |
| Formal process | Conduct، grievance، discrimination، legal/safety | Need-to-know، protection و Policy |
| Incident command | آسیب فعال | Containment و نقشها مقدم بر Consensus |
برای Remote/Hybrid، متن کوتاه و قابلترجمه، زمان UTC همراه Asia/Tehran، دسترسپذیری جلسه/Artifact، فرصت برابر پاسخ و پرهیز از تصمیم در کانال خصوصی مهماند. نبود پاسخ فوری را Agreement ندانید و اختلاف زبانی/Accent را کمبود تخصص فرض نکنید.
Metrics سالم برای سیستم تعارض
- Time to classify/route: از Conflict-ready تا Authority؛ با Countermetric Misroute/Reopen.
- Decision latency by type: Queue/meeting/wait تفکیک شود؛ سرعت به قیمت Silence نباشد.
- Unknown aging: Unknown اثرگذار بر تصمیم، نه تعداد کل سؤالها.
- Repeated conflict mechanism: Requirement/Policy/Owner/Environmentهای تکراری.
- Decision reversal: علت Evidence تازه، Authority اشتباه یا اجرای ناقص.
- Commitment completion: Action بهموقع با Outcome، نه فقط Ticket closed.
- Repair follow-up: Agreement اجرا شد؟ دادهٔ رابطه خصوصی و غیررتبهای بماند.
- Safety route access: آگاهی/دسترسی/زمان پاسخ؛ نه کمبودن Report بهعنوان موفقیت.
- Customer/flow guardrails: Incident/blocked time/rework، بدون نسبتدادن علیت ساده.
- Policy change effectiveness: آیا Mechanism پس از تغییر واقعاً کمتر شد؟
تعداد Conflict پایین KPI سلامت نیست؛ شاید افراد خبر بد را پنهان میکنند. «درصد حل Win-win» نیز هدف بازیپذیر است. Metricها را برای اصلاح سیستم استفاده کنید، نه امتیاز «همکار خوب» یا شناسایی فرد مسئلهدار.
حریم خصوصی، قدرت و AI
- Artifact فنی را از پروندهٔ Conduct/HR جدا و Access/Retention را حداقلی کنید.
- Facilitator بیطرفی نسبی و Conflict of interest خود را اعلام کند.
- اختلاف قدرت، قرارداد، وضعیت مهاجرت/استخدام و وابستگی مدیریتی را نادیده نگیرید.
- ضبط جلسه فقط با Policy/Consent/نیاز روشن؛ Transcript عمومی پیشفرض نیست.
- AI میتواند Fact/Unknown/Option را Draft کند، اما Tone/نیت/دروغ/آزار یا «مقصر» را استنتاج نکند.
- خلاصهٔ AI باید Source-linked و قابل Correction باشد؛ دادهٔ حساس وارد مدل/کانال غیرمجاز نشود.
- Decision، Risk acceptance، Formal finding و Performance action انسانی و دارای Authority بمانند.
ضدالگوهای مدیریت تعارض QA و Dev
- Dev builds/QA breaks: هویت متضاد بهجای Outcome مشترک.
- One team slogan: Authority و Incentive متعارض زیر شعار پنهان میشود.
- More meetings: Type/owner/evidence بدون تغییر میماند.
- Manager solves all: Requirement/Code/Risk/HR به Authority اشتباه Route میشوند.
- Severity equals Priority: Impact و ترتیب کار مخلوط میشوند.
- Not reproducible = closed: Scope/Unknown/Instrumentation حذف میشود.
- QA approval gate: Evidence provider به Risk owner بدل میشود.
- Consensus required: Decision تا رضایت همه معطل میماند.
- Compromise worship: Hard constraint/آسیب برگشتناپذیر نصف میشود.
- Escalation shame: بنبست و Customer pain طولانی میشود.
- Escalation as threat: قدرت برای ساکتکردن Challenge مصرف میشود.
- Public correction, private praise: اعتبار فرد ناعادلانه آسیب میبیند.
- Intent over impact: «منظورم بد نبود» Repair را متوقف میکند.
- Blameless = no accountability: Action/Owner و Boundary حذف میشوند.
- Mediation for harassment: مواجههٔ اجباری و آسیب بیشتر.
- Incident debate: Containment منتظر RCA/Consensus میماند.
- Chat archaeology: تصمیم در صدها پیام بیSource گم میشود.
- Silence = commit: قدرت/زمان/زبان نادیده گرفته میشود.
- Conflict count KPI: گزارشنکردن پاداش میگیرد.
- No repair: Ticket حل میشود، الگوی رابطهای باقی میماند.
برنامهٔ ۳۰روزه پیادهسازی پروتکل
هفته اول: Conflict audit و Safety boundary
- ۱۰ اختلاف اخیر را بدون رتبهبندی افراد نمونهگیری کنید.
- Type، Authority gap، Wait، Reopen و Mechanism را استخراج کنید.
- Safety/Conduct/Formal paths را با HR/Policy/Legal محلی تأیید کنید.
- Stop condition و Incident boundary را منتشر کنید.
هفته دوم: Card، Taxonomy و Authority
- Conflict Card و Type→Route map را سبک طراحی کنید.
- Severity/Priority/Disposition/Release authority را جدا کنید.
- Escalation packet و Default policy را ببندید.
- Access/Retention و Recordهای فنی/محرمانه را تفکیک کنید.
هفته سوم: Tabletop و Pair evidence
- Cannot reproduce، Release risk، Style و Safety را Tabletop کنید.
- Pause/Contain، Joint reproduction و Escalation را تمرین کنید.
- Code review severity label و Triage readiness را Pilot کنید.
- Facilitatorها را روی Power/Safety/Confidentiality آموزش دهید.
هفته چهارم: Live pilot و Repair review
- یک Value stream و تعارض کم/متوسطریسک را Pilot کنید.
- Time-to-route، Misroute، Decision/Action و Unknown را بسنجید.
- Repair و Policy change را تا Outcome پیگیری کنید.
- Templateهای پرزحمت را حذف و Authority gap را به Operating model برگردانید.
چکلیست قبل از بستن تعارض
- Customer/data/service یا Safety نیاز به Containment دارد؟
- Decision blocked، Deadline و Default معلوماند؟
- موضوع بدون نسبتدادن نیت نوشته شده است؟
- Typeهای تعارض و احتمال چندنوعیبودن مشخصاند؟
- Safety/Conduct و Record محرمانه جدا بررسی شدهاند؟
- Fact، Interpretation، Assumption و Unknown جدا هستند؟
- Position، Interest، Constraint و affected parties معلوماند؟
- Evidence نسخه/منبع/زمان/Scope و محدودیت دارد؟
- Policy/Requirement/Standard معتبر و جاری است؟
- Disposition، Severity، Priority و Release decision تفکیک شدهاند؟
- Authority و Facilitator تعارض منافع ندارند؟
- Self-resolution time-box و Escalation trigger داریم؟
- حداقل دو Option و Trade-off/Reversibility ساخته شده است؟
- Hard constraint و کسی که هزینه/آسیب میبیند روشن است؟
- Decision، Basis، Dissent و Expiry ثبت شدهاند؟
- Action/Owner/Due/Default و Guardrail داریم؟
- اجرای تصمیم و Outcome Verify شدهاند؟
- در صورت آسیب رابطه، Repair جدا انجام شده است؟
- Mechanism سیستمی و Policy/Tool/Capacity action پیگیری میشود؟
- Close به معنی Meeting/Ticket closed نیست و Reopen rule دارد؟
پرسشهای متداول
۱. چرا بین QA و توسعه تعارض ایجاد میشود؟
معمولاً نه بهخاطر تضاد ذاتی شخصیت، بلکه بهدلیل Requirement/Oracle مبهم، Risk appetite متفاوت، Pressure/Capacity، KPI متعارض، Authority و Handoff نامشخص، Evidence ناقص یا اعتماد آسیبدیده. تشخیص نوع مهمتر از توصیهٔ عمومی «همکاری کنید» است؛ هر علت Route و اصلاح سیستمی متفاوت دارد.
۲. وقتی Dev میگوید باگ قابل بازتولید نیست چه کنیم؟
Build/Environment/Data/Identity و Scope را ببندید، Evidence را Pair بررسی و تفاوت محیط را مقایسه کنید. نتیجه را محدود بنویسید: «در X مشاهده نشد»، نه «وجود ندارد». برای خطر بالا Joint reproduction، Instrumentation یا آزمایش دیگری برنامه دهید؛ Disposition/Close و Reopen policy باید نامدار باشد.
۳. چه کسی در اختلاف Severity و Priority تصمیم میگیرد؟
Severity پیامد را با Policy Cross-functional میسنجد؛ Priority ترتیب کار را با Value/Risk/Urgency/Dependency/Capacity تعیین میکند. Authority محلی ممکن است Product، Risk owner یا Triage group باشد. QA/Dev Evidence میدهند، اما هیچکدام نباید هر دو تصمیم و Release acceptance را یکطرفه مالک شوند.
۴. چه زمانی تعارض را Escalate کنیم؟
وقتی Authority محلی نیست، Deadline/Customer pain نزدیک است، بنبست پس از Time-box ادامه دارد، Policyها متناقضاند، Dependency چندتیمی است، آسیب برگشتناپذیر یا Safety/Conduct محتمل است. Escalation باید Decision packet داشته باشد؛ تهدید مدیریتی یا Forwardکردن Chat نیست.
۵. آیا ادغام QA در تیم Dev تعارض را حل میکند؟
نه لزوماً. Embedded QE میتواند Context و Feedback را بهتر کند، اما اگر Authority، Incentive، استقلال Challenge، Specialist service و Risk acceptance مبهم بماند، تعارض فقط پنهان میشود. Central/Embedded/Federated را بر اساس Value stream، Capability، Risk و Interaction انتخاب کنید؛ Conflict protocol مستقل از Org chart لازم است.
جمعبندی: اختلاف را به نوع، Evidence و Authority تبدیل کنید
تعارض QA و Dev با شعار «یک تیم» یا جلسهٔ بیشتر حل نمیشود. پروتکل سالم ابتدا خطر را مهار میکند، نوع اختلاف و Safety boundary را میشناسد، Fact/Unknown/Position/Interest را جدا میکند، Authority درست را به Policy و Evidence وصل میکند، Option/Trade-off و Dissent را ثبت میکند و پس از اجرا، هم Outcome و هم Repair را بررسی میکند.
از ۱۰ اختلاف اخیر و یک Route map کوچک شروع کنید. اگر تیم بتواند بهجای «چه کسی حق دارد؟» بپرسد «چه نوع تصمیمی با چه Evidence، توسط کدام Authority و تا چه زمانی لازم است؟»، مخالفت از جنگ هویت به سازوکار یادگیری و تصمیم کیفیت تبدیل شده است.
