درخواست بودجهٔ QA اغلب با یک فهرست خرید شروع میشود: «دو تستر، یک ابزار اتوماسیون، Device farm و دورهٔ آموزشی». مدیر مالی میپرسد چرا، مدیر محصول میپرسد کدام ریسک کم میشود و تیم مهندسی تازه متوجه میشود محیط تست و دادهٔ پایدار—پیشنیاز همان اتوماسیون—اصلاً در بودجه نیست. مشکل «نگاه مرکز هزینه» نیست؛ مشکل این است که فهرست هزینه هنوز به Outcome، ریسک، قابلیت، وابستگی و تصمیم سرمایهگذاری تبدیل نشده است.
این راهنما روش عملی بودجهبندی QA و تخصیص سرمایهٔ کیفیت را توضیح میدهد: تقاضای کیفیت و تعهدهای اجتنابناپذیر را میشناسیم، شکاف قابلیت را پیدا میکنیم، گزینههای Build/Buy/Borrow/Hire/Design-away را با Business as usual مقایسه میکنیم، TCO و عدمقطعیت را میبندیم، Initiativeها را در یک Portfolio دارای Constraint و Dependency قرار میدهیم و با Pilot، Stop/Scale و Review، بودجه را از «مجوز خرج» به «فرضیهٔ سرمایهگذاری» تبدیل میکنیم.
خلاصه اجرایی: بودجه QA در ۱۰ اصل
- درصد استاندارد وجود ندارد: ۱۵٪، ۲۰٪ یا ۳۰٪ بودجهٔ توسعه بدون Risk، Scope و Capability معنای تصمیمساز ندارد.
- بودجه را از تقاضا بسازید: Journey، تعهد، خطر، تغییر، Failure demand و Evidence gap؛ نه از عنوان شغلی و کاتالوگ ابزار.
- Run را از Change جدا کنید: هزینهٔ ادامهٔ خدمت، تعهد و نگهداری نباید با سرمایهگذاری کاهش ریسک یا Enablement مخلوط شود.
- Business as usual یک گزینه است: «هیچ سرمایهگذاری جدید» را با پیامد و هزینهٔ فرصت شفاف مقایسه کنید.
- ابزار یک Capability نیست: Adoption، داده، Integration، مالک، نگهداری، دسترسی و Exit هزینه دارند.
- Dependency ترتیب میسازد: اتوماسیون وسیع بدون Testability، محیط، داده و هویت رخداد، ظرفیت را میسوزاند.
- Point estimate کافی نیست: Low/Base/High، Range، Assumption، حساسیت، Currency و Contingency لازماند.
- Portfolio باید Constraint داشته باشد: Obligations، مهارت کمیاب، ظرفیت تغییر، تمرکز Vendor و حداقل پوشش Risk.
- Funding را مرحلهای کنید: Discovery→Pilot→Scale با Evidence و Stop rule، نه Commit کامل پیش از یادگیری.
- بودجه مالک مشترک دارد: Product، Engineering، QA، SRE، Security، Finance و Procurement؛ QA بهتنهایی درآمد یا ریسک کسبوکار را امضا نمیکند.
مرز این مقاله با ROI، استراتژی تست و انتخاب ابزار
- برای Expected loss، TCO، Attribution، ROI و Payback، ارزش تجاری تست نرمافزار مالک محاسبهٔ Business case است.
- برای Risk/Evidence/Gate و انتخاب کنترلها، سند استراتژی تست را ببینید.
- برای PoC، Hard gate، TCO و Exit یک محصول، راهنمای انتخاب ابزار مدیریت تست مالک موضوع است.
- برای اینکه کدام سناریوها را خودکار کنیم، راهنمای اتوماسیون تست را بخوانید.
خروجی این صفحه یک QA Investment Portfolio است: Demand map، Capability gap، Option cards، Cost envelope، Dependency graph، Portfolio decision، Funding stages و Benefits/Evidence review. ROI فقط یکی از ورودیهای احتمالی این تصمیم است.
سه ادعای رایج اما نامعتبر را کنار بگذارید
«قانون ۱-۱۰-۱۰۰» بودجه را ثابت میکند
یک ضریب ثابت برای هزینهٔ پیشگیری، تست و تولید در همهٔ محصولات وجود ندارد. هزینه به نوع نقص، Detection opportunity، معماری، قابلیت Rollback، Exposure، تنظیمگری، داده و پیامد بستگی دارد. یک typo شاید در تولید ارزان باشد؛ برداشت تکراری یا افشای داده حتی با Fix سریع، پیامد جبرانناپذیر دارد. برای تصمیم از دادهٔ خود، Range و Scenario استفاده کنید، نه «۱ دلار/۱۰ دلار/۱۰۰ دلار» بهعنوان قانون مهندسی.
«۱۵ تا ۳۰ درصد بودجهٔ توسعه» استاندارد است
درصد بدون تعریف صورت و مخرج قابل مقایسه نیست: آیا Security، SRE، محیط، Test data، Device، پشتیبانی و توسعهٔ Testability داخل بودجه QA هستند؟ آیا محصول پزشکی با MVP داخلی یک ریسک دارد؟ درصد میتواند Sanity check محلی باشد، نه Target یا Benchmark جهانی.
«اتوماسیون در بلندمدت همیشه ROI مثبت دارد»
هیچ «همیشه»ای وجود ندارد. تغییرپذیری UI، عمر Journey، تعداد اجرای مجدد، هزینهٔ Oracle، Flakiness، نگهداری، زیرساخت، Triage و گزینهٔ سادهتر تعیینکنندهاند. گاهی Contract test یا حذف Coupling ارزشمندتر از صدها UI test است؛ گاهی تست دستی هدفمند و Observability بهتر، انتخاب اقتصادیتری است.
بودجه QA دقیقاً شامل چه چیزی است؟
| Cost pool | نمونه | هزینهٔ پنهان |
|---|---|---|
| People/Capacity | QE، Test engineer، QA lead، Analyst | Onboarding، Review، مدیریت، Context switching، Backup |
| Shared engineering | Testability، Observability، Contract، feature flag | ظرفیت Developer/SRE/Product، نه فقط QA |
| Tools/Licenses | Test management، Device cloud، security scanner | Seat/usage growth، Integration، migration، support، Exit |
| Infrastructure | CI runner، محیط، DB، شبکه، دستگاه | Idle/peak، egress، storage، secrets، monitoring |
| Data | Synthetic data، masking، reset، dataset | Privacy، lineage، refresh، ownership، incident risk |
| Specialist evidence | Security، performance، accessibility، legal | Scope clarification، remediation، retest، coordination |
| Learning/Capability | آموزش، Pairing، Mentor، Community | زمان تمرین/انتقال، نه فقط هزینهٔ دوره |
| Operations/Maintenance | Flaky triage، upgrade، quarantine، support | Toil دائمی و Failure demand |
| Contingency/Option | Pilot، Vendor exit، دستگاه/PSP جایگزین | هزینهٔ حفظ انعطاف و ریسک باقیمانده |
مرز حسابداری را با Finance هماهنگ کنید؛ اما برای تصمیم، Total resource demand را ببینید. «ابزار رایگان» ممکن است بیشترین هزینه را در نگهداری مهندسی داشته باشد و «تستر موجود» ظرفیت آزاد برای Initiative جدید نداشته باشد.
مدل چهارسبدی برای Portfolio بودجه کیفیت
| سبد | هدف | نمونه | قاعدهٔ Funding |
|---|---|---|---|
| Run & Obligation | ادامهٔ خدمت و تعهد اجتنابناپذیر | Regression جاری، محیط، مجوز، کنترل قانونی | کف خدمت، SLA/تعهد، Capacity و Toil شفاف |
| Risk Reduction | کاهش Exposure/Impact/Unknown مهم | Payment resilience، security review، recovery test | بر اساس ریسک/شاهد/Residual risk، نه تعداد باگ |
| Enablement & Platform | کاهش اصطکاک و ساخت قابلیت تکرارشونده | Test data service، trusted CI lane، device lab | Internal-product outcome، adoption، TCO و J-curve |
| Discovery & Options | خرید اطلاعات و حفظ انعطاف | PoC ابزار، spike، benchmark، vendor-exit rehearsal | Time-box، learning question، cost cap و تصمیم بعدی |
سبد Run را پنهان نکنید و همهچیز را «تحول» ننامید. اگر ۴۰٪ ظرفیت صرف Flaky suite، دسترسی محیط و دادهٔ خراب است، Initiative جدید روی Capacity خیالی برنامهریزی میشود. در عین حال، بودجه را فقط به نگهداری ندهید؛ Discovery کوچک میتواند از Commit بزرگ اشتباه جلوگیری کند.
چرخه بودجهبندی: Demand → Capability → Options → Portfolio → Evidence
Business/Product outcomes & obligations → Quality risk / evidence demand → Current capability & capacity baseline → Gap / root constraint → BAU + Build/Buy/Borrow/Hire/Design-away options → Cost range / dependency / risk / benefit hypothesis → Portfolio constraints & sequencing → Discovery/Pilot/Scale funding gates → Outcome, cost, learning and residual-risk review → Continue | Change | Scale | Stop | Exit
گام اول: Demand map کیفیت را بسازید
تقاضای بودجه را از شش منبع استخراج کنید:
- Value stream/Journey: Checkout، تسویه، ثبتنام، گزارش بالینی یا هر Outcome حیاتی.
- Change portfolio: قابلیت، معماری، Migration، Vendor، قانون و کمپین آینده.
- Risk/obligation: ایمنی، امنیت، حریم خصوصی، دسترسپذیری، قرارداد و Audit.
- Failure demand: Incident تکراری، Rework، Ticket، Flaky triage، مغایرت و Escalation.
- Evidence gap: Unknownهای انتشار، نبود Observability، محیط/دادهٔ نامعتبر و Testability.
- Service demand: Intake سایر تیمها، Device/Performance/Security specialist و Platform support.
Demand Card ID / source / owner: Outcome or obligation: Affected journey/population: Risk: event × exposure × impact × recoverability Current evidence / unknown: Demand class: Run | Risk | Enablement | Discovery Decision/date supported: Service/capability required: If unfunded: residual risk / delay / manual burden Dependencies / constraints:
برای اولویتدادن به خطرها از تست مبتنی بر ریسک استفاده کنید؛ اما Risk score را پول فرض نکنید. Risk، هزینه، امکانپذیری، تعهد، زمان و Option value ورودیهای متفاوت Portfolio هستند.
گام دوم: Baseline قابلیت و ظرفیت واقعی را اندازه بگیرید
| قابلیت | Evidence فعلی | Gap نمونه | Dependency |
|---|---|---|---|
| Risk analysis | Risk map و review cadence | فقط Severity defect داریم | Product/Domain participation |
| Testability | Control/observe/reset/isolate | PSP fault قابل تزریق نیست | Architecture/Engineering |
| Test data | Synthetic/masked/resettable | DB کپی Production و stale | Privacy/Data/Platform |
| Feedback system | Trusted signal distribution | p95=۷۰ دقیقه، Flaky=۸٪ | CI compute، ownership |
| Specialist evidence | Security/performance/a11y access | یک متخصص و صف ۶ هفته | Procurement/capacity |
| Production learning | Trace/SLO/support/reconciliation | Release cohort قابل اتصال نیست | Telemetry identity/data |
Capacity را از تقویم افراد حدس نزنید:
gross capacity − leave/on-call/meetings − Run obligations − unplanned/failure demand − maintenance/toil − protected learning/support = realistic change capacity
اگر Specialist یا Platform گلوگاه است، افزودن Test case یا License خروجی نمیسازد. برای طراحی سرویس و ظرفیت بین تیمها، مدل عملیاتی QA مکمل این Baseline است.
گام سوم: Root constraint را قبل از راهحل پیدا کنید
درخواست «ابزار Automation» ممکن است در واقع یکی از این مسئلهها باشد:
- Release feedback دیر است چون Queue و Environment setup زمان میگیرد.
- تست ناپایدار است چون داده و Clock/Dependency کنترل نمیشوند.
- Regression زیاد است چون Architecture coupling و Contract مبهماند.
- Coverage کم است چون Risk/State/Data model تعریف نشده است.
- Manual effort بالاست چون محصول Testability hook ندارد.
- تیم ابزار را ندارد، یا دارد اما Owner/Skill/Adoption ندارد.
هر Initiative باید یک Constraint statement داشته باشد: «برای تصمیم X، Signal Y اکنون بهدلیل Z دیر/نامعتبر است؛ پیامد آن A است.» بدون این جمله، خرید راهحل از مسئله جلو زده است.
گام چهارم: گزینههای واقعی بسازید
| گزینه | چه زمانی محتمل است؟ | سؤال کلیدی |
|---|---|---|
| Business as usual | Gap کماهمیت یا موقت | هزینه/ریسک ادامهٔ وضع موجود چیست؟ |
| Stop/Remove | تقاضا یا Test کمارزش | آیا حذف، مسئله را ارزانتر حل میکند؟ |
| Design-away | ریسک از Coupling/پیچیدگی میآید | آیا معماری/UX میتواند خطر را حذف کند؟ |
| Build | نیاز متمایز، قابلیت داخلی و عمر کافی | TCO و Bus factor/maintenance چیست؟ |
| Buy | Commodity، Time-to-value و Vendor مناسب | Data residency، lock-in، usage cost و Exit؟ |
| Borrow/Share | نیاز دورهای و سرویس مشترک موجود | Queue، SLA، priority و failure demand؟ |
| Hire | Demand پایدار و Capability استراتژیک | زمان جذب/Onboarding و کار واقعی چیست؟ |
| Contract specialist | تخصص کمیاب/ممیزی مستقل/Peak | Scope، knowledge transfer و retest؟ |
| Train/Pair | Gap مهارت با بستر تمرین واقعی | Protected time و transfer evidence؟ |
| Pilot/Defer | عدمقطعیت بالا یا تصمیم برگشتپذیر | چه اطلاعاتی با چه سقف هزینه میخریم؟ |
NIST SSDF در دامنهٔ توسعهٔ امن، رویکرد Outcome/Risk-based دارد و میگوید هنگام انتخاب Practice علاوه بر ریسک، هزینه، امکانپذیری، کاربردپذیری، قابلیت Automation و وابستگی به Practiceهای پایه لحاظ شوند؛ نمونهها نیز Checklist اجباری نیستند. همین منطق برای Portfolio کیفیت قابل اقتباس است، نه اینکه SSDF چارچوب عمومی بودجه QA باشد.
گام پنجم: Initiative Card نسخهدار بنویسید
QA Investment Initiative v1 ID / sponsor / accountable owner: Demand / outcome / risk / obligation: Root constraint / evidence / baseline: Option: BAU | Stop | Design-away | Build | Buy | Borrow | Hire | Pilot Scope / non-scope / affected consumers: Capability/service delivered: Dependencies / prerequisite / scarce skills: Cost envelope: one-time + recurring + shared + contingency Time envelope / earliest value / ramp/J-curve: Benefit hypothesis / leading + outcome evidence: Counterfactual / attribution limits: Guardrails / harms / privacy/security/accessibility: Milestones: discovery → pilot → scale Stop / scale / rollback / exit rules: Residual risk if funded / unfunded: Review date / decision log:
نمونه: سرویس دادهٔ تست Checkout
Demand: تست timeout/callback/Reconciliation با دادهٔ فعلی قابل اعتماد نیست Root constraint: DB snapshot مشترک، PII و reset دستی 90 دقیقهای Option: Build thin self-service synthetic/reset layer; BAU retained for comparison Consumers: Checkout, Finance, Support integration tests Dependencies: identity schema, privacy approval, environment API Cost range: 18–26 person-weeks + infra 120–220m IRR/year + 20% contingency Benefit hypothesis: setup p95 90m→15m; invalid runs 12%→<3% Guardrails: zero production PII; access audit; platform toil <=10h/week Pilot: two journeys, 6 weeks, three teams Stop: adoption <2 teams or invalid runs not reduced after remediation window Scale: risk-evidence improves and TCO/team within agreed range Exit: export schemas/datasets; no proprietary-only format
TCO بودجه QA: هزینهٔ خرید فقط نوک کوه یخ است
TCO = acquisition/subscription
+ implementation/integration/migration
+ infrastructure/usage/data/egress
+ people/onboarding/training/review
+ operation/support/upgrade/maintenance/triage
+ security/privacy/compliance/procurement
+ downtime/failure-demand/opportunity cost
+ exit/export/replacement
+ contingency for residual uncertainty
| Cost timing | مثال | اشتباه رایج |
|---|---|---|
| One-time | Migration، setup، integration، device purchase | نادیدهگرفتن ظرفیت تیمهای دیگر |
| Recurring fixed | License، specialist retainer، support | فرض ثبات FX/renewal |
| Recurring variable | CI minutes، devices، storage، API usage | محاسبه بر مبنای Pilot کمحجم |
| Ramp/J-curve | افت اولیه بهدلیل آموزش و dual running | وعدهٔ Benefit فوری |
| Failure/Toil | Flaky triage، outage، manual workaround | خارجکردن از «قیمت ابزار» |
| Exit | Export، rewrite، data deletion، parallel run | فرض Vendor دائمی |
راهنمای DORA برای Platform engineering به الگوی J-curve اشاره میکند: سرمایهگذاری ممکن است ابتدا بهبود، سپس افت ناشی از پیچیدگی و بعد بلوغ ایجاد کند؛ اثر باید با Delivery، رضایت/DevEx، Adoption و Task success متوازن شود. Quality platform نیز محصول داخلی است، نه پروژهٔ ابزار با پایان نصب.
برآورد را به Range، Assumption و Sensitivity تبدیل کنید
| سناریو | Cost | Time-to-evidence | Assumption غالب |
|---|---|---|---|
| Low | Reuse بالا، Integration ساده | ۴ هفته | API/Skill آماده، Adoption سریع |
| Base | Integration و آموزش متوسط | ۶–۸ هفته | دو Dependency طبق برنامه |
| High | Migration/Access/FX سخت | ۱۲+ هفته | Vendor/Environment delay و Rework |
- Cost driverهای بزرگ را جدا کنید: نفر-هفته، Usage، Device، FX، Migration، داده و Specialist.
- Assumption register داشته باشید و منبع/تاریخ/Owner بنویسید.
- یک متغیر را تغییر دهید تا Sensitivity معلوم شود؛ چند متغیر همزمان برای Scenario/Risk range.
- Forecast error Initiativeهای مشابه را نگه دارید و Optimism bias محلی بسازید.
- Contingency را «بودجهٔ آزاد» ندانید؛ به ریسک باقیمانده و Release rule وصل کنید.
- Benefit غیرپولی مثل انطباق یا کاهش آسیب را حذف نکنید؛ آن را شفاف و جدا گزارش کنید.
راهنمای Cost Estimating and Assessment دفتر پاسخگویی دولت آمریکا (GAO) بر شناسایی Assumption و Cost driver، Sensitivity analysis، Range و Risk/uncertainty analysis تأکید دارد. این منبع برای برنامههای عمومی/سرمایهای نوشته شده؛ استفاده در بودجه QA اقتباس اصول برآورد است، نه الزام حسابداری یا نسخهٔ آماده.
گام ششم: Option appraisal شفاف انجام دهید
مقایسهٔ گزینه فقط «Benefit/Cost» نیست. یک Decision matrix کوچک میتواند این معیارها را با تعریف روشن نگه دارد:
| معیار | پرسش | Hard gate؟ |
|---|---|---|
| Outcome/Risk fit | کدام خطر/تعهد را با چه شاهدی پوشش میدهد؟ | برای Critical ممکن است |
| Feasibility/Dependency | Prerequisite، مهارت و Integration موجودند؟ | بله اگر غیرقابل تأمین |
| Affordability/Cash | داخل Cost envelope و زمانبندی پرداخت است؟ | بله |
| TCO/Exit | هزینهٔ عمر و خروج چیست؟ | برای lock-in حساس |
| Time-to-evidence | چه زمانی میفهمیم فرض درست است؟ | Context-dependent |
| Reversibility/Option | اگر غلط بود چه چیزی قابل بازگشت است؟ | برای High uncertainty مهم |
| Capacity/Toil | چه تیمی Build/Run/Support میکند؟ | بله اگر Owner ندارد |
| Distribution/harm | چه گروهی سود/زیان میبیند؟ | قانونی/ایمنی ممکن است |
راهنمای Green Book ۲۰۲۶ دولت بریتانیا بر Case for change، Business as usual، ساخت Longlist/Shortlist، مقایسهٔ Cost/Benefit/Risk، بیان عدمقطعیت، Optimism bias، Sensitivity و Monitoring/Evaluation تأکید میکند. این چارچوب برای خرج عمومی بریتانیاست؛ در این مقاله فقط منطق شفاف Option appraisal و یادگیری پس از تصمیم اقتباس شده است.
گام هفتم: Dependency graph و Sequence بسازید
Identity/Telemetry ─┬→ Metric/Data-quality
└→ Release cohort evidence
Environment API → Test data service → Trusted CI lane → Broader automation
└→ Performance/security scenarios
Role/Service owner → Adoption/support → Scale
Vendor PoC → Security/procurement → Contract → Migration → Exit rehearsal
Portfolio ممکن است از نظر مجموع هزینه «جا شود» اما از نظر Specialist، Change capacity یا Dependency شدنی نباشد. بودجهٔ همهٔ Initiativeها در Q1 به معنی امکان اجرای همزمان نیست. WIP، Critical path، earliest evidence و Rollback را وارد Roadmap کنید.
Constraintهای Portfolio را پیش از انتخاب ببندید
- سقف کل Cost و Cash/FX در هر دوره.
- کف Run/Obligation و تعهدهای غیرقابل مذاکره.
- حداکثر Change WIP و Protected capacity.
- ظرفیت Specialist، Security review، Procurement و Platform.
- Dependency و ترتیب Foundation→Consumer.
- حداقل پوشش Risk classهای حیاتی.
- حداکثر Concentration روی Vendor، Tool یا یک فرد.
- Contingency و Reserve برای Incident/Regulatory change.
- حداقل Discovery/Option budget برای Unknownهای پرپیامد.
- Guardrail حریم خصوصی، امنیت، دسترسپذیری و سلامت تیم.
Constraintها قضاوت Governance هستند و باید قبل از دیدن «برندهٔ موردعلاقه» تصویب شوند. تغییرشان مجاز است، اما با علت و Decision log—نه برای جا دادن پروژهٔ محبوب.
آزمایش قطعی: Benefit اسمی در برابر Portfolio محدود به Risk
برای نمایش خاصیت Constraint/Dependency، هفت Initiative ساختگی با بودجهٔ ۱۰۰ واحد در Node.js Enumerate شدند. RUN با هزینهٔ ۳۰ Mandatory بود. DATA هزینهٔ ۲۲ و پیشنیاز CI/AUTO بود؛ CI، SEC، AUTO، PERF و A11Y هزینه/منفعت اسمی و Risk class فرضی داشتند. ۲۱ Portfolio معتبر از نظر Budget/Dependency بررسی شد.
Runtime: Node.js 24.18.0 Budget: 100 arbitrary units Valid portfolios evaluated: 21 Nominal-benefit selection: RUN + DATA + AUTO + A11Y cost=100 | nominal benefit=134 risks: continuity, payment, privacy, regression, accessibility Scenario-governed selection: RUN + DATA + CI + SEC cost=96 | nominal benefit=123 | governed score=238 risks: continuity, payment, privacy, release, regression, security
چرا اجرای اول را تغییر دادیم؟
Rule نخست فقط به تعداد Risk classها Bonus یکسان میداد و انتخاب Nominal را عوض نکرد؛ پس برای این سناریو Decision-useful نبود. در اجرای ثبتشده، Risk weightهای ازپیشتعریفشدهٔ سناریو برای Security=۳۰، Payment=۲۵، Continuity/Privacy/Campaign=۲۰، Release=۱۵ و Regression/Accessibility=۵ استفاده شد. در نتیجه Portfolio با منفعت اسمی کمتر، Risk priority بیشتری پوشش داد. این تغییر خود نشان میدهد «مدل» بدون Risk appetite فقط ظاهر بیطرف دارد.
این آزمایش چه چیزی را ثابت نمیکند؟
Initiative، هزینه، Benefit، Risk class، وزن و Dependency همگی ساختگی و قطعیاند؛ Cost/benefit uncertainty، Capacity زمانی، Synergy منفی/مثبت، Benefit overlap، Cash flow، Human behavior، Opportunity cost واقعی و کیفیت Evidence مدل نشدهاند. Governed score نیز فرمول بودجهبندی عمومی نیست و ۲۳۸ واحد اقتصادی ندارد. خروجی فقط نشان میدهد با این ورودیها، اضافهکردن Mandatory work، Dependency و Risk priority میتواند انتخاب بیشترین Benefit اسمی را تغییر دهد. تصمیم واقعی به Option appraisal، Range، Finance و Authority انسانی نیاز دارد.
نمونه ایرانی: Portfolio بودجه کیفیت Marketplace
یک Marketplace فرضی برای فصل کمپین، Checkout، تسویه و بازپرداخت را توسعه میدهد. دو PSP، SMS provider، Mobile app و پنل فروشنده دارد. Amount قانونی در IRR ذخیره میشود و UI تومان نشان میدهد. callback دیررس/تکراری، timeout-after-commit، Reconciliation، ارقام فارسی/عربی/لاتین و UTC/Asia/Tehran/Jalali در Scope هستند.
Demand و Gap
- Run: Regression جاری، Deviceهای اصلی، مجوز ابزار، تست Reconciliation و On-call support.
- Risk: برداشت/سفارش تکراری، مغایرت IRR/تومان، نتیجهٔ نامعلوم و افشای Token در Log.
- Enablement: دادهٔ Synthetic/resettable، Identity مشترک و CI lane قابل اعتماد.
- Discovery: رفتار PSP هنگام اختلال منطقهای و PoC یک Device cloud قابل دسترس.
- Gap: ۱۲٪ Run نامعتبر بهدلیل Data، p95 Feedback برابر ۷۰ دقیقه، Specialist امنیت در صف ششهفتهای.
Cost envelope و واقعیت ایران
- IRR/تومان را در Cost model با واحد Canonical و Conversion rule صریح نگه دارید.
- تورم، FX، Renewal خارجی، تحریم/دسترسی، پرداخت بینالمللی و ریسک قطع Vendor را Scenario کنید.
- قیمت Cloud/CI را با Usage و Peak کمپین بسنجید، نه نرخ امروز × ۱۲.
- دستگاه واقعی، تعمیر/جایگزینی، سیمکارت/شبکه و Location را در TCO بیاورید.
- تعطیلات، نوروز، جمعه، Availability متخصص و Procurement داخلی بر Timeline اثر دارند.
- Data residency، PII، دسترسی به Production و الزامات قراردادی PSP را Hard gate کنید.
- Vendor خارجی باید Export، Local fallback، Credential ownership و Exit rehearsal داشته باشد.
Portfolio پیشنهادی و Sequence
| Initiative | سبد | مرحله | Evidence/Stop |
|---|---|---|---|
| Run obligation | Run | Fund floor | Service/Toil review ماهانه |
| Identity + Test data thin layer | Enablement | Discovery→Pilot | Invalid run ۱۲%→<۳%; توقف اگر Adoption/Privacy fail |
| Payment fault/Reconciliation evidence | Risk | پس از Foundation | Critical scenarios + production cohort |
| Security specialist review | Risk/Obligation | Scope ثابت، قبل Gate | Finding/remediation/retest؛ knowledge transfer |
| UI automation expansion | Enablement | Defer/limited Pilot | فقط پس از Data/Flaky guardrail |
| Device cloud PoC | Discovery option | Time-box ۳ هفته | Access/latency/device/TCO/exit hard gates |
تصمیم فرضی این است که بودجهٔ Automation وسیع کامل Commit نشود؛ Foundation و Payment/Security evidence ابتدا Pilot شوند، درحالیکه Automation روی دو Journey ثابت ادامه یابد. این حکم عمومی نیست؛ Sequence از Gap و Risk همین سناریو میآید.
Funding مرحلهای: Discovery، Pilot و Scale
| Gate | سؤال | Funding/Evidence | خروجی تصمیم |
|---|---|---|---|
| Discovery | مسئله/گزینه شدنی و ارزش بررسی دارد؟ | سقف کوچک؛ baseline، dependency، PoC question | Stop / Pilot / Redesign |
| Pilot | در Context محدود Outcome/Guardrail بهبود مییابد؟ | Consumer واقعی، TCO، adoption، comparison | Stop / Extend / Scale |
| Scale | قابلیت تکرارشونده و قابلعملیات است؟ | Owner، service level، support، security، exit | Fund service / Limit / Exit |
| Operate | هنوز ارزش، سلامت و تقاضا دارد؟ | Outcome، unit cost، toil، satisfaction، incidents | Continue / Optimize / Retire |
Scale rule example Scale only if: invalid_run_rate <= 3% AND setup_p95 <= 15m AND privacy_findings_critical == 0 AND support_toil = 2 consumer teams retain use after 4 weeks Stop/reshape if two review windows miss after agreed remediation.
Benefit realization بدون ادعای علیت
| لایه | نمونه Evidence | تفسیر مجاز |
|---|---|---|
| Input | Cost، capacity، license، training | چه مصرف شد؛ نه ارزش |
| Capability output | Self-service data، fault hook، trusted lane | قابلیت تحویل شد؛ نه Outcome مشتری |
| Adoption/task | تیم فعال، task success، time-to-first-use | مصرف/کارایی سرویس |
| Leading/flow | setup p95، feedback p95، invalid run | مکانیسم فرضی بهتر/بدتر |
| Risk/evidence | critical unknown، risk evidence sufficiency | کفایت شاهد برای تصمیم |
| Outcome | unresolved payment، duplicate charge، rework | همزمانی؛ Attribution نیازمند طراحی |
| Economic | TCO، avoided loss range، payback | Scenario با عدمقطعیت، نه واقعیت قطعی |
برای ساخت KPIهای Decision-specific و ضدبازی از راهنمای KPI تضمین کیفیت استفاده کنید. Benefit owner باید در Product/Engineering/Operations نامدار باشد؛ QA بهتنهایی Conversion، Churn یا Revenue را کنترل نمیکند.
Portfolio review: بودجه را سالی یکبار منجمد نکنید
Monthly/quarterly investment review 1. Cost actual vs range؛ علت variance؟ 2. Dependency/capacity/FX/Vendor چه تغییر کرد؟ 3. Evidence/unknown/guardrail چیست؟ 4. Adoption, task success, toil and risk outcome؟ 5. Benefit overlap یا double count؟ 6. BAU/option landscape هنوز معتبر است؟ 7. Continue | Change | Defer | Scale | Stop | Exit؟ 8. چه بودجه/ظرفیتی آزاد یا منتقل میشود؟
- Rebalance: Risk یا Constraint تغییر کرده و Initiative دیگری Marginal value بیشتری دارد.
- Pause: Dependency آماده نیست؛ بودجه نگهداری نمیشود مگر Option value روشن باشد.
- Stop: فرض رد شده، Guardrail آسیب دیده یا TCO از Switching value عبور کرده است.
- Scale: Outcome/Adoption/Operations در Context Pilot تکرارپذیر و Owner آماده است.
- Retire: سرویس تقاضا/ارزش ندارد یا راه سادهتر جایگزین شده است.
برای اجرای آزمایشهای بهبود و تصمیم Keep/Standardize/Rollback، بهبود مستمر QA مکمل این Review است.
RACI کافی نیست: اختیار مالی و Risk را نامدار کنید
| نقش | مسئولیت | مرز |
|---|---|---|
| Executive/Product sponsor | Outcome، Risk appetite، Priority | Evidence فنی را یکطرفه معتبر نمیکند |
| Finance | Cost model، affordability، scenario، actual | Risk/quality Target را تنها تعیین نمیکند |
| QA/QE | Demand/Risk/Evidence، Option و limitation | درآمد یا Avoided loss را تضمین نمیکند |
| Engineering/SRE/Platform | Feasibility، dependency، Run/TCO/owner | نیاز کاربر را فقط با Tool metric جایگزین نمیکند |
| Security/Privacy/Legal | Hard gate و تعهد تخصصی | کل Portfolio را خارج دامنهٔ خود مالک نیست |
| Procurement/Vendor owner | Contract، data، SLA، renewal، Exit | PoC فنی را موفقیت اقتصادی فرض نمیکند |
| Investment/Risk owner | Fund/Defer/Stop/Scale و residual risk | Unknown را Pass بازنویسی نمیکند |
ضدالگوهای بودجه QA
- Fixed percentage: سهم ثابت جای Demand/Risk/Capability را میگیرد.
- Cost-center shame: هر هزینه باید درآمد مستقیم نشان دهد؛ Obligation/Option/Resilience حذف میشود.
- QA hero budget: بودجهٔ Quality فقط در واحد QA میماند و Engineering Testability بیمالک است.
- Tool shopping: Feature list پیش از Root constraint و Consumer.
- License-only TCO: Integration، data، run، support و Exit صفر فرض میشوند.
- People as fungible: نفر-ماه بدون Skill/Context/Onboarding/Bus factor.
- Automation quota: درصد خودکارسازی Target سرمایهگذاری است.
- Big-bang platform: همهٔ بودجه پیش از Pilot/Adoption Commit میشود.
- Foundation starvation: Consumer initiative بدون داده/محیط/Identity تأمین میشود.
- Dependency blindness: Portfolio روی کاغذ جا میشود ولی Specialist/Procurement ندارد.
- Point-estimate theater: Cost/benefit دقیق بدون Range و Assumption.
- Sunk-cost escalation: چون زیاد خرج شده، Initiative زیانبار ادامه مییابد.
- Benefit double count: کاهش Rework، Support و Incident همپوشان سهبار جمع میشوند.
- Avoided defect fantasy: هر باگ یافتهشده حتماً به Production و خسارت تخمینی میرسید.
- ROI certainty: Low/Base/High و Attribution حذف میشوند.
- No BAU: وضع موجود و Design-away از مقایسه حذف میشوند.
- No exit: Vendor/Tool دائمی فرض میشود.
- Contingency slush: Reserve بدون Risk trigger مصرف میشود.
- Spend equals progress: مصرف بودجه، Capability/Outcome نام میگیرد.
- Annual freeze: Portfolio با تغییر Risk/FX/Dependency بازتنظیم نمیشود.
برنامهٔ ۳۰روزه ساخت Portfolio بودجه QA
هفته اول: Cost و Demand baseline
- Cost pool و مرز Finance را تعریف کنید.
- Run/Toil/Failure demand و Change capacity را اندازه بگیرید.
- Journey/Change/Risk/Obligation/Evidence demand را Inventory کنید.
- یک Value stream را برای Pilot انتخاب کنید.
هفته دوم: Capability و Options
- Capability gap و Root constraint را با Evidence ببندید.
- BAU، Stop، Design-away، Build/Buy/Borrow/Hire/Pilot را Longlist کنید.
- Hard gate و Dependency/skill/owner را بررسی کنید.
- Initiative card و Cost envelope اولیه بسازید.
هفته سوم: Range و Portfolio
- Low/Base/High، Assumption، FX و Contingency را کامل کنید.
- Risk priority و Portfolio constraint را پیش از انتخاب تصویب کنید.
- Dependency graph، Sequence و realistic capacity بسازید.
- Discovery/Pilot/Scale funding و Stop rule را تعیین کنید.
هفته چهارم: Decision و Shadow review
- Decision packet را با Finance/Product/Engineering/Risk review کنید.
- یک Initiative را در Shadow یا Discovery با سقف هزینه اجرا کنید.
- Cost actual، Evidence، Unknown و رفتار ناخواسته را مقایسه کنید.
- Fund/Defer/Stop و Review cadence را ثبت کنید.
چکلیست دفاع از بودجه QA
- Outcome، Obligation و Risk appetite روشناند؟
- Demand Card و Decision/date داریم؟
- Run، Risk، Enablement و Discovery جدا هستند؟
- Baseline قابلیت، ظرفیت، Toil و Failure demand واقعی است؟
- Root constraint با Evidence مشخص است؟
- BAU، Stop و Design-away کنار خرید/استخدام بررسی شدهاند؟
- Initiative صاحب Outcome/Run و Non-scope دارد؟
- Dependency، prerequisite و مهارت کمیاب معلوماند؟
- TCO شامل People/Data/Infra/Run/Exit است؟
- Cost و Benefit به Range/Assumption/Scenario تبدیل شدهاند؟
- FX، inflation، Vendor access و Contingency دیده شدهاند؟
- Benefit overlap و Attribution limit ثبت شدهاند؟
- Portfolio سقف بودجه و کف Obligation دارد؟
- Capacity/WIP و Sequence از نظر زمانی شدنیاند؟
- Risk concentration و Vendor/Bus factor کنترل شدهاند؟
- Discovery/Pilot/Scale Gate و Cost cap داریم؟
- Stop/rollback/exit rule پیش از شروع نوشته شده است؟
- Evidence/Countermetric/Guardrail و Data quality معلوماند؟
- Authority Fund/Residual risk و Dissent نامدارند؟
- Review/Rebalance/Retire cadence وجود دارد؟
پرسشهای متداول
۱. بودجه QA چند درصد از بودجه توسعه باشد؟
عدد جهانی معتبری وجود ندارد. مرز هزینه، Risk، صنعت، تعهد، معماری، مرحله محصول، Capability و اینکه Security/SRE/Data/Environment داخل کدام Cost center هستند فرق میکند. از Demand و Cost envelope بسازید؛ درصد را فقط برای مقایسهٔ تاریخیِ تعریف ثابت و طرح سؤال استفاده کنید، نه سهمیه.
۲. اول نفر استخدام کنیم یا ابزار بخریم؟
ابتدا Root constraint را پیدا کنید. اگر مشکل مالکیت/مهارت پایدار است، Hire/Train ممکن است؛ اگر Commodity و Time-to-value مهم است، Buy؛ اگر نیاز دورهای است، Borrow/Contract؛ اگر ریشه معماری/داده است، ابزار بهتنهایی شکست میخورد. BAU، Design-away، TCO، Dependency و Pilot را مقایسه کنید.
۳. چگونه ارزش بودجه QA را به مدیر مالی نشان دهیم؟
با فهرست باگ یا شعار کیفیت نه؛ Case for change، BAU، گزینهها، Cost range، Risk/obligation، Benefit hypothesis، عدمقطعیت، Affordability و Stop/Scale بسازید. Capability output را از Outcome و Benefit اقتصادی جدا کنید و از ادعای علیت/هزینهٔ اجتنابشدهٔ قطعی بدون طرح مقایسه پرهیز کنید.
۴. آیا اتوماسیون همیشه اولویت بودجه است؟
خیر. اگر Risk، Oracle، Testability، داده، محیط و Feedback pipeline آماده نیستند، اتوماسیون وسیع Toil تولید میکند. Journey تکرارشونده و پایدار، اجرای کافی، هزینه دستی، Detection value و نگهداری را بسنجید؛ گاهی Contract test، Observability، Synthetic data یا طراحی سادهتر Marginal value بیشتری دارد.
۵. بودجه QA را هر چند وقت بازبینی کنیم؟
Cost actual و Run/Guardrail ماهانه، Portfolio و Dependency معمولاً فصلی، و هنگام تغییر Risk، قانون، Vendor، FX، Architecture یا Strategy فوراً. Initiativeهای Discovery/Pilot در Milestoneهای کوتاهتر Gate میشوند. بودجه سالانه سقف Governance است، نه دلیل منجمدکردن انتخابهای اشتباه.
جمعبندی: بودجه کیفیت، Portfolio یادگیری و کاهش ریسک است
بودجه QA وقتی قابل دفاع میشود که از درصد و فهرست خرید عبور کند: Demand و Obligation روشن، Capability/Capacity واقعی، Root constraint، گزینههای متنوع، TCO و Range، Dependency و Constraint، Funding مرحلهای و Evidence برای Stop/Scale. کیفیت «هزینه نیست» نیز بهاندازهٔ «فقط هزینه است» سادهسازی است؛ برخی خرجها Obligation، برخی کاهش ریسک، برخی Platform و برخی خرید Option/اطلاعاتاند.
از یک Value stream، چهار Cost pool و سه Initiative شروع کنید. اگر بتوانید صریح بگویید «با تأمین/عدم تأمین هر گزینه چه Outcome، Risk، Unknown، Cost و انعطافی تغییر میکند و در چه Milestone دوباره تصمیم میگیریم»، مذاکرهٔ بودجه از دفاع از واحد QA به تخصیص مسئولانهٔ سرمایهٔ محصول تبدیل شده است.
