اگر هر 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 constraintScrum «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 کجا میایستد؟
سه حالت رایج وجود دارد و باید صریح نامگذاری شود:
- عضو Developers با تخصص کیفیت: برای ساخت Increment کار میکند؛ عنوان سازمانی او Accountability تازه نمیسازد.
- People/Capability manager بیرون Team: جهت، رشد، بودجه یا سرویس میدهد؛ Sprint را مدیریت نمیکند.
- 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 خوبی داشته باشد، اما این به معنی پذیرش همهٔ ریسکها نیست. مسیر سالم:
- Signal را با Scope، Source، Version و Confidence ثبت کنید.
- Risk statement را Condition → Event → Impact بنویسید.
- Evidence موجود، Gap و Alternative explanation را جدا کنید.
- آن را به Authority صاحب پیامد Route کنید.
- Decision، Conditions، Dissent، Owner و Expiry را ثبت کنید.
- پس از 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
- همهٔ Releaseها منتظر Sign-off یک نفرند؛
- تیم برای تغییر Test یا DoD اجازه میخواهد؛
- مدیر در همهٔ Ceremonyها Status میگیرد؛
- Risk owner و Product owner به QA ارجاع میدهند؛
- Tool/Platform مصرفکننده و Service owner ندارد؛
- Manager هم سازنده، هم Reviewer و هم ارزیاب شغلی است؛
- تیم پس از Coaching هنوز بدون او Task را تمام نمیکند؛
- کار Strategic همیشه بهخاطر Approval/Incident عقب میافتد؛
- Deputy/backup و Decision log وجود ندارد؛
- تعطیلی مدیر سیستم تصمیم را متوقف میکند.
سیگنالهای 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
- جا زدن QA Manager بهعنوان Accountability چهارم Scrum؛
- QA sign-off مبهم برای همهٔ Releaseها؛
- Shadow Product Owner یا Shadow Scrum Master شدن؛
- تخصیص Test task در Daily و Sprint؛
- مالکیت همزمان Strategy، Tool، Test، Evidence و Risk acceptance؛
- تعریف Role فقط با صفات مربی/استراتژیست/مبلغ؛
- فهرست ابزار بهعنوان Quality strategy؛
- هرم/نسبت ثابت برای همهٔ Productها؛
- Coaching بدون Task، Evidence و Exit؛
- Enablement دائمی که Dependency میسازد؛
- Workshop/Meeting count بهعنوان Outcome؛
- Bug/Test/Automation/Story point بهعنوان عملکرد فرد؛
- Code coverage بهعنوان تشویق عمومی تست بهتر؛
- RCA بدون System action یا با Blame پنهان؛
- فرهنگ کیفیت بهعنوان شعار مسئولیت همه؛
- Embedded یا Centralized بهعنوان مدل جهانی؛
- Approval سریعتر بدون بازنگری ضرورت Approval؛
- Empowerment بدون Access، Skill، Context و Authority؛
- Charter بدون Expiry، backup و Sunset؛
- نادیدهگرفتن 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 یا خود نقش باید تغییر کند.
