مدیر QA در Agile؛ Role Charter، اختیار و Enablement

اگر هر Definition of Done، انتخاب ابزار، اختلاف Severity، ارزیابی عملکرد، تصمیم Release و Risk acceptance باید از مدیر QA عبور کند، او رهبر کیفیت نیست؛ صف مرکزی کیفیت است. از آن طرف، حذف عنوان Manager بدون تعیین مالک Capability، رشد افراد، Evidence integrity و ریسک‌های میان‌تیمی نیز «Agile» نیست؛ فقط خلأ پاسخ‌گویی می‌سازد.

پرسش درست این نیست که «آیا Agile به مدیر QA نیاز دارد؟»؛ باید پرسید: کدام Outcome و شکاف Capability به یک نقش سازمانی نیاز دارد، چه اختیار محدودی می‌گیرد، چه تصمیم‌هایی را نباید تصاحب کند و چگونه اثربخشی و خروجش سنجیده می‌شود؟ این راهنما نقش را با چرخهٔ Mandate → Role Charter → Decision rights → Enablement/Service → Evidence → Review → Adapt/Delegate/Sunset طراحی می‌کند.

پاسخ کوتاه: نقش مدیر QA در Agile چیست؟

مدیر QA در Agile یک Role اجباری در Scrum نیست. بسته به اندازه، Risk، ساختار و نیاز سازمان، می‌تواند یک People manager، Capability leader، Evidence assurance owner، Quality portfolio lead یا ترکیبی شفاف از آن‌ها باشد. ارزش نقش در تأییدکردن کار تیم نیست؛ در ایجاد شرایطی است که تیم‌های خودمدیر بتوانند کیفیت را با Strategy، Skill، Platform، Policy و Evidence معتبر بسازند.

Healthy QA leadership role
sets direction without taking Product ownership
builds capability without creating permanent dependency
protects evidence without owning every test
surfaces risk without accepting every risk
manages people without directing Sprint work
removes constraints without becoming the new constraint

Scrum «QA Manager» تعریف نمی‌کند

راهنمای رسمی Scrum ۲۰۲۰ سه Accountability را تعریف می‌کند: Product Owner، Scrum Master و Developers. Scrum Team را Cross-functional و Self-managing می‌داند، درون آن Sub-team یا Hierarchy قرار نمی‌دهد و Developers را نسبت به ساخت Increment قابل‌استفاده و رعایت Definition of Done پاسخ‌گو می‌داند. بنابراین QA Manager عنوان یا Gate رسمی Scrum نیست.

این به معنی ممنوع‌بودن مدیر خطی، Chapter lead، متخصص کیفیت یا نقش‌های سازمانی بیرون Scrum Team نیست. سازمان ممکن است برای استخدام، رشد، بودجه، Capability مشترک، انطباق، ریسک میان‌محصولی یا Platform به نقش نیاز داشته باشد؛ اما نباید آن را Accountability چهارم Scrum جا بزند یا Self-management تیم را با Approval روزمره خنثی کند.

Agile هم به معنی «بدون مدیریت» نیست

اصول Manifesto چابک بر همکاری روزانهٔ کسب‌وکار و توسعه، محیط و حمایت برای افراد باانگیزه، اعتماد، سرعت پایدار، Excellence فنی، سادگی، تیم‌های Self-organizing و بازاندیشی منظم تأکید دارد. این Principles ساختار سازمانی خاص، عنوان مدیر QA یا ابزار مشخصی را تجویز نمی‌کنند.

مدیریت سالم در این فضا کمتر «تخصیص Task به فرد» و بیشتر «جهت، Constraint، Capability، Context، بودجه، Fairness و Removal of impediment» است. Self-management نیز تیم را از سیاست امنیت، قانون، تعهد مشتری یا پاسخ‌گویی حرفه‌ای معاف نمی‌کند.

مرز این راهنما با مقالات نزدیک

موضوع	مقالهٔ مالک	این صفحه چه چیزی را نگه می‌دارد؟
ساخت، انگیزش، ۱:۱ و سلامت تیم QA	رهبری تیم QA	رابط People mandate با Role Charter چابک
کیفیت مسئولیت همه و حقوق تصمیم	مالکیت همگانی کیفیت	جلوگیری از تصاحب آن حقوق توسط مدیر
Centralized/Embedded/Federated و Team API	مدل عملیاتی QA	انتخاب Interaction نقش با تیم‌ها
Risk→Evidence→Gate→Release	سند استراتژی تست	Portfolio و Assurance آن Strategyها
رفتار، Speak-up و مشوق	فرهنگ کیفیت	رفتار مدیریتی و Incentive alignment
Metric Contract و ضدبازی	KPI تضمین کیفیت	System review، نه رتبه‌بندی افراد

