کیفیت به‌اندازه کافی خوب؛ چارچوب تصمیم انتشار

وقتی مدیر محصول می‌پرسد «این نسخه برای انتشار به‌اندازه کافی خوب هست؟»، پاسخ حرفه‌ای نه «همه تست‌ها پاس شده‌اند» است و نه «هیچ نرم‌افزاری بی‌نقص نیست». پاسخ باید نشان دهد این نسخه برای چه کسانی، با چه هدفی، در چه مقیاسی و تا چه زمانی مناسب است؛ چه ریسک‌هایی باقی مانده، این قضاوت بر چه شواهدی تکیه دارد و اگر فرض‌ها اشتباه از آب درآمدند چگونه عقب‌نشینی می‌کنیم.

«کیفیت به‌اندازه کافی خوب» یا Good Enough Quality (GEQ) مجوز کم‌کاری نیست. این مفهوم یک پرونده استدلالی برای تصمیم انتشار است: فایده مورد انتظار باید کافی باشد، مسئله بحرانی حل‌نشده نداشته باشیم، فایده‌ها به‌طور معنادار بر زیان‌ها غلبه کنند و در وضعیت فعلی، هزینه یا آسیب ادامه بهبود از منفعت آن بیشتر باشد. این راهنما GEQ را به چارچوبی قابل ممیزی برای تیم‌های محصول، تست، امنیت، عملیات و مدیر ریسک تبدیل می‌کند.

خلاصه اجرایی: کیفیت کافی یک تصمیم زمینه‌مند است

• موضوع تصمیم را دقیق کنید: کدام Build، قابلیت، کانال، جامعه کاربری و بازه زمانی؟
• تعهدهای غیرقابل معامله را جدا کنید: قانون، قرارداد، ایمنی، امنیت، حریم خصوصی، دسترس‌پذیری و یکپارچگی داده را نمی‌توان صرفاً با منفعت تجاری تهاتر کرد.
• فایده و ریسک را چندبعدی ببینید: کیفیت فقط تعداد Bug یا نرخ Pass نیست.
• ادعا را به شواهد وصل کنید: هر ادعای آمادگی انتشار باید شاهد، دامنه، تاریخ و محدودیت داشته باشد.
• مالک پذیرش ریسک را نام ببرید: QA اطلاعات تصمیم را فراهم می‌کند؛ لزوماً صاحب اختیار پذیرش همه ریسک‌های کسب‌وکار نیست.
• انتشار را برگشت‌پذیر کنید: Feature Flag، Canary، پایش و Rollback بخشی از پرونده کیفیت‌اند، نه جایگزین کیفیت.

کیفیت به اندازه کافی خوب چیست؟

جیمز باخ در مقاله سال ۱۹۹۷ خود، GEQ را فراتر از یک شعار بازاریابی صورت‌بندی کرد. با بازنویسی چهار گزاره اصلی آن چارچوب، یک محصول در وضعیت معین «به‌اندازه کافی خوب» است اگر:

1. فایده‌های کافی برای ذی‌نفعان مهم ایجاد کند؛
2. هیچ مسئله بحرانیِ شناخته‌شده و حل‌نشده‌ای نداشته باشد؛
3. فایده‌هایش به‌طور کافی بر پیامدهای منفی غلبه کنند؛
4. با توجه به شرایط امروز، ادامه بهبود اکنون زیان‌بارتر یا پرهزینه‌تر از توقف و عرضه باشد.

این تعریف را می‌توان در نسخه آرشیوی مقاله Good Enough Quality: Beyond the Buzzword و اطلاعات کتاب‌شناختی/DOI آن را در کتاب‌شناسی نویسنده دید. نکته مهم این است که GEQ معادل «متوسط»، «ارزان» یا «سریع» نیست. یک سامانه پزشکی نیز ممکن است پس از شواهد بسیار سخت‌گیرانه به وضعیت کافی برسد؛ در مقابل، ممکن است یک تغییر ظاهراً کوچک هنوز برای انتشار محدود هم کافی نباشد.

چرا «۸۰ درصد کیفیت» تعریف مناسبی نیست؟

کیفیت یک مخزن یک‌بعدی نیست که بگوییم ۸۰ درصد آن پر شده است. کارایی عالی، نقض حریم خصوصی را جبران نمی‌کند و ظاهر زیبا، اشتباه در مانده کیف پول را خنثی نمی‌سازد. اصل پارتو می‌تواند برای اولویت‌بندی یک فرض مفید باشد، اما قانون طبیعی کیفیت نیست. سهم «مهم» قابلیت‌ها، خرابی‌ها و کاربران باید از داده همان محصول به دست آید، نه از نسبت ازپیش‌تعیین‌شده.

