طراحی Workflow در جیرا: از وضعیت‌های اضافه تا فرایندی که گزارش می‌دهد

Workflow تنها جایی در Jira است که فرایند شما به شکل اجرایی نوشته می‌شود. هر گزارشی که بعداً می‌گیرید — زمان چرخه، نرخ تحویل، گلوگاه — از همین وضعیت‌ها ساخته می‌شود. اگر اینجا شلخته باشد، هیچ داشبوردی نجاتش نمی‌دهد.

این نوشته دربارهٔ نحوهٔ کلیک‌کردن در صفحهٔ ویرایش Workflow نیست؛ دربارهٔ تصمیم‌هایی است که قبل از آن باید بگیرید.

هر وضعیت اضافه، یک ستون خالی در گزارش شماست

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

هزینهٔ وضعیت اضافه فقط شلوغی بصری نیست. هر وضعیت یک ستون بالقوه روی Board است، یک شاخه در هر JQL، و یک نقطهٔ اختلاف بین دو گزارش. وقتی مدیر می‌پرسد «چند تا کار در جریان داریم؟» و دو نفر دو عدد متفاوت می‌دهند، ریشه‌اش تقریباً همیشه این است که هر کدام مجموعهٔ متفاوتی از وضعیت‌ها را «در جریان» حساب کرده‌اند.

قاعدهٔ عملی: هر وضعیت باید به یک سؤال مدیریتی جواب بدهد. اگر نمی‌توانید بگویید با دیدن آن وضعیت چه تصمیمی گرفته می‌شود، آن وضعیت وجود ندارد.

وضعیت‌هایی که در واقع وضعیت نیستند

• Waiting for Ali — این Assignee است، نه وضعیت. اگر ساختید، هر بار که علی عوض شود باید Workflow را ویرایش کنید.
• Urgent — این Priority است. وضعیت باید بگوید کار کجای مسیر است، نه چقدر مهم است.
• Frontend و Backend — این Component یا Label است. با ساختن وضعیت برایشان، ماتریس وضعیت‌ها ضربدری بزرگ می‌شود.
• Cancelled و Won't Do به‌عنوان دو وضعیت جدا — این‌ها یک وضعیت پایانی با دو Resolution متفاوت‌اند.

status، statusCategory و resolution سه چیز متفاوت‌اند

این سه‌تایی، منبع بیشترین سوءتفاهم در گزارش‌گیری Jira است.

نکتهٔ کلیدی: یک Issue تا وقتی resolution نگیرد، از نظر Jira باز است — حتی اگر وضعیتش Done باشد و در ستون آخر Board نشسته باشد. Burndown، Velocity و بیشتر گجت‌های داشبورد به resolution نگاه می‌کنند، نه به اسم وضعیت. همین موضوع در نوشتن کوئری هم بزرگ‌ترین تلهٔ کار است؛ در راهنمای عملی JQL کامل بازش کرده‌ام.

برعکسش هم خطرناک است: اگر Transition برگشت از Done به In Progress فیلد resolution را پاک نکند، Issue هم‌زمان «باز» و «حل‌شده» می‌ماند و از هر دو گزارش می‌افتد. برای همین هر Transition خروجی از وضعیت پایانی باید یک Post Function با اقدام «پاک‌کردن resolution» داشته باشد.

چهار ابزاری که روی هر Transition دارید

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

1. Condition — چه کسی این دکمه را می‌بیند. اگر شرط برقرار نباشد، دکمهٔ Transition اصلاً نمایش داده نمی‌شود. مثال واقعی: انتقال به Approved فقط برای نقش Project Lead دیده شود.
2. Validator — با چه اطلاعاتی اجازهٔ عبور دارد. دکمه دیده می‌شود، ولی اگر شرط برقرار نباشد با خطا رد می‌شود. مثال: انتقال به Done بدون پرکردن فیلد Root Cause ممکن نباشد.
3. Post Function — بعد از عبور چه اتفاقی بیفتد. ست‌کردن resolution، خالی‌کردنش، تخصیص خودکار، افزودن کامنت سیستمی.
4. Trigger — چه رویداد بیرونی این انتقال را خودکار انجام بدهد. مثلاً باز شدن Pull Request در ابزار گیت، Issue را به In Review ببرد.

اشتباهی که تقریباً همه می‌کنند

وقتی می‌خواهیم مطمئن شویم فیلدی پر می‌شود، وسوسه این است که آن را روی Screen اجباری کنیم. مشکل: Screen ساخت Issue همان اول کار نمایش داده می‌شود، جایی که هنوز جواب آن سؤال معلوم نیست.

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

