«تیم ما سریع کار میکند» یک ادعاست؛ «میانگین زمان انجام هر تسک ۳ روز است» یک داده. فرق این دو، دقیقاً تفاوت بین قضاوت ذهنی و اندازهگیری واقعی است. در سیستم کانبان، این اندازهگیری با معیاری به نام Cycle Time انجام میشود و بدون آن، هر بحثی دربارهٔ سرعت تیم، حدس و گمان است.
در این مقاله میبینید Cycle Time چیست، چه فرقی با Lead Time دارد، چطور محاسبه و تحلیل میشود، چه رابطهای با قانون لیتل و Flow Efficiency دارد، چطور با صدکها پیشبینی کنید و از کجا گلوگاههای جریان کار را پیدا کنید.
Cycle Time چیست؟ (پاسخ سریع)
Cycle Time (زمان چرخه) مدت زمانی است که یک کار از لحظهای که واقعاً شروع به انجام میشود تا لحظهای که تحویل میشود طول میکشد. به بیان ساده، «یک کار چقدر در دست تیم طول میکشد تا تمام شود». این معیار یکی از پایههای تحلیل جریان کار در کانبان است و سرعت واقعی تیم را از قضاوت ذهنی به عدد تبدیل میکند.
Cycle Time در برابر Lead Time
این دو معیار اغلب اشتباه گرفته میشوند:
| معیار | از کجا | تا کجا | چه چیزی را نشان میدهد |
|---|---|---|---|
| Lead Time | لحظهٔ ثبت درخواست | تحویل به مشتری | تجربهٔ کامل مشتری |
| Cycle Time | لحظهٔ شروع کار | تحویل | سرعت واقعی تیم |
مثال: اگر مشتری روز اول درخواستی ثبت کند، تیم روز پنجم شروع کند و روز هشتم تحویل دهد، Lead Time هشت روز و Cycle Time سه روز است. تفاوت این دو (پنج روز)، زمان «انتظار» است — که خودش یک فرصت بهبود مهم و اغلب بزرگترین فرصت است.
همین امروز به دوایتیفای بپیوندید
پروژهها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفتها و گزارشهای تیم در یک محیط یکپارچه. ساختهشده برای شرکتها، استارتاپها و تیمهای دورکار — با راهاندازی چنددقیقهای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
چرا Cycle Time مهم است؟
- پیشبینیپذیری: وقتی توزیع Cycle Time را بدانید، میتوانید تخمین بزنید یک کار جدید با چه اطمینانی کی تمام میشود.
- تشخیص گلوگاه: اگر Cycle Time بالا میرود، یعنی در جریان کار جایی گیر کرده است.
- تحویل سریعتر: کاهش Cycle Time یعنی ارزش سریعتر به دست کاربر میرسد.
- رضایت مشتری: زمان انتظار کمتر، تجربهٔ بهتر.
- کاهش کار در جریان: Cycle Time پایین معمولاً یعنی WIP پایین و جریان روانتر.
چطور Cycle Time را محاسبه کنیم؟
فرمول ساده است:
> Cycle Time = تاریخ تحویل − تاریخ شروع
مثلاً اگر تسکی در ۱۰ مرداد شروع و در ۱۳ مرداد تحویل شده، Cycle Time آن ۳ روز است. اما یک عدد بهتنهایی فریبنده است؛ برای تحلیل واقعی، توزیع را ببینید:
- میانگین: تصویر کلی را نشان میدهد اما نسبت به دادههای پرت حساس است.
- میانه: نقطهٔ وسط؛ مقاومتر از میانگین در برابر دادههای پرت.
- صدک (Percentile): مثلاً صدک ۸۵ میگوید ۸۵ درصد کارها در چند روز تمام میشوند؛ این معیار برای قولدادن زمان به مشتری بسیار مناسبتر است.
رابطهٔ Cycle Time با قانون لیتل
در سیستمهای جریان پایدار، رابطهای معروف به نام قانون لیتل برقرار است:
> Cycle Time ≈ WIP ÷ Throughput
یعنی زمان چرخه، تقریباً برابر است با تعداد کارهای در جریان تقسیم بر نرخ تحویل. نتیجهٔ عملی ساده اما مهم: اگر WIP را کم کنید، Cycle Time کوتاه میشود — بدون اینکه لازم باشد تیم سریعتر کار کند. این شاید مؤثرترین و در عین حال کمتنشترین اهرم بهبود جریان است.
Cycle Time و Flow Efficiency
یک معیار مکمل برای اینکه بفهمید چقدر از زمان چرخه واقعاً صرف «کار» میشود، بازدهی جریان (Flow Efficiency) است:
> Flow Efficiency = زمان کارِ واقعی ÷ Cycle Time
مثلاً اگر Cycle Time یک تسک ۸ روز باشد اما فقط ۲ روز آن صرف کار واقعی و ۶ روزش در انتظار تأیید یا در صف بماند، بازدهی جریان فقط ۲۵ درصد است. این عدد، بزرگیِ فرصت بهبود را نشان میدهد: بیشتر وقت تلفشده، صرف «انتظار» است، نه «انجام». کاهش زمان انتظار، سریعترین راه کوتاهکردن چرخه است.
مثال عددی ۱: محاسبهٔ ساده
تسکی ساعت ۹ صبح روز دوشنبه وارد ستون «در حال انجام» میشود و ساعت ۵ عصر روز چهارشنبه بسته میشود. Cycle Time آن دو روز و نیم است. اگر ده تسک اینطوری را بررسی کنید و میانگینشان حدود ۳ روز باشد، میتوانید بگویید «کار معمولاً در حدود ۳ روز تمام میشود».
مثال عددی ۲: اثر WIP بر Cycle Time
فرض کنید تیمی با ظرفیت تحویل ۲ تسک در روز، ۱۰ کار را همزمان شروع کند. طبق قانون لیتل، زمان چرخه تقریباً ۵ روز میشود (۱۰ تقسیم بر ۲). همان تیم اگر فقط ۴ کار را همزمان در جریان نگه دارد، زمان چرخه حدود ۲ روز میشود — بیش از نصف کاهش، فقط با کمتر شروعکردن کار، بدون یک ساعت اضافهکاری.
مثال عددی ۳: پیدا کردن گلوگاه
فرض کنید تیم پشتیبانی، درخواستهای مشتری را پردازش میکند. بررسی ۵۰ درخواست نشان میدهد میانگین Cycle Time چهار روز است. اما وقتی زمان هر مرحله را جدا میسنجید میبینید که از این چهار روز، سه روز در مرحلهٔ «در انتظار تأیید مدیر» میماند و فقط یک روز صرف خودِ کار میشود. پس مشکل، سرعت تیم نیست؛ گلوگاه مرحلهٔ تأیید است. حذف یا خودکارکردن آن مرحله، Cycle Time را بدون فشار به تیم به حدود یک روز میرساند.
مثال عددی ۴: پیشبینی با صدک
فرض کنید Cycle Time صد تسک اخیر تیم این توزیع را دارد: صدک ۵۰ برابر ۳ روز، صدک ۸۵ برابر ۵ روز و صدک ۹۵ برابر ۹ روز است. اگر به مشتری قول دهید «هر تسک ۳ روزه تمام میشود»، تقریباً در نیمی از کارها قولتان میشکند. اما اگر بگویید «اکثر کارها (۸۵٪) تا ۵ روز تمام میشوند»، قولی واقعبینانه دادهاید. این دقیقاً دلیل استفاده از صدک بهجای میانگین است: صدک، سناریوهای بد را هم در خود دارد.
عوامل مؤثر بر Cycle Time
- اندازهٔ کار: کارهای کوچک، چرخهٔ کوتاهتر دارند.
- محدودیت WIP: محدودکردن کارهای در جریان، از ازدحام و کندی جلوگیری میکند.
- وضوح کار: کار مبهم، بارها متوقف و دوباره شروع میشود.
- وابستگیها: وابستگی به تیمهای بیرونی، چرخه را طولانی میکند.
- تعریف انجام (DoD): اگر تعریف «انجامشده» سنگین و مبهم باشد، کار دیرتر بسته میشود.
چطور Cycle Time را بدون فشار به تیم کاهش دهیم؟
کاهش چرخه معمولاً از «سختتر کارکردن» نمیآید، بلکه از «بهتر جریاندادن» میآید:
- WIP را محدود کنید: کارهای کمتر در جریان، چرخهٔ سریعتر.
- کارها را کوچک کنید: تسکهای بزرگ را به تسکهای کوچکتر بشکنید تا سریعتر جریان بیابند.
- گلوگاه را پیدا و رفع کنید: زمان هر مرحله را جدا بسنجید و مرحلهٔ کند را درمان کنید.
- زمان انتظار را کم کنید: تأییدها را خودکار کنید یا بازهٔ بازبینی را کوتاه کنید.
- تعریف انجام را سبک کنید: مراحلی که ارزش اضافه نمیکنند، حذف کنید.
مزایا و محدودیتهای Cycle Time
مزایا:
- معیاری عینی و قابل اندازهگیری برای سرعت واقعی تیم.
- مبنای پیشبینیپذیری و قولدادن زمان تحویل واقعبینانه.
- آشکارسازی گلوگاهها با تحلیل زمان هر مرحله.
- ساده و قابل فهم برای همهٔ اعضای تیم، نه فقط مدیران.
محدودیتها:
- فقط سرعت را میگوید، نه کیفیت یا ارزش کار؛ کار سریعِ بیکیفیت، بهبود نیست.
- به ثبت دقیق زمان شروع و پایان وابسته است؛ ثبت ناقص، معیار را خراب میکند.
- در کارهای با اندازهٔ بسیار متفاوت، میانگین گمراهکننده است؛ باید با توزیع و صدک کار کنید.
- مقایسهٔ مستقیم بین تیمها بدون توجه به نوع کار، گمراهکننده است.
اشتباهات رایج
- خلط Cycle Time و Lead Time: این دو نقطهٔ شروع متفاوتی دارند.
- نگاه به یک عدد: یک عدد معنا ندارد؛ روند و توزیع را ببینید.
- بهینهسازی فقط با فشار: بهجای پیدا کردن گلوگاه، فقط به تیم فشار آوردن.
- نادیدهگرفتن کارهای نیمهکاره: WIP بالا، Cycle Time را بالا میبرد.
- استفاده از میانگین برای قول زمان: میانگین، بدترین سناریوها را پنهان میکند؛ صدک ۸۵ را مبنا قرار دهید.
- بهینهسازی سرعت بدون نگاه به کیفیت: چرخهٔ کوتاهتر با کیفیت پایین، در مجموع ضرر است.
نکات کاربردی
- نکته مهم: برای هر مرحله از جریان کار، زمان را جداگانه بسنجید تا گلوگاه دقیق پیدا شود.
- ترفند کاربردی: WIP را محدود کنید؛ کارهای کمتر در جریان، چرخهٔ سریعتر.
- ترفند کاربردی دوم: برای قولدادن زمان تحویل، از صدک ۸۵ Cycle Time استفاده کنید، نه میانگین.
- اشتباه رایج: این تصور که Cycle Time بالا همیشه یعنی تنبلی؛ معمولاً یعنی گلوگاه یا کار بزرگ.
- قبل از شروع این را بدانید: برای محاسبهٔ دقیق، ابزار کانبان باید زمان شروع و تحویل هر کار را خودکار ثبت کند.
دوایتفای و اندازهگیری Cycle Time
برای اندازهگیری Cycle Time، باید زمان ورود و خروج هر کار از هر مرحله ثبت شود. در دوایتفای میتوانید جریان کار را در برد کانبان تعریف کنید، هر تسک را بین مراحل حرکت دهید و از گزارشهای کاری و عملکرد برای تحلیل زمان چرخه و پیدا کردن گلوگاهها استفاده کنید؛ به این ترتیب دادهٔ لازم برای بهبود، خودکار و پیوسته جمع میشود. با محدودکردن کار در جریان هر ستون و ثبت مهلتها، اهرمهای کوتاهکردن چرخه را همانجا در اختیار دارید.
سوالات متداول
جمعبندی
Cycle Time معیار سادهای است که سرعت واقعی تحویل را نشان میدهد. آن را از لحظهٔ شروع تا تحویل بسنجید، از Lead Time جدا کنید و برای پیدا کردن گلوگاهها، زمان هر مرحله را جدا بررسی کنید. و به یاد داشته باشید: مؤثرترین راه بهبود، فشار به تیم نیست؛ محدودکردن کارهای در جریان و حذف گلوگاه است. برای قول زمان هم بهجای میانگین، صدک ۸۵ را مبنا بگیرید تا قولی واقعبینانه بدهید.
اگر موضوع Cycle Time برایتان مفید بود، پیشنهاد میکنیم بهترین روش برنامه ریزی هفتگی برای کنکور 1405 و اپلیکیشن برنامه ریزی فارسی را هم بخوانید.
همین امروز به دوایتیفای بپیوندید
پروژهها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفتها و گزارشهای تیم در یک محیط یکپارچه. ساختهشده برای شرکتها، استارتاپها و تیمهای دورکار — با راهاندازی چنددقیقهای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