این صفحه مالک Role design مدیر QA در محیط Agile است: Mandate، In/Out، Authority، Interaction، Artifact، Cadence، Delegation، Evidence و Sunset.

اول Mandate، بعد عنوان شغلی

عنوان‌های Head of QA، QA Manager، Quality Lead، QE Director یا Chapter Lead در دو سازمان معنای یکسان ندارند. پیش از شرح وظایف بپرسید سازمان کدام Problem را حل می‌کند.

Mandate	مسئلهٔ سازمانی	خروجی اصلی	خطر تصاحب
People	رشد، Fairness، ظرفیت و سلامت تخصص QA	Role/skill/growth/capacity system	Micro-management کار Sprint
Capability	شکاف Testability، Data، Environment یا Evidence	Enablement/Platform/standard	تیم‌ها مشتری دائمی Manager شوند
Strategy portfolio	ریسک‌های میان‌محصولی و سرمایه‌گذاری پراکنده	Thesis، priorities، funding evidence	تبدیل Strategy به Test-plan مرکزی
Assurance	نیاز به استقلال Evidence یا Obligation	Evidence policy، review، dissent	Approval همهٔ Ticketها
Operating system	تقاضا، صف، سرویس و Interaction مبهم	Team API، SLE، WIP، Rebalance	مرکز کنترل واحد
Transformation	تغییر Capability یا ساختار زمان‌دار	Pilot، adoption، handoff، sunset	برنامهٔ تحول دائمی

یک نفر می‌تواند چند Mandate داشته باشد، اما Capacity، تضاد منافع و Authority باید روشن شوند. «استراتژیک بودن» مجوز مالکیت همه‌چیز نیست.

Role Charter قابل‌کپی برای مدیر QA

QA Manager Role Charter — v1.3
Context / products / teams:
Problem and evidence:
Mandates: People / Capability / Portfolio / Assurance / Transformation
Desired organizational outcomes:
In scope:
Out of scope:
Decision rights:
Consult / advise / veto boundaries:
Artifacts owned:
Services offered + consumers:
Interaction mode + expected duration:
Capacity / WIP / reserve:
Risk / security / privacy boundaries:
Escalation and dissent:
Measures + countermetrics:
Conflicts of interest / separation:
Delegation / backup:
Review cadence:
Expiry / sunset / renewal evidence:
Named accountable executive:

Charter باید تاریخ انقضا داشته باشد. اگر Mandate تحول تمام شد، نقش یا Interaction باید Adapt/Delegate/Sunset شود؛ حفظ Scope فقط به‌خاطر عنوان سازمانی، دلیل معتبر نیست.

یک نمونهٔ واقعی‌نما از In/Out

در Scope مدیر QA	خارج Scope یا مشروط
Skill/role architecture و رشد افراد	تخصیص روزانهٔ Taskهای Sprint
Portfolio شکاف‌های کیفیت و Capability	اولویت Product Backlog
Policy حداقلی Evidence و Risk escalation	نوشتن همهٔ Test caseها یا تأیید هر Result
سرویس‌های مشترک و Operating owner	مالکیت Architecture هر Squad
شفاف‌کردن Risk و محدودیت Evidence	پذیرش Risk مالی/حقوقی خارج اختیار
بودجه و Optionهای Capability	انتخاب یک‌جانبهٔ Tool برای مصرف‌کنندگان
People fairness و Conflict support	دورزدن Scrum Master یا Manager مستقیم دیگر
Assurance مستقل در دامنهٔ تعریف‌شده	Gate عمومی Release بدون Risk policy

Decision rights؛ RACI کافی نیست

RACI می‌تواند مشارکت را نشان دهد، اما برای تصمیم باید پرسید چه کسی تصمیم می‌گیرد، چه کسی می‌تواند Stop کند، Default در نبود پاسخ چیست و تصمیم چه زمانی منقضی می‌شود. این ماتریس نمونه است، نه ساختار اجباری Scrum:

تصمیم	مالک نمونه	نقش مدیر QA	نباید انجام دهد
Product priority/value	Product Owner/Product	Risk/Evidence advisor	Shadow PO شدن
Sprint plan و Who/How	Scrum Team/Developers	Capability support در صورت درخواست	تخصیص Task و Approval کار روزانه
Definition of Done	طبق Context و Scrum commitments	پیشنهاد Policy/Obligation و Evidence	تغییر یک‌جانبه بدون تیم/سازمان
Test design/execution	تیم سازندهٔ Increment	Coach، specialist یا assurance محدود	مالک همهٔ تست‌ها شدن
Evidence integrity	Evidence owner / qualified reviewer	Policy و independent review	تأیید خودساخته در Risk بالا
Risk acceptance	Authority صاحب پیامد	Signal، Evidence، dissent و escalation	پذیرش ریسک خارج Mandate
Release/rollout	Release/service authority	Residual-risk input	«QA sign-off» مبهم
People performance/growth	Line manager	مالک در People mandate	Test/bug count به‌عنوان عملکرد
Shared capability investment	Portfolio/budget authority	Problem/option/evidence owner	خرید Tool بدون PoC/TCO/Exit