با داده تصمیم بگیرید، نه با وایت‌برد

قبل از بازطراحی، از محیط خودتان بپرسید چه چیزی واقعاً استفاده می‌شود. چند کوئری که همیشه اجرا می‌کنم:

-- Has this status been used at all in the last 90 days?
-- Zero results means the status is dead. Delete it.
project = OPS AND status WAS "In Review" AFTER -90d

-- Work that bounced back out of Done
project = OPS AND status CHANGED FROM "Done" AFTER -90d

-- Stalled work: no status change for 14 days
project = OPS
  AND statusCategory != Done
  AND NOT status CHANGED AFTER -14d
ORDER BY updated ASC

وضعیتی که کوئری اولش صفر برمی‌گرداند، بدون بحث حذف می‌شود. نرخ بالای کوئری دوم یعنی Definition of Done شما روشن نیست — مشکل در وضعیت‌ها نیست، در توافق تیم است.

یک Workflow مینیمال که در عمل جواب می‌دهد

برای یک تیم نرم‌افزاری، این پنج وضعیت تقریباً همیشه کافی است:

To Do  ->  In Progress  ->  In Review  ->  Done
              ^                 |
              +---- Reopened ---+

statusCategory mapping:
  To Do        ->  To Do
  In Progress  ->  In Progress
  In Review    ->  In Progress
  Reopened     ->  In Progress
  Done         ->  Done    + Post Function: set resolution

برای یک تیم پشتیبانی یا IT، شکل متفاوت است چون انتظار برای طرف مقابل یک حالت واقعی است و باید از زمان چرخه کسر شود:

Open  ->  In Progress  ->  Waiting for Customer  ->  Resolved  ->  Closed
                     ^                        |
                     +------------------------+

یک Workflow برای چند پروژه، نه یکی برای هر پروژه

Workflow Scheme اجازه می‌دهد یک Workflow بین ده پروژه مشترک باشد. وقتی این کار نشود، بعد از دو سال بیست Workflow تقریباً یکسان دارید که هیچ‌کس جرئت دست‌زدن به هیچ‌کدامشان را ندارد — چون معلوم نیست کدام پروژه به کدام وصل است.

پیشنهاد من: با دو یا سه Workflow پایه شروع کنید (مثلاً «تحویل نرم‌افزار»، «درخواست خدمت»، «کار عملیاتی») و پروژهٔ جدید را به یکی از آن‌ها وصل کنید. انحراف فقط وقتی مجاز است که یک نفر بتواند توضیح بدهد چرا فرایند این تیم ذاتاً فرق دارد.

تفاوت Cloud و Data Center که باید بدانید

در Jira Cloud دو نوع پروژه وجود دارد و این تفاوت مستقیماً روی Workflow اثر می‌گذارد. اگر هنوز بین دو نسخه تصمیم نگرفته‌اید، Jira Cloud یا Data Center را اول بخوانید:

• Team-managed — تیم خودش وضعیت‌ها را می‌سازد. سریع است و برای شروع خوب، ولی کانفیگش مال همان پروژه است و بین پروژه‌ها مشترک نمی‌شود. برای سازمانی که می‌خواهد گزارش یکپارچه بگیرد، معمولاً انتخاب اشتباهی است.
• Company-managed — Schemeهای مشترک، Condition و Validator کامل، و همان مدلی که در Data Center می‌شناسید. اگر چند تیم قرار است با هم مقایسه شوند، از اول همین را انتخاب کنید.

در Jira Data Center فقط مدل Schemeمحور وجود دارد و در عوض به Post Functionها و افزونه‌های بیشتری دسترسی دارید. مهاجرت از Team-managed به Company-managed ممکن است ولی بی‌دردسر نیست؛ همان اول درست انتخاب کنید.

جمع‌بندی

کمترین تعداد وضعیتی که به سؤال‌های مدیریتی شما جواب می‌دهد، بهترین Workflow است. resolution را جدی بگیرید، Validator را جای فیلد اجباری بنشانید، و قبل از هر بازطراحی از خود Jira بپرسید چه چیزی واقعاً استفاده می‌شود.

اگر می‌خواهید این کار روی محیط خودتان انجام شود، طراحی Workflow و Board دقیقاً همین است. اگر مشکل شما در خروجی است نه در فرایند، احتمالاً داشبورد و گزارش مدیریتی نقطهٔ درست شروع است.