داشبورد QA پنج عدد سبز دارد: پوشش تست ۸۵٪، خودکارسازی ۷۰٪، Pass rate برابر ۹۵٪، چگالی نقص ۱٫۲ و MTTR چهار ساعت. مدیر میپرسد: «کدام تصمیم باید عوض شود؟» کسی پاسخ روشنی ندارد. هدف محصول، Population، Baseline، Target، Owner و Guardrail ثبت نشدهاند؛ با این حال همهٔ کارتها «KPI استراتژیک» نام گرفتهاند. مشکل رنگ یا ابزار نیست؛ هیچکدام هنوز KPI نیستند.
KPI تضمین کیفیت (QA KPI) یک Metric محبوب یا عددی که مدیر میبیند نیست. Measure نسخهداری است که به Objective و Outcome مشخص، تصمیم و Action مشخص، Population و Horizon مشخص متصل شده؛ Data fitness، Target/Threshold، Guardrail، Owner، Authority، Review و Retirement دارد. داشبورد فقط یکی از Viewهای این KPI Registry است.
پاسخ کوتاه: ابتدا Objective و Decision را بنویسید؛ سپس Metric Contract و Baseline بسازید؛ فرض رابطهٔ Metric با Outcome را آشکار کنید؛ Target و Threshold را از هم جدا کنید؛ Countermetric و Data-health بگذارید؛ در Shadow رفتار و Gaming را بررسی کنید؛ فقط بعد از تصویب محدود، آن را KPI فعال بنامید.
این راهنما چه چیزی را مالک میشود؟
این صفحه مالک KPI Charter و KPI Portfolio Governance در QA است: Purpose/Objective → Outcome/Decision → Candidate Measure → Charter/Contract → Baseline/Target/Threshold → Portfolio/Guardrails → Shadow → Active use → Review/Correction/Retirement. برای فهرست و قرارداد عمومی متریکها به متریکهای تست نرمافزار بروید.
معماری Dashboard و Semantic layer در داشبورد گزارش تست، انتخاب Chart و Visual QA در بصریسازی دادههای تست و پیام مدیریتی در Quality Decision Brief مالک مستقل دارند. این مقاله آنها را تکرار نمیکند؛ تعیین میکند چه چیزی اصلاً حق دارد برچسب KPI بگیرد.
Metric، Measure، Indicator و KPI چه تفاوتی دارند؟
| مفهوم | کارکرد محدود | مثال |
|---|---|---|
| Observation | رخداد یا مقدار خام | ۲۴ Failure در Run R42 |
| Measure | مقدار طبق روش تعریفشده | Elapsed time یک Run |
| Metric | محاسبهٔ نسخهدار روی Population/Window | Accepted-signal rate |
| Indicator | Metric تفسیرشده نسبت به Outcome/Decision | نامزد هشدار ریسک Feedback دیررس |
| KPI | Indicator منتخب و حاکمیتشده برای یک Objective و تصمیم کلیدی | درصد PRهای پرریسک با Evidence پذیرفتهشده پیش از Merge |
| Target | سطح مطلوب یا Target condition | مقدار مشروط برای دورهٔ مشخص |
| Threshold | مرز Trigger یک Action | اگر Data PASS و دو Window نقض شد، Review |
همهٔ KPIها Metric دارند، اما بیشتر Metricها نباید KPI شوند. یک Metric میتواند برای Diagnosis یا Context روی داشبورد دیده شود، بدون آنکه Target، پاداش یا توجه مدیریتی اصلی به آن متصل شود.
حرف K در KPI یعنی چه؟
«Key» یعنی برای Objective و Decision فعلی کلیدی؛ نه مشهور، آسانمحاسبه یا قابلرنگکردن. اگر حذف یک Metric هیچ تصمیم، اولویت، Investigation یا Action را تغییر نمیدهد، احتمالاً KPI نیست. اگر تیم نمیتواند با اختیار مشروع بر Driverهای آن اثر بگذارد، شاید Outcome/Context باشد نه KPI عملکرد تیم.
KPI یک رابطه است، نه ستون دائمی
یک Metric واحد برای دو هدف نقش متفاوت دارد. MTTR برای Objective بازیابی سرویس ممکن است KPI باشد؛ برای Objective کیفیت Requirement فقط Context است. Pass rate برای تصمیم Run triage یک Signal محدود است؛ برای «کیفیت محصول» KPI معتبر نیست. با تغییر Objective، Product stage یا Decision، KPI باید بازبینی یا Retire شود.
از Purpose و Goal شروع کنید
پژوهش DORA دربارهٔ Measurement Frameworks توصیه میکند Framework براساس هدف سازمان انتخاب شود؛ Framework چرایی Measurement را شکل میدهد و Metrics میتوانند میان Frameworkها مشترک باشند. این منبع KPI استاندارد برای QA تجویز نمیکند؛ اصل قابلانتقال آن Goal-first و Action-oriented بودن است.
objective_id: OBJ-SYN-QA-042-v1 purpose: "کاهش زمان دریافت Evidence تصمیمپذیر برای تغییرات پرریسک Checkout" subject: SYN-CHECKOUT population: risk-class HIGH pull requests outcome: accepted decision evidence before merge deadline horizon: 30-day pilot owner_role: ROLE-OBJECTIVE-OWNER authority_role: ROLE-QUALITY-DECISION constraints: [no-production, no-people-scoring, fixed-risk-registry] success_boundary: outcome improvement without higher false-alert or escaped-risk guardrail not_claimed: product-quality, revenue, trust, release-readiness
Objective، Outcome، Output و Activity را جدا کنید
| لایه | نمونهٔ QA | خطر |
|---|---|---|
| Objective | Evidence بهموقع برای تصمیم تغییر پرریسک | عبارت مبهم «افزایش کیفیت» |
| Outcome | Decision evidence پذیرفتهشده پیش از Due | ادعای Outcome بدون Consumer |
| Output | Check result و Evidence packet | Output را Benefit نامیدن |
| Activity | تعداد اجرای Test یا Review | مشغله را عملکرد خواندن |
| Input | Runner، نفر-ساعت، ابزار | مصرف منابع را Success دانستن |
تعداد Test، Script یا Defect معمولاً Activity/Output است. میتواند برای ظرفیت یا Diagnosis مفید باشد، ولی بدون Theory و Outcome مشخص KPI موفقیت نیست.
Decision Contract پیش از KPI Charter
decision_id: DEC-KPI-SYN-042 question: "آیا KPI candidate برای Pilot محدود فعال شود؟" options: [REJECT, REDESIGN, SHADOW_PILOT] decision_user: ROLE-QUALITY-DECISION decision_due: 2026-09-15T09:00:00Z evidence_needed: [objective, metric-contract, baseline, target-rationale, guardrails] action_if_triggered: bounded evidence review not_deciding: [release, risk-acceptance, team-performance, headcount] expiry: 2026-10-15T09:00:00Z
اگر KPI قرمز شود اما هیچ Option، Owner یا Authority تعریف نشده باشد، رنگ فقط اضطراب تولید میکند. Actionability یعنی Trigger به سؤال، اقدام محدود، Due، Evidence بعدی و Closure وصل باشد؛ نه اینکه هر تغییر عدد فوراً منابع را جابهجا کند.
از Benefit و Hypothesis به Measure برسید
راهنمای GOV.UK برای Performance metrics سرویس مسیر Purpose→Goals/Benefits→Hypotheses→Measures→Data sources→Context→Iteration را توضیح میدهد و ترکیب Metrics با User research را لازم میداند. الزامهای خاص سرویسهای دولتی بریتانیا را به QA تعمیم نمیدهیم؛ فقط ترتیب فکری را اقتباس میکنیم.
hypothesis_id: HYP-KPI-SYN-042-v1 if: evidence checks run on eligible high-risk changes with stable oracle then: accepted evidence is available before the merge decision due because: repeatable checks shorten collection while preserving evidence profile expected_direction: higher on-time accepted-evidence rate counter_outcomes: [false-alert-rate, triage-effort, escaped-risk-evidence] alternatives: [smaller-scope, better-testability, changed-review-capacity] falsifier: no improvement after mature comparable shadow windows not_claimed: causality before evaluation
معیارهای ارتقای Metric به KPI
- Objective/Outcome و Decision مشخص دارد.
- Consumer، Owner و Authority مشخص دارد.
- Metric Contract و Data lineage قابلبازتولید دارد.
- Population، Window، Maturity و Segment روشناند.
- Baseline و Target/Threshold rationale دارد.
- تیم میتواند از طریق Driverهای مشروع اقدام کند.
- Guardrail و Anti-gaming controls دارد.
- در Shadow، Data fitness و رفتار تفسیرشده است.
- Claim، limitation و Not claimed روشن است.
- Review، Expiry، Change و Retirement policy دارد.
KPI Charter کامل
kpi_id: KPI-SYN-EVIDENCE-ONTIME-v1 status: CANDIDATE objective_ref: OBJ-SYN-QA-042-v1 decision_ref: DEC-KPI-SYN-042 outcome_ref: OUT-SYN-EVIDENCE-v2 metric_contract_ref: M-EVIDENCE-ONTIME-v3 subject_population: HIGH-risk PRs in SYN-CHECKOUT window: rolling 14 mature days direction: higher is conditionally desirable baseline_ref: BASE-KPI-SYN-v2 target_ref: TARGET-KPI-SYN-v1 threshold_ref: TH-KPI-SYN-v1 guardrails: [G-FALSE-ALERT-v2, G-TRIAGE-EFFORT-v2, G-ESCAPED-RISK-v1] data_health_ref: DQ-KPI-SYN-v2 action_policy_ref: ACT-KPI-SYN-v2 owner_role: ROLE-KPI-OWNER metric_steward: ROLE-METRIC-STEWARD decision_authority: ROLE-QUALITY-DECISION review_cadence: event-driven plus monthly governance review expiry: 2026-10-15T09:00:00Z not_claimed: [quality, cause, release, people-performance] correction_policy: supersede; no silent edit
Metric Contract زیرساخت KPI است
KPI Charter چرایی و کاربرد را نگه میدارد؛ Metric Contract چگونگی محاسبه را: Unit، Population، Numerator، Denominator، Eligibility، Exclusion، Window، Event time، Dedup، Join، Missing، Version و Source. یک KPI بدون Contract با تغییر Query معنا عوض میکند ولی همان نام و Target را حفظ میکند.
metric_id: M-EVIDENCE-ONTIME-v3 unit: eligible high-risk change numerator: changes with accepted evidence before decision_due denominator: all mature eligible high-risk changes in frozen registry snapshot eligibility: risk_class=HIGH and build/subject identity valid exclusions: cancelled-before-work with reason; never failed/unknown window: event-time rolling 14d; 7d maturity lag dedup: canonical change_id join: change_id + build_id + evidence_id missing: UNKNOWN; never zero/pass source_versions: [RISK-REG-v4, EVIDENCE-REG-v3, DECISION-LOG-v2] timezone: UTC canonical; Asia/Tehran view owner: ROLE-METRIC-STEWARD
KPI Portfolio به یک عدد نیاز ندارد
یک «Quality score» ترکیبی، Trade-off و Unknown را پنهان میکند. Portfolio کوچک و قابلفهم از نقشهای مکمل بهتر است: Outcome، Driver candidate، Guardrail، Data health و Context. تعداد جهانی ۳، ۵ یا ۱۰ وجود ندارد؛ کمترین مجموعهای را نگه دارید که تصمیم و عوارض جانبی را پوشش دهد.
| نقش Portfolio | پرسش | نمونهٔ ساختگی |
|---|---|---|
| Outcome KPI | پیامد موردنظر چه شد؟ | On-time accepted evidence rate |
| Driver candidate | چه عامل قابلاقدامی شاید Outcome را حرکت دهد؟ | Eligible check readiness |
| Guardrail | برای سبزشدن چه آسیبی ممکن است رخ دهد؟ | False-alert و triage effort |
| Data health | آیا خود سنجش سالم است؟ | Missing/late/join/schema |
| Context | چه تغییر بیرونی تفسیر را عوض میکند؟ | Risk mix، change size، runner version |
| Diagnostic | برای Investigation چه جزئیاتی لازم است؟ | Failure category by environment |
Outcome KPI و Driver KPI را قاطی نکنید
Outcome نتیجه را میسنجد؛ Driver چیزی است که تیم انتظار دارد بر نتیجه اثر بگذارد. Driver تا زمان اعتبارسنجی، Candidate است. اگر Coverage بالا رفت و Outcome تغییر نکرد، Target Coverage را سختتر نکنید؛ Theory، Scope، Lag، Confounder و Guardrail را بازبینی کنید.
Leading و Lagging بودن نسبی است
KPI را با برچسب ذاتی Leading/Lagging انتخاب نکنید. همان Failure rate نسبت به Build فعلی Outcome و نسبت به تصمیم فردا Candidate پیشرو است. چارچوب اعتبارسنجی Outcome/Horizon/خطا در شاخص پیشرو و پسرو در QA آمده است. تقدم زمانی بهتنهایی Predictive validity نیست.
KPI Tree و Theory را آشکار کنید
Tree نشان میدهد Objective به Outcome و Driverها چگونه مرتبط فرض شده است. رابطهٔ AND/OR، Lag، Constraint و Alternative را ثبت کنید؛ Arrow را Cause قطعی ننامید. هر Driver میتواند روی چند Outcome و Guardrail اثر متعارض داشته باشد.
Objective: timely decision evidence ├─ Outcome: accepted evidence before due │ ├─ Candidate driver: eligible checks ready │ ├─ Candidate driver: environment available │ └─ Candidate driver: triage completed within decision window ├─ Guardrail: false-alert rate ├─ Guardrail: escaped high-risk obligation ├─ Guardrail: human triage burden └─ Data health: missing/late/foreign-build evidence Arrows = hypotheses, not causal proof.
Baseline پیش از Target
Baseline باید Contract ثابت، دورهٔ نماینده، Population/Segment، points، known changes، missing و uncertainty داشته باشد. یک هفتهٔ خوب یا بد Baseline نیست. Intervention-contaminated period را پنهان نکنید. اگر دادهٔ اولیه ندارید، ابتدا Shadow baseline جمع کنید و Target قطعی نسازید.
Target از کجا میآید؟
| منبع Target | کاربرد | محدودیت |
|---|---|---|
| User/decision need | آخرین زمان/سطح لازم برای تصمیم | ممکن است فعلاً غیرقابلدستیابی باشد |
| Risk/control requirement | حد الزام یا کنترل | Scope و Authority لازم دارد |
| Internal baseline/capability | Target condition یادگیری | گذشته، مطلوبیت را تعیین نمیکند |
| Experiment/Pilot | اثر و feasibility محلی | موقت و دامنهدار است |
| External benchmark | Context یا Question starter | تعریف/جمعیت/فرصت متفاوت |
| Aspiration | جهت بلندمدت | نباید Threshold یا Commitment جا زده شود |
هدف «۱۰۰٪ Coverage»، «۰ Defect» یا «۹۵٪ Pass» بدون Rationale خطرناک است. Target باید Version، effective period، owner، review، direction/shape، minimum data و Guardrail داشته باشد.
Target، Threshold، SLO، Benchmark و Control Limit یکی نیستند
| مفهوم | معنا | کاربرد ممنوع |
|---|---|---|
| Target | سطح مطلوب در دورهٔ مشخص | رفتار طبیعی یا Cause |
| Threshold | Trigger یک Action | اثبات کیفیت |
| SLO/Commitment | سطح خدمت با Scope/Window/Policy | Target داخلی مبهم |
| Benchmark | مرجع با Protocol قابلمقایسه | عدد عمومی صنعت |
| Control limit | مرز رفتار فرایند تحت فرض آماری | قبولی محصول |
| Budget/Tolerance | حد مصرف/ریسک موردپذیرش Authority | Target انگیزشی |
Threshold بدون Action Policy رنگ است
threshold_id: TH-KPI-SYN-v1 applies_to: KPI-SYN-EVIDENCE-ONTIME-v1 predicate: data_fitness=PASS AND two mature windows below target condition action: request bounded evidence/process review action_owner: ROLE-KPI-OWNER decision_authority: ROLE-QUALITY-DECISION due: 2 business days in fictional lab required_evidence: [population-delta, source-health, guardrails, context] automatic_release_block: false automatic_resource_reallocation: false automatic_people_action: false closure: decision record plus next mature observation expires_with: KPI charter version
RAG باید Predicate نسخهدار داشته باشد
سبز/زرد/قرمز را با احساس تعیین نکنید. Rule، Window، Target، Threshold، Data fitness، Guardrail override و UNKNOWN را ثبت کنید. رنگ بهتنهایی Status نیست؛ متن، Icon/Pattern و دلیل لازم است. «GREEN» نباید Release-ready، Product healthy یا Risk accepted معنی دهد مگر همان Decision صریحاً ثبت شده باشد.
Direction همیشه «بیشتر بهتر» نیست
Review time بسیار کم میتواند سطحی و بسیار زیاد میتواند Bottleneck باشد؛ Automation ratio بالاتر میتواند Triage burden را زیاد کند؛ Defect count بالاتر شاید Detection بهتر باشد. Direction میتواند lower/higher/within-range/conditional/unknown باشد و شکل رابطه ممکن است غیرخطی باشد.
Guardrail از بهینهسازی محلی جلوگیری میکند
برای هر KPI بپرسید تیم چگونه میتواند عدد را بهتر کند ولی Outcome را خراب کند. Speed با Evidence quality، Automation با Flake/Triage، Closure با Reopen/Residual risk و Coverage با Assertion/Mutation/Risk evidence جفت میشود. Guardrail خودکار حقیقت نیست؛ Counterevidence تصمیم است.
Metric gaming را در طراحی پیشبینی کنید
- تغییر Denominator یا Eligibility برای سبزشدن
- شکستن/ادغام Ticket، Test یا Component
- تأخیر در ثبت Failure/Defect تا Cutoff بعدی
- Retry تا Pass و پنهانکردن First-attempt result
- حذف سناریوی سخت از Population
- افزایش Script/LOC/Execution بدون Risk value
- تنزل Severity یا تبدیل Defect به Improvement
- انتخاب Window یا Segment مطلوب پس از دیدن داده
KPI برای رتبهبندی افراد نیست
Defect count، Cycle time، Pass rate، Coverage و Automation ratio زمینهٔ سیستمی و تیمی دارند. اتصال مستقیم آنها به پاداش، تنبیه، Leaderboard یا Headcount رفتار نمایشی و پنهانکاری میسازد. Charter باید unit of analysis و people_scoring=false داشته باشد. Measurement برای یادگیری سیستم است، نه کنترل فرد.
Data Quality بخشی از KPI Portfolio است
راهنمای Government Data Quality Framework تأکید میکند فقط چیزهای Critical و متصل به Data use مشخص سنجیده شوند و Baseline کیفیت داده ساخته شود. این منبع برای دادهٔ دولتی است؛ ما اصل Fit-for-purpose و Data-use-specific را برای KPI QA اقتباس میکنیم.
data_health_id: DQ-KPI-SYN-v2 schema_version_match: required source_freshness: within decision-specific SLA completeness: eligible records with required identities uniqueness: canonical change/evidence IDs validity: allowed state/unit/time vocabularies join_integrity: change+build+evidence relationships late_event_rate: visible and provisional foreign_build_rate: zero tolerance for numerator fitness_states: [PASS, LIMITED, HOLD, UNKNOWN] failure_action: hold KPI verdict; repair/recompute/correct owner_role: ROLE-DATA-STEWARD
Freshness را از Real-time جدا کنید
Real-time همیشه بهتر نیست. Cadence باید با Decision latency، Event maturity، Collection cost و Noise متناسب باشد. Defect escape ممکن است هفتهها بالغ شود؛ Pipeline health شاید دقیقهای لازم باشد. «روزانه حداقل استاندارد Agile» قانون عمومی نیست. Facts-as-of و freshness SLA را کنار KPI نشان دهید.
Observed، Ingested و Computed زمانهای متفاوتاند
| زمان | معنا | خطای رایج |
|---|---|---|
| event/observed_at | رخداد واقعاً چه زمانی بود؟ | جایگزینی با زمان Dashboard |
| ingested_at | چه زمانی وارد Source شد؟ | پنهانکردن Reporting lag |
| facts_as_of | Facts تا کدام Cutoff معتبرند؟ | ترکیب Sourceهای با Cutoff متفاوت |
| computed_at | KPI چه زمانی محاسبه شد؟ | محاسبهٔ تازه روی Snapshot قدیمی |
| published_at | View چه زمانی منتشر شد؟ | تازهبودن View را تازهبودن داده دانستن |
| mature_at | Outcome چه زمانی قابلقضاوت است؟ | Unknown را صفر/Pass شمردن |
Coverage خودکار KPI نیست
Coverage میتواند Metric تشخیصی یا Driver candidate باشد. Code/Requirement/Risk coverage تعریفهای متفاوت دارند؛ لمس کد، Assertion/Oracle و نبود Defect را ثابت نمیکند. اگر KPI candidate میشود، Population، method، risk obligations، Target rationale و Guardrailهای Mutation/escaped-risk/data health لازماند.
Automation ratio KPI موفقیت نیست
درصد Automated/Manual به Definition واحد Case/Scenario/Risk وابسته است و تیم را به خودکارکردن موارد آسان سوق میدهد. برای Investment/Portfolio شاید Context باشد؛ برای Outcome بهتر، accepted evidence، feedback time، reliability و TCO مهمترند. Flake، maintenance و exploratory capacity Guardrailاند.
Pass rate KPI کیفیت محصول نیست
Pass rate تابع Suite selection، Attempt/Retry، Build، Environment، Eligibility و Oracle است. ۹۵٪ Pass نمیگوید ۹۵٪ Product سالم است. برای Run triage ممکن است Metric باشد؛ برای Objective محصول، Evidenceهای Risk و Unknownها لازماند. First-attempt و final-attempt را جدا نگه دارید.
Defect Density KPI عمومی نیست
Density فقط نرخ Defectهای مشاهدهشده بر Size/Exposure قراردادی است. عدد بالا Cause Complexity/ضعف Code و عدد پایین Quality را ثابت نمیکند. Comparability Gate، Window، Detection opportunity و Size contract در راهنمای چگالی نقص آمده است.
Defect Escape Rate به Attribution و Maturity نیاز دارد
«باگ کاربر ÷ همهٔ باگها» بدون Release cohort، discovery window، duplicate، severity، origin/escape phase، user exposure و maturity گمراهکننده است. Escape پایین ممکن است از Reporting کم باشد. اگر Objective کاهش Risk پس از Release است، Scenario exposure و Guardrailهای detection/reporting لازماند.
Open bugs trend سلامت پروژه نیست
Backlog count به Intake، Closure policy، Duplicate، Scope و Severity mix وابسته است. بالا رفتن الزاماً خطر و پایینآمدن الزاماً سلامت نیست. Aging، exposure، blocked decisions، residual risk و data quality را ببینید. Trend unusual نیز Cause یا بحران نیست؛ پروتکل Noise/Signal در تحلیل روند معیارها جداست.
MTTR میانگین ساده نیست
Resolution، Repair، Recovery و Closure زمانهای متفاوتاند. Open/censored work، Severity، Queue/active time، timezone و Percentileها لازماند. MTTR طولانی Cause ارتباط ضعیف یا Complexity نیست. KPI فقط وقتی معنا دارد که Objective/Service، event boundaries و Action owner مشخص باشند.
Test Cycle Time نیازمند مرز و Flow unit است
شروع و پایان Cycle، Queue، blocked، rework، parallel work و Unit تغییر میکنند. کاهش Calendar duration میتواند با Scope کمتر یا Evidence ضعیفتر رخ دهد. Outcome/Guardrail را نگه دارید. اتوماسیون شاید بخشی از Critical path را تغییر دهد؛ Cause و عرضه سریعتر خودکار ثابت نمیشوند.
Metric مثبت و منفی را متوازن کنید
Portfolio فقط Error/Defect/Delay نباشد و فقط Activity سبز نیز نباشد. Outcome موفق، Risk/Unknown، Flow، Evidence quality، Data health و Human/system burden را کنار هم ببینید. تعادل به معنای Average یا Composite score نیست؛ Trade-offها باید جدا دیده شوند.
Composite KPI و Quality Score چه خطری دارند؟
جمع Coverage، Pass، Defect و MTTR با وزن دلخواه، واحدها و جهتهای متفاوت را به عددی ظاهراً دقیق تبدیل میکند. یک KPI خوب میتواند دیگری را پنهان کند. اگر Composite لازم است، normalization، weights/authority، missing policy، sensitivity، drill-down و prohibition of release/people decisions لازماند؛ مؤلفههای خام حفظ شوند.
Qualitative evidence هم جایگاه دارد
همهٔ Outcomeها با Count بهتر فهمیده نمیشوند. Comprehension interview، User research، Retrospective evidence و Expert review میتوانند Context یا Outcome evidence باشند. Coding protocol، sample، provenance و limitations لازم است. Sentiment AI یا Survey کوچک را بدون روش به Score قطعی تبدیل نکنید.
Dashboard منبع حقیقت نیست
Source systems، versioned semantic model و KPI Registry منبع Claimاند؛ Dashboard View است. Data copy در Spreadsheet یا Slide نباید تعریف دوم بسازد. Drill-down باید از KPI card به Charter، Metric Contract، Snapshot، Source lineage، Guardrails و Correction برسد.
یک Registry، چند View مخاطب
مدیر، QA Lead و Engineer سؤالهای متفاوت دارند، اما Factهای متناقض نباید دریافت کنند. Executive view Objective/Outcome/Options/Unknown را نشان میدهد؛ Operational view Driver/Guardrail/Action؛ Technical view Contract/Source/Debug. همه از همان KPI ID، Snapshot و Facts-as-of تولید شوند.
Dashboard، Alert، Report و Decision Brief متفاوتاند
| Artifact | کارکرد | نباید باشد |
|---|---|---|
| Dashboard | Exploration/monitoring view | Decision record |
| Alert | Event-triggered توجه با Runbook | Cause/decision خودکار |
| Report | Snapshot دورهای/تحلیلی | Query شناور بیهویت |
| Decision brief | Claims/Risk/Options/Recommendation | Raw chart wall |
| Decision record | Authority/choice/rationale/action/review | تفسیر بیمالک |
Chart را براساس سؤال انتخاب کنید
Pie chart پیشفرض درصد نیست؛ line chart هر نوسان را Trend معتبر نمیکند؛ RAG هر عدد را Actionable نمیکند. Chart contract، scale/axis، uncertainty، denominator، accessible table و Visual regression را طبق مالک بصریسازی دادههای تست طراحی کنید.
دسترسیپذیری KPI View
- رنگ تنها حامل معنا نباشد؛ متن/Icon/Pattern افزوده شود.
- Chart عنوان، summary، long description یا Data table داشته باشد.
- Keyboard، screen reader، focus، zoom، mobile و print بررسی شوند.
- فارسی RTL با English ID/عدد/واحد LTR واضح ترکیب شود.
- Digits، decimal separator، ریال/تومان و زمان/Timezone برچسب داشته باشند.
- Animation و auto-refresh با Reduced motion و کنترل Pause سازگار باشد.
حریم خصوصی و KPI افراد
KPI عملیاتی معمولاً به نام، ایمیل، IP، Screenshot، Payload یا Activity فردی نیاز ندارد. Aggregate حداقلی، Role-based access، suppression برای گروه کوچک، retention، export audit و redaction را تعریف کنید. Survey/Wellbeing دادهٔ حساستری است و باید داوطلبانه، Purpose-limited و مستقل از ارزیابی شغلی باشد.
نقشها و اختیارها
| نقش قابلیتمحور | مسئولیت | اختیار پیشفرض ندارد |
|---|---|---|
| Objective owner | Purpose/Outcome/Priority | تغییر Formula برای سبزی |
| KPI owner | Charter، action، review، retirement | تأیید مستقل Data خودش |
| Metric steward | Contract، compute، version، lineage | Target/people action |
| Data steward | Source quality، access، correction | تفسیر Outcome |
| Domain reviewer | Theory، alternatives، risk context | Decision authority |
| Decision authority | Target/threshold/action/trade-off | بازنویسی Evidence |
| Independent reviewer | Gaming، comparability، claim limits | مالکیت Objective |
چرخهٔ عمر KPI
DRAFT → CANDIDATE → DATA_READY → SHADOW → ACTIVE → UNDER_REVIEW → RETIRED
↘ REJECTED ↘ CORRECTED / SUSPENDED
Promotion requires evidence; no status by dashboard color.
ACTIVE is scoped and expiring, not permanent.
RETIRED preserves history and affected decisions.
Shadow پیش از Target pressure
در Shadow، KPI محاسبه و تفسیر میشود اما به پاداش، Gate یا تصمیم خودکار متصل نیست. هدف کشف Missing، Lag، Seasonality، denominator drift، false alert، gaming path و Action feasibility است. Target اولیه میتواند Target condition آزمایشی باشد، نه Commitment.
KPI Review چه سؤالهایی دارد؟
- Objective و Decision هنوز معتبرند؟
- Contract/Population/Source/Context تغییر کرده؟
- Data fitness و Maturity کافی است؟
- Outcome، Driver و Guardrail چه میگویند؟
- Signal یا Target gap واقعاً Actionable است؟
- چه Alternative explanation و Disconfirming evidence داریم؟
- Gaming یا رفتار ناخواسته دیده شده؟
- Forecast/Target و Actual چگونه فرق کردند؟
- Action قبلی چه Outcome و Correctionی داشت؟
- KPI باید Continue، Redesign، Suspend یا Retire شود؟
Meeting برای خواندن Cardها نیست؛ برای تصمیم دربارهٔ Charter و Action است. Raw analysis پیشخوانده شود، dissent و Unknown ثبت و Decision record تولید شود.
Cadence دورهای و Event-driven
Review governance میتواند ماهانه/فصلی یا متناسب با Product باشد، اما Eventهای Contract change، Data breach، target gaming، incident، major scope shift و Objective change نباید تا جلسهٔ بعد منتظر بمانند. هیچ cadence جهانی برای همهٔ KPIها وجود ندارد.
Change control KPI
تغییر Formula، Target، Window، Eligibility، Source یا RAG rule نسخهٔ جدید میخواهد. Change reason، effective date، affected history/decision، bridge/recompute و approval را ثبت کنید. Target را برای سبزشدن عقب نبرید و Query را بدون Migration عوض نکنید.
چه زمانی KPI را Retire کنیم؟
- Objective یا Decision دیگر وجود ندارد.
- هیچ Action مشروعی از تغییر KPI حاصل نمیشود.
- Measurement cost از ارزش تصمیم بیشتر شده است.
- Metric بهسادگی Gaming میشود و Guardrail کافی نیست.
- رابطهٔ KPI با Outcome در Shadow/Review پشتیبانی نمیشود.
- Contract/Data تغییر بنیادی کرده و Bridge معتبر نداریم.
- KPI با Measure سادهتر و دقیقتر جایگزین شده است.
- استفادهٔ آن باعث آسیب، فشار فردی یا تصمیم اشتباه میشود.
Correction و Supersession
correction_id: COR-KPI-SYN-042-02 corrects: KPI-SYN-EVIDENCE-ONTIME-v1 / SNAP-KPI-SYN-042 reason: six late evidence events were classified as missing old_value: 0.81 new_value: 0.88 old_status: AMBER new_status: UNDER_REVIEW affected_windows: [2026-W31, 2026-W32] affected_decisions: [DEC-KPI-SYN-042] issued_at: 2026-08-20T09:00:00Z superseding_artifacts: [KPI-v2, SNAP-v2] owner_role: ROLE-METRIC-STEWARD silent_edit: false
Automation و AI چه مرزی دارند؟
- Automation میتواند Schema، identity، time، dedup، join، formula، target/rule version و Data fitness را قطعی کنترل کند.
- Pipeline باید Contract mismatch و stale/missing data را HOLD کند، نه سبز.
- AI میتواند KPI candidate، alternative explanation یا Plain-language summary پیشنهاد کند.
- AI نباید KPI/Target بسازد، Cause اعلام کند، افراد را Score کند یا Decision/Resource action صادر کند.
- هر AI output به Source/Contract پیوند، limitation، model/version و Human review نیاز دارد.
آزمایش اجرایی: پنج کارت سبز بدون KPI Charter
Fixture زیر کاملاً ساختگی، آفلاین و غیرقابلتعمیم است. Checker سطحی فقط وجود پنج عدد را میبیند و `KPI_PORTFOLIO_APPROVED` اعلام میکند. ممیزی Governance دارای ۵۶ Rule است؛ Rule آخر People scoring را منع میکند و چون false است، نسخهٔ خام دقیقاً ۵۵ Finding میگیرد. تعداد Ruleها Benchmark صنعت یا بلوغ نیست.
const draft = {
cards: {
coverage: 85,
automation_ratio: 70,
pass_rate: 95,
defect_density: 1.2,
mttr_hours: 4
},
declared_status: "KPI_PORTFOLIO_APPROVED",
people_scoring: false
};
const present = (v) =>
v !== undefined && v !== null &&
!(typeof v === "string" && v.trim() === "") &&
!(Array.isArray(v) && v.length === 0);
const rules = [
["KPI-01 review_id", x => present(x.review_id)],
["KPI-02 revision", x => present(x.revision)],
["KPI-03 supersedes", x => present(x.supersedes)],
["KPI-04 purpose", x => present(x.purpose)],
["KPI-05 objective_ref", x => present(x.objective_ref)],
["KPI-06 outcome_ref", x => present(x.outcome_ref)],
["KPI-07 decision_ref", x => present(x.decision_ref)],
["KPI-08 decision_user", x => present(x.decision_user)],
["KPI-09 decision_due", x => present(x.decision_due)],
["KPI-10 action_policy", x => present(x.action_policy)],
["KPI-11 kpi_id", x => present(x.kpi_id)],
["KPI-12 lifecycle_status", x => present(x.lifecycle_status)],
["KPI-13 portfolio_role", x => present(x.portfolio_role)],
["KPI-14 metric_contract", x => present(x.metric_contract)],
["KPI-15 population", x => present(x.population)],
["KPI-16 unit", x => present(x.unit)],
["KPI-17 numerator", x => present(x.numerator)],
["KPI-18 denominator", x => present(x.denominator)],
["KPI-19 eligibility", x => present(x.eligibility)],
["KPI-20 exclusions", x => present(x.exclusions)],
["KPI-21 window", x => present(x.window)],
["KPI-22 maturity", x => present(x.maturity)],
["KPI-23 identity_dedup_join", x => present(x.identity_dedup_join)],
["KPI-24 missing_policy", x => present(x.missing_policy)],
["KPI-25 source_versions", x => present(x.source_versions)],
["KPI-26 direction_shape", x => present(x.direction_shape)],
["KPI-27 hypothesis", x => present(x.hypothesis)],
["KPI-28 alternatives", x => present(x.alternatives)],
["KPI-29 baseline_ref", x => present(x.baseline_ref)],
["KPI-30 target_ref", x => present(x.target_ref)],
["KPI-31 target_rationale", x => present(x.target_rationale)],
["KPI-32 threshold_ref", x => present(x.threshold_ref)],
["KPI-33 rag_rule", x => present(x.rag_rule)],
["KPI-34 guardrails", x => present(x.guardrails)],
["KPI-35 countermetrics", x => present(x.countermetrics)],
["KPI-36 data_health", x => present(x.data_health)],
["KPI-37 facts_as_of", x => present(x.facts_as_of)],
["KPI-38 freshness_sla", x => present(x.freshness_sla)],
["KPI-39 context_fields", x => present(x.context_fields)],
["KPI-40 segment_policy", x => present(x.segment_policy)],
["KPI-41 anti_gaming", x => present(x.anti_gaming)],
["KPI-42 not_claimed", x => present(x.not_claimed)],
["KPI-43 kpi_owner", x => present(x.kpi_owner)],
["KPI-44 metric_steward", x => present(x.metric_steward)],
["KPI-45 data_steward", x => present(x.data_steward)],
["KPI-46 decision_authority", x => present(x.decision_authority)],
["KPI-47 access_privacy", x => present(x.access_privacy)],
["KPI-48 accessibility", x => present(x.accessibility)],
["KPI-49 shadow_plan", x => present(x.shadow_plan)],
["KPI-50 review_cadence", x => present(x.review_cadence)],
["KPI-51 revalidation_triggers", x => present(x.revalidation_triggers)],
["KPI-52 change_policy", x => present(x.change_policy)],
["KPI-53 retirement_policy", x => present(x.retirement_policy)],
["KPI-54 expiry", x => present(x.expiry)],
["KPI-55 correction_policy", x => present(x.correction_policy)],
["KPI-56 people_scoring_prohibited", x => x.people_scoring !== true]
];
const findings = (x) => rules.filter(([, ok]) => !ok(x)).map(([id]) => id);
console.log("SUPERFICIAL", Object.keys(draft.cards).length, draft.declared_status);
console.log("GOVERNANCE", findings(draft).length ? "HOLD" : "READY", findings(draft).length);
const corrected = {
review_id: "SYN-KPI-042", revision: "v1", supersedes: "none:first-revision",
purpose: "timely accepted decision evidence", objective_ref: "OBJ-SYN-QA-042-v1",
outcome_ref: "OUT-SYN-EVIDENCE-v2", decision_ref: "DEC-KPI-SYN-042",
decision_user: "ROLE-QUALITY-DECISION", decision_due: "2026-09-15T09:00:00Z",
action_policy: "bounded evidence/process review only", kpi_id: "KPI-SYN-EVIDENCE-ONTIME-v1",
lifecycle_status: "CANDIDATE", portfolio_role: "OUTCOME_KPI_CANDIDATE",
metric_contract: "M-EVIDENCE-ONTIME-v3", population: "HIGH-risk PRs in SYN-CHECKOUT",
unit: "eligible high-risk change", numerator: "accepted evidence before decision due",
denominator: "all mature eligible changes", eligibility: "risk=HIGH with valid subject/build",
exclusions: "cancelled-before-work with reason only", window: "rolling 14 event-time days",
maturity: "7d", identity_dedup_join: "change+build+evidence canonical IDs",
missing_policy: "UNKNOWN; never zero/pass", source_versions: ["RISK-v4", "EVIDENCE-v3", "DECISION-v2"],
direction_shape: "higher conditionally desirable; no linear claim", hypothesis: "HYP-KPI-SYN-042-v1",
alternatives: ["testability", "scope-mix", "review-capacity"], baseline_ref: "BASE-KPI-SYN-v2",
target_ref: "TARGET-KPI-SYN-v1", target_rationale: "decision need plus shadow feasibility",
threshold_ref: "TH-KPI-SYN-v1", rag_rule: "RAG-KPI-SYN-v1 with UNKNOWN",
guardrails: ["false-alert", "triage-effort", "escaped-risk"],
countermetrics: ["population-drift", "first-attempt-signal"], data_health: "DQ-KPI-SYN-v2",
facts_as_of: "2026-08-15T00:00:00Z", freshness_sla: "decision-specific 24h",
context_fields: ["risk-mix", "change-size", "runner-version"], segment_policy: "predeclared risk strata",
anti_gaming: ["frozen population", "first-attempt retained", "state audit"],
not_claimed: ["quality", "cause", "release", "people-performance"], kpi_owner: "ROLE-KPI-OWNER",
metric_steward: "ROLE-METRIC-STEWARD", data_steward: "ROLE-DATA-STEWARD",
decision_authority: "ROLE-QUALITY-DECISION", access_privacy: "aggregate minimum; role-based",
accessibility: "text+pattern+table; keyboard/RTL", shadow_plan: "30d no automated gate/reward",
review_cadence: "event-driven plus monthly governance", revalidation_triggers: ["objective", "contract", "data", "gaming"],
change_policy: "version+bridge+approval", retirement_policy: "preserve history and affected decisions",
expiry: "2026-10-15T09:00:00Z", correction_policy: "supersede; no silent edit",
people_scoring: false
};
const correctedFindings = findings(corrected);
console.log("CORRECTED", correctedFindings.length ? "HOLD" : "READY_FOR_KPI_GOVERNANCE_REVIEW", correctedFindings.length);خروجی مستقل Fixture و مرز تفسیر
SUPERFICIAL 5 KPI_PORTFOLIO_APPROVED GOVERNANCE HOLD 55 CORRECTED READY_FOR_KPI_GOVERNANCE_REVIEW 0
پنج Card عدد دارند اما ۵۵ جزء Governance ندارند؛ Rule منع People scoring تنها Rule پاسشده است. نسخهٔ اصلاحشده صفر Finding ساختاری دارد، اما صحت داده، کفایت Baseline/Target، اعتبار Hypothesis، مناسببودن KPI، Outcome واقعی، Cause، کیفیت محصول، Release یا درستی تصمیم را ثابت نمیکند. نام خروجی عمداً Review است، نه Approved/Validated.
آزمایشگاه آفلاین KPI فارسی Checkout
Lab کاملاً جدا از Production بسازید: Order، PaymentAttempt، PSP Stub جعلی، Callback، Ledger، Reconciliation و اعلان ساختگی. سناریوهای timeout پیش/پس از Fake commit، retry، duplicate/late/out-of-order callback، foreign Build، missing Evidence، Collector outage و Target gaming را وارد کنید. KPI Registry باید identities و Correctionها را نگه دارد.
lab_id: SYN-IR-CHECKOUT-KPI-01
network: disabled
production_data: forbidden
identities: [Objective, KPI, Metric, Target, Threshold, Change, Build, Evidence, Snapshot, Decision]
canonical_currency: fictional IRR only when a cost context is needed
toman_view: presentation-only and explicitly labelled
digits: [Persian, Arabic, Latin]
unicode_pairs: [ی/ي, ک/ك]
event_time: ISO-8601 UTC
display_timezone: Asia/Tehran
jalali_date: presentation-only
forbidden: [real company, person score, user, order, payment, PSP, bank, PAN,
CVV2, OTP, account, mobile, email, IP, cookie, token, credential,
production log, screenshot]
claims: synthetic, non-representative, no legal/financial/security/HR conclusion
اعداد، Targetها، Roleها و Cadenceهای Lab ساختگیاند. IRR فقط در Context هزینه و تومان فقط View برچسبدار است؛ هیچ نرخ بازار وارد نمیشود. UTC زمان Canonical، Asia/Tehran نمایش و جلالی فقط Presentation است. KPI Lab برای ارزیابی فرد، شرکت، بازار یا نظام بانکی ایران نیست.
Pilot سیروزهٔ KPI Governance
- روز ۱ تا ۵: Purpose/Objective/Outcome/Decision و Candidate portfolio را Review کنید.
- روز ۶ تا ۱۰: KPI/Metric/Data/Target/Threshold/Guardrail contracts و Roleها را Freeze کنید.
- روز ۱۱ تا ۲۰: Shadow محاسبه کنید؛ هیچ Gate، پاداش یا People action فعال نباشد.
- روز ۲۱ تا ۲۵: Data fitness، Target behavior، false alert، gaming، context/segment و Action feasibility را بررسی کنید.
- روز ۲۶ تا ۳۰: Independent governance review و یکی از REJECT، REDESIGN، EXTEND_SHADOW یا LIMITED_ACTIVE را ثبت کنید.
سی روز قانون عمومی نیست؛ Window و Outcome maturity ممکن است بیشتر باشد. اگر Objective هنوز مبهم یا Data نارس است، Candidate را Active نکنید. UNKNOWN و Retirement نتیجهٔ معتبرند.
ضدالگوهای KPI تضمین کیفیت
- نامیدن هر کارت Dashboard بهعنوان KPI
- شروع از دادهٔ موجود بهجای Goal/Decision
- فهرست ثابت ۳ تا ۵ KPI برای همهٔ تیمها
- Coverage/Automation/Pass/Defect/MTTR بهعنوان KPIهای جهانی
- Target ۱۰۰%/۰/۹۵% بدون Baseline و rationale
- یکیگرفتن Target/Threshold/Benchmark/Control limit
- Real-time یا روزانه بهعنوان Cadence عمومی
- RAG رنگی بدون Predicate و UNKNOWN
- Composite Quality score با وزن دلخواه
- Metric tree بهعنوان اثبات Cause
- مقایسهٔ تیمها با Population/Context متفاوت
- بهینهسازی KPI بدون Guardrail
- Retry/Denominator/State/Window gaming
- Missing یا Outcome نارس بهعنوان صفر/Pass
- Dashboard بهعنوان Source of truth
- تغییر Formula/Target بدون Version/Bridge
- جلسهٔ KPI برای خواندن نمودارها بدون Decision
- KPI بدون Owner/Authority/Action/Expiry
- People leaderboard، پاداش یا تنبیه با QA KPI
- حفظ KPI پس از پایان Objective
چکلیست Owner پیش از فعالکردن KPI
- Purpose، Objective و Outcome نسخهدارند.
- Decision، User، Options، Authority و Due روشناند.
- Candidate واقعاً تصمیم یا Action را تغییر میدهد.
- Portfolio role: Outcome/Driver/Guardrail/Data/Context مشخص است.
- Metric Contract، Population، Unit و Formula کاملاند.
- Window، Maturity، Identity/Dedup/Join و Missing روشناند.
- Source versions و Data lineage قابلبازتولیدند.
- Direction/shape، Hypothesis و Alternatives ثبتاند.
- Baseline نماینده و uncontaminated است.
- Target rationale/effective period/owner وجود دارد.
- Threshold به Action/Authority/Closure وصل است.
- RAG predicate و UNKNOWN نسخه دارند.
- Guardrail، Countermetric و Data health کنار KPI هستند.
- Facts-as-of، Freshness و Context/Segment دیده میشوند.
- Anti-gaming و no-people-scoring صریحاند.
- Not claimed و Claim boundary روشناند.
- KPI/Metric/Data/Decision roleها جدا هستند.
- Access/privacy و accessibility کاملاند.
- Shadow/Review/Revalidation/Change/Retirement تعریف شدهاند.
- Expiry و Correction بدون Silent edit وجود دارد.
پرسشهای متداول درباره KPI تضمین کیفیت
بهترین KPIهای QA کداماند؟
فهرست جهانی وجود ندارد. KPI باید از Objective، Outcome، Decision، Population و Context محلی ساخته شود. یک Portfolio معمولاً نقشهای Outcome، Driver candidate، Guardrail و Data health دارد؛ اما کمترین مجموعهٔ لازم را انتخاب کنید، نه عدد ثابت یا KPI مشهور.
تفاوت Metric و KPI چیست؟
Metric روش محاسبهٔ نسخهدار روی داده است. KPI همان Metric نیست؛ یک Indicator منتخب برای Objective و تصمیم کلیدی است که Charter، Owner، Baseline، Target/Threshold، Guardrail، Data fitness، Action، Review و Expiry دارد. بیشتر Metricها باید Diagnostic یا Context بمانند.
آیا Coverage، Pass Rate و Defect Density KPI هستند؟
ذاتاً نه. Coverage Driver candidate، Pass rate Run metric و Density observed-rate محدود است. هرکدام فقط برای Objective/Decision/Population مشخص و پس از قرارداد و Governance ممکن است KPI شود؛ هیچکدام کیفیت، Cause یا Release readiness را بهتنهایی ثابت نمیکند.
داشبورد KPI باید Real-time باشد؟
نه همیشه. Cadence به Decision latency، Event maturity، Noise، Cost و Freshness need بستگی دارد. Pipeline health شاید دقیقهای و Defect escape شاید پس از Window بالغ معنا داشته باشد. Facts-as-of و SLA را نشان دهید؛ تازهبودن View برابر بلوغ Outcome نیست.
آیا KPIهای QA برای ارزیابی عملکرد تستر مناسباند؟
خیر. KPIهای QA تحت اثر سیستم، Scope، Product، Team، Tool و Data هستند. استفادهٔ فردی Gaming و پنهانکاری ایجاد میکند. Unit of analysis را Process/Product flow نگه دارید، People scoring را ممنوع و دادهٔ افراد را حداقل/خصوصی کنید.
جمعبندی: KPI را حاکمیت کنید، نه اینکه فقط نمایش دهید
داشبوردی با پنج عدد سبز هنوز KPI Portfolio نیست. KPI از Purpose، Objective، Outcome و Decision آغاز میشود؛ Metric Contract، Baseline، Target/Threshold، Guardrail، Data health، Owner و Action میگیرد؛ در Shadow آزموده و با Expiry/Correction اداره میشود.
هر Metric را Key ننامید. Outcome و Driver را جدا، Data و Context را آشکار، RAG را Predicate، Target را قابلچالش و People scoring را ممنوع کنید. Dashboard فقط View است. KPI بالغ، عددی برای فشار بیشتر نیست؛ قرارداد محدودی است که تصمیم، Evidence، اقدام و یادگیری را بدون پاککردن تاریخچه به هم وصل میکند.