Decision Contract
Decision / scope:
Outcome and risk:
Decider / contributors:
Evidence required:
Hard constraints:
Options and reversibility:
Default if no response:
Stop / escalation trigger:
Dissent and appeal:
Decision / rationale:
Conditions / owner:
Expiry / review:
Artifact / audience / confidentiality:

QA Manager در Scrum Team کجا می‌ایستد؟

سه حالت رایج وجود دارد و باید صریح نام‌گذاری شود:

1. عضو Developers با تخصص کیفیت: برای ساخت Increment کار می‌کند؛ عنوان سازمانی او Accountability تازه نمی‌سازد.
2. People/Capability manager بیرون Team: جهت، رشد، بودجه یا سرویس می‌دهد؛ Sprint را مدیریت نمی‌کند.
3. Stakeholder/Assurance authority: Evidence یا Constraint معینی را طبق Policy بررسی می‌کند؛ باید Scope، SLA/SLE و استقلالش مشخص باشد.

ترکیب نقش‌ها ممکن است، اما مثلاً Line manager بودن همزمان با Scrum Master یا Independent assurance می‌تواند Power/conflict بسازد. تعارض را ثبت، کانال Speak-up و Reviewer جایگزین تعیین کنید.

Interactionها را زمان‌دار کنید

Team Topologies Enabling team را برای کمک به رفع مانع Stream-aligned team و Interactionها را Collaboration، Facilitation و X-as-a-Service توصیف می‌کند. این مدل نسخهٔ اجباری Agile یا ساختار HR نیست؛ برای شفاف‌کردن رابطهٔ نقش با تیم‌ها مفید است.

Interaction	مناسب وقتی	قرارداد خروج	هشدار
Collaboration	ابهام بالاست و راه تازه کشف می‌شود	Question/Artifact/Date/Decision	جلسهٔ دائمی و Shared ownership مبهم
Facilitation/Enablement	تیم Capability را می‌آموزد	Competency evidence و independence	Manager کار را به‌جای تیم انجام دهد
X-as-a-Service	کار تکراری و Interface پایدار است	Service scope/SLE/support/version	صف تیکت پنهان و Consumer بی‌صدا
Assurance review	استقلال یا Obligation لازم است	Evidence/authority/turnaround/appeal	Gate همه‌کاره بدون Risk class

Artifactهای یک مدیر QA چابک

اثر نقش باید در Artifact و تصمیم دیده شود، نه تعداد جلسه یا پیام. بسته به Mandate، خروجی‌ها می‌توانند این‌ها باشند:

• Role Charter و Decision/Authority map؛
• Quality thesis و Risk/Capability portfolio؛
• Team API یا Service catalog برای Platform/Specialist؛
• Skill matrix، Growth plan و Succession/backup؛
• Evidence policy، Result semantics و Assurance plan؛
• Investment option، Pilot contract، TCO و Exit؛
• Constraint card، WIP/Capacity policy و Rebalance decision؛
• Quality review record با Outcome، Guardrail، Dissent و Expiry؛
• Delegation/Sunset record برای Interaction موفق.

Dashboard، Test plan یا Tool list به‌خودی‌خود Strategy نیست. هر Artifact باید مصرف‌کننده، تصمیم، Owner، Version و Review داشته باشد.

Cadence را از Ceremony جدا کنید

Cadence نمونه	هدف	ورودی/خروجی	نباید باشد
هفتگی Flow/constraint	صف، Block و Failure demand	Constraint action مالک‌دار	Status افراد
دو‌هفته‌ای Capability review	Pilot/Adoption/Support	Scale/Adapt/Hold/Stop	Demo theatre
ماهانه Risk/Evidence	Cross-team systemic risk	Risk route و investment option	Approval همهٔ Sprintها
ماهانه People	Growth، load، fairness، health	Action محرمانه و Capacity	رتبه‌بندی با Bug/Test count
فصلی Charter/portfolio	آیا Role/mandate هنوز لازم است؟	Renew/Change/Delegate/Sunset	تمدید خودکار Scope

مدیر لازم نیست در Daily Scrum همهٔ تیم‌ها حاضر باشد. حضور ناظر قدرتمند می‌تواند گفتگو را به گزارش‌دهی تبدیل کند. دعوت باید به Outcome جلسه و نیاز واقعی وصل باشد.

از «مربی» به Enablement قابل‌سنجش برسید

Coaching یک صفت شخصیت نیست. یک مداخله با Baseline، Task، Practice، Evidence و Exit است. گفتن «تیم را توانمند کردم» بدون استقلال قابل‌مشاهده، ادعای خالی است.

