یک استارتاپ در ماه ۲۴ بار Deploy کرده، Change lead time را به پنج ساعت رسانده و هیچ باگ Critical ثبت نکرده است. مدیرعامل میگوید «تعادل سرعت و کیفیت عالی است». اما معلوم نیست تغییرها چه Outcomeی را آزمودهاند، چه Harmهایی اصلاً پایش شده، چند کاربر در معرض بودهاند، نبودِ باگ نتیجهٔ کیفیت است یا کمگزارشی، Rollback واقعاً کار میکند یا چه بدهیای پشت Waiverها جمع شده است.
این راهنما یک Startup Speed–Quality Decision Loop میسازد: Outcome Bet → Change Class → Harm Floor → Quality Envelope → Evidence Minimum → Small Batch → Rollout/Rollback → Outcome & Guardrails → Debt/Exception → Continue/Adapt/Stop/Repay. هدف یافتن یک نقطهٔ جادویی میان «سریع» و «باکیفیت» نیست؛ هدف تصمیمی محدود، قابلبازگشت و قابلاصلاح زیر ظرفیت واقعی استارتاپ است.
پاسخ کوتاه: سرعت و کیفیت در استارتاپ چگونه متعادل میشوند؟
ابتدا بگویید کدام Outcome یا عدمقطعیت باید تا چه تاریخی روشن شود. سپس Harmهای غیرقابلمعامله، کیفیت لازم برای همان Change، دامنهٔ Exposure، Evidence پیش از Rollout، قابلیت بازگشت و معیار توقف را تعیین کنید. Change کوچک را به گروه محدود بدهید، Outcome و Guardrail را با مخرج و پنجرهٔ ثابت بخوانید و دربارهٔ ادامه، گسترش، اصلاح، توقف یا بازپرداخت بدهی تصمیم بگیرید. سرعت یعنی کوتاهشدن زمان تا Evidence قابلتصمیم، نه صرفاً افزایش Ticket یا Deploy.
- Outcome Bet: تغییر برای چه گروهی، از چه سازوکاری، چه اثر قابلسنجشی را دنبال میکند.
- Harm Floor: مرزهایی که صرفهجویی زمان مجوز عبور از آنها نیست.
- Quality Envelope: ویژگیهای لازم و حدشان برای همین Scope و مرحله.
- Evidence Minimum: کمترین بستهٔ شواهدی که تصمیم بعدی را پشتیبانی میکند، نه کمترین Test count.
- Reversibility: توان توقف، محدودکردن Exposure و بازگرداندن State با زمان و مالک مشخص.
- Debt/Exception: Gap آگاهانه با Risk، مالک، موعد، Trigger بازپرداخت و Expiry.
مسئله «سرعت در برابر کیفیت» نیست
سرعت و کیفیت دو سر یک خط واحد نیستند. Change بزرگ و دیرآزمون میتواند هم کند و هم پرخطر باشد؛ Batch کوچک، Test feedback سریع و Rollout محدود میتواند تحویل را هم سریعتر و هم کمریسکتر کند. در مقابل، افزایش Deployment frequency بدون Outcome یا Guardrail فقط جابهجایی سریعتر Change است. تصمیم باید چندبعدی باشد، نه انتخاب شعار «کیفیت اول» یا «سرعت اول».
سه نوع سرعت را جدا اندازه بگیرید
| نوع سرعت | شروع و پایان | چیزی که ثابت نمیکند |
|---|---|---|
| Build speed | شروع کار تا Artifact قابل اجرا | ارزش یا آمادگی انتشار |
| Delivery speed | Commit تا استقرار موفق در دامنهٔ تعریفشده | Outcome کاربر یا کیفیت کل |
| Learning speed | فرض تصمیم تا Evidence معتبر و Decision receipt | درستی قطعی فرضیه |
| Recovery speed | تشخیص impairment تا بازیابی معیار خدمت | نبود Harm باقیمانده |
ممکن است Delivery سریع شود اما Learning کند بماند، چون Instrumentation دیر داده میدهد یا Decision owner در دسترس نیست. ممکن است Deploy کم باشد اما تیم با Prototype کمخطر سریع یاد بگیرد. Metric را با سؤال تصمیم همراستا کنید.
کیفیت یک امتیاز واحد نیست
کیفیت برای Checkout مالی میتواند شامل درستی مبلغ، Idempotency، محرمانگی، دسترسپذیری، قابلیت بازیابی و فهمپذیری باشد؛ برای صفحهٔ آزمایشی محتوا ممکن است مجموعهٔ دیگری لازم باشد. Pass rate، Coverage یا صفر Critical جای این Claimها را نمیگیرد. برای هر Change، Quality attribute، subject، condition، measure، threshold، evidence و validity window را بنویسید.
مرحلهٔ استارتاپ Context است، نه مجوز کیفیت پایین
| مرحله | عدمقطعیت غالب | واحد یادگیری مناسب | چیزی که حذف نمیشود |
|---|---|---|---|
| Discovery | مسئله/گروه/نیاز | مصاحبه، Prototype یا Concierge محدود | رضایت، حریم خصوصی و منع آسیب |
| MVP | ارزش و استفادهٔ واقعی | Slice قابلاستفاده با Exposure محدود | درستی Claimهای حیاتی و Recovery |
| Early growth | تکرارپذیری و ظرفیت | Cohort/rollout مرحلهای | Isolation، Observability و support path |
| Scale | تابآوری و هزینهٔ تغییر | Platform/control experiment | SLO، dependency و rollback discipline |
| حوزهٔ پرپیامد | ایمنی/حقوق/پول/داده | آزمایش تخصصی و کنترلشده | الزام قابلاعمال و اختیار متخصص |
جدول نسخهٔ عمومی Policy نیست. Domain، قرارداد، تعهد قانونی، نوع داده و گروه آسیبپذیر میتواند آستانه را تغییر دهد؛ برای امور حقوقی، ایمنی، امنیت یا مالی از صاحبصلاحیت همان حوزه استفاده کنید.
MVP یعنی کوچکترین آزمون ارزش، نه محصول کمکیفیت
ویژگی کمتر، مسیر کوتاهتر یا عملیات دستی پشت صحنه میتواند Scope را کم کند؛ اما نمایش مبلغ غلط، از دستدادن داده، رضایت مبهم یا نبود راه برگشت «حداقل» نیست. MVP باید Claim محدود و مرز استفادهٔ روشن داشته باشد. اگر سؤال با Prototype یا Fake-door اخلاقی و شفاف پاسخ میگیرد، ساخت سامانهٔ کامل اتلاف ظرفیت است؛ اگر اقدام برگشتناپذیر است، Prototype سطح Evidence لازم را تأمین نمیکند.
Harm Floor را پیش از فشار Deadline تعیین کنید
Harm floor فهرست ریسکهایی است که تیم نمیتواند صرفاً برای سرعت Waive کند یا فقط با KPI تجاری جبرانشده بداند. نمونهها میتوانند افشای داده، انتقال پول نادرست، حذف برگشتناپذیر، دورزدن کنترل دسترسی، فریب کاربر، آسیب ایمنی یا نقض الزام قابلاعمال باشند. دامنه و Authority هر مورد باید در Policy محلی تصویب شود؛ این مقاله فهرست حقوقی جهانی ارائه نمیکند.
harm_floor_id: HF-CHECKOUT-IRR-v3
scope: checkout-price-preview
valid_from: 2026-08-01
floors:
- claim: charged_amount == confirmed_amount
disposition_if_unmet: BLOCK
- claim: no real charge in experiment cohort
disposition_if_unmet: BLOCK
- claim: deletion requires explicit confirmation and recovery path
disposition_if_unmet: BLOCK
exceptions: none_for_this_scope
policy_owner_role: product-risk-owner
specialist_review: [security, privacy, finance-domain]
Quality Envelope را برای هر Bet بسازید
| Attribute/Claim | Scope | Threshold | Evidence | Validity |
|---|---|---|---|---|
| Correctness | IRR total برای rule-set v18 | exact reconciliation | property + example matrix | Build b391 |
| Reliability | price-preview endpoint | SLI/SLO مصوب | telemetry با مخرج eligible | rollout window |
| Recoverability | flag و cache state | rollback ≤ ۱۰ دقیقه | rehearsal trace | ۳۰ روز |
| Usability | نمایش IRR/تومان | task-specific criterion | مطالعهٔ محدود | UI revision 6 |
| Security/privacy | cohort assignment/logging | policy-specific | specialist review | config + vendor version |
Envelope تعهد «محصول باکیفیت» نیست؛ مجموعهای از Claimهای لازم برای یک تصمیم و Scope است. NFR و Measurement contract را میتوانید در راهنمای تست غیرعملکردی عمیقتر طراحی کنید.
Outcome Bet را نسخهدار کنید
bet_id: BET-IRR-042 decision: expand | adapt | stop population: SEG-RETURNING-BUYER problem_evidence: EVID-PREVIEW-CONFUSION-v2 change: show canonical IRR and explicitly labelled toman mechanism_hypothesis: reduce unit ambiguity before confirmation primary_outcome: valid_confirmation_without_unit_correction guardrails: [incorrect_amount, abandonment, support_contact, latency] not_claimed: [revenue, loyalty, market_fit, causality_without_comparison] decision_due: 2026-09-01 owner_role: product-owner risk_owner_role: checkout-risk-owner
«ویژگی را سریع عرضه کنیم» Bet نیست. باید گروه، مسئله، Change، Mechanism، Outcome، Guardrail و چیزهایی که ادعا نمیشوند معلوم باشد. تصمیم نهایی میتواند فقط «آزمایش بعدی» باشد، نه Scale یا موفقیت محصول.
Change را بر اساس Risk و Reversibility طبقهبندی کنید
| بعد | پرسش | اثر بر Evidence |
|---|---|---|
| Impact | بدترین پیامد معتبر چیست؟ | شدت بیشتر، بررسی تخصصیتر |
| Exposure | چه تعداد/گروه/داده و چه مدت؟ | دامنهٔ بیشتر، rollout محافظهکارتر |
| Detectability | پیش از Harm با چه signalی میفهمیم؟ | Detection ضعیف، پیشتست/مهار بیشتر |
| Reversibility | کد و State در چه زمانی برمیگردد؟ | برگشتناپذیر، آستانهٔ Evidence بالاتر |
| Novelty | کدام dependency/behavior ناشناخته است؟ | Probe و Observation window |
| Coupling | Failure به کجا منتشر میشود؟ | Contract/integration/recovery evidence |
ضرب چند امتیاز دلخواه، Risk را دقیق نمیکند. Profile و Unknownها را حفظ کنید؛ یک Harm شدید را میانگین نگیرید و با Deployment frequency جبران نکنید.
Reversible بودن را اثبات کنید
Feature flag بهتنهایی Reversibility نیست. باید Code path قدیم هنوز سازگار، State migration قابلبازگشت یا forward-fix، cache قابل پاکسازی، event schema سازگار، flag دارای مالک و دسترسی، و rollback rehearsal دارای Evidence باشد. زمان بازیابی را از تشخیص تا بازگشت SLI بسنجید، نه فقط زمان اجرای دستور.
Evidence Minimum را از Change Class مشتق کنید
| کلاس نمونه | Evidence پیش از Exposure | کنترل هنگام Exposure | پس از Exposure |
|---|---|---|---|
| متن/ظاهر برگشتپذیر | review، render/accessibility smoke | flag یا انتشار محدود | error/feedback guardrail |
| منطق محاسبه | contract/property/boundary/reconciliation | shadow یا cohort + invariant | ledger/aggregate reconciliation |
| schema/state change | compatibility، migration rehearsal، backup test | dual-read/write یا staged cutover | consistency و recovery check |
| auth/privacy/security | threat/claim review و specialist evidence | least exposure + alert/kill | access/anomaly review |
| dependency جدید | contract/fault/timeout/retry/circuit behavior | traffic cap و fallback | latency/error/cost drift |
اینها الگو هستند، نه Minimum جهانی. Test mix را بر سؤال، Fidelity، هزینه و Risk تنظیم کنید؛ نسبت جادویی Unit/Integration/E2E وجود ندارد. هرم تست در عمل طراحی سبد Evidence را پوشش میدهد.
Batch کوچک، Risk را حذف نمیکند اما قابلمدیریتتر میکند
تغییر کوچکتر فهم، Review، Test، Rollback و Attribution را آسانتر میکند؛ به شرطی که Slice مستقل و قابلمشاهده باشد. خردکردن مصنوعی یک تغییر اتمیک یا پنهانکردن dependency میتواند Risk را بیشتر کند. Batch را بر واحد Outcome/State/rollback ببرید، نه بر تعداد Story point.
WIP و Queue، دشمن پنهان سرعت یادگیریاند
اگر ده Bet همزمان باز باشد، Context switching، انتظار Review، محیط، داده و تصمیم زیاد میشود. Lead time را به Process time و Queue time بشکنید. محدودکردن WIP ممکن است Utilization ظاهری را کم کند اما زمان تا Evidence را کوتاه کند. Idle محلی همیشه اتلاف نیست؛ ظرفیت Slack برای Review، Incident و بازپرداخت بدهی لازم است.
Automation یک Option است، نه پاسخ پیشفرض
Check پرتکرار، پایدار و دارای Oracle میتواند Feedback را سریع کند؛ Check کمارزش یا Flaky، Queue و نگهداشت میسازد. هزینهٔ طراحی، اجرا، Triage، داده، محیط، تعمیر و Retirement را بسنجید. برای چرخهٔ کامل، راهنمای چرخهٔ Evidence اتوماسیون را ببینید.
Error Budget کجا مفید است؟
فصل رسمی Google SRE دربارهٔ پذیرش Risk توضیح میدهد که هدف Reliability صددرصدی عموماً هزینه و Opportunity cost دارد و Error budget از SLO برای همراستاکردن سرعت Change و تحمل عدمقابلیتاعتماد استفاده میکند. اگر SLI، SLO، Window، data quality و policy ندارید، عدد «بودجه» فقط استعاره است.
error_budget = 1 - SLO_target budget_consumed = bad_events / eligible_events remaining = allowed_bad_events - observed_bad_events Required: SLI semantics + eligible denominator SLO target + window exclusions and late-data policy burn thresholds allowed actions and authority reset/carry-over rule
این فرمول نمونه برای Reliability است. «Bad event» باید دقیق تعریف شود و دادهٔ تأخیردار اصلاح شود. باقیبودن Error budget بهتنهایی مجوز Release، پذیرش Privacy/Security harm یا اثبات ارزش محصول نیست.
Error Budget را به بودجهٔ همهٔ کیفیتها تبدیل نکنید
قابلیت دسترسپذیری میتواند در Window مشخص Budget داشته باشد؛ افشای داده یا مبلغ نادرست را نمیتوان صرفاً با چند دقیقه uptime بیشتر «جبران» کرد. برای هر Quality attribute semantics مستقل لازم است. Harm floor قبل از Budget اعمال میشود و Risk acceptance به Authority تعیینشده نیاز دارد.
Policy واکنش به Burn را پیشاپیش بنویسید
| وضعیت نمونه | اقدام مجاز | استثنا |
|---|---|---|
| Budget سالم + Guardrail سالم | Rollout طبق Plan | Harm floor همچنان مقدم است |
| Burn سریع | Pause، reduce exposure یا rollback | رفع علت impairment طبق Authority |
| Budget تمامشده | کاهش Change risk و تمرکز Reliability | Security/emergency fix با plan جدا |
| SLI نامعتبر/داده دیر | HOLD یا تصمیم محافظهکارانه | Waiver زماندار با Unknown روشن |
| Outcome بیاثر و Guardrail سالم | STOP/ADAPT؛ نه Scale خودکار | Window ناکافی با دلیل تمدید شود |
این جدول Policy پیشنهادی است، نه نسخهٔ Google. تیم باید Threshold، اختیار و Exception خود را تصویب کند. صفحهٔ بهترینروشهای سرویس Google SRE نمونهٔ توقف Change هنگام مصرف Budget را شرح میدهد، اما سازمان شما باید آن را با Context خود Tailor کند.
DORA چه چیزی را میسنجد؟
راهنمای رسمی و بهروز سنجههای عملکرد تحویل نرمافزار DORA پنج Metric را در دو خانواده میآورد: Throughput شامل Change lead time، Deployment frequency و Failed deployment recovery time؛ Instability شامل Change fail rate و Deployment rework rate. DORA نیز هشدار میدهد Context سرویسها را مخلوط نکنید، یک Metric را هدف مطلق نسازید و از چند سنجهٔ دارای تنش سالم استفاده کنید.
DORA Metric برابر Product Quality نیست
این پنج سنجه عملکرد فرایند تحویل را توصیف میکنند. Deployment سریع نمیگوید تیم مسئلهٔ درست را حل کرده؛ Change fail rate پایین، Harm کشفنشده یا Defect پیش از Deploy را نفی نمیکند؛ Recovery سریع خسارت برگشتناپذیر را پاک نمیکند. Outcome، Harm، SLO، Debt و Evidence quality را جدا کنار آنها بگذارید.
Metric Contract بنویسید
metric_id: CHANGE-LEAD-CHECKOUT-v2 question: is commit-to-successful-production delivery getting shorter? start_event: first_commit_on_change end_event: successful_production_deploy unit: change population: checkout changes merged to main window: rolling_28d statistic: median_and_p85 excluded: [revert_only, test_fixture_only] late_event_policy: recompute_7d source: git_and_deploy_events_v4 owner_role: delivery-analytics-owner not_claimed: [customer_value, product_quality, developer_productivity]
بدون شروع/پایان، Population، percentile، exclusion و source، «Lead time پنج ساعت» قابل مقایسه نیست. Average میتواند Tail را پنهان کند؛ Median و percentile هم بدون توزیع و Sample count کافی نیستند.
سرعت یادگیری را با Outcome Evidence بسنجید
| Metric | مخرج/قرارداد | Countermetric |
|---|---|---|
| Time to decision evidence | Bet approved تا Evidence window complete | نرخ Decision با دادهٔ ناکافی |
| Valid learning rate | Decisionهای reviewed / Betهای سررسیدشده | Outcome تکرارنشدنی یا Correction rate |
| Exposure efficiency | Evidence کافی / کاربر-زمان در معرض | Harm و sample bias |
| Stop discipline | Bet بیاثر متوقف / Bet بیاثر | توقف زودهنگام false-negative |
| Debt repayment | Gap verified-closed / Gap سررسیدشده | Feature delay و replacement debt |
تعداد Experiment یا Decision را KPI پاداش ندهید؛ تیم میتواند Bet را خرد یا Evidence ضعیف را «یادگیری» اعلام کند. Outcome quality و Correction را کنار Throughput نگه دارید.
Guardrail را پیش از دیدن نتیجه ثابت کنید
Guardrail باید تعریف، Population، Window، Threshold، data delay، stop action و owner داشته باشد. اگر Primary outcome بهتر شد اما مبلغ نادرست، latency، شکایت پشتیبانی یا نرخ برگشت بالا رفت، تصمیم Scale خودکار نیست. تغییر پس از دیدن داده باید بهعنوان تحلیل اکتشافی ثبت و در دور تازه تأیید شود.
Rollout Contract را قابل اجرا کنید
rollout_id: RO-BET-IRR-042 artifact: b391 config: price-unit-v6 cohort_rule: stable_hash(account_synthetic_id) % 100 < 5 initial_exposure: 5_percent excluded: [high_risk_accounts, unsupported_locale] observation_window: 24h promotion_requires: - harm_floor == pass - guardrails == within_threshold - primary_measure_data_quality == valid stop: - incorrect_amount > 0 - p95_latency > threshold_for_10m rollback_owner_role: oncall-release-owner rollback_evidence: rehearsal/ro-042/v1 max_rollback_time: 10m
Cohort باید Stable و قابل توضیح باشد؛ Exposure واقعی را از assignment جدا کنید. Exclusion میتواند Bias بسازد و باید در Claim نتیجه دیده شود. Rollout محدود Evidence همان Population است، نه مجوز تعمیم به همه.
Observation و Rollback بخشی از کیفیتاند
اگر تیم پس از Deploy نمیتواند بفهمد کدام Build/Config/Cohort چه رفتاری دارد، سریعبودن Pipeline سود محدودی دارد. Telemetry باید subject، denominator، timestamp، traceability و data quality داشته باشد. Alert بدون Action یا On-call بدون Authority یک کنترل کامل نیست.
Technical Debt را از Defect و Risk جدا کنید
Technical debt انتخابی است که امروز زمان میخرد و هزینه یا محدودیت آینده میسازد؛ هر کد بد، Defect یا Requirement تغییرکرده بدهی نیست. Debt باید principal، interest mechanism، affected change paths و repayment option داشته باشد. Harm فعال را صرفاً «بدهی» ننامید تا عادی نشود.
Debt/Exception Register بسازید
| فیلد | نمونه | چرا لازم است |
|---|---|---|
| Gap/decision | integration matrix فقط ۱۲/۲۴ rule pair | دانستن چیزی که عمداً ناقص است |
| Benefit now | آزمون cohort یک هفته زودتر | قابل نقد بودن trade-off |
| Interest mechanism | هر Rule جدید نیازمند manual pair review | مشاهدهٔ هزینهٔ آینده |
| Risk/exposure | فقط preview؛ charge غیرفعال | جلوگیری از تعمیم |
| Owner/authority | pricing owner / risk owner | پاسخگویی و پذیرش |
| Due/trigger/expiry | پیش از charge enable یا ۱۴ روز | جلوگیری از Waiver دائمی |
| Repayment evidence | ۲۴ pair + fault witness | Closure واقعی |
Debt Budget پول واقعی نیست
میتوانید WIP یا ظرفیت محدود برای Debt تعریف کنید، اما جمعکردن Severityهای ناهمگون در یک عدد توهم قابلیت مبادله میسازد. Aging، interest signal، blocked change و Harm exposure را جدا ببینید. Debt سقفخورده باید Trigger توقف Bet جدید یا تخصیص ظرفیت داشته باشد.
ظرفیت را میان Feature، Reliability، Debt و Learning شفاف کنید
درصد ثابت جهانی وجود ندارد. Demand، Incident load، SLO burn، debt aging، runway و Betهای استراتژیک را در Portfolio review بیاورید. بودجهبندی Portfolio سرمایهگذاری کیفیت مالک انتخاب Build/Buy/Pilot و TCO است؛ این مقاله فقط قرارداد تصمیم روزمرهٔ سرعت–Risk را میسازد.
Opportunity Cost را Rangeدار گزارش کنید
«دو هفته تأخیر برابر از دستدادن بازار است» معمولاً ادعای قطعی نیست. گزینهها را با Time-to-evidence، ظرفیت نفر-روز، dependency، window فرصت، زیان موردانتظارِ Rangeدار و Unknown مقایسه کنید. زیان مالی همهٔ Harmها را نمایندگی نمیکند و نباید ارزش انسانی، اعتماد یا الزام را بهطور خودکار پولی کند.
گزینهها را فراتر از Ship یا Delay بسازید
| Option | یادگیری | Risk control | هزینه/محدودیت |
|---|---|---|---|
| Prototype | فهمپذیری/تقاضای اولیه | بدون عملیات واقعی | Behavior واقعی محدود |
| Shadow | رفتار محاسبه روی traffic کپی | بدون اثر کاربر | Side-effect باید مسدود شود |
| Internal/dogfood | Workflow و operability | Population محدود | نمایندگی کاربر کم |
| Canary/cohort | Production evidence محدود | cap، guardrail، kill | آمار/تعیم محدود |
| Manual concierge | ارزش مسیر با عملیات انسانی | حجم پایین و review | مقیاس و رفتار automation نامعلوم |
| Delay + risk reduction | Evidence فنی بیشتر | Gap مشخص بسته میشود | Opportunity window ممکن است کم شود |
| Do nothing/stop | ظرفیت آزاد میشود | Risk تغییر حذف | مسئلهٔ اصلی باقی میماند |
Decision Packet را کوتاه اما کامل نگه دارید
decision_id: SQD-042 as_of: 2026-08-25T12:00:00+03:30 bet: BET-IRR-042 change_class: reversible_medium_exposure options: [prototype, shadow, cohort_5, delay, stop] harm_floor: HF-CHECKOUT-IRR-v3 quality_envelope: QE-042-v2 evidence_manifest: EM-042-v4 unknowns: [late_callback_behavior] selected: cohort_5 rationale: strongest bounded evidence before opportunity window rollback: RO-BET-IRR-042 debt_exceptions: [DEBT-042-01] decision_owner_role: product-owner risk_acceptor_role: checkout-risk-owner review_due: 2026-09-01 correction_policy: append_only
Product owner میتواند ارزش و Option را تصمیم بگیرد، اما بهطور خودکار صاحب پذیرش همهٔ Riskها نیست. QA Evidence و Gap را گزارش میکند و بهتنهایی «کیفیت» یا Release را امضا نمیکند. تصمیم انتشار عمومی با جزئیات بیشتر در چارچوب Good Enough Quality آمده است.
Authority Map جلوی Gatekeeper مبهم را میگیرد
| نقش | تصمیم | تصمیمی که ندارد |
|---|---|---|
| Product owner | Outcome Bet و اولویت | Waive خودکار Harm floor تخصصی |
| Engineering owner | طرح فنی، batch و rollback feasibility | اعلام ارزش محصول |
| Quality/Test owner | Evidence profile، limitation و finding | تضمین کیفیت یا Risk acceptance |
| SRE/Operations | SLI/SLO evidence و operability | تصمیم نهایی محصول |
| Domain risk owner | پذیرش Risk در دامنهٔ اختیار | پذیرش Risk خارج دامنه |
| On-call release owner | Pause/rollback طبق Policy | تغییر مخفی Threshold |
تعارض سرعت و کیفیت را به گزینه و Evidence تبدیل کنید
بهجای «QA مانع است» یا «محصول بیملاحظه است»، اختلاف را دقیق کنید: کدام Deadline، کدام Outcome، کدام Gap، چه Exposure و چه اختیار؟ حداقل سه Option با اثر بر زمان، Evidence و Risk ارائه کنید. مدیریت انتظارات و قرارداد Quality با ذینفع را در راهنمای مدیریت انتظارات QA ببینید.
موفقیت Pilot با Scale readiness یکی نیست
در Cohort پنجدرصدی ممکن است Dependency، Support، Abuse، locale یا Peak load نمایان نشود. Result را با Scope همان Pilot ثبت کنید و پیش از Scale، Coverage delta، capacity، monitoring، rollback at scale و cohort shift را بررسی کنید. برنامههای نوآوری را میتوان با الگوی مسئله تا Scale یا Stop مدیریت کرد.
شرایط ایران را در Contract آشکار کنید
دسترسی ناپایدار یا محدود به SaaS، پرداخت ارزی، تغییر نرخ هزینه، latency شبکه، locale فارسی، تقویم و واحد پول میتواند Evidence و Recovery را تغییر دهد. ابزار جایگزین، Export، self-host/exit، زمان تمدید License و fallback را ثبت کنید. مبلغ canonical را IRR نگه دارید و اگر تومان نمایش میدهید label و تبدیل را صریح کنید. اینها ادعای حقوقی، بانکی یا مالی دربارهٔ ایران نیستند.
آزمایش تکرارپذیر: Dashboard سبز اما Decision ناقص
Fixture مصنوعی زیر ۲۴ Deploy در ۲۸ روز، Lead time پنجساعته و صفر Critical defect نشان میدهد و نتیجه را SPEED_QUALITY_BALANCED اعلام میکند. Auditor بررسی میکند آیا این اعداد به Bet، Scope، Harm floor، Evidence، Rollout و Authority متصلاند.
{
"decision_id": "",
"bet": {"population": "", "outcome": "", "mechanism": "", "not_claimed": []},
"change": {"artifact": "", "class": "", "scope": "", "reversibility_evidence": ""},
"harm_floor": {"policy_id": "", "claims": []},
"quality_envelope": [],
"evidence_manifest": "",
"rollout": {"cohort": "", "exposure": "", "stop": [], "rollback_evidence": ""},
"metrics": [
{"name": "deployments", "value": 24, "window": "28d"},
{"name": "lead_time_hours", "value": 5},
{"name": "critical_defects", "value": 0}
],
"debt_exceptions": [{"id": "D1", "owner_role": "", "expiry": "", "repayment_evidence": ""}],
"decision_owner_role": "",
"risk_acceptor_role": "",
"declared": "SPEED_QUALITY_BALANCED"
}
const fs = require('node:fs');
const x = JSON.parse(fs.readFileSync(process.argv[2], 'utf8'));
const findings = [];
const req = (ok, rule, path) => { if (!ok) findings.push({ rule, path }); };
req(x.decision_id, 'IDENTITY', 'decision_id');
req(x.bet?.population, 'BET', 'bet.population');
req(x.bet?.outcome, 'BET', 'bet.outcome');
req(x.bet?.mechanism, 'BET', 'bet.mechanism');
req((x.bet?.not_claimed || []).length, 'CLAIM_BOUNDARY', 'bet.not_claimed');
req(x.change?.artifact, 'CHANGE_IDENTITY', 'change.artifact');
req(x.change?.class && x.change?.scope, 'CHANGE_CLASS', 'change');
req(x.change?.reversibility_evidence, 'REVERSIBILITY', 'change.reversibility_evidence');
req(x.harm_floor?.policy_id, 'HARM_FLOOR', 'harm_floor.policy_id');
req((x.harm_floor?.claims || []).length, 'HARM_FLOOR', 'harm_floor.claims');
req((x.quality_envelope || []).length, 'QUALITY_ENVELOPE', 'quality_envelope');
req(x.evidence_manifest, 'EVIDENCE', 'evidence_manifest');
req(x.rollout?.cohort && x.rollout?.exposure, 'ROLLOUT', 'rollout');
req((x.rollout?.stop || []).length, 'STOP_RULE', 'rollout.stop');
req(x.rollout?.rollback_evidence, 'ROLLBACK', 'rollout.rollback_evidence');
req(x.decision_owner_role, 'AUTHORITY', 'decision_owner_role');
req(x.risk_acceptor_role, 'AUTHORITY', 'risk_acceptor_role');
for (const [i, d] of (x.debt_exceptions || []).entries())
req(d.owner_role && d.expiry && d.repayment_evidence, 'DEBT_CONTRACT', `debt_exceptions[${i}]`);
const metricNames = new Set((x.metrics || []).map(m => m.name));
req(metricNames.has('primary_outcome'), 'OUTCOME_METRIC', 'metrics');
req(metricNames.has('harm_guardrail'), 'GUARDRAIL_METRIC', 'metrics');
req((x.metrics || []).every(m => m.window && m.population && m.source),
'METRIC_CONTRACT', 'metrics');
const computed = findings.length ? 'HOLD' : 'READY_FOR_SPEED_QUALITY_REVIEW';
if (x.declared !== computed)
findings.push({ rule: 'DECISION_MISMATCH', path: 'declared' });
console.log(JSON.stringify({ computed, count: findings.length, findings }, null, 2));
process.exitCode = findings.length ? 2 : 0;
اجرای نسخهٔ ناقص باید HOLD و ۲۲ Finding بدهد: Identity، چهار شکاف Bet/Claim، چهار شکاف Change، دو Harm floor، Quality envelope، Evidence، سه Rollout، دو Authority، Debt contract، Outcome metric، Guardrail metric، Metric contract و Decision mismatch. اعداد سبز حذف نمیشوند؛ فقط از ادعایی بزرگتر از معنای خود منع میشوند.
پس از افزودن BET-IRR-۰۴۲، Build/Scope/Class، Harm policy، Quality envelope، Evidence manifest، cohort پنجدرصدی، stop/rollback rehearsal، Metric contractهای Outcome/Guardrail و Debt/Authority معتبر، اجرای دوباره باید count=۰ و READY_FOR_SPEED_QUALITY_REVIEW بدهد. این نتیجه فقط کاملبودن ساختار Packet را میسنجد؛ Evidence truth، ارزش محصول، کفایت Threshold، ایمنی، انطباق یا «تعادل» را اثبات نمیکند.
نمونهٔ Decision: نمایش IRR و تومان
تیم فرض کرده ابهام واحد پول باعث اصلاح دستی پیش از تأیید میشود. بهجای تغییر یکبارهٔ Checkout، ابتدا Prototype فارسی را با دادهٔ مصنوعی میسنجد؛ سپس Build b391 فقط نمایش را برای cohort پنجدرصدی تغییر میدهد، درحالیکه مبلغ canonical IRR و Charge واقعی غیرفعال است. Primary outcome «تأیید معتبر بدون اصلاح واحد» و Guardrailها مبلغ نادرست، رهاشدن، تماس پشتیبانی و latency هستند.
نتیجهٔ ۲۴ساعته فقط برای همان Segment، UI revision، Exposure و Window معتبر است. اگر Outcome بهتر و Guardrail سالم باشد، Decision بعدی «افزایش محدود Exposure» است، نه اثبات Revenue یا Market fit. اگر داده دیر برسد یا cohort assignment drift کند، نتیجه INCONCLUSIVE میشود. همهٔ شناسهها، ارقام و سامانههای این مثال ساختگیاند؛ شبکه، Production، پول واقعی، PSP، بانک، نام، موبایل، حساب، PAN، CVV2، OTP، Cookie، Token یا Credential واقعی وجود ندارد.
Anti-patternهای رایج تعادل سرعت و کیفیت
| ادعا/رفتار | مشکل | اصلاح |
|---|---|---|
| ۲۴ Deploy یعنی سریع و باکیفیت | Outcome/Scope/Instability غایب | Metric contract + Outcome/Guardrail |
| صفر Critical یعنی امن | Detection و taxonomy نامعلوم | Evidence coverage و unknown |
| همهٔ Criticalها همیشه اولاند | Severity، urgency، exposure و authority مخلوط | Risk profile و triage policy |
| MVP میتواند خراب باشد | Scope کم با Harm مجاز اشتباه شده | Harm floor + Claim محدود |
| اتوماسیون سرعت و کیفیت را تضمین میکند | Oracle/maintenance/flaky نادیده | Option economics و lifecycle |
| CI/CD یعنی Release امن | Pipeline capability با Decision یکی شده | Evidence، rollout و recovery |
| Error budget داریم، پس Risk مجاز است | Reliability budget به همهٔ Harmها تعمیم یافته | SLO scope + floor |
| Debt را بعداً میپردازیم | مالک/trigger/expiry ندارد | Debt contract و capacity |
| درست از بار اول | یادگیری و uncertainty انکار میشود | small bet + correction |
| AI زمان تست را نصف کرد | Baseline/quality/review/cost نامعلوم | bounded pilot + countermetrics |
AI و ابزارها چه نقشی دارند؟
ابزار میتواند Change metadata را جمع، Risk candidate را علامت، Test selection پیشنهاد، cohort/flag را اجرا، Metric را محاسبه و Debt expiry را یادآوری کند. AI میتواند Option یا missing-field candidate بسازد. نباید Evidence گمشده را جعل، Harm floor را Waive، Outcome را علی اعلام، فرد را مقصر، یا Risk/Release/Scale را خودمختار تصویب کند. Prompt/model/version/source/reviewer و Correction باید ثبت شوند.
سیستم سنجش متوازن
| بعد | Metric نمونه | Countermetric |
|---|---|---|
| Flow | Change lead time با p50/p85 | WIP، queue و batch size |
| Delivery | Deployment frequency | Change fail و rework rate |
| Recovery | Failed deployment recovery time | Harm برگشتناپذیر |
| Reliability | SLI و error-budget burn | data quality و exclusion rate |
| Product | Outcome مخصوص Bet | Guardrail/Harm و nonresponse |
| Evidence | time-to-valid-decision | Correction/inconclusive rate |
| Debt | risk-weighted aging | feature delay و debt replacement |
| People | after-hours/rework load | survey nonresponse و support burden |
Dashboard را به Action وصل کنید
برای هر Threshold بنویسید چه کسی، در چه SLA و با چه اختیار چه میکند. نمودار Burn بدون Pause policy فقط تزئین است؛ Outcome بدون Stop rule به Confirmation bias کمک میکند؛ Debt aging بدون ظرفیت بازپرداخت، فهرست آرزوهاست. Data freshness و Correction را روی Dashboard نمایش دهید.
ریتم تصمیم برای تیم کوچک
- روزانه: Guardrail، SLO burn، Rollout و Stop/Pause.
- هفتگی: Betهای باز، WIP/Queue، Evidence quality و Debt سررسید.
- در پایان Window: Outcome، Alternative، limitation و Continue/Adapt/Stop.
- ماهانه: Metric drift، correction، ظرفیت Feature/Reliability/Debt/Learning.
- فصلی: Harm floor، SLO، authority و ابزار/وابستگی/exit.
برنامهٔ اجرایی ۳۰روزه
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۳ | یک Value stream و Decision را انتخاب کنید | Scope و baseline رویدادها |
| روز ۴–۷ | Harm floor و Authority را تصویب کنید | Policy v1 و escalation |
| روز ۸–۱۲ | Bet/Quality/Evidence templates را بسازید | Fixture کامل و ناقص |
| روز ۱۳–۱۸ | یک Change برگشتپذیر را Pilot کنید | Rollout، stop و rehearsal |
| روز ۱۹–۲۳ | DORA/Outcome/Guardrail contracts را متصل کنید | Dashboard با data quality |
| روز ۲۴–۲۷ | Debt/Exception و capacity review | repay/adapt/expire decisions |
| روز ۲۸–۳۰ | خودِ فرایند را بازبینی کنید | ADOPT/ADAPT/STOP و correction v2 |
چکلیست Decision Owner
- Outcome Bet، Population، Mechanism، Decision و not-claimed روشن است.
- Stage و Constraint استارتاپ ثبت شده، اما مجوز Harm نشده است.
- Harm floor و صاحب اختیار پیش از Deadline تعیین شدهاند.
- Quality envelope برای Scope/Build/Window نسخه دارد.
- Change class، Impact، Exposure، Detectability و Reversibility معلوماند.
- Evidence minimum به Claim وصل است، نه به تعداد Test.
- Batch قابل فهم و State/Dependency آن قابل برگشت است.
- Rollout، cohort، observation، stop و rollback rehearsal دارند.
- Metricهای DORA تعریف محلی، Population، source و Window دارند.
- Outcome و Guardrail از Delivery metric جدا هستند.
- Error budget فقط در Scope همان SLI/SLO مصرف میشود.
- Debt/Exception مالک، Risk، expiry، trigger و repayment evidence دارد.
- Authority محصول، مهندسی، QA، عملیات و Risk جداست.
- Decision receipt، limitation، next review و correction ثبت شده است.
جمعبندی
استارتاپ خوب «کیفیت را قربانی سرعت» نمیکند و برای کیفیت نامحدود نیز Opportunity را از دست نمیدهد. سؤال درست این است: کدام عدمقطعیت را با کوچکترین Change قابلبازگشت، درون Harm floor، با Evidence کافی و Exposure محدود روشن کنیم؟ Deployment، SLO، Outcome، Debt و Recovery هر کدام معنای جدا دارند. وقتی این قراردادها روشن باشند، تیم بهجای جنگ شعارها، دربارهٔ Continue، Adapt، Stop یا Repay تصمیمی قابلممیزی میگیرد.
سؤالات متداول تعادل سرعت و کیفیت در استارتاپ
آیا سرعت و کیفیت واقعاً Trade-off هستند؟
در یک تصمیم کوتاهمدت، ظرفیت محدود میتواند Trade-off بسازد؛ اما Batch کوچک، Feedback سریع، Testability و Rollback اغلب هر دو را بهتر میکنند. رابطه را با Context و چند Metric بسنجید، نه با حکم همیشگی.
آیا MVP میتواند باگ داشته باشد؟
وجود Defect ممکن است، اما «MVP» مجوز Harm یا Claim غلط نیست. Scope، Exposure و Featureها را کم کنید؛ Harm floor، Evidence لازم، Recovery و اطلاع شفاف را حذف نکنید. Disposition هر Defect به Risk و Policy بستگی دارد.
بهترین نسبت زمان Feature و Technical Debt چیست؟
نسبت جهانی وجود ندارد. SLO burn، Incident load، debt aging/interest، runway، opportunity window و ظرفیت را در Portfolio ببینید. Trigger بازپرداخت و سقف WIP از درصد ثابت مهمتر است.
آیا Deployment frequency بالا نشانهٔ کیفیت است؟
خیر. این Metric Throughput تحویل است. آن را با Change lead time، recovery، change fail/rework، SLO، Outcome، Guardrail و Evidence quality بخوانید. تعداد Deploy بهتنهایی ارزش یا کیفیت محصول را ثابت نمیکند.
چه زمانی برای سرعت، تست کمتری اجرا کنیم؟
وقتی Claim، Change class و Exposure نشان دهد Evidence دیگری سریعتر و کافیتر است و Harm floor/Policy اجازه میدهد؛ مثلاً Test selection ریسکمحور همراه با Rollout محدود. Test را تصادفی حذف نکنید و Gap، Compensation، Expiry و Reopen را ثبت کنید.
