مالک محصول میگوید «این قابلیت برای کمپین لازم است» و تستر سه Finding، دو ناشناخته و محدودیت محیط را مطرح میکند. اگر گفتگو فقط به «چند باگ باز است؟» یا «PO تأیید کرد؟» ختم شود، نه ارزش محصول روشن شده، نه ریسک، نه کف شواهد و نه اختیار تصمیم. همکاری تستر و مالک محصول زمانی عملیاتی است که Product Bet و تصمیم مورد نیاز به Quality Question، Evidence Request، Option، Trade-off و Decision Record قابل بازبینی تبدیل شود.
این راهنما یک Tester–Product Owner Decision Interface میسازد: قرارداد نسخهداری که Product Goal، ذینفع/بهرهمند، Outcome مطلوب، فرضها و Decision need را به شواهد کیفیت وصل میکند و پس از تصمیم با Rollout، Guardrail، Outcome review و Correction بسته میشود. این Interface جای Product Backlog، Sprint Planning، UAT، UX Research، Test Strategy یا Release authority را نمیگیرد.
پاسخ کوتاه: تستر و مالک محصول چگونه مؤثر همکاری کنند؟
مالک محصول Context ارزش، Goal، Bet، محدودیت و تصمیم مورد نیاز را قابل بررسی میکند؛ تستر Risk claim را به سؤال کیفیت، طراحی شواهد، Observation، Finding، Unknown و محدودیت تبدیل میکند؛ نقشهای دارای اختیار گزینهها و Trade-offها را میسنجند؛ تصمیم با Scope، شرط، Expiry و Dissent ثبت میشود؛ نتیجهٔ Rollout و Outcome در Window مشخص بازبینی و در صورت خطا Correction میگیرد. عنوان شغلی بهتنهایی هیچکدام از این حقوق تصمیم را ثابت نمیکند.
- Product Goal و Product Bet را نسخهدار کنید.
- Decision need و صاحب اختیار را پیش از تست مشخص کنید.
- فرضها و Risk claimها را به Quality Question تبدیل کنید.
- برای هر سؤال، Evidence Request محدود بسازید.
- Observation، Finding، Unknown و Recommendation را جدا نگه دارید.
- Options و Trade-offها را پیش از تصمیم ثبت کنید.
- تصمیم را با شرط، Rollout، Guardrail و Expiry ببندید.
- Outcome را مشاهده و ادعا/تصمیم اشتباه را اصلاح کنید.
مرز مالکیت: این مقاله Product Decision Interface است
| موضوع | واحد اصلی | خروجی | مالک محتوایی |
|---|---|---|---|
| Tester–PO Interface | یک Product Bet/Decision | Question، Evidence request، Option و Decision loop | همین مقاله |
| Sprint Planning | یک Sprint Goal و Plan | Risk-to-Evidence، ظرفیت و Forecast | نقش تستر در Sprint Planning |
| Early Quality Interface | یک Risk و نقطهٔ Feedback | Earliest economical evidence + Countercheck | نقش تستر در Shift-left |
| UX Research | یک Research Question | Observation، Insight و Product Decision | تست تجربه کاربری |
| UAT | یک Acceptance Claim | Participant evidence و Sign-off محدود | تست پذیرش کاربر |
این Interface دربارهٔ انتقال معنا و شواهد میان قابلیت Product و Test است. نه میگوید همهٔ تصمیمها با PO است، نه تستر را Gatekeeper انتشار میکند. برای گزارش یکصفحهای به مدیران، Quality Decision Brief مالک دقیقتری است؛ برای قرارداد انتظار چند ذینفع، راهنمای مدیریت انتظارات ذینفعان را ببینید.
منابع اصلی چه میگویند و چه چیزی را تضمین نمیکنند؟
Scrum Guide 2020 Product Owner را در برابر بیشینهکردن ارزش محصول و مدیریت مؤثر Product Backlog پاسخگو میداند؛ کل Scrum Team را در برابر Increment ارزشمند و مفید پاسخگو میشمارد و Developers را در قبال کیفیت از مسیر Definition of Done پاسخگو میکند. Scrum «Tester» را Accountability چهارم، PO را صدای کامل مشتری، مسئول UAT یا تأییدکنندهٔ انتشار تعریف نمیکند.
اصول مانیفست چابک بر همکاری روزانهٔ افراد کسبوکار و توسعه، تحویل زود و پیوسته، گفتوگو، سادگی و بازاندیشی تأکید دارد. این اصول ابزار، عنوان جلسه، حضور اجباری تستر در هر رویداد، Three Amigos ثابت یا SLA پیام تجویز نمیکنند. «روزانه» را نباید به دسترسپذیری لحظهای یا جلسهٔ روزانهٔ اضافی تحریف کرد.
راهنمای رسمی Evidence-Based Management ۲۰۲۴ تصمیم آگاهانهتر را به آزمایش هدفمند و Feedback وصل میکند و Input، Activity، Output، Outcome و Impact را جدا میسازد؛ Feature، Report و Defect report را Output میداند و هشدار میدهد Output لزوماً Outcome بهتر نیست. EBM یک Lens مدیریتی است، نه نسخهٔ اجباری نقش QA/PO یا اثبات علیت یک تغییر محصول.
قرارداد مرکزی: Product Decision Interface
interface_id: PDI-CHECKOUT-01 version/status/supersedes: 1.0.0 / PILOT / null effective_from/review_at: 2026-08-17 / 2026-09-16 product/product_goal: SYN-CHECKOUT / PG-SYN-18 beneficiary/desired_outcome: SEG-SYN-NEW / recover checkout after delayed callback current_evidence: EVIDENCE-SNAPSHOT-SYN-4 product_bet: BET-SYN-11 assumptions: [callback delay is primary barrier, recovery message is understood] scope/out_of_scope: callback recovery / [pricing, real banking, release authority] decision_need/decision_by: choose rollout option / 2026-08-20T09:00:00Z decision_owner/authority: PRODUCT-DECISION-OWNER / PRODUCT-MANDATE-v2 test_capability_owner/product_context_owner: TEST-CAP / PRODUCT-CONTEXT quality_questions/risk_claims/harm_floor: versioned references evidence_requests/evidence_minimum: versioned references observations/findings/unknowns/uncertainty: immutable records options/tradeoffs/recommendation/dissent: decision packet decision/conditions/expiry: DEC-SYN-8 / COND-SYN-2 / 2026-09-16 rollout/guardrails/stop/rollback: ROLLOUT-SYN-3 outcome_measure/countermetrics/review: OUTCOME-CONTRACT-SYN-5 people_scoring: false correction/audit/not_claimed: required
شناسهها و مقدارها کاملاً مصنوعیاند. این Schema بهتنهایی همکاری یا تصمیم خوب نمیسازد؛ فقط نقاطی را که باید معنا، مالک و Trail داشته باشند آشکار میکند. تیم میتواند شکل Artifact را کوچک کند، اما حذف فیلد باید آگاهانه و متناسب با Risk باشد.
هویت، نسخه و Snapshot را پیش از گفتگو قفل کنید
`interface_id` پایدار، Version، Status، Supersedes، تاریخ اثر و Review را ثبت کنید. Product، Goal، Bet، Backlog item، Build، Environment و Evidence snapshot نباید با عبارتهای «همین نسخه» یا «داستان پرداخت» رها شوند. اگر Product Goal یا Acceptance basis پس از دیدن نتیجه تغییر کند، نسخهٔ جدید و اثر آن بر Evidence قبلی لازم است.
Product Goal را با Feature list اشتباه نگیرید
Product Goal مقصد بلندمدت محصول است، نه فهرست Storyهای Sprint. Interface باید نشان دهد Bet مورد بحث چگونه—با چه فرضی—به Goal کمک میکند. «افزودن دکمهٔ بازیابی» Output است؛ «کاربر هدف پس از Callback نامطمئن بتواند خرید را بدون پرداخت دوباره ادامه دهد» Candidate outcome است. تحقق آن هنوز نیاز به Evidence دارد.
Beneficiary را از Persona و Stakeholder جدا کنید
بگویید چه گروهی قرار است چه Outcomeای تجربه کند و چه کسانی ممکن است متحمل Harm شوند. Persona یک ابزار طراحی است و نمایندهٔ آماری همهٔ کاربران نیست؛ Stakeholder میتواند از نتیجه اثر بگیرد ولی کاربر مستقیم نباشد. Segment، Eligibility، Exclusion و Unknown coverage را ثبت کنید و ادعای «برای کاربران» را بیدامنه نگذارید.
Desired Outcome باید قابل مشاهده اما محدود باشد
Outcome رفتار یا وضعیت مطلوبی است که بهرهمند تجربه میکند؛ Impact نتیجهٔ سازمانی گستردهتر است. «Release ویژگی» Output و «افزایش درآمد» Impact چندعلتی است. Desired outcome را با Population، Direction، Window، Baseline، Measure و Guardrail بنویسید؛ Target قراردادی را Benchmark عمومی یا وعدهٔ قطعی معرفی نکنید.
Current Evidence را پیش از Product Bet منجمد کنید
شواهد وضع موجود میتواند Analytics، Support case، UX study، Incident، Test result یا Observation عملیاتی باشد. Source، Window، Population، Missingness، Freshness و Limits را ثبت کنید. یک شکایت، یک نمودار Funnel یا سه Defect حقیقت کامل مسئله نیست. Snapshot منجمد مانع از آن میشود که Baseline بعد از Outcome دلخواه بازنویسی شود.
Product Bet را به وعده تبدیل نکنید
bet_id: BET-SYN-11 change: show recoverable state after a synthetic delayed callback for: SEG-SYN-NEW because: current evidence suggests abandonment after ambiguous state expected_outcome: more eligible synthetic journeys resume safely assumptions: [state detection is correct, message is understood, retry is idempotent] risks: [duplicate action, false recovery, inaccessible message] evidence_before_rollout: [state model checks, exploratory session, accessibility review] evidence_after_rollout: [guardrail and outcome windows] not_claimed: [revenue cause, all-user benefit, release safety]
Bet یعنی فرضیهٔ سرمایهگذاری تحت عدم قطعیت. «حتماً Conversion را بالا میبرد» Bet نیست، وعدهٔ اثباتنشده است. Change، Beneficiary، Expected outcome، Assumptions، Risk، Evidence و Limit را کنار هم بگذارید.
Assumption Register را زنده نگه دارید
فرضهای Value، Desirability، Usability، Feasibility، Viability، Safety، Operability و Measurability را دستهبندی کنید. هر Assumption باید Owner، Confidence rationale، Consequence if false، Testability و Review state داشته باشد. Confidence عددی بدون روش نسازید. فرضی که قابل آزمون نیست میتواند بهصورت Constraint یا Unknown صریح باقی بماند.
Decision need را پیش از Evidence روشن کنید
«تستش کنید» نمیگوید چه تصمیمی در انتظار است. تصمیم میتواند DISCOVER_MORE، SELECT_OPTION، FUND_PILOT، START، CONTINUE، EXPAND، PAUSE، ROLLBACK یا RETIRE باشد. Scope تصمیم، موعد، Decider، Mandate و Cost of delay را ثبت کنید. Evidence بیش از حد یا نامرتبط وقتی رایج میشود که سؤال تصمیم مبهم باشد.
نقش PO را دقیق و محدود بخوانید
در Scrum، Product Owner یک Accountability برای ارزش و Product Backlog است، نه کمیته و نه «نمایندهٔ کامل همهٔ کاربران». PO میتواند کار مدیریت Backlog را واگذار کند اما پاسخگویی او باقی میماند. این بهخودیخود اختیار پذیرش Risk امنیتی، امضای UAT، تغییر DoD، Release production یا نادیدهگرفتن Policy سازمان را نمیدهد.
نقش تستر Capability contribution است
تستر میتواند در مدلسازی Risk، طراحی سؤال، Oracle، Sample، مشاهده، تحلیل Failure و محدودکردن Claim تخصص بیاورد. او «صدای کاربر» یا تضمینکنندهٔ کیفیت نیست و لزوماً صاحب تصمیم Product یا Release نیست. استقلال لازم برای بعضی Assuranceها باید حفظ شود؛ همکاری به معنی همرنگکردن Evidence با ترجیح Product نیست.
Product Context Owner و Test Capability Owner را نامگذاری کنید
برای هر Interface کسی باید Context Goal/Bet/beneficiary و کسی باید کیفیت سؤال و طرح Evidence را نگه دارد. ممکن است این قابلیتها بین افراد توزیع شوند. Owner یعنی نگهداری Artifact و پاسخ به Gap، نه انحصار تولید ایده. Backup و Delegation را تعریف کنید تا غیبت فرد Flow را متوقف نکند.
از Product Bet به Quality Question برسید
Quality Question باید Subject، Condition، Population، Quality attribute، Comparator/threshold در صورت نیاز و Decision link داشته باشد. «آیا خوب کار میکند؟» قابل طراحی نیست. نمونه: «در Build مصنوعی B22، آیا بازیابی پس از Callback دیر برای Stateهای eligible بدون ثبت Side effect تکراری و با پیام قابل درک عمل میکند؟» این سؤال هنوز Test case یا Verdict نیست.
Risk Claim را از نگرانی مبهم جدا کنید
risk_claim_id: RC-SYN-14 subject: BUILD-SYN-22 recovery flow claim: a late callback may expose an ambiguous state and invite duplicate action basis: EVIDENCE-SNAPSHOT-SYN-4 affected_beneficiary: SEG-SYN-NEW consequence: duplicate synthetic attempt or abandonment exposure/likelihood: unknown; measurement requested confidence: qualitative-with-rationale alternatives: [message comprehension, dependency latency, state mapping] decision_link: PDI-CHECKOUT-01
Severity، likelihood و uncertainty را یکی نکنید. Finding تست ممکن است Failure را ثابت کند ولی Business impact یا فراوانی Production را نه. Product context میتواند Consequence را روشن کند؛ Tester میتواند Evidence limit را حفظ کند. هر دو باید Alternative explanation را قابل دیدن نگه دارند.
Harm Floor را پیش از فشار Deadline تعیین کنید
Harm Floor حدی است که Option نباید از آن عبور کند یا برای عبور، Authority خاص لازم است. میتواند دربارهٔ ازدسترفتن داده، پرداخت تکراری، دسترسپذیری، حریم، ایمنی یا تعهد سازمانی باشد. Floor را پس از دیدن Failure پایین نیاورید. این مفهوم Policy حقوقی/امنیتی را جایگزین نمیکند و مقدار جهانی ندارد.
Evidence Request بهجای «یک تست کامل»
evidence_request_id: ER-SYN-31 decision/question: DECIDE-ROLLOUT-OPTION / QQ-SYN-7 claim_limit: synthetic callback recovery in BUILD-SYN-22 method_candidates: [model check, exploratory session, accessibility review] population/sample: STATE-PORTFOLIO-SYN-3 / SAMPLE-SYN-12 environment/data: ENV-SYN-4 / DATASET-SYN-10 oracle_basis: STATE-CONTRACT-SYN-v5 minimum: witness + control attempts with evidence manifest unknowns_to_preserve: real dependency distribution, production behavior owner/due/freshness: TEST-CAP / 2026-08-19T09:00:00Z / 48h security/privacy: synthetic only decision_link: PDI-CHECKOUT-01
Evidence Request روش را قبل از سؤال قفل نمیکند؛ Candidate methodها باید بر اساس Risk و Decision انتخاب شوند. «تمام تستها»، «صددرصد Coverage» و «بدون باگ» کف شواهد معتبر نیستند. Minimum باید کوچکترین بستهای باشد که تصمیم را معقولتر میکند، همراه با Unknownهایی که باقی میمانند.
Evidence Minimum را با Claim limit جفت کنید
هرچه Evidence محدودتر است، Claim هم محدودتر باشد. Component check میتواند State transition را در Stub نشان دهد، نه Outcome کاربر واقعی. یک Exploratory session میتواند Finding بسازد، نه نرخ رخداد Population. Minimum شامل Identity، Oracle، Witness/Control، Attempt history، Evidence manifest و Limits میشود؛ تعداد Test case جای این معنا را نمیگیرد.
Source Authority و Oracle Basis را آشکار کنید
وقتی PO انتظار A و Spec رفتار B را میگوید، رأیگیری Oracle نمیسازد. Authority map مشخص کند Product Goal، Acceptance criteria، Policy، State model، Design و Production invariant از کجا میآیند و تعارض چگونه حل میشود. Expected result باید Source/version و Scope داشته باشد. تغییر Oracle پس از Failure نیازمند Correction یا نسخهٔ تازه است.
Population، Sample و Environment را پنهان نکنید
چه Stateها، Journeyها، Segmentها، Deviceها، Localeها یا Dependency modeهایی هدفاند؟ Frame و Sample چه چیزهایی را جا میاندازند؟ Environment چه Fidelity و Deltaای با مقصد دارد؟ «روی Staging تست شد» کافی نیست. Sample کوچک میتواند برای کشف Failure مفید باشد، اما نرخ موفقیت کل Population را بدون Design مناسب تخمین نمیزند.
Build، Data و Attempt identity را حفظ کنید
Evidence بدون Build/Commit، Environment، Dataset/Seed، Test subject، Run و Attempt به تصمیم بعدی وصل نمیشود. Retry نباید Attempt ناموفق را پاک کند. دادهٔ Production را برای واقعینمایی بیمحابا کپی نکنید. Synthetic/Masked/Generated بودن، Lineage، Expiry و Cleanup را ثبت کنید.
Observation، Finding، Insight و Decision یک چیز نیستند
| Artifact | پرسش | نمونهٔ مصنوعی |
|---|---|---|
| Observation | چه چیزی در Attempt دیده شد؟ | پس از Callback دیر، State تا ۸ ثانیه UNKNOWN نمایش داده شد |
| Finding | Observation نسبت به Basis چه معنایی دارد؟ | State contract حداکثر ۲ ثانیه را میخواهد |
| Insight | الگوی تحلیلشده در دامنهٔ مطالعه چیست؟ | نیازمند مطالعه/تحلیل مستقل است |
| Recommendation | با Evidence و Unknown چه گزینهای ترجیح دارد؟ | Pilot محدود با Guardrail |
| Decision | صاحب اختیار چه تعهدی ساخت؟ | Rollout پنجدرصدی مصنوعی با Stop rule |
تستر Observation را «کاربر ناراضی است» تفسیر نکند؛ PO هم Finding را بهخاطر ارزش بالقوه حذف نکند. Trail اجازه میدهد هر جهش استدلالی دیده و بازبینی شود.
Unknown و Uncertainty خروجی معتبرند
UNKNOWN شکست تیم نیست. میتواند از Sample gap، Environment delta، Instrument error، زمان ناکافی، Dependency نامشخص یا Evidence متناقض بیاید. Unknown owner، تصمیم متاثر، مسیر کاهش و موعد بازبینی داشته باشد. عدد Confidence بیروش نسازید؛ Range، Scenario و Assumption گاهی صادقانهترند.
Options را پیش از Recommendation بسازید
گزینهها فقط Ship/Delay نیستند: Discovery بیشتر، Scope کوچکتر، Feature flag، Segment محدود، Manual control، Pilot، تغییر Design، Pause یا Retire. هر Option باید Outcome hypothesis، Evidence، Risk، Unknown، Cost range، Reversibility، Time، Guardrail و Authority need داشته باشد. گزینهٔ ظاهری که عملاً ممکن نیست، انتخاب واقعی نیست.
Trade-off را شفاف و چندبعدی کنید
Time-to-market، Current value، reliability، accessibility، privacy، operability، learning speed و Opportunity cost ممکن است همجهت نباشند. یک امتیاز وزنی میتواند گفتگو را کمک کند، اما وزنها و عدم قطعیت را پنهان نکند. Harm Floor و Policy باید قبل از امتیاز از گزینهٔ غیرمجاز جلوگیری کنند.
| Option مصنوعی | Evidence | Unknown | Trade-off | Reversibility |
|---|---|---|---|---|
| A: انتشار کامل | شواهد Staging محدود | توزیع Delay واقعی | یادگیری سریعتر، Exposure بزرگتر | اثباتنشده |
| B: Pilot محدود | همان شواهد + Guardrail | Outcome بلندمدت | یادگیری کندتر، Exposure محدود | با Rollback rehearsal |
| C: Discovery بیشتر | Evidence تکمیلی | هزینه فرصت | کاهش بعضی Unknownها، تأخیر Bet | بالا |
Recommendation باید مشروط و منقضیشونده باشد
Recommendation را با Preferred option، Reasons، Evidence snapshot، Unknowns، Conditions، Dissent، Valid-until و Trigger بازبینی بنویسید. «QA تأیید میکند» مبهم است؛ بهتر است بگویید «بر اساس Build B22 و Evidence E4، Pilot محدود B تا ۴۸ ساعت معتبر است، مشروط به Stop rule S2». Recommendation تصمیم نیست مگر Authority آن را بپذیرد.
Dissent و Minority evidence را حفظ کنید
اختلاف ممکن است دربارهٔ Oracle، وزن Trade-off، کف شواهد یا اختیار باشد. View مخالف را با Basis، Consequence و requested action ثبت کنید. Consensus صوری نباید Evidence نامطلوب را پاک کند. اگر تعارض منافع یا Harm مطرح است، Recusal/Appeal مستقل لازم میشود؛ رأی PO بهتنهایی حقیقت فنی را تغییر نمیدهد.
Decision Rights را از Backlog accountability جدا کنید
PO دربارهٔ Content/order Product Backlog در Scrum پاسخگو است، اما سازمان ممکن است برای Security exception، Compliance، Budget، Production change یا Risk acceptance Authorityهای دیگری داشته باشد. Decision matrix برای هر نوع تصمیم Contributor، Recommender، Decider، Veto/constraint و Appeal را روشن کند. «PO گفت منتشر شود» Record کافی نیست.
Priority را از Severity و Queue position جدا کنید
Severity شدت اثر در Context است؛ Priority فوریت اقدام نسبت به گزینههای دیگر؛ ترتیب Product Backlog یک تصمیم Product و Queue position ممکن است تحت Capacity/Dependency تغییر کند. Defect count یا صدای بلندتر نباید Priority را خودکار تعیین کند. برای Disposition تخصصی Finding به راهنمای تریاژ رجوع شود؛ Interface فقط Trace تصمیم را نگه میدارد.
Backlog Trace یعنی Evidence قابل بازیابی باشد
Decision را به Product Goal، Bet، PBI/Change، Risk claim، Evidence snapshot، Option و Outcome review وصل کنید. این Trace به معنی افزودن صدها Link دستی نیست؛ ID پایدار و Query قابل بازتولید کافی است. حذف Item از Backlog نباید Decision history یا Accepted risk را محو کند.
Acceptance Criteria، DoD و Product Outcome را یکی نکنید
| مفهوم | کارکرد | چه چیزی را ثابت نمیکند؟ |
|---|---|---|
| Acceptance Criteria | انتظارهای مشخص برای یک Item/Scope | کاملبودن Risk یا Value |
| Definition of Done | تعهد کیفیت برای Increment در Scrum | تحقق Product Outcome یا Release |
| Test Result | Verdict یک Subject/Attempt نسبت به Oracle | نبود Defect یا رضایت کاربر |
| Product Outcome | تغییر تجربه/رفتار Beneficiary در Window | علیت قطعی Change بدون Design مناسب |
پنج معیار پذیرش Passشده میتواند با Outcome نامطلوب همزمان باشد. AC را پس از Implementation برای همسانکردن نتیجه تغییر ندهید؛ Change با Version، Reason و Impact بر Evidence انجام شود.
Three Amigos تاکتیک اختیاری است
گفتوگوی Product، Development و Test میتواند Example و Unknown را زود آشکار کند، اما سه عنوان شغلی ثابت، جلسهٔ اجباری یا تضمین فهم مشترک نیست. Participant را با Capability لازم انتخاب کنید؛ Pre-read، سؤال، Example/Rule map، Decision owner و خروجی ثبتشده داشته باشید. برای Example Mapping و Gherkin، راهنمای نوشتن سناریوی BDD مناسبتر است.
Refinement و Planning را به Approval gate تستر تبدیل نکنید
تستر لازم نیست هر Story را پیش از ورود «تأیید» کند یا در همهٔ جلسهها حاضر باشد. Risk بالا، ابهام Oracle، نیاز Testability یا Unknown مهم میتواند Trigger مشارکت باشد. Contribution Async هم معتبر است. Sprint Planning دربارهٔ Why/What/How Sprint است و جزئیات آن در مقالهٔ ۱۸۴۷ پوشش داده شده است.
UX Evidence را با نظر PO یا Tester جایگزین نکنید
PO Context محصول دارد و Tester میتواند رفتار و Usability risk را ببیند، اما هیچکدام خودکار نمایندهٔ کاربر نیستند. Observation کاربر، Sample، Consent، تحلیل و Insight قرارداد جدا میخواهند. «من هم گیج شدم» Signal است، نه نتیجهٔ تعمیمپذیر Research. Interface به مطالعهٔ UX Link میدهد و Limit آن را حفظ میکند.
UAT و Sign-off مرز مستقل دارند
PO همیشه Participant یا Signatory مناسب UAT نیست. Beneficiary segment، نمایندگی، Acceptance basis و Authority تعیین میکنند چه کسی Evidence میسازد و چه کسی Sign-off میکند. UAT success با Release approval یکی نیست. Interface فقط UAT decision/limits را به Product decision پیوند میدهد.
Release Decision را از Product Decision جدا کنید
انتخاب اینکه Bet ارزش ادامهدادن دارد با مجازبودن Deployment یکی نیست. Release ممکن است Operational readiness، Security، Legal، Change management، SRE و Risk acceptance جدا بخواهد. Decision Record باید `release_boundary` و Authority reference داشته باشد. PASS مجموعه تست یا Approval PO بهتنهایی Release safety را تضمین نمیکند.
Decision Record حلقه را میبندد
decision_id: DEC-SYN-8 interface/bet: PDI-CHECKOUT-01@1.0.0 / BET-SYN-11 decision: RUN_LIMITED_PILOT selected_option: B evidence_snapshot: EVIDENCE-SNAPSHOT-SYN-4 unknowns: [real delay distribution, long-window outcome] dissent: DISSENT-SYN-2 conditions: [guardrail G1, stop rule S2, rollback rehearsal] scope/population: synthetic eligible segment / 5% fictional allocation owner/authority: PRODUCT-DECISION-OWNER / PRODUCT-MANDATE-v2 decided_at/expires_at: 2026-08-20T08:00:00Z / 2026-09-16T00:00:00Z review/rollout: REVIEW-SYN-6 / ROLLOUT-SYN-3 not_claimed: [general release approval, causal outcome, product quality]
Decision باید چه چیزی انتخاب شد، چه چیزی رد شد، چرا، بر پایهٔ کدام Snapshot، با چه Unknown، شرط، Scope، Authority و Expiry را حفظ کند. «Approved» بدون این زمینه بعداً قابل تفسیر دلخواه است.
Condition و Expiry را واقعی اجرا کنید
Decision مشروط باید Machine-checkable یا حداقل Auditپذیر باشد: Guardrail حاضر، Rollback تمرین شده، Segment محدود و Owner On-call. Expiry باعث میشود Evidence کهنه یا Accepted risk ابدی نشود. در پایان Window، RENEW، AMEND، EXPAND، PAUSE، ROLLBACK یا RETIRE ثبت کنید؛ سکوت Renewal نیست.
Rollout یک آزمایش کنترلشده است، نه انتشار کوچکِ بیطرح
Rollout contract شامل Population، Allocation، Exposure، Flag/version، Observation window، Guardrails، Stop rule، Rollback، Owner و Data quality است. «پنج درصد» بدون denominator، eligibility و assignment معنایی ندارد. Reversibility باید با Rehearsal و State recovery بررسی شود؛ وجود Feature flag برگشتپذیری را ثابت نمیکند.
Outcome Review را از Acceptance Review جدا کنید
Acceptance میپرسد Artifact نسبت به Basis چه وضعی دارد؛ Outcome review میپرسد Beneficiary در Window چه تغییری تجربه کرده است. Baseline، Exposure، Measure، Countermetric، Seasonality، Missingness و Alternative explanation را ثبت کنید. Before/after ساده علیت را ثابت نمیکند؛ اگر Design اجازه نمیدهد، زبان Association بهکار ببرید.
Output را به Outcome یا Impact جا نزنید
| نوع | مثال | خطر تفسیر |
|---|---|---|
| Input | زمان و بودجه | بیشتر بودن به معنی ارزش بیشتر نیست |
| Activity | جلسه یا اجرای تست | فعالیت، نتیجه نیست |
| Output | Feature، Report یا Defect report | تحویل، تجربهٔ بهتر را ثابت نمیکند |
| Outcome | توانایی بهتر Beneficiary در Journey | سنجش و Attribution لازم دارد |
| Impact | درآمد یا سهم بازار | چندعلتی و خارج از کنترل یک تیم است |
این تفکیک از EBM برای جلوگیری از داستان «۱۲ Story تمام شد، پس ارزش ساختیم» استفاده میشود؛ نه برای ادعای پیادهسازی کامل EBM یا الزام KVA مشخص.
Correction؛ Bet، Evidence و Decision هم ممکن است غلط باشند
اگر Population اشتباه، Oracle منسوخ، Dashboard دارای Join error، Decision خارج از Mandate یا Outcome claim بیش از Evidence بود، Correction record بسازید: affected IDs، old/new claim، reason، evidence، author، time، downstream views/decisions و notification. Silent edit به Backlog یا گزارش کافی نیست. Product learning بدون تاریخچه میتواند همان خطا را تکرار کند.
Remote و Async باید Decision-ready باشند
Template را برای Context مستقل از جلسه طراحی کنید: Goal/Bet، سؤال، Snapshot، Option، Unknown و needed decision. Canonical timestamp، Time zone، پاسخگویی، Hand-off و Accessibility را ثبت کنید. Async به معنی نوشتن سند عظیم نیست؛ Progressive disclosure و Stable ID کمک میکند. Sync مفید باید خروجی را به Record برگرداند.
شرایط ایران را بدون ادعای عمومی آشکار کنید
تعطیلی، `Asia/Tehran`، دسترسی ناپایدار به سرویس خارجی، پرداخت ریالی، نمایش تومان، Locale فارسی و محدودیت داده ممکن است روی Bet و Evidence اثر بگذارند. آنها را Assumption/Constraint قابل بررسی کنید، نه ویژگی همهٔ کاربران ایرانی. مبلغ canonical، واحد نمایش، Provider dependency، Calendar و Fallback را نسخهدار کنید.
امنیت، حریم و رضایت را Trade-off خام نکنید
حداقلسازی داده، Purpose، Access، Retention، Redaction و Consent/Withdrawal را در Evidence contract بیاورید. Product value مجوز استفادهٔ نامحدود از دادهٔ مشتری نیست. دادهٔ حساس Route و Authority مستقل میخواهد. این مقاله توصیهٔ حقوقی، امنیتی، بانکی یا حریم خصوصی نیست و Review متخصص/Policy سازمان را جایگزین نمیکند.
AI Candidate میسازد، نه Context یا Authority
مدل زبانی میتواند فرضها، سؤالها، Optionها یا خلاصهٔ Evidence را Draft کند؛ ممکن است Source بسازد، Minority view را حذف، دادهٔ حساس را افشا یا Recommendation را مطمئنتر از شواهد بنویسد. Human owner باید Grounding، Limit و Trail را بررسی کند. «AI پنجاه تست ساخت» Evidence sufficiency یا Product value نیست.
Metric همکاری باید Fitness Interface را بسنجد
Metricهای سالم دربارهٔ خود Interface سؤال دارند: درصد Decisionهایی با Goal/Bet trace همراه با Record burden؛ Evidence requestهایی که پیش از Method سؤال داشتند همراه با Delay؛ Decisionهای منقضی بازبینیشده همراه با Renewal صوری؛ Outcome reviewهای دارای Countermetric همراه با instrumentation cost. Bug count، Story count و ساعت جلسه امتیاز همکاری نیستند.
| Measure | سؤال | Countermetric | Not for |
|---|---|---|---|
| Decision trace completeness | آیا Goal→Evidence→Decision قابل بازیابی است؟ | زمان/بار ثبت | درستی تصمیم |
| Unknown preservation | آیا Unknown مهم در Record مانده؟ | فهرستسازی بیاقدام | امتیاز صداقت فرد |
| Expiry review rate | تصمیمهای منقضی بازبینی شدند؟ | Renewal صوری | مقایسه تیمها |
| Outcome loop closure | Outcome در Window دیده شد؟ | هزینه Instrument و Data quality | اثبات علیت |
`people_scoring=false` باید صریح باشد. Metric برای اصلاح System است، نه رتبهبندی PO، Tester یا Team. KPI فردی فشار به پنهانکردن Unknown و ساخت Approval صوری ایجاد میکند.
آزمایش تکرارپذیر: Story و جلسه، Alignment را ثابت نمیکنند
Fixture مصنوعی `SYN-TESTER-PO-DECISION-INTERFACE-۰۱` دارای ۱۲ User story، معیار پذیرش موجود، سه Defect باز، پنج جلسه در Sprint و Approval مالک محصول است. Gate سطحی با دیدن AC، Meeting و Approval نتیجه `PRODUCT_QUALITY_ALIGNED` میدهد. ممیز قرارداد فقط حضور کنترلهای ساختاری را میسنجد و ادعاها یا شواهد را معتبر نمیکند.
{
"fixture": "SYN-TESTER-PO-DECISION-INTERFACE-01",
"superficialGate": "PRODUCT_QUALITY_ALIGNED",
"initialAudit": "HOLD",
"initialFindingCount": 68,
"independentRule69PeopleScoringDisabled": true,
"correctedAudit": "READY_FOR_PRODUCT_DECISION_REVIEW",
"correctedFindingCount": 0,
"proves": "structural completeness only"
}
۶۸ Finding اولیه چه بودند؟
| گروه | کنترلهای مفقود |
|---|---|
| هویت و چرخه | Interface ID، Version، Status، Supersedes، Effective، Review |
| Product context | Product، Goal، Beneficiary، Desired outcome، Current evidence، Bet، Assumptions، Scope/out |
| Decision | Need، By، Owner، Authority، Test/Product context owners |
| Risk/Evidence | Questions، Claims، Harm floor، Requests، Minimum، Owner، Due، Freshness، Source، Oracle |
| Design identities | Population، Sample، Environment، Data، Build، Attempt |
| Interpretation | Observations، Findings، Unknowns، Uncertainty، Alternatives |
| Choice | Options، Trade-offs، Recommendation، Dissent، Priority |
| Trace/boundaries | Backlog، Acceptance، DoD، UAT، UX، Release |
| Commitment | Decision record، Conditions، Expiry، Rollout، Guardrails، Stop، Rollback |
| Learning | Outcome measure، Countermetrics، Review window/owner، Correction، Audit |
| حفاظها | Privacy و Not-claimed |
Rule شصتونهم مستقل `people_scoring=false` را بررسی کرد و PASS شد، بنابراین جزو ۶۸ Finding نبود. پس از تکمیل همهٔ فیلدها، `READY_FOR_PRODUCT_DECISION_REVIEW` با صفر Finding ساختاری صادر شد—نه اثبات Value، صحت Goal/Oracle/Evidence، کفایت Sample، درستی تصمیم، تحقق Outcome، ایمنی Release یا علیت.
آزمایشگاه فارسی و آفلاین Checkout
Lab کاملاً جدا از شبکه و خیالی است: Order، PaymentAttempt، PSP Stub، Callback، Ledger، Reconciliation و Notification مصنوعی. Timeout قبل/بعد از Commit خیالی، Callback تکراری/دیر/جابجا، State مبهم، Retry، Rollback و Outcome window Seed میشوند. Identityهای Product/Goal/Bet/Decision/Build/Attempt/Evidence/Outcome ثابت و Timestamp canonical به UTC است؛ `Asia/Tehran` و جلالی فقط View هستند.
مبالغ canonical کاملاً خیالی IRR و نمایش تومان فقط با Label صریح است. ارقام فارسی/عربی/لاتین، ی/ی و ک/ک، نیمفاصله، RTL/LTR و Stable ID آزموده میشوند. هیچ Production، سازمان، تیم، کاربر، سفارش، پرداخت، PSP، بانک، پول، نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Log یا Screenshot واقعی وجود ندارد و هیچ ادعای مالی، بانکی، حقوقی، امنیتی، حریم خصوصی یا منابع انسانی ساخته نمیشود.
سناریوی نمونه: Recovery پس از Callback دیر
- Product context owner Goal، Beneficiary، Current evidence و Bet را نسخهدار میکند.
- Tester سه فرض را به سؤال State safety، فهم پیام و Accessibility تبدیل میکند.
- Evidence request، Build/Environment/Sample/Oracle و Unknownهای Production را قفل میکند.
- Witness و Control Attemptها Observation و Finding میسازند؛ Retry قبلی حذف نمیشود.
- تیم سه Option میسازد و Harm floor گزینهٔ بدون Idempotency guard را حذف میکند.
- Authority یک Pilot محدود با Stop rule و Dissent ثبتشده انتخاب میکند.
- Outcome و Countermetric در Window بررسی و Claim فقط در حد Design گزارش میشود.
- اگر Snapshot یا تفسیر غلط بود، Correction به Backlog/Brief/Decisionهای متاثر وصل میشود.
۳۰ ضدالگوی همکاری تستر و مالک محصول
- PO صدای کامل مشتری است.
- تستر مدافع قطعی کاربر است.
- PO فقط What/Why و Tester فقط How-well دارد.
- تستر باید همهٔ Storyها را Approve کند.
- حضور تستر در همهٔ جلسهها اجباری است.
- Three Amigos سه عنوان ثابت و الزامی است.
- Acceptance criteria تمام Risk را پوشش میدهد.
- Pass شدن AC یعنی Outcome محقق است.
- DoD یعنی Release مجاز است.
- Approval PO یعنی UAT و Release کامل است.
- Bug count سلامت Product را نشان میدهد.
- Escaped defects اثربخشی QA را مستقیم ثابت میکند.
- Activity و Output بهجای Outcome گزارش میشود.
- هرچه زودتر تست شود همیشه کمهزینهتر است.
- رفع زودهنگام صدها برابر ارزانتر قانون عمومی است.
- همهٔ Feedback باید فوری باشد.
- نظر PO یا Tester جای UX evidence است.
- یک Persona نماینده همه کاربران است.
- Unknown از گزارش حذف میشود.
- Confidence درصدی بدون Method ساخته میشود.
- فقط Ship/Delay Option محسوب میشوند.
- Recommendation همان Decision است.
- Priority و Severity یکیاند.
- PO هر Riskی را میتواند بپذیرد.
- Feature flag برگشتپذیری را ثابت میکند.
- Pilot کوچک بدون Guardrail امن است.
- Before/after علیت را ثابت میکند.
- Decision و Evidence بیردپا ویرایش میشوند.
- AI Context، Evidence یا Authority میسازد.
- Metric همکاری برای رتبهبندی افراد استفاده میشود.
چکلیست ۲۶نقطهای Interface
- ID، Version، Status و Snapshot قفلاند.
- Product Goal از Feature list جداست.
- Beneficiary، Outcome و Harm مشخصاند.
- Current evidence Source/Window/Limit دارد.
- Product Bet و Assumptionها نسخهدارند.
- Scope و Out-of-scope روشناند.
- Decision need، موعد و Authority معلوماند.
- نقشها Capabilityمحور و Backupدارند.
- Quality Question به Decision وصل است.
- Risk claim، Consequence و Alternative دارد.
- Harm floor پیشاپیش تعریف شده است.
- Evidence request و Minimum محدودند.
- Source authority و Oracle basis تعارضپذیرند.
- Population/Sample/Environment/Data آشکارند.
- Build/Attempt history حفظ شده است.
- Observation/Finding/Insight/Decision جدا هستند.
- Unknown و Uncertainty حذف نشدهاند.
- Options واقعی و Trade-off چندبعدیاند.
- Recommendation مشروط و منقضی است.
- Dissent و Appeal قابل ثبتاند.
- Backlog/AC/DoD/UX/UAT/Release مرز دارند.
- Decision record شرط و Expiry دارد.
- Rollout، Guardrail، Stop و Rollback اجراییاند.
- Outcome measure با Countermetric همراه است.
- Privacy، AI limit و `people_scoring=false` روشناند.
- Review، Correction، Audit و Not-claimed کاملاند.
Pilot سیروزهٔ Decision Interface
| بازه | کار | خروجی | Gate |
|---|---|---|---|
| روز ۱ تا ۵ | انتخاب یک Decision واقعینما و Baseline Flow | Context، Goal، Bet، Authority و Problem signals | Scope کوچک و تصمیم معتبر است |
| روز ۶ تا ۱۰ | ساخت Question/Risk/Evidence contracts | Interface v0.۱ و Evidence requests | Claim limit و Harm floor روشناند |
| روز ۱۱ تا ۲۰ | جمعآوری Evidence و ساخت Optionها | Snapshot، Unknown، Trade-off و Recommendation | Evidence برای همان تصمیم قابل استفاده است |
| روز ۲۱ تا ۲۵ | Decision rehearsal و Rollout check | Decision، Conditions، Stop/Rollback | Authority و Reversibility معتبرند |
| روز ۲۶ تا ۳۰ | Outcome/Process review و Correction | KEEP، AMEND یا RETIRE + audit trail | بار Interface متناسب و Learning قابل بازیابی است |
سی روز عدد آموزشی است، نه استاندارد. Flow کمتکرار یا Outcome دیررس Window بلندتر میخواهد؛ تصمیم کوچک پرتکرار ممکن است سریعتر Evidence بسازد. برای Betهای استارتاپی و Rollout ریسکمحور، راهنمای تعادل سرعت و کیفیت از Bet تا Evidence مرز عمیقتری ارائه میکند.
چه چیزی را از Interface نتیجه نگیریم؟
کاملبودن فیلدها ثابت نمیکند Product Goal درست، Beneficiary نماینده، Oracle معتبر، Sample کافی، Finding مهم، Option عملی، Decision اخلاقی یا Outcome علّی است. همکاری خوب تضمین Quality، Value، Team morale، Time-to-market یا Release safety نیست. Interface یک Control برای حفظ معنا و Trail است و به Review تخصصی و Evidence واقعی نیاز دارد.
جمعبندی: از Approval به حلقهٔ تصمیم و یادگیری برسید
همکاری تستر و مالک محصول زمانی بالغ میشود که نه PO مجبور باشد از چند عدد خام Value حدس بزند و نه تستر از PASS/FAIL ادعای Product بسازد. Goal، Bet و Decision need را قفل کنید؛ سؤال و Evidence محدود بسازید؛ Unknown را نگه دارید؛ گزینه و Trade-off را آشکار کنید؛ Authority تصمیم بگیرد؛ سپس Rollout و Outcome را مشاهده و اشتباه را با تاریخچه اصلاح کنید. Approval یک لحظه است؛ Product Decision Interface یک حلقهٔ یادگیری است.
سؤالات متداول همکاری تستر و مالک محصول
آیا Product Owner تصمیم نهایی درباره همه باگها را میگیرد؟
خیر. PO در Scrum نسبت به ارزش و Product Backlog پاسخگو است، اما Disposition فنی، Security exception، Risk acceptance، Production change یا Release ممکن است Authorityهای دیگری داشته باشند. Severity، Priority و Backlog order را جدا و Decision matrix سازمان را ثبت کنید.
تستر چه زمانی باید در Refinement یا Planning حضور داشته باشد؟
وقتی Risk، ابهام Oracle، Testability، Environment/Data dependency یا Evidence obligation به قابلیت تست نیاز دارد. حضور در همهٔ جلسهها قانون عمومی نیست؛ Contribution Async یا حضور فرد دیگری با Capability مناسب میتواند کافی باشد. خروجی مهمتر از Attendance است.
آیا Acceptance Criteria کامل یعنی Story آماده توسعه است؟
نه الزاماً. AC میتواند انتظارهای Item را روشن کند، اما Goal contribution، Risk، DoD، dependency، داده، محیط، مشاهدهپذیری، Unknown و ظرفیت همچنان ممکن است ناقص باشند. Readiness باید قراردادی و Contextual باشد و Approval تستر به Gate اجباری تبدیل نشود.
چگونه درباره اولویت یک Finding با PO گفتگو کنیم؟
Observation و Basis، Consequence، Population/Exposure، uncertainty و Alternativeها را عرضه کنید؛ Severity را از Priority جدا نگه دارید؛ Optionها و Trade-offها را بسازید؛ سپس صاحب اختیار Priority تصمیم را ثبت کند. تعداد باگ یا لحن مطمئن جای Evidence و Authority را نمیگیرد.
موفقیت همکاری تستر و مالک محصول را چگونه بسنجیم؟
Fitness خود Interface را بسنجید: Trace تصمیم، حفظ Unknown، Review پیش از Expiry و بستهشدن Outcome loop، هرکدام با Countermetric هزینه/بازیپذیری. Story، Defect، Meeting یا پاسخ سریع بهتنهایی همکاری، Value یا Product quality را ثابت نمیکند و نباید برای رتبهبندی افراد استفاده شود.
