در بیشتر پروژه‌ها، پذیرش یک خروجی با معیارهای کسب‌وکار سنجیده می‌شود: آیا کاربر می‌تواند کارش را انجام دهد؟ آیا نتیجه درست است؟ اما تیم عملیات سؤال دیگری دارد: آیا می‌توانم این سیستم را در نیمه‌شب، زیر بار، و در روز خرابی اداره کنم؟ اگر این پرسش معیار روشن نداشته باشد، تیم عملیات ناچار می‌شود چیزی را بپذیرد که در عمل نمی‌تواند نگه دارد.
Operational Acceptance Criteria (معیار پذیرش عملیاتی) همان معیارها هستند: شرایطی که تیم عملیات بر اساس آن‌ها سرویس را رسماً تحویل می‌گیرد. در این مقاله می‌بینید این معیارها دقیقاً چیست، با معیارهای پذیرش کاربر چه تفاوتی دارد، چه حوزه‌هایی را پوشش می‌دهد، چگونه نوشته می‌شود و چطور از آن به یک پذیرش قابل‌دفاع برسیم.
Operational Acceptance Criteria چیست؟ (پاسخ سریع)
Operational Acceptance Criteria (معیار پذیرش عملیاتی) مجموعهٔ شرایط فنی و عملیاتی است که تیم عملیات برای تحویل گرفتن رسمی یک سرویس تعیین می‌کند. این معیارها تضمین می‌کنند که سرویس، پیش از انتقال مسئولیت، در برابر شرایط واقعی بهره‌برداری — بار، خطا، پشتیبان‌گیری و پشتیبانی — قابل نگهداری است. هر معیار باید قابل‌آزمون و مبتنی بر شواهد باشد.
تفاوت معیار پذیرش عملیاتی با پذیرش کاربر چیست؟
پذیرش کاربر (User Acceptance) می‌سنجد که سیستم نیاز کسب‌وکار را برآورده می‌کند. پذیرش عملیاتی می‌سنجد که سیستم قابل نگهداری است. یک سیستم می‌تواند از نظر کاربر بی‌نقص باشد اما از نظر عملیات غیرقابل‌اداره: بدون لاگ، بدون پایش، بدون مسیر بازیابی.
| معیار | پذیرش کاربر (UAT) | پذیرش عملیاتی (OAC) |
|---|---|---|
| پرسش | کارکرد درست است؟ | نگه‌داشتنی است؟ |
| پاسخ‌دهنده | کاربر نهایی | تیم عملیات/پشتیبانی |
| تمرکز | نیاز کسب‌وکار | قابلیت عملیات |
| نمونه معیار | محاسبهٔ درست فاکتور | بازیابی پشتیبان در بازهٔ هدف |
| شواهد | سناریوی کاربر | آزمون فنی و عملیاتی |
| خروجی | تأیید کارکرد | پذیرش مسئولیت |
نکته مهم: پذیرش عملیاتی، وتوی تیم عملیات نیست؛ توافقی از پیش تعریف‌شده است که مانع انتقال ریسک پنهان به عملیات می‌شود.
همین امروز به دوایتیفای بپیوندید
پروژه‌ها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفت‌ها و گزارش‌های تیم در یک محیط یکپارچه. ساخته‌شده برای شرکت‌ها، استارتاپ‌ها و تیم‌های دورکار — با راه‌اندازی چنددقیقه‌ای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
معیار پذیرش عملیاتی چه حوزه‌هایی را پوشش می‌دهد؟
هشت حوزهٔ اصلی وجود دارد:
- در دسترس بودن (Availability): درصد زمانی که سرویس باید فعال باشد.
- کارایی و ظرفیت (Performance): زمان پاسخ و تحمل بار در شرایط اوج.
- پایش و هشدار (Monitoring): پوشش مؤلفه‌های حیاتی و کیفیت هشدارها.
- پشتیبان و بازیابی (Backup & Restore): صحت پشتیبان و زمان بازگردانی هدف.
- امنیت و دسترسی (Security): کنترل نقش‌ها و مدیریت ورود.
- مستندات و Runbook: راهنمای عملیاتی بازبینی و آزمایش‌شده.
- پشتیبانی و سطح خدمت: SLA، مسیر ارجاع و مدیریت حادثه.
- تداوم و بازیابی از فاجعه: آمادگی برای رخدادهای بزرگ.
| حوزه | نمونهٔ معیار قابل‌آزمون | شواهد |
|---|---|---|
| در دسترس بودن | فعال بودن در بازهٔ هدف ماه | گزارش پایش ماهانه |
| کارایی | زمان پاسخ زیر حد هدف در بار اوج | نتیجهٔ آزمون بار |
| پایش | پوشش همهٔ مؤلفه‌های حیاتی | فهرست پایش |
| بازیابی | بازیابی در بازهٔ هدف | لاگ آزمون بازیابی |
| امنیت | بدون حساب بی‌مالک | گزارش دسترسی |
| مستندات | Runbook آزمایش‌شده | گزارش تمرین |
| پشتیبانی | مسیر ارجاع اعلام‌شده | سند SLA |
| تداوم | آزمون بازیابی فاجعه انجام‌شده | گزارش آزمون |
چگونه معیار پذیرش عملیاتی بنویسیم؟
معیار خوب، قابل‌آزمون و صریح است. چهار قاعده:
- قابل‌سنجش بنویسید: «سریع» معیار نیست؛ «زمان پاسخ زیر حد مشخص در بار اوج» معیار است.
- شواهد را مشخص کنید: هر معیار باید بگوید با چه سندی اثبات می‌شود.
- مالک بگذارید: چه کسی مسئول فراهم‌کردن شواهد است.
- سطح بحرانیت تعیین کنید: کدام معیارها توقف‌کننده و کدام‌ها شرطی‌اند.
مثال ضعیف: «سیستم باید پایدار باشد». مثال قوی: «سیستم در آزمون بار با X کاربر همزمان، زمان پاسخ زیر حد هدف و بدون خطای بحرانی داشته باشد؛ شواهد: گزارش آزمون بار؛ مالک: تیم فنی».
چک‌لیست پذیرش عملیاتی (Go-Live Readiness)
این جدول، معیارهای پذیرش را در قالب چک‌لیست پیش از تحویل جمع می‌کند:
| # | حوزه | معیار | شواهد | وضعیت |
|---|---|---|---|---|
| ۱ | در دسترس بودن | فعال در بازهٔ هدف | گزارش پایش | ☐ |
| ۲ | کارایی | پاسخ زیر حد هدف در اوج | آزمون بار | ☐ |
| ۳ | ظرفیت | حاشیهٔ ظرفیت هدف | تحلیل ظرفیت | ☐ |
| ۴ | پایش | پوشش مؤلفه‌های حیاتی | فهرست پایش | ☐ |
| ۵ | هشدار | هشدار مؤثر و بدون نویز زیاد | آزمون هشدار | ☐ |
| ۶ | پشتیبان | پشتیبان روزانهٔ سالم | گزارش پشتیبان | ☐ |
| ۷ | بازیابی | بازیابی در بازهٔ هدف | آزمون بازیابی | ☐ |
| ۸ | امنیت | کنترل نقش‌ها | گزارش دسترسی | ☐ |
| ۹ | مستندات | Runbook آزمایش‌شده | گزارش تمرین | ☐ |
| ۱۰ | پشتیبانی | SLA و مسیر ارجاع | سند SLA | ☐ |
| ۱۱ | تداوم | آزمون بازیابی فاجعه | گزارش آزمون | ☐ |
| ۱۲ | مالکیت | مالک سرویس تعیین‌شده | سند مالکیت | ☐ |
ترفند کاربردی: معیارها را در یک جلسه با حضور تیم پروژه و عملیات نهایی کنید؛ معیاری که یک‌طرفه نوشته شود، در لحظهٔ تحویل جنجالی می‌شود.
مثال‌های واقعی و قابل‌اندازه‌گیری
- سامانهٔ رزرو با بار اوج: معیار پذیرش «پاسخ زیر حد هدف در اوج» بود؛ آزمون نشان داد در بار اوج پاسخ کندتر از حد است. یک بهینه‌سازی پیش از تحویل، سرویس را به معیار رساند.
- پروژهٔ داده: معیار «بازیابی در بازهٔ هدف» در آزمون برآورده نشد؛ تنظیم فرایند پشتیبان، زمان بازگردانی را به بازهٔ قابل‌قبول رساند.
- سرویس مشتری‌محور: معیار «پوشش کامل پایش» ناقص بود؛ افزودن هشدار برای یک مؤلفهٔ حیاتی، از کشف دیرهنگام خطا در هفتهٔ اول جلوگیری کرد.
- تحویل زیرساخت: معیار «بدون حساب بی‌مالک» شناسایی دو دسترسی قدیمی را ممکن کرد که پیش از تحویل بسته شدند.
مزایا، معایب و Trade-off
| مزایا | معایب و محدودیت‌ها |
|---|---|
| پذیرش مبتنی بر شواهد و قابل‌دفاع | زمان‌بر بودن تدارک شواهد |
| کاهش ریسک انتقال به عملیات | خطر سختگیری بیش‌ازحد و تأخیر |
| شفافیت انتظارات دو تیم | نیاز به همکاری زودهنگام عملیات |
| جلوگیری از انتقال ریسک پنهان | وابستگی به بلوغ فرایندی |
Trade-off اصلی: معیار هرچه سختگیرانه‌تر باشد، ریسک عملیاتی کمتر اما تحویل دیرتر و هزینهٔ آزمون بیشتر می‌شود. راه درست، «معیار متناسب با ریسک سرویس» است: برای سرویس حیاتی سختگیرانه و برای تغییر کم‌ریسک سبک‌تر.
اشتباهات رایج
- نوشتن معیار مبهم: «پایدار» و «سریع» معیار نیستند؛ قابل‌سنجش بنویسید.
- تعیین معیار در لحظهٔ تحویل: معیارها باید از ابتدا توافق شوند.
- نبود شواهد: معیار بدون شواهد، فقط ادعاست.
- یک‌طرفه نوشتن: معیاری که با تیم پروژه هماهنگ نشود، غیرواقعی می‌ماند.
- بسنده دانستن UAT: عبور از پذیرش کاربر، پذیرش عملیاتی نیست.
- بی‌توجهی به سطح بحرانیت: همهٔ معیارها یک وزن ندارند؛ تفکیک کنید.
نکات کاربردی
- نکته مهم: معیار پذیرش عملیاتی را در آغاز پروژه، همراه با سایر معیارهای پذیرش بنویسید.
- ترفند کاربردی: هر معیار را به یک آزمون مشخص و یک شاهد متصل کنید.
- اشتباه رایج: پذیرش شفاهی بدون ثبت شواهد.
- قبل از شروع این را بدانید: اگر تیم عملیات در نوشتن معیارها حضور نداشته باشد، احتمالاً معیارها نیاز واقعی بهره‌برداری را پوشش نمی‌دهند.
دوایتفای و معیار پذیرش عملیاتی
معیار پذیرش عملیاتی مجموعه‌ای از موارد است که هر کدام باید وضعیت، مالک و شاهد داشته باشند. دوایتفای بستری است که این ساختار را ممکن می‌کند: تسک و زیرتسک چندلایه، چک‌لیست، مسئول تسک، ددلاین، وضعیت و پیشرفت کارها، وابستگی‌های WBS، مستندات پروژه، ریسک‌ها و محدودیت‌ها، Milestone و DOD، و گزارش‌های کاری و عملکرد. می‌توانید هر معیار پذیرش را به یک تسک با مالک و معیار تحقق تبدیل کنید و در لحظهٔ تصمیم، وضعیت شواهد را یک‌جا ببینید. Doitify Copilot و AI Coach نیز در ساخت و مدیریت این تسک‌ها، چک‌لیست‌ها و گزارش‌ها کمک می‌کنند. دوایتفای محصول ماست و این معرفی فقط در همین بخش مرتبط آمده است.
نمونهٔ معیار ضعیف در برابر معیار قوی
این جدول نشان می‌دهد چگونه یک معیار مبهم را به معیار قابل‌آزمون تبدیل کنیم:
| معیار ضعیف | مشکل | معیار قوی |
|---|---|---|
| سیستم سریع باشد | قابل‌سنجش نیست | زمان پاسخ زیر حد هدف در بار اوج |
| سیستم پایدار باشد | مبهم است | فعال در بازهٔ هدف در ماه |
| پشتیبان‌گیری انجام شود | معیار کیفیت ندارد | پشتیبان روزانهٔ سالم و آزمون بازیابی دوره‌ای |
| امنیت رعایت شود | غیرقابل‌آزمون | بدون حساب بی‌مالک و با کنترل نقش‌ها |
| مستندات کامل باشد | «کامل» چیست؟ | Runbook شامل رویه‌های اصلی و آزمایش‌شده |
| پشتیبانی وجود داشته باشد | مبهم است | SLA و مسیر ارجاع مشخص و اعلام‌شده |
ترفند کاربردی: برای هر معیار بپرسید «چطور می‌فهم این مورد تأمین شده؟». اگر پاسخ روشنی ندارید، معیار هنوز آماده نیست.
چطور بر سر معیارها به توافق برسیم؟
پذیرش عملیاتی یک مذاکرهٔ فنی است، نه یک ابلاغ. برای رسیدن به توافق:
- زود شروع کنید: معیارها را در آغاز پروژه و همراه با معیارهای پذیرش کاربر بنویسید.
- هزینه را شفاف کنید: هر معیار هزینهٔ زمان و منابع دارد؛ آن را روی میز بگذارید.
- ریسک را وزن کنید: اگر معیاری سختگیرانه است، بگویید جلوی چه ریسکی را می‌گیرد.
- تاریخ و مالک بگذارید: معیار بدون مالک، در عمل اجرا نمی‌شود.
- بازبینی دوره‌ای کنید: معیارها با تغییر سرویس باید به‌روز شوند.
اشتباه رایج: نوشتن معیارهای یک‌طرفه توسط تیم عملیات. معیاری که تیم پروژه در شکل‌گیری‌اش نقشی نداشته باشد، در لحظهٔ تحویل به دعوا تبدیل می‌شود.
چه کسانی باید در تعیین معیار حضور داشته باشند؟
- تیم عملیات: تأمین‌کنندهٔ معیارهای قابلیت نگهداری.
- تیم پروژه: تأمین‌کنندهٔ واقع‌گرایی فنی و برآورد هزینه.
- مالک کسب‌وکار: تعیین‌کنندهٔ وزن ریسک و سطح بحرانیت.
- تیم امنیت و انطباق: تضمین‌کنندهٔ الزامات.
معیار پذیرش عملیاتی و بدهی فنی
گاهی معیاری برآورده نمی‌شود و تصمیم گرفته می‌شود با شرط جلو برویم. در این حالت، معیار برآورده‌نشده به یک «بدهی عملیاتی» تبدیل می‌شود که باید صریح ثبت و پیگیری شود:
- ثبت صریح: بدهی را با معیار، اثر و سطح ریسک بنویسید، نه به‌صورت شفاهی.
- مالک و مهلت: هر بدهی باید مالک و تاریخ رفع داشته باشد.
- آستانهٔ پذیرش: مشخص کنید چه سطحی از بدهی عملیاتی مجاز است؛ بدهی بی‌سقف، ریسک انباشته می‌سازد.
- پایش دوره‌ای: بدهی‌های عملیاتی باید در جلسات دوره‌ای مرور شوند.
نکته مهم: «برو با شرط» بدون ثبت بدهی، در واقع «برو با فراموشی» است. شرطی که پیگیری نشود، وجود ندارد.
سوالات متداول
جمع‌بندی
Operational Acceptance Criteria پُلی است میان تحویل پروژه و انتقال رسمی مسئولیت. این معیارها با تمرکز بر قابلیت نگهداری، جلوی انتقال ریسک پنهان به تیم عملیات را می‌گیرند. برای نوشتن آن‌ها، قابل‌سنجش بنویسید، شواهد و مالک تعیین کنید، سطح بحرانیت را روشن کنید و از ابتدا با هر دو تیم توافق کنید. نتیجه، پذیرشی است که هم قابل‌دفاع است و هم پایدار.
اگر موضوع Operational Acceptance Criteria برایتان مفید بود، پیشنهاد می‌کنیم نمونه KPI برای فروش، مارکتینگ، HR، پروژه و پشتیبانی و مدیریت پروژه های ساختمانی را هم بخوانید.
همین امروز به دوایتیفای بپیوندید
پروژه‌ها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفت‌ها و گزارش‌های تیم در یک محیط یکپارچه. ساخته‌شده برای شرکت‌ها، استارتاپ‌ها و تیم‌های دورکار — با راه‌اندازی چنددقیقه‌ای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