پنج مفهوم نزدیک که نباید با هم مخلوط شوند

۱. کیفیت محصول

کیفیت محصول ارزیابی تناسب ویژگی‌های آن با نیاز ذی‌نفعان است. مدل ISO/IEC 25010:2023 کیفیت محصول را با مجموعه‌ای از ویژگی‌ها مانند تناسب کارکردی، کارایی، سازگاری، قابلیت تعامل، قابلیت اطمینان، امنیت، نگهداشت‌پذیری، انعطاف‌پذیری و ایمنی صورت‌بندی می‌کند. این مدل چک‌لیست ثابت پذیرش نیست؛ کمک می‌کند بعد مهمی را فراموش نکنیم.

۲. کفایت تست

کفایت تست یعنی تیم بتواند داستانی قانع‌کننده درباره وضعیت محصول، روش شناخت آن وضعیت و اعتبار خود فرایند تست ارائه کند؛ و آزمون‌های بیشتر به‌احتمال زیاد نتیجه این داستان را به‌طور معنادار تغییر ندهند. این برداشت در مقاله How Much is Enough? توضیح داده شده است. «تمام Test Caseها اجرا شدند» فقط یک داده است؛ درباره پوشش ریسک‌های ناشناخته یا کیفیت طراحی تست چیزی را به‌تنهایی ثابت نمی‌کند.

۳. Definition of Done

در راهنمای رسمی Scrum ۲۰۲۰، تعریف انجام‌شده توصیف رسمی وضعیتی است که Increment معیارهای کیفیت لازم را برآورده می‌کند. Done یک کف مشترک و شفاف برای کار تکمیل‌شده است؛ اما به‌تنهایی نمی‌گوید بهترین زمان، جامعه و روش Release چیست. ممکن است Increment واقعاً Done باشد ولی تصمیم تجاری این باشد که امروز عرضه نشود.

۴. آمادگی انتشار

Release Readiness قضاوتی درباره یک تغییر مشخص در یک زمینه مشخص است: آیا شواهد، کنترل‌ها و برنامه بازیابی برای انتقال آن به محیط یا مخاطب هدف کافی‌اند؟ این همان محدوده اصلی GEQ در این مقاله است.

۵. سلامت عملیاتی

سلامت عملیاتی پس از استقرار با Telemetry، رخداد، ظرفیت، SLO و بازخورد کاربر سنجیده می‌شود. قبولی پیش از انتشار تضمین نمی‌کند رفتار واقعی در ترافیک، داده و وابستگی‌های تولید همان باشد. به همین دلیل پرونده کیفیت باید برنامه یادگیری در تولید داشته باشد.

Deploy، Release و Launch یک رویداد نیستند

• Deploy: انتقال کد یا پیکربندی به یک محیط؛
• Release: در دسترس‌کردن قابلیت برای گروهی از کاربران؛
• Launch: اعلام یا ترویج گسترده آن قابلیت در بازار.

یک Build ممکن است برای Deploy خاموش پشت Feature Flag کافی باشد، برای Release به کارکنان کافی باشد، اما برای Launch عمومی کافی نباشد. جمله «آماده است» بدون نام‌بردن این مرحله ناقص است.

گام اول: زمینه تصمیم را روی یک کارت بنویسید

پیش از بحث درباره Bugها، یک Decision Context Card بسازید. اگر پاسخ هر فیلد مبهم است، هنوز موضوع تصمیم روشن نیست:

• موضوع: شناسه Build، تغییرات و پیکربندی دقیق؛
• مخاطب: کارکنان، کاربران آزمایشی، یک شهر، درصدی از کاربران یا همه مشتریان؛
• هدف: مسئله‌ای که نسخه باید حل کند و فایده قابل مشاهده؛
• زمان: تاریخ تصمیم، مدت اعتبار آن و رویدادهای حساس پیش رو؛
• مقیاس: حجم ترافیک، تراکنش، داده و نرخ رشد؛
• وابستگی: سرویس‌های داخلی، پرداخت، پیامک، نقشه، احراز هویت یا شریک بیرونی؛
• برگشت‌پذیری: زمان خاموش‌کردن قابلیت، Rollback، سازگاری داده و هزینه بازگشت؛
• مالک تصمیم: شخص دارای اختیار انتشار و اشخاص دارای اختیار پذیرش ریسک.

به‌جای «نسخه خوب است»، ادعای آزمون‌پذیر بنویسید: «Build ۷.۱۴ برای فعال‌سازی قابلیت پرداخت قسطی به ۵ درصد کاربران احراز‌شده اندروید، به‌مدت ۴۸ ساعت و با سقف تراکنش مشخص کافی است؛ مشروط به فعال‌بودن Kill Switch و پایش شاخص‌های توافق‌شده.»