Enablement Card — Contract Testing
Consumer/team:
Problem evidence: integration defects + wait/rework
Target task: consumer contract را مستقل طراحی، اجرا و diagnose کند
Baseline: assisted completion / time / error / confidence
Capability gap:
Mode: pair → guided practice → shadow → independent
Practice environment/data:
Evidence: 3 representative changes + one breaking seeded change
Guardrails: false block, bypass, support load
Support boundary:
Owner / coach capacity:
Exit: 2 members مستقل + runbook + review pass
Follow-up: 30/60 days
Fallback / escalation:

تعداد Workshop یا نفر-ساعت آموزش Outcome نیست. Time-to-first-independent-success، Retention مهارت، کیفیت Artifact، نیاز به Rescue و مصرف واقعی را ببینید. فردی که به‌دلیل نبود Access یا Testability مستقل نمی‌شود، کم‌انگیزه فرض نشود.

Delegation ladder؛ اختیار را یک‌باره رها نکنید

سطح	روش	Evidence برای حرکت	حق بازگشت
Tell با دلیل	در Safety/Obligation تازه	فهم Policy و Runbook	Escalation فوری
Propose/approve	تیم Option می‌سازد	Evidence packet کامل	Reject با rationale
Decide/consult	تیم پیش از تصمیم نظر می‌گیرد	Risk/authority درست	Hard gate stop
Decide/inform	تیم تصمیم و ثبت می‌کند	نتیجه و Guardrail پایدار	Trigger تعریف‌شده
Own/review periodically	تیم مالک کامل است	Self-service + learning + backup	Policy change/incident review

Delegation برای همهٔ تصمیم‌ها یکسان نیست. تیم می‌تواند Test design را کاملاً مالک باشد اما پذیرش ریسک Privacy همچنان Authority دیگری بخواهد. Power را زیر واژهٔ Empowerment پنهان نکنید.

Strategy مدیر QA؛ Outcome و Capability، نه فهرست Tool

Quality Leadership Thesis
Context / strategic outcome:
Customer and business guardrails:
Systemic quality risks:
Current evidence and unknowns:
Capability gaps:
Options: do nothing / design away / enable / platform / specialist / buy
Dependencies and constraints:
90-day experiments:
People/capacity implications:
Decision rights:
Measures and countermetrics:
Investment range / TCO / exit:
Review / stop / sunset:

مدیر QA نباید به‌تنهایی «کیفیت» را تعریف کند. Product، Engineering، Operations، Security/Privacy، Support و مشتریان نماینده باید Outcome و Trade-off را بسازند. فهرست Performance/Security/Usability هنوز Priority نیست؛ Context و Risk تعیین می‌کند چه شواهدی لازم است.

مدیریت Risk؛ Signal بدهید، Authority را جعل نکنید

مدیر QA ممکن است Cross-team view خوبی داشته باشد، اما این به معنی پذیرش همهٔ ریسک‌ها نیست. مسیر سالم:

1. Signal را با Scope، Source، Version و Confidence ثبت کنید.
2. Risk statement را Condition → Event → Impact بنویسید.
3. Evidence موجود، Gap و Alternative explanation را جدا کنید.
4. آن را به Authority صاحب پیامد Route کنید.
5. Decision، Conditions، Dissent، Owner و Expiry را ثبت کنید.
6. پس از Release، Outcome و Residual risk را بازبینی کنید.

پروتکل ارتباط ریسک کیفیت این حلقه را با Ack، Escalation، Handoff و Closure جزئی‌تر می‌کند.

Assurance بدون Gatekeeper شدن

گاهی قانون، قرارداد، Critical safety/security یا استقلال Evidence واقعاً Review جدا می‌خواهد. راه‌حل حذف Assurance نیست؛ Risk-tier و Service contract است.

Assurance Service Contract
Risk classes in scope:
Evidence requirements by class:
Ready criteria:
Reviewer qualification/independence:
Turnaround SLE + probability:
Result: Ready / Conditional / Insufficient / Invalid
Not a result: generic QA Approved
Hard-stop authority:
Default and escalation:
Dissent / appeal / second reviewer:
Artifact / retention / confidentiality:
Capacity / backup:
Review effectiveness / false block / miss:
Expiry / policy version:

Low-risk reversible change می‌تواند Self-service evidence داشته باشد؛ High-impact irreversible change Review عمیق‌تری می‌خواهد. یک Checkpoint واحد برای همهٔ تغییرها Queue و Theater می‌سازد.

People management را با Delivery control مخلوط نکنید

