وقتی یک تسک «در حال انجام» است، آیا کسی واقعاً روی آن کار میکند یا منتظر پاسخ مشتری مانده است؟ وقتی «انجامشده» اعلام میشود، آیا خروجی بررسی شده یا فقط مجری کارش را تمام کرده است؟ ابهام در همین دو پرسش کافی است تا برد کار، تصویری نادرست از پیشرفت پروژه نشان دهد.
گردش وضعیت تسکها یا status workflow مشخص میکند هر کار از چه مرحلههایی عبور میکند، چه زمانی اجازه جابهجایی دارد و چه کسی مسئول انتقال آن است. برای طراحی گردش کار مفید، ابتدا باید معنای وضعیتها را روشن کنید؛ سپس قواعد ورود، خروج و برگشت بین آنها را بنویسید.
status workflow چیست و چه تفاوتی با فهرست وضعیتها دارد؟
فهرست وضعیتها فقط نام مرحلههاست؛ مثلاً «آماده»، «در حال انجام» و «انجامشده». گردش وضعیت، علاوه بر این نامها، مسیرهای مجاز و شرایط حرکت بین آنها را تعریف میکند.
هر گردش کار چهار جزء اصلی دارد:
- وضعیت: موقعیت فعلی تسک در فرایند.
- انتقال: حرکت از یک وضعیت به وضعیت دیگر.
- شرط انتقال: چیزی که باید پیش از جابهجایی برقرار باشد.
- مسئول انتقال: فرد یا نقشی که جابهجایی را انجام میدهد یا تأیید میکند.
برای مثال، انتقال از «در حال انجام» به «در انتظار بررسی» میتواند مشروط به ثبت پیوند خروجی و تکمیل چکلیست تحویل باشد. انتقال بعدی به «انجامشده» هم ممکن است به تأیید بررسیکننده نیاز داشته باشد.
وضعیت باید مرحله فرایند را نشان دهد، نه اهمیت یا نوع کار را. «فوری» اولویت است، «طراحی» نوع فعالیت است و «علی» مسئول تسک؛ هیچکدام بهتنهایی وضعیت مناسبی نیستند.
طراحی مراحل کار را از فرایند واقعی شروع کنید
بهجای انتخاب ستونهای آماده، چند تسک معمول تیم را از زمان درخواست تا تحویل مرور کنید. ببینید کجا کار شروع میشود، کجا منتظر میماند و در چه نقطههایی مسئولیت تغییر میکند.
۱. نقطه شروع و پایان را مشخص کنید
آیا درخواست تازه فوراً وارد کار میشود یا ابتدا باید بررسی و اولویتبندی شود؟ آیا پایان کار، تولید خروجی است یا تأیید و تحویل آن؟
برای نمونه، در تیم محتوا ممکن است نوشتن متن پایان فعالیت نویسنده باشد، اما پایان تسک زمانی است که متن ویرایش و آماده انتشار شده باشد. اگر این مرز روشن نباشد، هر فرد تعریف متفاوتی از «تمامشدن» خواهد داشت.
۲. فقط مرحلههای دارای معنای مستقل را جدا کنید
یک مرحله زمانی ارزش دارد که دستکم یکی از این موارد در آن تغییر کند:
- مسئول انجام یا بررسی کار؛
- شرط ورود یا خروج؛
- نوع فعالیت؛
- صف انتظار قابل پیگیری.
اگر «شروعشده» و «در حال انجام» هیچ تفاوت عملی ندارند، یکی را حذف کنید. در مقابل، ادغام «در حال انجام» و «در انتظار بررسی» میتواند صف بررسی را پنهان کند.
۳. برای هر وضعیت تعریف قابل تشخیص بنویسید
تعریف وضعیت نباید فقط بازنویسی نام آن باشد. جمله «در حال انجام یعنی کار در حال انجام است» ابهام را حل نمیکند.
تعریف بهتر این است: «مسئول مشخص شده، پیشنیازهای شروع فراهم است و اجرای کار آغاز شده است.» با چنین تعریفی، تسکی که فقط به فردی اختصاص یافته اما هنوز شروع نشده، در این وضعیت قرار نمیگیرد.
یک الگوی پایه برای گردش وضعیت تسکها
این الگو نقطه شروع است، نه نسخه ثابت برای همه تیمها:
| وضعیت | معنای عملی | شرط خروج |
|---|---|---|
| ورودی | درخواست ثبت شده، اما هنوز ارزیابی نشده است | تصمیم درباره پذیرش، رد یا نیاز به اطلاعات بیشتر |
| آماده انجام | کار پذیرفته شده و اطلاعات لازم برای شروع موجود است | تعیین مسئول و شروع واقعی کار |
| در حال انجام | اجرای کار آغاز شده است | آمادهشدن خروجی برای بررسی |
| در انتظار بررسی | خروجی تحویل شده و منتظر ارزیابی است | تأیید یا ثبت اصلاحات لازم |
| انجامشده | خروجی مطابق معیار توافقشده پذیرفته شده است | معمولاً پایان مسیر؛ مگر بازگشایی با دلیل |
| لغوشده | تصمیم گرفته شده کار ادامه پیدا نکند | ثبت دلیل لغو و تعیین تکلیف وابستگیها |
تیم کوچک ممکن است وضعیت «ورودی» را نیاز نداشته باشد. تیمی با تأیید رسمی مشتری نیز ممکن است «در انتظار تأیید مشتری» را جدا کند. ملاک، نیاز واقعی به تصمیمگیری و پیگیری است، نه شلوغتر کردن برد.
«مسدود» وضعیت باشد یا نشانه؟
مسدودشدن همیشه یک مرحله مستقل نیست. تسک ممکن است هنگام اجرا یا بررسی به مانع بخورد. اگر فقط به ستون «مسدود» منتقل شود، اطلاعات مرحله قبلی آن از دست میرود.
در ابزارهایی که امکان ثبت مانع جدا از وضعیت وجود دارد، میتوان مرحله اصلی را حفظ کرد و دلیل توقف، مسئول رفع مانع و زمان پیگیری را ثبت کرد. اگر ابزار چنین امکانی ندارد، یک وضعیت مستقل هم قابل استفاده است؛ به شرط آنکه مرحله بازگشت مشخص باشد.
همچنین «منتظر پاسخ» را با «مسدود» یکسان نگیرید. انتظار برنامهریزیشده برای تأیید با مانعی که ادامه کار را ناممکن کرده، یک معنا ندارد.
قواعد انتقال را چگونه بنویسیم؟
برای هر مسیر مهم، یک قاعده کوتاه بنویسید:
تسک از «وضعیت مبدأ» به «وضعیت مقصد» میرود، وقتی «شرط مشخص» برقرار باشد؛ انتقال را «نقش مسئول» انجام میدهد و «اطلاعات لازم» ثبت میشود.
نمونه قواعد برای یک فرایند عمومی:
| انتقال | شرط لازم | مسئول پیشنهادی |
|---|---|---|
| ورودی ← آماده انجام | هدف، خروجی مورد انتظار و اولویت روشن باشد | مسئول برنامهریزی |
| آماده انجام ← در حال انجام | مسئول مشخص و پیشنیازها فراهم باشد | مجری کار |
| در حال انجام ← در انتظار بررسی | خروجی و شواهد تکمیل ثبت شده باشد | مجری کار |
| در انتظار بررسی ← انجامشده | معیارهای پذیرش تأیید شده باشد | بررسیکننده |
| در انتظار بررسی ← در حال انجام | اصلاحات مشخص و قابل اقدام ثبت شده باشد | بررسیکننده |
در جدول بالا، مسیر هر ردیف از وضعیت سمت راستِ پیکان به وضعیت سمت چپ آن است؛ مثلاً «ورودی» به «آماده انجام».
شرط انتقال را قابل بررسی کنید
«کیفیت مناسب باشد» شرط مبهمی است. «خروجی با سه معیار پذیرش ثبتشده مطابقت داشته باشد» قابل بررسی است.
برای انتقال به بررسی، بسته به نوع کار میتوان این موارد را لازم دانست:
- پیوند یا فایل خروجی موجود باشد؛
- بخشهای الزامی تکمیل شده باشند؛
- زیروظیفههای مرتبط تعیین تکلیف شده باشند؛
- محدودیتها یا موارد حلنشده توضیح داده شده باشند.
هرچه شرطها بیشتر شوند، هزینه نگهداری فرایند هم بالاتر میرود. فقط اطلاعاتی را اجباری کنید که نبودشان واقعاً باعث توقف، خطا یا دوبارهکاری میشود.
انتقال مستقیم و برگشت را تعیین تکلیف کنید
آیا تسک میتواند از «آماده انجام» مستقیماً به «انجامشده» برود؟ برای کاری ساده شاید بله؛ برای خروجی نیازمند کنترل کیفیت، احتمالاً نه. استثنا را بر اساس نوع کار تعریف کنید، نه سلیقه افراد.
برگشت از بررسی نیز باید همراه با توضیح باشد. «نیاز به اصلاح دارد» کافی نیست؛ باید معلوم شود چه چیزی تغییر کند و چه معیاری برای بررسی دوباره استفاده خواهد شد.
معیار شروع و معیار پایان را جدا کنید
دو توافق، بخش بزرگی از ابهام گردش کار را برطرف میکنند:
معیار آمادگی: چه اطلاعات و پیشنیازهایی لازم است تا کار شروع شود؟
معیار تکمیل: چه شواهدی نشان میدهد کار واقعاً تمام شده است؟
برای یک تسک تولید مقاله، معیار آمادگی میتواند شامل موضوع، مخاطب، هدف و الزامات تحویل باشد. معیار تکمیل ممکن است شامل تأیید متن، بررسی پیوندها و تحویل نسخه نهایی باشد.
معیار تکمیل مشترک تیم با معیار پذیرش اختصاصی تسک فرق دارد. اولی استاندارد عمومی تحویل است؛ دومی میگوید همین خروجی خاص باید چه نیازهایی را پاسخ دهد. هر دو باید پیش از پایان کار روشن باشند.
نمونه عملی: گردش کار یک درخواست طراحی
فرض کنید تیم باید یک بنر برای صفحه محصول آماده کند. مسیر پیشنهادی چنین است:
- ورودی: درخواست ثبت میشود، اما اندازه و متن بنر ناقص است.
- آماده انجام: متن، ابعاد، هدف و مرجع تأیید مشخص میشوند.
- در حال انجام: طراح اجرای کار را آغاز میکند.
- در انتظار بررسی: نسخه پیشنهادی همراه با توضیحات لازم تحویل میشود.
- بازگشت به اجرا: بررسیکننده اصلاح مشخصی، مثلاً تغییر خوانایی متن، ثبت میکند.
- انجامشده: نسخه اصلاحشده تأیید و خروجی توافقشده تحویل میشود.
اگر متن نهایی هنوز نرسیده باشد، تسک نباید صرفاً برای نشاندادن پیشرفت وارد «در حال انجام» شود. اگر هم پس از تأیید، درخواست تازهای برای طراحی متفاوت مطرح شود، ممکن است ساخت تسک جدید از بازگشایی کار قبلی شفافتر باشد.
قاعده پیشنهادی این است: نقص در خروجی توافقشده میتواند دلیل بازگشایی باشد؛ تغییر دامنه کار باید جداگانه ارزیابی شود.
گردش کار را اجرا، مشاهده و اصلاح کنید
پیش از اجرای عمومی، الگو را روی چند نمونه معمول و استثنایی مرور کنید: کار فوری، تسک لغوشده، خروجی ردشده و کاری که به تیم دیگری وابسته است.
سپس گردش کار را با مسئولان اجرا و بررسی به اشتراک بگذارید. نام وضعیتها بدون توافق مشترک، رفتار مشترک ایجاد نمیکند.
در بازبینیهای بعدی به این نشانهها توجه کنید:
- تجمع تسک در یک مرحله: شاید ظرفیت آن مرحله کم باشد یا شرط خروج مبهم باشد.
- برگشتهای مکرر: شاید درخواست اولیه یا معیار پذیرش روشن نباشد.
- جابهجایی بدون تغییر واقعی: احتمالاً وضعیتها بیشازحد زیاد یا مشابهاند.
- ماندن طولانی در اجرا: ممکن است مانعها و زمان انتظار ثبت نشوند.
اگر داده لازم در دسترس باشد، زمان ماندن در هر وضعیت و فاصله شروع تا تکمیل را بررسی کنید؛ اما این اعداد را بدون توجه به اندازه و نوع کار، معیار قضاوت درباره افراد قرار ندهید.
برای مرحلههای پرتراکم، محدودیت کار همزمان تعیین کنید. هدف، جلوگیری از شروع بیرویه کارهای تازه است، نه اضافهکردن یک قانون تشریفاتی. وقتی صف بررسی پر میشود، کمک به تخلیه آن ممکن است از شروع تسک بعدی مفیدتر باشد.
سوالات متداول
چند وضعیت برای یک گردش کار مناسب است؟
عدد ثابتی وجود ندارد. از کمترین تعداد لازم شروع کنید و فقط وقتی مرحله تازه اضافه کنید که مسئولیت، شرط خروج یا صف انتظار مستقلی داشته باشد.
آیا همه پروژهها باید گردش وضعیت یکسان داشته باشند؟
خیر. میتوان چند تعریف مشترک، مانند «انجامشده»، داشت و جزئیات مسیر را برای نوع کار تغییر داد. یکسانسازی نباید تفاوت واقعی فرایندها را پنهان کند.
آیا تغییر وضعیت باید خودکار باشد؟
فقط وقتی رویداد محرک و شرط انتقال قابل اعتماد باشند. خودکارسازی برای انتقالهای تکراری مفید است، اما وجود فایل خروجی بهتنهایی به معنی تأیید کیفیت نیست.
با تسکهای موازی چگونه برخورد کنیم؟
اگر چند فعالیت مستقل با مسئولان متفاوت وجود دارد، آنها را به زیروظیفه یا تسکهای جدا تقسیم کنید. وضعیت تسک اصلی باید طبق یک قاعده مشخص، وضعیت کل خروجی را بیان کند.
تسکیـ چگونه اجرای گردش وضعیت را سادهتر میکند؟
بعد از تعریف مرحلهها و قواعد، لازم است تیم آنها را در یک فضای مشترک اجرا و پیگیری کند. تسکیـ نرمافزار ایرانی مدیریت پروژه و وظایف برای تیمهاست و با برد کانبان و نمای فهرست، مدیریت کارها و مرور جریان آنها را سادهتر میکند.
برای شروع، این مسیر را دنبال کنید:
- قواعد وضعیتها، معیار آمادگی و معیار تکمیل را در مستندات و ویکی تیمی بنویسید.
- کارها را به وظایف و زیروظیفههای قابل پیگیری تبدیل کنید.
- برای پیشنیازهای زمانی، از چارت گانت و وابستگیها استفاده کنید.
- درخواستهای ورودی را با فرمساز و مدیریت درخواستها سامان دهید.
- از قابلیت خودکارسازی جریان کار برای بخشهای تکراری، متناسب با قواعد تعریفشده، استفاده کنید.
در مثال درخواست طراحی، اطلاعات اولیه از مسیر مدیریت درخواستها جمعآوری میشود، آمادهسازی و بررسی خروجی در وظایف ثبت میشود و توافقهای تحویل در ویکی تیمی قرار میگیرد. این ساختار کمک میکند تصمیمها از گفتوگوهای پراکنده جدا و قابل مراجعه شوند.
تقویم شمسی، راستبهچپ کامل و پشتیبانی فارسی نیز استفاده روزمره را برای تیم فارسیزبان آسانتر میکنند. ابزار جای توافق تیم را نمیگیرد؛ ارزش آن در اجرای منظم همان توافق است.
برای شروع، یک فرایند پرتکرار را انتخاب کنید، وضعیتهایش را تعریف کنید و قواعد انتقال را روی چند تسک واقعی بیازمایید. تسکیـ پلن رایگان همیشگی و بدون پیشپرداخت دارد؛ میتوانید از شروع رایگان با تسکیـ برای تبدیل این الگو به روال کاری تیم استفاده کنید.