گام دوم: ذی‌نفع، هدف بحرانی و تعریف مسئله را مشخص کنید

یک نسخه می‌تواند برای کاربر جدید ساده باشد اما کار پشتیبانی را دو برابر کند؛ برای فروش جذاب باشد اما هزینه زیرساخت را بالا ببرد؛ یا برای مالک محصول سودمند باشد ولی برای کاربر دارای محدودیت بینایی غیرقابل استفاده بماند. تحلیل ذی‌نفعان حداقل باید مشتری، کاربر نهایی، عملیات، پشتیبانی، امنیت، حقوقی، مالی، توسعه و مالک کسب‌وکار را پوشش دهد.

مسئله بحرانی را پیشاپیش تعریف کنید

«بحرانی» نباید پس از دیدن باگ و برای عبور از Gate بازتعریف شود. معیار می‌تواند شامل مرگ یا آسیب جسمی، افشای داده حساس، انتقال مالی نادرست، فساد داده غیرقابل بازیابی، نقض صریح تعهد قانونی/قراردادی، از دسترس‌رفتن گسترده یا ناتوانی کامل کاربر در هدف اصلی باشد. شدت را همراه با احتمال، گستره، مدت، کشف‌پذیری و امکان بازیابی بسنجید. چند نقص کوچک هم می‌توانند در کنار هم یک شکست بحرانی بسازند.

برای طراحی آزمون‌ها از ریسک آغاز کنید؛ راهنمای تست مبتنی بر ریسک روش اولویت‌بندی پوشش را توضیح می‌دهد. GEQ مرحله بعدی است: آیا شواهد حاصل برای تصمیم حاضر کافی‌اند؟

گام سوم: تعهدهای سخت را از معامله‌های کیفیت جدا کنید

در هر تصمیم دو سبد بسازید:

سبد A: شرط‌های غیرقابل معامله

• تعهد صریح قانونی، قراردادی یا رگولاتوری؛
• حفاظت از جان، داده حساس و دارایی مالی؛
• یکپارچگی و قابلیت بازیابی داده؛
• کنترل‌های امنیتی مصوب و الزامات Secure SDLC؛
• معیارهای دسترس‌پذیری یا سازگاری که قرارداد یا جامعه هدف الزام می‌کند؛
• نبود مشکل بحرانی طبق تعریف قبلی.

این شروط Gate هستند. اگر یکی نقض شود، افزایش درآمد یا نزدیک‌بودن موعد به‌تنهایی آن را خنثی نمی‌کند. برای ساخت خط پایه امنیت توسعه می‌توان از NIST Secure Software Development Framework 1.1 استفاده کرد؛ SSDF یک مجموعه عمل پیشنهادی است، نه گواهی امنیت و نه الزام حقوقی جهانی.

سبد B: ویژگی‌های قابل موازنه

برخی کمبودها را می‌توان با دامنه محدود، راه‌حل موقت، پشتیبانی بیشتر یا برنامه اصلاح پذیرفت؛ مثلاً کندی جزئی یک گزارش کم‌کاربرد. اما پذیرش باید حد، مالک، تاریخ انقضا و Trigger بازبینی داشته باشد. عبارت «بعداً درست می‌کنیم» کنترل ریسک نیست.

گام چهارم: پرونده فایده بسازید

فایده صرفاً «زودتر رفتن به بازار» نیست. برای هر ذی‌نفع مهم یک ادعا، شاخص و بازه مشاهده ثبت کنید:

• کاهش زمان انجام کار یا نرخ رهاکردن فرایند؛
• کاهش خطای انسانی یا بار پشتیبانی؛
• افزایش دسترسی کاربران محروم از خدمت؛
• کاهش هزینه عملیاتی یا زمان بازیابی؛
• یادگیری معتبر درباره یک فرضیه محصول؛
• رفع یک ریسک امنیتی یا انقضای فناوری.

فایده باید با هزینه تأخیر مقایسه شود، اما هزینه تأخیر را هم مستند کنید. «رقیب جلو می‌افتد» بدون داده، هم‌ارز ریسک مستند خرابی نیست. اگر هدف نسخه یادگیری است، حداقل داده لازم، معیار توقف و مدت آزمایش را تعریف کنید تا MVP به محصول نیمه‌تمام دائمی تبدیل نشود.

گام پنجم: پرونده ریسک و ریسک باقیمانده را بسازید

استاندارد ISO 31000:2018 یک چارچوب عمومی برای شناسایی، تحلیل، ارزیابی، درمان، پایش و ارتباط ریسک ارائه می‌کند. برای تصمیم انتشار، یک Risk Register سبک کافی است، اگر قابل پیگیری باشد:

• سناریوی ریسک به‌شکل «اگر… آنگاه… و پیامد…»؛
• ذی‌نفع و دارایی در معرض آسیب؛
• احتمال، شدت، گستره و سرعت وقوع؛
• کنترل پیشگیرانه و کنترلی که اثر را محدود می‌کند؛
• شاهد کارکرد کنترل؛
• ریسک باقیمانده پس از کنترل؛
• مالک، موعد و Trigger تشدید یا توقف.

ریسک ناشناخته را صفر فرض نکنید

نبود باگ گزارش‌شده شاهد صفر بودن باگ نیست. بخش «ناشناخته‌ها» را عمداً در گزارش نگه دارید: مسیرهایی که تست نشدند، دستگاه‌هایی که در دسترس نبودند، وابستگی‌هایی که شبیه‌سازی شدند، داده تولیدی که نمونه‌اش را ندارید و فرض‌هایی که هنوز اعتبارسنجی نشده‌اند. ناشناخته مهم یا باید با تست/آزمایش کاهش یابد یا با دامنه انتشار و قابلیت بازگشت مهار شود.

گام ششم: Evidence Pack بسازید، نه داشبورد تزئینی

برای هر ادعای مهم، شاهدی با مشخصات زیر ثبت کنید:

• ردیابی: شاهد دقیقاً کدام ادعا یا ریسک را پوشش می‌دهد؟
• منبع: تست خودکار، بررسی اکتشافی، لاگ، تحلیل کد، مشاهده کاربر یا تمرین بازیابی؛
• تازگی: روی کدام Build، داده، محیط و تاریخ تولید شده است؟
• دامنه: چه سناریوها و جمعیتی را شامل یا مستثنا می‌کند؟
• اعتبار: Oracle، داده تست و محیط چقدر قابل اعتمادند؟
• نتیجه و محدودیت: چه چیزی را نشان می‌دهد و چه چیزی را نشان نمی‌دهد؟

Pipeline می‌تواند شاهد را سریع و تکرارپذیر تولید کند. مقاله تست مداوم در DevOps و راهنمای ساخت CI/CD با تست خودکار پیاده‌سازی این بخش را پوشش می‌دهند. بااین‌حال سبز بودن Pipeline فقط ادعاهای رمزگذاری‌شده در آن را پشتیبانی می‌کند.

چه زمانی تست کافی است؟

توقف تست یک تصمیم اقتصادیِ صرف نیست؛ قضاوتی درباره قدرت داستان شواهد است. پیش از توقف بپرسید:

• آیا ریسک‌های باقیمانده مهم را می‌شناسیم؟
• آیا تغییر، سناریوی شکست تازه‌ای ایجاد کرده است؟
• آیا تست بعدی احتمال معقولی دارد تصمیم Release را عوض کند؟
• آیا نتیجه‌های قبلی تازه، مرتبط و قابل اعتمادند؟
• آیا برای بخش تست‌نشده کنترل تولیدی یا محدودیت دامنه داریم؟

اگر آزمون بعدی می‌تواند یک فرض حیاتی را با هزینه مناسب رد کند، توقف زود است. اگر فقط عدد Test Case را بالا می‌برد و هیچ ادعای تصمیم را تقویت نمی‌کند، ادامه آن احتمالاً اتلاف است.

اطمینان را با قطعیت اشتباه نگیرید

برای هر نتیجه سطح اطمینان «کم/متوسط/زیاد» و دلیلش را بنویسید. عدد دقیق احتمال، وقتی داده کافی نداریم، فقط ظاهر علمی ایجاد می‌کند. یک ارزیابی صادقانه با محدودیت‌های روشن از امتیاز ۹۲ از ۱۰۰ بدون مدل معتبر مفیدتر است. بحث معاصر درباره اینکه کیفیت کل بیشتر ارزیابی می‌شود تا به‌طور جامع اندازه‌گیری نیز همین مرز میان سنجه و قضاوت را برجسته می‌کند.

گام هفتم: سه کلاس تصمیم تعریف کنید

Block: اکنون به‌اندازه کافی خوب نیست

یک تعهد سخت نقض شده، مشکل بحرانی باز است، شاهد حیاتی نداریم، بازگشت امن نیست یا ریسک باقیمانده از آستانه مصوب بیشتر است. نتیجه باید دقیق باشد: «برای Release عمومی Block؛ پس از اصلاح X و اجرای آزمون Y بازبینی شود.»

Review: تصمیم به اختیار بالاتر یا تخصص دیگر نیاز دارد

ریسک در مرز تحمل است، تعارض ذی‌نفعان وجود دارد یا تفسیر حقوقی/امنیتی لازم است. تیم QA نباید این ابهام را با یک تیک سبز پنهان کند.