• ۱:۱ برای رشد، حمایت و Context است؛ Status meeting یا بازرسی Ticket نیست.
• Performance فرد را با Test count، Bug count، Automation %، Story point یا Release pass نسنجید.
• Outcome تیمی را هم بدون Attribution به فرد تبدیل نکنید.
• Feedback چندمنبعی باید رفتار/پیامد مشخص، Privacy و حق پاسخ داشته باشد.
• Career ladder، Pay، Promotion و Layoff معیار و Review منصفانه بخواهند.
• Power imbalance، retaliation، harassment یا Safety از Coaching مشترک اجباری جداست.
• Manager نباید تنها Reviewer فنی، Risk acceptor و ارزیاب شغلی همان فرد باشد.

طراحی Skill matrix، Hiring، Onboarding، ۱:۱، Team health و مسیر رشد در راهنمای رهبری تیم QA با جزئیات آمده است.

Capacity مدیر؛ Strategy بعد از Meeting leftovers نیست

QA Manager Capacity Envelope — illustrative
People/growth/fairness: 25–35%
Capability/constraint removal: 20–30%
Portfolio/risk/evidence: 15–25%
Stakeholder/service/operations: 10–20%
Learning/reserve/interrupt: 10–20%
Direct delivery intervention: explicit, time-boxed, with exit

These are not universal ratios.
Use demand, mandate, team count, risk and historical load.

اگر Manager از ۸ Daily، ۴ Planning و ده Approval روزانه پر است، «استراتژیک‌تر شو» قابل‌اجرا نیست. Demand، WIP، Delegate، Cancel و Service policy لازم است. نسبت‌های نمونه بالا Target یا معیار عملکرد نیستند.

آزمایش عددی: Gatekeeper در برابر Role Charter

یک اسکریپت قطعی با Node.js ۲۴.۱۸.۰ روی ۱۶ تقاضای کاملاً ساختگی در یک Burst شبیه Release/Incident week اجرا شد. انواع تقاضا Sprint، Product، People، Risk، Capability، Evidence، Definition of Done و Policy بودند. در GATEKEEPER همه به یک QA Manager Route شدند؛ در ROLE_CHARTER فقط People/Capability/Policy به Manager و بقیه به Scrum Team، Product Owner، Risk authority یا Evidence owner رفتند.

Policy	Manager load	Owner match	Mean delay	p90 delay	بیش از ۱ روز	پایان صف Manager
GATEKEEPER	18.1h	6/16	1.03d	1.68d	8	day 3.02
ROLE_CHARTER	10.1h	16/16	0.27d	0.58d	0	day 1.78

Author-defined routing
SPRINT / DOD → SCRUM_TEAM
PRODUCT → PRODUCT_OWNER
RISK → RISK_AUTHORITY
EVIDENCE → EVIDENCE_OWNER
PEOPLE / CAPABILITY / POLICY → QA_MANAGER

One workday = 6 fictional decision-service hours.
Each owner was modeled as one independent serial server.

اجرای اولیه با Arrivalهای پراکنده Owner match و Manager load را تغییر داد، اما p90 هر دو ۰.۳۳ روز ماند؛ Dataset برای آزمون Queue تمایز کافی نداشت. سپس همان ۱۶ نوع و Effort در یک Burst فشرده‌تر باززمان‌بندی و نتیجهٔ بالا تولید شد. این اصلاح پس از مشاهدهٔ اجرای اول است، پس نتیجه Confirmation مستقل نیست و باید شفاف بماند.

محدودیت‌ها: نوع، «مالک درست»، Arrival، Effort، ظرفیت روزانه و Serial-server rules همگی نویسنده‌ساخته‌اند؛ Owner match مستقیماً از همان تعریف ناشی می‌شود. Parallel work، Skill، Context switch، کیفیت تصمیم، Escalation، غیبت، Power، Collaboration cost، Risk severity و Outcome واقعی حذف شده‌اند. این خروجی اثبات نمی‌کند Charter همیشه Delay را کم یا مدیر QA را بهتر می‌کند؛ فقط مکانیک صفِ همین Routing و Burst را نشان می‌دهد، نه Benchmark سازمانی یا Staffing formula.

مثال ایرانی: مدیر QA در Marketplace چندتیمی

Marketplace فرضی شش Squad، سه PSP، یک Ledger، یک تیم Data و یک تیم Security دارد. مدیر QA پیشین همهٔ Releaseها را Sign-off، Toolها را انتخاب و Test work را توزیع می‌کرد. با رشد تیم، ۲۷ درخواست Approval باز، تصمیم‌های Risk بی‌Authority و فرسودگی Manager رخ داده است.

Mandate بازطراحی‌شده

• People: Career/skill/capacity برای ۹ متخصص کیفیت؛ نه Sprint assignment.
• Capability: Test data، PSP fault simulation و Evidence identity.
• Portfolio: ریسک‌های cross-team Checkout/Ledger/Reconciliation و گزینه‌های سرمایه‌گذاری.
• Assurance: فقط تغییرهای Financial critical/Privacy طبق Contract؛ نه همهٔ Storyها.
• Out: Product priority، Architecture ownership، daily test design و پذیرش Risk کسب‌وکار.

