نویسنده: WKFGo Editorial · ·
«انجام شد» در Slack — QA اصلاً ندید
توسعه‌دهنده تسک را «انجام‌شد» علامت می‌زند، همان روز کد در نسخهٔ تولید می‌رود، و باگ در تولید سر بر می‌آورد — چون هیچ بازبینی واقعی بین این دو مرحله نبود. ارسال برای بازبینی (submit_for_review) این شکاف را می‌بندد: تسک وارد صف بازبین می‌شود، دارندهٔ مجوز TASK_APPROVAL با تصمیم تأیید (decide_approval) پاسخ می‌دهد، و کل مسیر در تاریخچهٔ تسک ثبت می‌ماند — بدون رشتهٔ ایمیل گم‌شده.
علائم و هزینه
| علامت | هزینه |
|---|---|
| «انجام‌شد» غیررسمی بدون گیت | نقص از دید بازبین پنهان می‌ماند |
| بازبینی در ایمیل جدا از تسک | رشتهٔ گفتگو گم می‌شود |
| بازبین بدون مهلت مشخص | صف روزها معطل می‌ماند |
| رد کردن بدون توضیح | چرخهٔ دوباره‌کاری بی‌پایان |
چارچوب ۷ مرحله‌ای
۱. تعریف «انجام‌شدن» شامل بازبینی باشد
برای تسک‌های پرریسک، «انجام‌شد» بدون تأیید بازبین معتبر نیست — این قانون را در تعریف انجام‌شدن تیم بنویسید، نه فقط در ذهن یک نفر.
۲. ارسال برای بازبینی با یک کلیک
از رابط وب یا از داخل ویرایشگر با ابزار MCP، ارسال برای بازبینی (submit_for_review) باید کمتر از یک دقیقه طول بکشد — هرچه اصطکاک کمتر، پذیرش بیشتر.
۳. بازبین مشخص، نه کل تیم
هر تسک باید یک بازبین نام‌دار داشته باشد؛ فرستادن به «هرکسی که وقت دارد» یعنی در عمل هیچ‌کس مسئول نیست.
۴. تصمیم تأیید با یادداشت عملی
تصمیم تأیید (decide_approval) باید همراه با دلیل تأیید یا رد ثبت شود — رد بدون توضیح فقط دوباره‌کاری کور تولید می‌کند.
۵. فهرست تأییدهای در انتظار، هر روز
مدیر پروژه با فهرست تأییدهای در انتظار (list_pending_approvals) صف را روزانه مرور کند تا هیچ تسکی چند روز بدون پاسخ نماند.
۶. گیت انتشار را وصل کنید
هیچ تسکی بدون تأیید نباید وارد انتشار شود — این قانون را در چک‌لیست انتشار بنویسید، نه فقط در توافق شفاهی.
۷. زمان چرخهٔ بازبینی را بسنجید
هر هفته زمان بین ارسال و تصمیم را اندازه بگیرید؛ اگر صف رشد می‌کند، مشکل معمولاً ظرفیت بازبین است نه ابزار.
نقش WKFGo
WKFGo این گردش‌کار را با سه ابزار به هم وصل می‌کند: ارسال برای بازبینی (submit_for_review) که برای تغییر وضعیت تسک به TASK_EDIT نیاز دارد؛ فهرست تأییدهای در انتظار (list_pending_approvals) با سطح مشاهده TASK_APPROVAL؛ و تصمیم تأیید (decide_approval) با سطح ویرایش همان مجوز. کلید read-only نیز هیچ‌یک از عملیات نوشتنی را اجرا نمی‌کند. این تفکیک مهم است: تحویل‌دهنده حق ارسال دارد، اما الزاماً حق تأیید کار خودش را ندارد.
شروع عملی در همین هفته
یک نوع کار پرریسک، مثل تغییر احراز هویت یا گزارش مالی، انتخاب کنید. تعریف انجام‌شدن، بازبین اصلی، جانشین و زمان پاسخ مورد انتظار را در ویکی بنویسید. سپس پنج تسک واقعی را از ارسال تا تصمیم دنبال کنید؛ rollout را با همه تسک‌ها شروع نکنید.
سناریوهای رایج (یکی را انتخاب کنید)
تغییر کد توسط عامل AI. عامل با submit_for_review گزارش ساخت‌یافته، فایل‌های تغییرکرده و اطلاعات شاخه یا کامیت را تحویل می‌دهد؛ انسان تصمیم نهایی را می‌گیرد.
تحویل محتوای مشتری. تولیدکننده فایل را آماده می‌کند، صاحب حساب صحت پیام و دامنه انتشار را تأیید می‌کند و ردشدن با اقدام اصلاحی مشخص برمی‌گردد.
عملیات مالی. سازنده ورودی نمی‌تواند همان ورودی را تأیید کند. مجوز ارسال و تصمیم را میان دو هویت جدا تقسیم کنید.
متریک‌هایی که باید بسنجید (روند، نه benchmark ساختگی)
میانه زمان از ارسال تا اولین تصمیم، درصد ردشدن با توضیح قابل اقدام، تعداد آیتم‌های مانده خارج از SLA و نرخ برگشت پس از تأیید را طی ۴ تا ۶ هفته رصد کنید. کاهش نرخ ردشدن همیشه موفقیت نیست؛ شاید بازبینی سطحی شده باشد. زمان چرخه و نقص پس از تأیید را کنار هم بخوانید.
الگوهای ضدِمقابل — این کارها را نکنید
- همه تسک‌ها را بدون توجه به ریسک وارد یک صف نکنید؛ صف شلوغ، کار مهم را پنهان می‌کند.
- از بازبین بدون نام یا SLA استفاده نکنید؛ «هرکس فرصت داشت» مالک نیست.
- رد را فقط با «اصلاح شود» ثبت نکنید؛ رفتار مورد انتظار و شاهد شکست را بنویسید.
- تأیید داخل چت را جای تصمیم ثبت‌شده نگذارید؛ تاریخچه قابل جست‌وجو از بین می‌رود.
- تحویل‌دهنده را به‌طور پیش‌فرض تأییدکننده همان کار نکنید.
نکته برای مدیر پروژه فارسی‌زبان
نام وضعیت و یادداشت بازبینی را طوری بنویسید که برای تیم فارسی‌زبان عملی باشد؛ اصطلاح انگلیسی مبهم را صرفاً ترجمه لفظی نکنید. تقویم نمایش و زبان رابط به رفع اصطکاک کمک می‌کنند، اما کیفیت معیار پذیرش و دلیل رد همچنان مسئولیت تیم است.
سؤالات متداول
آیا همهٔ تسک‌ها باید بازبینی شوند؟
نه لزوماً — فقط تسک‌های پرریسک یا مرتبط با انتشار به گیت نیاز دارند؛ بقیه می‌توانند مسیر ساده‌تری داشته باشند.
آیا خودبازبینی مجاز است؟
فقط برای کارهای کم‌ریسک؛ برای هر چیزی که روی مشتری یا داده اثر دارد، بازبین دوم لازم است.
تأیید مشتری خارجی چطور؟
اگر سند رسمی لازم است، از گردش امضای دیجیتال کنار همین صف تأیید استفاده کنید.
آیا توسعه‌دهنده می‌تواند از داخل ویرایشگر ارسال کند؟
بله — با ابزار MCP، پس از موفق‌بودن تست‌ها و آماده‌شدن گزارش تغییر، submit_for_review مستقیماً از Cursor یا Claude قابل صدازدن است. end_work بستن session است و می‌تواند قبل یا بعد از تحویل انجام شود؛ خودش جای ارسال برای بازبینی را نمی‌گیرد.
همین امروز شروع کنید
منابع دست‌اول و روش راستی‌آزمایی
این فهرست برای بررسی بیشتر است؛ لینک‌های داخل متن، منبع ادعای مشخص همان بخش‌اند.