Permit within bounds: فقط در محدوده مصوب

انتشار با جمعیت، مدت، سقف تراکنش، کنترل، پایش و معیار توقف مشخص مجاز است. هر تغییر در این مرزها یک تصمیم جدید می‌خواهد. «مجوز Canary پنج‌درصدی» مجوز Launch سراسری نیست.

چه کسی می‌گوید کیفیت کافی است؟

کیفیت مسئولیت مشترک است، اما مسئولیت مشترک به‌معنای مالکیت مبهم نیست. مدل عملی می‌تواند چنین باشد:

• محصول: فایده، مخاطب و هزینه تأخیر را مالک است؛
• مهندسی: سلامت تغییر، محدودیت فنی و بازیابی را تأیید می‌کند؛
• QA: مدل ریسک، کفایت شواهد و محدودیت شناخت را به چالش می‌کشد؛
• امنیت/حقوقی/انطباق: درباره تعهدهای حوزه خود نظر یا Gate می‌دهند؛
• عملیات/SRE: ظرفیت، مشاهده‌پذیری، On-call و Rollback را ارزیابی می‌کند؛
• Release Authority: تصمیم نهایی و ریسک باقیمانده را در حدود اختیار خود می‌پذیرد.

راهنمای کیفیت به‌عنوان مسئولیت مشترک مدل عملیاتی گسترده‌تر را شرح می‌دهد. در GEQ، خروجی این همکاری باید یک نام و امضا داشته باشد؛ نه عبارت ناشناس «تیم موافق بود».

Waiver خوب چه اجزایی دارد؟

• الزام یا معیارِ مستثناشده و دلیل؛
• دامنه دقیق استثنا؛
• ریسک و ذی‌نفع آسیب‌پذیر؛
• کنترل جبرانی و شاهد کارکرد آن؛
• پذیرنده ریسک با اختیار معتبر؛
• تاریخ انقضا، مالک اصلاح و شرط لغو.

استثنای دائمی و بی‌مالک معمولاً همان بدهی پنهان است. Waiver نباید تعهدی را دور بزند که سازمان اصلاً اختیار چشم‌پوشی از آن را ندارد.

MVP، Prototype و Beta چگونه با GEQ مرتبط‌اند؟

• Prototype: برای پاسخ به پرسش طراحی یا فنی؛ لزوماً قابل استفاده تولیدی نیست.
• MVP: کمینه محصولی که بتواند یک فرض ارزش را با کاربر واقعی بیازماید؛ «کمینه» شرط‌های ایمنی و اعتماد را حذف نمی‌کند.
• Beta: عرضه محدود برای یادگیری، با انتظار و پشتیبانی روشن؛ برچسب Beta مسئولیت را محو نمی‌کند.
• GEQ: قضاوت می‌کند هر یک از این مصنوعات برای هدف و مخاطب تعیین‌شده کافی است یا نه.

بنابراین MVP می‌تواند از نظر دامنه کوچک اما از نظر یکپارچگی داده، امنیت و مسیر اصلی بسیار باکیفیت باشد. محصول پرقابلیت نیز ممکن است به‌علت نبود Rollback یا شاهد امنیتی برای Release کافی نباشد.

در سامانه‌های پرریسک، «کافی» سخت‌گیرانه‌تر می‌شود

گفتن اینکه بانکداری، سلامت یا ایمنی باید به «کمال مطلق» برسند عملی نیست؛ اثبات نبود همه نقص‌ها ممکن نیست. پاسخ حرفه‌ای‌تر این است که آستانه شواهد، حاشیه ایمنی، استقلال بررسی، قابلیت ردیابی و کنترل تغییر بسیار سخت‌تر می‌شوند. گاهی نتیجه صحیح این است: هیچ نسخه فعلی برای این کاربرد کافی نیست.

برای نمونه، در یک محصول مالی باید کنترل مجوز، ثبت حسابداری دوبل، Idempotency، Reconciliation، محدودیت تراکنش، ثبت ممیزی و سناریوهای بازیابی بخشی از پرونده باشند. راهنمای تست فین‌تک این ریسک‌های تخصصی را باز می‌کند. در دسترس‌پذیری نیز برچسب «نسخه اولیه» توجیهی برای حذف گروهی از کاربران نیست؛ از راهنمای تست دسترس‌پذیری برای تبدیل نیاز به شاهد استفاده کنید.

برگشت‌پذیری، انتشار تدریجی و یادگیری در تولید

وقتی پیامد قابل مهار است، Progressive Delivery می‌تواند هزینه خطا را کاهش دهد:

• Feature Flag مستقل از Deploy؛
• فعال‌سازی برای کارکنان یا Cohort کم‌ریسک؛
• Canary با افزایش مرحله‌ای جمعیت؛
• Guardrail برای خطا، تأخیر، شکایت، تقلب یا مغایرت مالی؛
• Kill Switch آزموده‌شده و مالک On-call؛
• Rollback نرم‌افزار و برنامه Forward Fix؛
• سازگاری داده در بازگشت و تست Restore؛
• بازه مشاهده کافی پیش از گسترش.

اگر Migration داده برگشت‌ناپذیر است، اثر آسیب فوری است یا جامعه Canary نماینده کاربران آسیب‌پذیر نیست، Rollout محدود دلیل کافی برای پذیرش ریسک نیست. کنترل تولیدی باید خودش تست شده باشد.

SLO و Error Budget چه کمکی می‌کنند؟

رویکرد Google SRE به توازن قابلیت اطمینان و ریسک نشان می‌دهد هدف ۱۰۰ درصد دسترس‌پذیری معمولاً انتخاب درستی نیست و SLO می‌تواند سطح مناسب خدمت را روشن کند. یک سیاست Error Budget نیز می‌تواند مشخص کند با مصرف بودجه خطا، سرعت Release چگونه تغییر کند. اما Error Budget مجوز نقض امنیت، قانون یا یکپارچگی مالی نیست؛ فقط یکی از سیگنال‌های سلامت خدمت است.

مثال ایرانی: انتشار قابلیت پرداخت قسطی

فرض کنید یک مارکت‌پلیس ایرانی می‌خواهد پرداخت قسطی را پیش از کمپین فروش فعال کند. موعد کمپین فایده واقعی دارد، اما «باید برسیم» پرونده کیفیت نیست.

زمینه و ادعا

Build مشخص فقط برای ۵ درصد کاربران احراز‌شده، خرید زیر سقف معین و ۴۸ ساعت فعال می‌شود. فروشنده‌های پرریسک و نسخه قدیمی اپ خارج از دامنه‌اند. هدف، سنجش تکمیل خرید بدون افزایش مغایرت مالی است.

تعهدهای سخت

• هیچ برداشت مضاعف یا ثبت نامتوازن پذیرفته نیست؛
• درخواست تکراری PSP باید Idempotent باشد؛
• اطلاعات مالی در لاگ یا ابزار تحلیل افشا نشود؛
• Reconciliation و مسیر بازپرداخت آزموده شده باشد؛
• رضایت و شرایط اقساط برای کاربر شفاف نمایش داده شود.

شواهد و ناشناخته‌ها

شواهد شامل Contract Test با PSP، تست هم‌زمانی، بازپخش Callback، Fault Injection برای Timeout، بررسی امنیت، Reconciliation روی داده مصنوعی و تمرین Kill Switch است. ناشناخته اصلی رفتار PSP در اوج ترافیک است؛ با سقف تراکنش، صف مقاوم، هشدار مغایرت و On-call مالی مهار می‌شود.

تصمیم

نتیجه «Permit within bounds» است، نه «کیفیت کامل». اگر نرخ مغایرت از صفر عبور کند، نسبت Timeout از آستانه بگذرد یا Reconciliation عقب بماند، قابلیت خودکار متوقف می‌شود. پس از ۴۸ ساعت شواهد دوباره ارزیابی می‌شوند؛ گسترش به ۲۵ درصد تصمیم جداگانه است.

قالب یک‌صفحه‌ای Quality Adequacy Memo

برای جلوگیری از جلسه‌های مبهم Go/No-Go، این یادداشت را حداکثر در یک صفحه نگه دارید و پیوند شواهد را ضمیمه کنید:

1. Decision: Block، Review یا Permit within bounds؛
2. Subject: Build، قابلیت، محیط و جامعه هدف؛
3. Benefit case: فایده، ذی‌نفع و معیار مشاهده؛
4. Hard obligations: Gateها و وضعیت هرکدام؛
5. Critical problems: موارد باز و دلیل بحرانی/غیربحرانی بودن؛
6. Evidence: مهم‌ترین شاهدها با Build، تاریخ و محدودیت؛
7. Residual risks: سناریو، کنترل، مالک و میزان تحمل؛
8. Unknowns: آنچه نمی‌دانیم و نحوه مهار؛
9. Operating bounds: درصد، مدت، سقف، Flag و Guardrail؛
10. Stop/Rollback: Trigger، تصمیم‌گیر و زمان بازیابی؛
11. Acceptance: نام، نقش، تاریخ و انقضای تصمیم.

پرسش‌های چالشی جلسه Go/No-Go