Authority map پرداخت

موضوع	Authority	مدیر QA	Evidence
اولویت قابلیت Refund	Product	Impact/Risk advisor	customer/ledger evidence
Idempotency design	Engineering owner	challenge/testability	invariant + fault test
Privacy دادهٔ تست	Privacy/Security owner	control evidence	synthetic/mask/access audit
Release critical payment	Release/Risk authority	residual-risk memo	PSP/Order/Ledger/Reconciler
Skill رشد QE	QA line manager	decider با fairness review	task competency evidence
Scale سرویس Dataset	Portfolio + service owner	option/pilot owner	adoption/outcome/guardrail/TCO

Iranian payment evidence boundary
money: canonical amount_irr + explicit displayed_toman
identity: order_id + attempt_id + psp_reference + idempotency_key
events: request → commit → callback(s) → ledger → reconciliation
faults: timeout-before-commit ≠ timeout-after-commit
duplicate callback ≠ retry; event identity retained
oracles: PSP + Order + Ledger + Outbox + Reconciler
digits/text: Persian/Arabic/Latin + Unicode/RTL policy
time: UTC instant + Asia/Tehran display; Jalali presentation only
data: synthetic identifiers; no production PAN/token/phone
authority: evidence owner ≠ financial risk acceptor

برای نوروز، مدیر QA می‌تواند Capacity/Risk review را تسهیل و Fault-simulation capability را تأمین کند؛ اما نباید به‌تنهایی سقف Risk مالی، Product scope یا Release را تعیین کند. تصمیم شرط‌دار و Rollout/Rollback باید صاحب پیامد داشته باشد.

مدیر QA و انتخاب ابزار

مدیر ممکن است Problem brief و بودجه را Sponsor کند؛ انتخاب نباید بر اساس Demo، شهرت یا ترجیح شخصی باشد. مصرف‌کنندگان Use case را اجرا، Security/Privacy Hard gate را بررسی، Migration/Exit را تمرین و TCO را بسنجند. «ابزارهای ضروری مدیر Agile» فهرست ثابت ندارد.

• اول مسئله و Workflow، سپس Category ابزار؛
• Buyer-operated PoC، نه Vendor-only demo؛
• API/export، Evidence identity و Accessibility؛
• FX، تحریم، Payment، Network access، Support و Data residency؛
• Adoption/retention و Support burden؛
• Exit، full-data export و Decommission owner.

متریک‌های اثربخشی نقش مدیر QA

لنز	نمونهٔ سنجه	Countermetric/مرز
Mandate	% Initiative با Problem/Owner/Expiry	Template completion مساوی Outcome نیست
Decision flow	Age، wait و re-route تصمیم‌ها	سرعت با Risk bypass بازی نشود
Capability	independent task success/retention	Workshop count و forced adoption
Evidence	valid/fresh/traceable decision evidence	Pass rate یا volume جای integrity ننشیند
Risk	Ack/decision/closure و expired acceptance	Incident count attribution به یک نقش نیست
Service	Time-to-first-success، SLE، support burden	Usage بدون eligible population
People	skill evidence، load، fairness، backup	Privacy، sample، nonresponse و power
Delegation	Dependency کم و owner coverage بیشتر	Manager invisibility یا abdication
Portfolio	Stop/scale با Evidence و constraint removed	Kill rate یا saving ادعایی Target نشود

اثر رهبری مستقیم و تک‌علتی نیست. راهنمای DORA دربارهٔ رهبری تحول‌آفرین توضیح می‌دهد رهبران از راه فعال‌کردن Capabilityهای فنی و Product-management بر Outcome اثر می‌گذارند و ویژگی‌های رهبری با عملکرد تحویل هم‌بستگی دارند. این هم‌بستگی یا مدل پژوهشی، اثبات نمی‌کند یک مدیر مشخص علت Outcome بوده یا Score ارزیابی فردی می‌سازد.

Manager dashboard چه چیزهایی را نباید نشان دهد؟

• تعداد Bug/Test/Automation/Commit به تفکیک فرد؛
• Pass rate بدون Result semantics، Population و Retry؛
• Utilization صددرصد به‌عنوان بهره‌وری؛
• Story point بین تیم‌ها یا «Velocity QA»؛
• Culture/engagement فردی در Cohort کوچک؛
• Score ترکیبی که Safety، Privacy یا Evidence invalid را جبران کند؛
• NPS/Revenue به‌عنوان اثر مستقیم مدیر QA؛
• AI-generated performance inference از Chat، Ticket یا Code بدون مبنای مجاز.

