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