• کدام شاهد، اگر فردا رد شود، تصمیم امروز را عوض می‌کند؟
• چه کاربری بیشترین آسیب را می‌بیند و آیا در تست نماینده داشته است؟
• اگر داشبورد سبز باشد ولی شکایت واقعی برسد، کدام را باور می‌کنیم و چرا؟
• چه کسی اختیار پذیرش این ریسک را دارد و مرز اختیارش چیست؟
• آیا Rollback را واقعاً تمرین کرده‌ایم یا فقط Runbook داریم؟
• تصمیم تا چه زمانی معتبر است و چه تغییری آن را باطل می‌کند؟

سنجه‌ها به قضاوت کمک می‌کنند؛ جای آن را نمی‌گیرند

نرخ عبور تست، Defect Escape، پوشش کد، تغییر ناموفق و زمان بازیابی سرنخ‌اند. مقاله سنجه‌های اثربخشی تست نحوه استفاده سالم از آن‌ها را توضیح می‌دهد. تاریخچه فعلی سنجه‌های DORA نیز پنج سنجه تحویل را در دو گروه Throughput و Instability معرفی می‌کند؛ این سنجه‌ها عملکرد تحویل را روشن می‌کنند، نه اینکه به‌تنهایی «نمره کیفیت محصول» باشند.

سه خطای رایج سنجه‌ای

• Goodhart: وقتی یک عدد هدف می‌شود، تیم رفتار را برای بهبود عدد بهینه می‌کند نه الزاماً کیفیت را؛
• میانگین گمراه‌کننده: میانگین تأخیر، Tail Latency کاربران ایران یا اینترنت ضعیف را پنهان می‌کند؛
• مخرج نامعلوم: «فقط دو باگ» بدون دانستن حجم، شدت و سطح مشاهده معنای کمی دارد.

تصمیم خوب همیشه نتیجه خوب نمی‌دهد

بعد از Release، تصمیم را فقط با نتیجه قضاوت نکنید. چهار حالت وجود دارد:

• فرایند خوب، نتیجه خوب: فرض‌ها و کنترل‌ها کار کردند؛
• فرایند خوب، نتیجه بد: ریسک باقیمانده رخ داده؛ مدل را با داده تازه بهبود دهید، نه اینکه الزاماً تصمیم‌گیر را سرزنش کنید؛
• فرایند بد، نتیجه خوب: خوش‌شانسی؛ نبود حادثه دلیل تکرار روش نیست؛
• فرایند بد، نتیجه بد: هم حادثه و هم ضعف سیستم تصمیم نیازمند اصلاح‌اند.

در Post-Release Review بپرسید کدام فرض غلط بود، کدام سیگنال دیر رسید، چه ناشناخته‌ای قابل پیش‌بینی بود و کدام کنترل فقط روی کاغذ وجود داشت. هدف، کالیبره‌کردن قضاوت‌های بعدی است.

برنامه ۳۰روزه پیاده‌سازی GEQ

هفته اول: زبان و اختیار مشترک

• Deploy، Release، Launch، Done و GEQ را تعریف کنید؛
• مالک هر نوع ریسک و Release Authority را مشخص کنید؛
• تعهدهای سخت و تعریف مشکل بحرانی را تصویب کنید.

هفته دوم: الگو و شواهد

• Decision Context Card و Adequacy Memo را برای یک تیم آزمایشی بسازید؛
• ادعاهای مهم را به تست، لاگ و Runbook پیوند دهید؛
• ناشناخته‌ها و محدودیت محیط تست را اجباری کنید.

هفته سوم: انتشار محدود و بازیابی

• یک Feature Flag و Canary واقعی را تمرین کنید؛
• Triggerهای Stop و Rollback را در مانور اجرا کنید؛
• یک Waiver قدیمی را با مالک و تاریخ انقضا اصلاح کنید.

هفته چهارم: بازنگری بدون سرزنش

• دو تصمیم گذشته را با ماتریس فرایند/نتیجه بررسی کنید؛
• سنجه‌های بی‌اثر را حذف و Guardrailهای مفید را نگه دارید؛
• آستانه‌ها و حدود اختیار را با شواهد واقعی تنظیم کنید.

ضدالگوهایی که GEQ را به بهانه تبدیل می‌کنند

• تعیین «کافی» فقط بر اساس موعد؛
• برابرگرفتن کیفیت با درصد Pass؛
• استفاده از نسبت ۸۰/۲۰ بدون داده محصول؛
• نادیده‌گرفتن کاربران کم‌تعداد اما پرآسیب؛
• جمع‌زدن امتیاز امنیت و ظاهر در یک نمره؛
• تعریف‌نکردن مشکل بحرانی پیش از Release؛
• تبدیل نبود شواهد به شاهد نبود مشکل؛
• واگذاری پذیرش ریسک تجاری/حقوقی به QA؛
• Waiver بی‌مالک و بی‌انقضا؛
• اتکا به Rollback آزمایش‌نشده؛
• تعمیم موفقیت Canary به کل جمعیت بدون مکث؛
• استفاده از برچسب MVP/Beta برای حذف تعهدها؛
• اعلام «کمال مطلق» به‌جای معیار قابل اثبات؛
• فراموش‌کردن بازبینی تصمیم پس از تغییر زمینه.