سیگنال‌های تبدیل‌شدن Manager به Constraint

1. همهٔ Releaseها منتظر Sign-off یک نفرند؛
2. تیم برای تغییر Test یا DoD اجازه می‌خواهد؛
3. مدیر در همهٔ Ceremonyها Status می‌گیرد؛
4. Risk owner و Product owner به QA ارجاع می‌دهند؛
5. Tool/Platform مصرف‌کننده و Service owner ندارد؛
6. Manager هم سازنده، هم Reviewer و هم ارزیاب شغلی است؛
7. تیم پس از Coaching هنوز بدون او Task را تمام نمی‌کند؛
8. کار Strategic همیشه به‌خاطر Approval/Incident عقب می‌افتد؛
9. Deputy/backup و Decision log وجود ندارد؛
10. تعطیلی مدیر سیستم تصمیم را متوقف می‌کند.

سیگنال‌های Abdication زیر نام Empowerment

• «تیم خودمدیر است» اما Skill، Access، Time یا Environment ندارد؛
• همه مالک کیفیت‌اند اما Risk authority نام‌دار نیست؛
• Manager Conflict، harassment یا overload را مسئلهٔ تیم می‌خواند؛
• Policy/Obligation به سلیقهٔ هر Squad واگذار شده؛
• Platform و Specialist service بی‌Budget و بی‌Owner مانده؛
• Career، Pay و Promotion مبهم و ناعادلانه است؛
• Dependency میان‌تیمی هیچ Escalation ندارد؛
• Manager Outcome می‌خواهد اما Context و Constraint را حذف نمی‌کند.

بازطراحی ۳۰/۶۰/۹۰ روزه نقش مدیر QA

روز ۱ تا ۳۰: کشف کار واقعی و Power

• دو هفته Activity/decision log بگیرید: چه چیزی چرا به Manager می‌رسد؟
• Mandateهای People/Capability/Portfolio/Assurance/Transformation را جدا کنید.
• Decision wait، re-route، recurring approval و Single point را Baseline بگیرید.
• مصرف‌کنندگان، Authorityها، تضاد نقش و Riskهای protected را مصاحبه کنید.
• Charter v0.۱ با In/Out/Expiry بسازید؛ هنوز ساختار را ناگهانی عوض نکنید.

روز ۳۱ تا ۶۰: Shadow و Delegation

• برای Product/Sprint/Risk/Evidence یک Authority map Shadow اجرا کنید.
• دو Approval پرتکرار را با Ready criteria و Delegation ladder واگذار کنید.
• یک Capability intervention را با Enablement Card زمان‌دار Pilot کنید.
• Assurance را به Risk tier و Service contract محدود کنید.
• Manager WIP، Reserve، backup و Stop-doing list را تصویب کنید.

روز ۶۱ تا ۹۰: Evidence و Sunset

• Delay، re-route، decision quality proxy، Risk/Guardrail و Team health را مرور کنید.
• Scopeی را که Dependency ساخته Adapt یا Delegate کنید.
• برای Service/Platform، Owner، SLE، Support، Version و Exit تعیین کنید.
• Charter را با Dissent و Executive accountable owner Renew/Change/Sunset کنید.
• Quarter بعد را حول دو Outcome/Capability محدود کنید، نه لیست Tool.

ضدالگوهای مدیر QA در Agile

1. جا زدن QA Manager به‌عنوان Accountability چهارم Scrum؛
2. QA sign-off مبهم برای همهٔ Releaseها؛
3. Shadow Product Owner یا Shadow Scrum Master شدن؛
4. تخصیص Test task در Daily و Sprint؛
5. مالکیت همزمان Strategy، Tool، Test، Evidence و Risk acceptance؛
6. تعریف Role فقط با صفات مربی/استراتژیست/مبلغ؛
7. فهرست ابزار به‌عنوان Quality strategy؛
8. هرم/نسبت ثابت برای همهٔ Productها؛
9. Coaching بدون Task، Evidence و Exit؛
10. Enablement دائمی که Dependency می‌سازد؛
11. Workshop/Meeting count به‌عنوان Outcome؛
12. Bug/Test/Automation/Story point به‌عنوان عملکرد فرد؛
13. Code coverage به‌عنوان تشویق عمومی تست بهتر؛
14. RCA بدون System action یا با Blame پنهان؛
15. فرهنگ کیفیت به‌عنوان شعار مسئولیت همه؛
16. Embedded یا Centralized به‌عنوان مدل جهانی؛
17. Approval سریع‌تر بدون بازنگری ضرورت Approval؛
18. Empowerment بدون Access، Skill، Context و Authority؛
19. Charter بدون Expiry، backup و Sunset؛
20. نادیده‌گرفتن Power، Privacy، Fairness و تضاد منافع.

چک‌لیست Role Review مدیر QA

• Problem و Mandate نقش با Evidence نوشته شده؟
• آیا نقش سازمانی را Accountability Scrum جا نزده‌ایم؟
• In scope و Out of scope هر دو روشن‌اند؟
• Product، Sprint، DoD، Evidence، Risk و Release Authority نام دارند؟
• Default، Stop، Escalation، Dissent و Expiry برای تصمیم‌ها ثبت شده؟
• تعارض People manager/Reviewer/Risk acceptor کنترل شده؟
• Interaction با تیم Collaboration/Facilitation/Service/Assurance نام‌دار است؟
• هر Interaction Goal، Artifact، Duration و Exit دارد؟
• Enablement با استقلال Task سنجیده می‌شود، نه Workshop count؟
• Strategy با Outcome/Risk/Capability شروع می‌شود، نه Tool؟
• Assurance بر اساس Risk tier است، نه Gate یکسان؟
• Manager WIP، Capacity، Reserve، Deputy و Stop-doing list دارد؟
• People metricها Privacy/Fairness و حق پاسخ دارند؟
• هیچ KPI فردی بر Bug/Test/Automation/Story point نیست؟
• Tool/Platform مصرف‌کننده، Owner، Support، TCO و Exit دارد؟
• ایران: FX/تحریم/شبکه/داده/PSP/IRR/تومان/Unicode/زمان دیده شده؟
• Outcome با Countermetric و Attribution limit گزارش می‌شود؟
• Single point و Holiday/absence سنجیده شده؟
• Charter در ۳۰/۶۰/۹۰ روز Adapt/Delegate/Sunset می‌شود؟
• Executive accountable owner و Review cadence مشخص است؟

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

آیا Scrum به مدیر QA نیاز دارد؟

Scrum نقش یا Accountabilityای به نام QA Manager تعریف نمی‌کند. سازمان ممکن است بیرون از Hierarchy داخلی Scrum Team برای People، Capability، Assurance یا Portfolio به مدیر نیاز داشته باشد. ارزش و حدود این نقش باید با Charter مشخص شود و Self-management تیم را تصاحب نکند.

مدیر QA باید Release را Sign-off کند؟

فقط اگر Policy و Mandate صریح، Risk class، Evidence requirement و Authority قانونی/سازمانی چنین مسئولیتی داده باشند. عبارت عمومی «QA Approved» مبهم است. معمولاً مدیر QA Evidence و Residual risk را ارائه می‌کند و صاحب پیامد یا Release authority تصمیم می‌گیرد.

تفاوت QA Manager با QA Lead و Scrum Master چیست؟

عنوان‌ها وابسته به سازمان‌اند. QA Lead ممکن است رهبری فنی/Delivery نزدیک تیم داشته باشد؛ QA Manager اغلب People/Capability/Portfolio mandate دارد؛ Scrum Master طبق Scrum برای اثربخشی Scrum Team و برقراری Scrum پاسخ‌گوست. یک فرد می‌تواند چند Hat داشته باشد، اما Power، Capacity و Conflict باید شفاف شود.

چگونه بفهمیم مدیر QA به گلوگاه تبدیل شده است؟

Decision age، تعداد Approval، re-route، Work awaiting manager، Scope creep، نبود backup و Dependency بعد از Enablement را بسنجید. اگر تیم بدون Manager نمی‌تواند تصمیم‌های داخل اختیارش را بگیرد یا غیبت او Release را می‌خواباند، Charter و Delegation نیاز به بازطراحی دارد.

موفقیت مدیر QA چابک با چه KPIهایی سنجیده می‌شود؟

با یک KPI یا Attribution مستقیم سنجیده نمی‌شود. Outcomeهای سیستم مانند Flow تصمیم، استقلال Capability، Evidence integrity، Risk closure، Service health، People fairness/skill/backup و کاهش Dependency را با Countermetric و Context ببینید؛ Test count، Bug count و Automation درصد معیار عملکرد فرد نیستند.

جمع‌بندی: نقش را طراحی کنید، عنوان را دفاع نکنید

مدیر QA در Agile نه باید بازرس انتهای خط باقی بماند، نه صرفاً «مربی و استراتژیست» نامیده شود. نقش سالم یک Mandate محدود، حقوق تصمیم روشن، Service و Artifact قابل‌مشاهده، Enablement زمان‌دار، Capacity واقعی و امکان Delegation/Sunset دارد.

از یک Role Charter و Decision map شروع کنید. دو Approval بی‌دلیل را Shadow-delegate کنید، یک Capability را تا استقلال تیم پیش ببرید و در پایان ۹۰ روز بپرسید: آیا تیم‌ها بهتر تصمیم می‌گیرند و Manager کمتر نقطهٔ شکست است؟ اگر پاسخ با Evidence مثبت نیست، Scope یا خود نقش باید تغییر کند.