چک‌لیست تصمیم انتشار با کیفیت کافی

• موضوع، Build، مخاطب، مقیاس و زمان تصمیم روشن است.
• فایده برای ذی‌نفعان مهم و معیار مشاهده آن ثبت شده است.
• تعهدهای سخت از ویژگی‌های قابل موازنه جدا شده‌اند.
• تعریف مشکل بحرانی پیشاپیش توافق شده است.
• ریسک‌های تجمعی و باقیمانده بررسی شده‌اند.
• هر ادعای مهم شاهد تازه، مرتبط و قابل ردیابی دارد.
• محدودیت تست و ناشناخته‌ها صریح‌اند.
• مالک هر ریسک و پذیرنده دارای اختیار نام برده شده‌اند.
• دامنه Permit و تاریخ انقضای Waiver مشخص است.
• Telemetry، Guardrail و Trigger توقف آماده‌اند.
• Rollback/Kill Switch واقعاً تمرین شده است.
• زمان و مالک بازبینی پس از انتشار تعیین شده‌اند.

پرسش‌های متداول درباره کیفیت به‌اندازه کافی خوب

آیا Good Enough Quality همان کیفیت پایین است؟

خیر. کیفیت پایین درباره کاستی محصول است؛ GEQ درباره کفایت یک نسخه برای هدف، مخاطب و زمان مشخص با شواهد و پذیرش آگاهانه ریسک است. در زمینه پرخطر، آستانه «کافی» می‌تواند بسیار سخت‌گیرانه باشد.

چه کسی باید تصمیم نهایی انتشار را بگیرد؟

شخص یا نهادی که اختیار Release و پذیرش ریسک باقیمانده را دارد. QA باید کیفیت شواهد و محدودیت شناخت را روشن کند؛ مالک محصول، مهندسی، امنیت، عملیات و حقوقی نیز در محدوده مسئولیت خود پاسخ‌گو هستند.

آیا پاس‌شدن همه تست‌ها برای Release کافی است؟

نه لزوماً. ممکن است تست‌ها ریسک درست را نپوشانند، روی Build دیگری اجرا شده باشند یا محدودیت محیط را پنهان کنند. نتیجه تست باید به ادعای کیفیت، زمینه اجرا و ریسک باقیمانده متصل شود.

آیا در نرم‌افزار مالی یا پزشکی هم GEQ کاربرد دارد؟

بله، اما نه با آستانه محصول کم‌خطر. تعهد قانونی، حاشیه ایمنی، استقلال بررسی، ردیابی و قدرت شواهد سخت‌تر می‌شوند. گاهی تصمیم درست این است که نسخه فعلی هنوز برای هیچ Releaseای کافی نیست.

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

بپرسید تست بعدی کدام عدم‌قطعیت مهم را کاهش می‌دهد و آیا نتیجه‌اش می‌تواند تصمیم انتشار را عوض کند. اگر شاهد تازه فقط شمار تست‌ها را بالا می‌برد، ارزش کمی دارد؛ اگر فرض حیاتی یا کنترل بازیابی را می‌آزماید، احتمالاً ضروری است.

جمع‌بندی

کیفیت به‌اندازه کافی خوب یک نقطه ثابت روی نمودار نیست؛ یک قضاوت زمینه‌مند، مستند و بازبینی‌پذیر است. تیم بالغ نمی‌پرسد «چند باگ مانده؟» و بحث را تمام کند. می‌پرسد این نسخه برای چه استفاده‌ای کافی است، چه تعهدهایی باید بی‌قیدوشرط رعایت شوند، فایده و ریسک برای چه کسانی‌اند، شواهد چقدر قابل اعتمادند، چه چیزهایی را هنوز نمی‌دانیم و چه کسی با چه اختیاری ریسک باقیمانده را می‌پذیرد.

خروجی خوب یک برچسب سبز نیست؛ یک Adequacy Memo کوتاه با مرز Release، شاهد، ناشناخته، Guardrail، Rollback، مالک و تاریخ بازبینی است. چنین رویکردی هم جلوی کمال‌گرایی بی‌هدف را می‌گیرد و هم مانع تبدیل فشار موعد به مجوز کیفیت نامعلوم می‌شود.