اگر تخته کانبان فقط سه ستون «انجامدادنی، در حال انجام، انجامشده» داشته باشد اما کار تازه بدون محدودیت وارد شود، کارتهای مسدود پیر شوند و تعریف پایان مبهم بماند، شما دیوار را تزئین کردهاید؛ جریان را مدیریت نکردهاید. کانبان زمانی مفید است که واحد کار، نقطه شروع و پایان، وضعیتها، سیاست حرکت، کنترل WIP و انتظار خدمت را شفاف کند و سپس با داده بهبود یابد.
این راهنما از نسخه مه ۲۰۲۵ Kanban Guide استفاده میکند و برای تیمهای محصول، پشتیبانی، محتوا، عملیات و کار شخصی مثال دارد. هدف، ساخت یک سیستم قابل مشاهده و قابل ممیزی است؛ نه معرفی فهرستی از نرمافزارها یا وعده افزایش قطعی بهرهوری.
پاسخ کوتاه: کانبان چیست؟
در Kanban Guide نسخه مه ۲۰۲۵، کانبان راهبردی برای بهینهکردن جریان ارزش در یک فرایند است و سه عمل همزمان دارد: تعریف و بصریسازی workflow، مدیریت فعال آیتمهای داخل workflow و بهبود workflow. تخته، نمایش Definition of Workflow است؛ خودِ سیستم کانبان نیست.
| لایه | پرسش | خروجی |
|---|---|---|
| تعریف | چه چیزی از کجا تا کجا جریان دارد؟ | واحد ارزش، Started/Finished و وضعیتها |
| کنترل | چند کار میتواند همزمان باز باشد؟ | WIP control و pull signal |
| سیاست | کارت چه زمانی وارد/خارج/مسدود میشود؟ | قواعد صریح کنار تخته |
| انتظار | تحویل معمولاً در چه بازهای محتمل است؟ | SLE زماندار و احتمالی |
| یادگیری | کجا جریان کند، متغیر یا بیارزش است؟ | سنجه، آزمایش و بازبینی |
کانبان با «تخته وظایف» چه فرقی دارد؟
تخته وظایف مکان کارتها را نشان میدهد. سیستم کانبان علاوه بر تصویر، تعریف مشترک جریان و کنترل رفتار دارد. اگر کارت «در حال انجام» است اما کسی روی آن کار نمیکند، اگر ستون Review صف نامحدود دارد، یا Done برای هر عضو معنی متفاوتی دارد، تصویر وضعیت واقعی را تحریف میکند.
یک تخته خوب باید سؤال عملی بسازد: کدام آیتم پیر شده؟ چه چیزی مسدود است؟ ظرفیت آزاد کجاست؟ پیش از شروع کار جدید، به چه کارت فعالی کمک کنیم؟ کدام سیاست باعث صف شده؟ اگر پاسخ فقط «چه کسی مشغول است؟» باشد، تخته به داشبورد نظارت فردی تبدیل شده است.
گام اول: محدوده سیستم را مشخص کنید
تخته باید یک خدمت یا جریان معنادار را پوشش دهد: «درخواست تا انتشار محتوا»، «ثبت تیکت تا حل و تأیید»، یا «ایده محصول تا نتیجه قابل استفاده». مرز خیلی کوچک، صفهای بیرون را پنهان میکند؛ مرز خیلی بزرگ، وضعیتها را نامفهوم میسازد.
نام مشتری/ذینفع، تقاضا، خروجی و صاحب سیاست را بنویسید. سپس موارد بیرون محدوده را نیز صریح کنید. برای workflow میان چند تیم، شاید یک board سطح خدمت و چند board اجرایی لازم باشد؛ یک تخته عظیم همیشه شفافتر نیست.
Definition of Workflow را با شش جزء بسازید
نسخه ۲۰۲۵ راهنمای کانبان حداقل شش جزء برای Definition of Workflow یا DoW دارد:
- تعریف واحدهای ارزش یا work item؛
- تعریف نقطه Started و Finished؛
- یک یا چند وضعیت میان شروع و پایان؛
- روش کنترل WIP؛
- سیاست صریح حرکت آیتمها؛
- Service Level Expectation شامل زمان و احتمال.
این شش مورد را کنار board نگه دارید، نه در سندی که کسی نمیخواند. هر تغییر باید نسخه و تاریخ داشته باشد تا بتوانید اثر آن را با داده قبل/بعد مقایسه کنید.
واحد کار را هماندازه نکنید؛ قابل فهم و قابل تحویل کنید
کارت میتواند درخواست مشتری، مقاله، feature، incident یا سفارش باشد. همه آیتمها الزاماً اندازه برابر ندارند، اما آیتم بسیار بزرگ جریان و SLE را مخدوش میکند. خروجی، ذینفع، معیار پذیرش و بزرگترین عدمقطعیت هر کارت را مشخص کنید.
«بازطراحی سایت» کارت مناسبی نیست. یک slice بالقوه ارزشمند مانند «کاربر موبایل بتواند مرحله پرداخت را با خطای قابل فهم تکمیل کند» قابل جریانتر است. خردکردن به taskهای فنی بدون ارزش مستقل هم تصویر غلط میسازد.
Started و Finished را آگاهانه انتخاب کنید
اگر Started را پس از تحلیل و Finished را پیش از استقرار بگذارید، زمان انتظار تحلیل و استقرار از Cycle Time حذف میشود. این ممکن است برای یک سؤال محلی مناسب باشد، اما برای وعده به مشتری ناقص است. نام نقطهها باید با سؤال تصمیم هماهنگ باشد.
مثلاً تیم محتوا میتواند Started را «پذیرش brief آماده» و Finished را «انتشار و کنترل لینکها» تعریف کند. Backlog خام WIP نیست تا وقتی طبق DoW شروع نشده؛ اما backlog بزرگ همچنان ریسک انباشت و انقضای تقاضاست و باید جداگانه مدیریت شود.
ستونها باید حالت جریان باشند، نه نام افراد
ستونهای «علی، سارا، مریم» ownership را نشان میدهند اما جریان را پنهان میکنند. وضعیتهایی مانند Ready، Doing، Review، Waiting on Customer و Done بهترند، به شرط اینکه مرز ورود و خروجشان روشن باشد.
برای صف و فعالیت تفاوت بصری بسازید. «Ready for Review» صف است و «Reviewing» فعالیت؛ ادغام آنها مشخص نمیکند آیتم منتظر است یا واقعاً بررسی میشود. تعداد ستون را فقط به اندازهای زیاد کنید که تصمیم متفاوتی ایجاد کند.
سیاستهای صریح را روی تخته بنویسید
| سیاست | نمونه | دلیل |
|---|---|---|
| ورود | brief، owner، outcome و acceptance حاضر باشد | جلوگیری از شروع کار مبهم |
| حرکت | فقط پس از test و ثبت evidence وارد Review شود | کاهش رفتوبرگشت |
| Blocked | علت، مالک رفع و تاریخ پیگیری لازم است | جلوگیری از برچسب بیاقدام |
| Expedite | فقط خطر ایمنی/خدمت و با مجوز نقش مشخص | کنترل سوءاستفاده از فوریت |
| Done | پذیرش، انتشار/تحویل و اطلاع ذینفع | یک معنی مشترک از پایان |
سیاست خوب کوتاه، قابل مشاهده و قابل آزمون است. «کارت کامل باشد» سیاست نیست؛ معیار پذیرش چه چیزی را باید ثابت کند؟
WIP چیست و چرا کنترل میشود؟
WIP تعداد آیتمهای Started اما Finishedنشده است. کنترل WIP ظرفیت را مرئی میکند و به pull signal میرسد: کار تازه زمانی شروع میشود که طبق DoW ظرفیت آزاد باشد. هدف پر نگهداشتن همه افراد نیست؛ هدف مدیریت کار بیحرکت و رساندن ارزش به پایان است.
اگر ستون به حد رسیده است، پاسخ معمول شروع کار پنهانی نیست. تیم باید به آیتم قدیمی کمک، blocker را رفع، review را انجام، کارت را کوچک یا policy را بررسی کند. بالا بردن limit فقط برای خاموشکردن هشدار، اطلاعات سیستم را از بین میبرد.
عدد WIP Limit را چگونه انتخاب کنیم؟
قانون «تعداد اعضا منهای یک» نسخه جهانشمول نیست. نوع کار، مهارتهای تخصصی، اندازه آیتم، dependency، انتظار بیرونی و ریسک فرق دارند. ابتدا WIP واقعی و جریان را چند روز یا چند هفته ببینید؛ سپس limit اولیهای انتخاب کنید که همکاری را فعال کند اما کار را بیدلیل متوقف نسازد.
limit را فرضیه بنویسید: «اگر WIP Review از ۵ به ۳ برسد، age آیتمها بدون افت throughput کاهش مییابد.» تاریخ، معیار، guardrail و بازبینی تعیین کنید. صفحه راهنمای WIP Limit اتلسین نمونه محصولمحور و software-team است؛ برای مشاهده anti-patternها مفید است اما عدد پیشنهادی آن قانون عمومی کانبان نیست.
نقض WIP Limit را چگونه اداره کنیم؟
limit دیوار اخلاقی یا ابزار سرزنش نیست. exception میتواند لازم باشد، اما باید در DoW تعریف یا همان لحظه ثبت شود: دلیل، صاحب تصمیم، اثر بر آیتمهای فعال و زمان بازگشت. اگر exception هر روز رخ میدهد، دیگر استثنا نیست؛ تقاضا، staffing، سیاست یا limit باید بررسی شود.
هیچکس برای رعایت عدد نباید incident، ایمنی یا الزام قانونی را پنهان کند. در کار پرخطر، policy تخصصی و اختیار توقف مقدم است.
Pull یعنی چه؟
Pull یعنی آیتم بر اساس ظرفیت و سیاست انتخاب شود، نه اینکه مدیر بدون توجه به WIP کار را به افراد push کند. صف Ready میتواند مرتب باشد، اما شروع فقط پس از signal ظرفیت رخ میدهد. انتخاب کار تازه باید با اولویت و ارزش هماهنگ باشد؛ راهنمای اولویتبندی کارهای تیمی برای مدیریت backlog و تغییر اولویت مکمل این صفحه است.
Pull به معنی انتخاب دلخواه هر فرد نیست. policy replenishment، owner تصمیم و classes/risks باید روشن باشند. آیتم شروعشده را دائماً reprioritize نکنید؛ این کار age و عدمپیشبینی را بالا میبرد.
Blocked و Waiting را پنهان نکنید
Blocked یک حالت با اقدام است، نه برچسب خاکستری. علت، زمان شروع انسداد، فرد/تیم پاسخگو، next follow-up و مسیر escalation را ثبت کنید. Waiting on Customer یا Waiting on Vendor اگر بخشی از زمان خدمت است، نباید با توقف ساعت از گزارش ناپدید شود؛ جداگانه نشان دهید و هر دو زمان کل و blocked time را تحلیل کنید.
مقاله ردیابی زمان برای بهبود فرایند نحوه جداسازی active/wait/rework/handoff و ساخت event log را پوشش میدهد.
SLE وعده قطعی نیست
Service Level Expectation پیشبینی احتمالی زمان از Started تا Finished است؛ مثلاً «۸۵٪ آیتمهای این نوع در ۱۲ روز یا کمتر تمام شدهاند». عدد باید از داده تاریخی cycle time همان DoW و همان نوع کار بیاید. اگر داده ندارید، یک حدس اولیه صریح بسازید و پس از جمعشدن داده جایگزین کنید.
SLE را با deadline قراردادی یا SLA یکی ندانید. SLE به گفتوگو درباره age و احتمال کمک میکند؛ تضمین تحویل نیست. تغییر workflow، اندازه آیتم یا mix تقاضا میتواند توزیع گذشته را نامعتبر کند.
چهار سنجه حداقلی کانبان
| سنجه | تعریف | پرسش تصمیم |
|---|---|---|
| WIP | تعداد Started و Finishedنشده | آیا بیش از ظرفیت شروع کردهایم؟ |
| Throughput | تعداد دقیق آیتم Finished در واحد زمان | نرخ خروج چگونه تغییر میکند؟ |
| Work Item Age | زمان سپریشده از شروع آیتم فعال تا اکنون | کدام آیتم در خطر عبور از SLE است؟ |
| Cycle Time | زمان سپریشده از Started تا Finished | توزیع زمان تحویل چگونه است؟ |
Kanban Guide ۲۰۲۵ این چهار سنجه را حداقل لازم میداند. میانگین تنها کافی نیست؛ توزیع، percentiles، outlier و تغییر mix را ببینید. سنجه بدون تصمیم بیمعناست و نباید به رتبهبندی فردی تبدیل شود.
Age را هر روز بهجای گزارش وضعیت بخوانید
در flow review کوتاه، از راست به چپ یا از پیرترین آیتم شروع کنید: چه چیزی برای Finishedشدن لازم است؟ کدام blocker باید امروز رفع شود؟ آیا WIP اجازه pull میدهد؟ چه آیتمی به SLE نزدیک شده؟ چه تصمیمی owner ندارد؟
جلسه نباید تورِ «دیروز چه کردم» باشد. اگر board بهروز است، گفتگو روی جریان و کمک متمرکز میشود. برای agenda، decision log و حذف status meetingهای زائد، راهنمای جلسه مؤثر را ببینید.
Throughput را با بهرهوری فردی یکی نکنید
Throughput خروجی سیستم است و به اندازه آیتم، کیفیت، تقاضا، dependency و mix بستگی دارد. مقایسه تعداد کارت افراد رفتارهای مخرب میسازد: خردکردن مصنوعی کارت، دوری از کار سخت، پنهانکردن همکاری و فشار برای بستن زودرس.
سنجه ارزش را کنار جریان ببینید: پذیرش مشتری، rework، defect، outcome و abandoned work. سریعکردن جریانِ چیزی که ارزش نمیسازد موفقیت نیست.
Forecast را با داده بسازید، نه تاریخ قطعی
برای یک آیتم مشابه، از توزیع cycle time و SLE استفاده کنید. برای چند آیتم، throughput تاریخی و شبیهسازی احتمالی میتواند range بدهد، به شرط اینکه داده، DoW و mix قابل مقایسه باشند. این مقاله روش آماری کامل یا تضمین forecast ارائه نمیکند.
تاریخ را همراه احتمال، فرضها و شرط بازنگری بگویید. «احتمال ۸۵٪ تا تاریخ X با فرض ثابتبودن تیم و نوع تقاضا» صادقانهتر از «حتماً جمعه» است.
کانبان و اسکرام رقیب اجباری نیستند
Scrum Guide رسمی Sprint را رویدادی با طول ثابت یک ماه یا کمتر، با Product/Sprint Goal، نقشها، رویدادها و artefactهای مشخص تعریف میکند. Kanban Guide نقش یا Sprint اجباری تعریف نمیکند و بر flow/DoW/WIP/SLE/metrics تمرکز دارد. تیم Scrum میتواند از سنجه و کنترل جریان کانبان داخل Sprint استفاده کند.
| موضوع | کانبان Guide ۲۰۲۵ | Scrum Guide 2020 |
|---|---|---|
| ساختار زمان | الزام به Sprint ندارد | Sprint ثابت یک ماه یا کمتر |
| نقشها | نقش اجباری مشخص نمیکند | Product Owner، Scrum Master، Developers |
| کنترل کار | WIP و pull در DoW | Sprint Goal و Sprint Backlog |
| سنجه | WIP، throughput، age، cycle time | سنجه اجباری جریان تعیین نمیکند |
| ترکیب | میتواند روشهای دیگر را تکمیل کند | flow practices میتوانند مکمل باشند |
تخته فردی را ساده نگه دارید
برای کار شخصی، Backlog / Ready / Doing / Waiting / Done کافی است. WIP کلی ۱ یا ۲ میتواند نقطه آزمایش باشد، نه نسخه همگانی. کارهای تقویمی را در تقویم نگه دارید و board را با reminder system اشتباه نگیرید.
کارتهای پروژه را به next action قابل انجام تبدیل کنید. راهنمای لیست کارهای قابل اجرا برای Inbox، Waiting و due date و راهنمای مدیریت پروژه شخصی برای WIP و Definition of Done مکملاند.
تخته تیم محتوا: یک نمونه
جریان نمونه: Intake → Brief Ready → Drafting → Editorial Review → Client/Legal Review → Ready to Publish → Published & Checked. Started در ورود به Drafting و Finished پس از انتشار و کنترل لینک تعریف میشود. Drafting limit=۳ و Editorial Review limit=۲ فقط فرض شروعاند.
سیاست Blocked مشخص میکند انتظار منبع، مجوز تصویر و بازخورد مشتری چگونه ثبت شود. SLE تا جمعشدن داده «حدس اولیه» است. بعد از چهار هفته، team age، blocked time، rework و cycle-time distribution را میبیند و فقط یک تغییر آزمایشی اجرا میکند.
تخته پشتیبانی: فوریت را کنترل کنید
هر تیکت ناراضی expedite نیست. سیاست شدت باید اثر، دامنه، workaround، ایمنی/قانون و مشتری متاثر را تعریف کند. lane فوری ظرفیت محدود و owner مجوز داشته باشد؛ ورود یک expedite باید اثرش بر بقیه آیتمها را مرئی کند.
Waiting on Customer را جدا کنید و زمان کل پاسخ را پنهان نکنید. یک تیکت بستهشده بدون تأیید نتیجه ممکن است throughput را زیبا و ارزش را بدتر کند.
تخته ریموت: شفافیت بدون نظارت افراطی
Board باید وضعیت کار را نشان دهد، نه حضور دقیقهای فرد را. assignee، owner و reviewer مفیدند؛ time-online، screenshot یا شمارش حرکت کارت معیار عملکرد نیست. دسترسی حداقلی، محرمانگی کارت، retention، audit log و خروج کارکنان را در ابزار تنظیم کنید.
نام assignee بهتنهایی دامنه اختیار یا پاسخگویی را روشن نمیکند. برای کار حساس، نتیجه، اختیار تصمیم، نقطه کنترل و صاحب پاسخگویی را با الگوی تفویض اختیار مؤثر تعریف کنید.
داده سلامت، HR، امنیت یا مشتری را روی کارت عمومی نگذارید. جزئیات حساس را در سیستم رسمی با دسترسی مناسب نگه دارید و board فقط reference امن داشته باشد.
ابزار فیزیکی یا دیجیتال؟
تخته فیزیکی تعامل ملموس و اصطکاک کم دارد، اما برای تیم توزیعشده، جستوجو، audit و analytics محدود است. ابزار دیجیتال دسترسی، automation و گزارش میدهد، اما میتواند پیچیدگی، هزینه، قفل فروشنده، اعلان و ریسک داده بسازد. هیچکدام ذاتاً «ضروری» یا «بهتر» نیست.
ابتدا workflow را روی کاغذ یا ابزار موجود آزمایش کنید. وقتی سیاستها پایدار شد، نیازمندی ابزار را بنویسید. برای مقایسه محصولات و پایلوت خرید بهروز، به راهنمای ابزارهای مدیریت پروژه بروید؛ مقاله حاضر رتبهبندی محصول نیست.
چکلیست انتخاب ابزار کانبان
- نمایش چند DoW، صف/فعالیت، blocker و WIP control؛
- Work Item Age، Cycle Time، Throughput و export خام؛
- SLE یا امکان ساخت نمودار/هشدار age؛
- سطح دسترسی، audit log، SSO/MFA و offboarding؛
- مکان داده، backup، retention، API و خروج کامل؛
- RTL/فارسی، دسترسپذیری، موبایل و اینترنت ضعیف؛
- automation با log و امکان rollback؛
- هزینه چرخه عمر: لایسنس، آموزش، admin، migration و exit.
دموی زیبا را با pilot واقعی ۲ تا ۴ هفتهای روی یک جریان محدود بیازمایید. pass/fail، داده خروجی و سناریوی خروج را پیش از خرید تعیین کنید.
چه automationهایی خطرناکاند؟
انتقال خودکار کارت بر اساس assignee، بستن خودکار بهعلت inactivity یا ساخت بیحد کارت از ایمیل میتواند وضعیت جعلی بسازد. هر automation باید trigger، owner، failure mode، audit و راه برگشت داشته باشد. ابتدا فرایند بد را اصلاح کنید؛ automation فقط آن را سریعتر تکثیر میکند.
اعلان برای هر حرکت نیز توجه تیم را میبلعد. فقط blocker، SLE risk، mention واقعی و decision deadline را به کانال مناسب بفرستید.
برنامه راهاندازی ۱۴روزه
- روز ۱–۲: scope، stakeholder، input/output و واحد کار را تعریف کنید.
- روز ۳: وضعیت فعلی را بدون آرایش روی تخته بیاورید.
- روز ۴: Started/Finished و policies را بنویسید.
- روز ۵: WIP control اولیه و exception را توافق کنید.
- روز ۶: blocker/age و ownerهای تصمیم را اضافه کنید.
- روز ۷: SLE حدسی را صریح و موقت ثبت کنید.
- هفته دوم: هر روز age-based flow review و فقط جمعآوری داده.
- روز ۱۴: یک مشکل، یک فرضیه، یک تغییر و تاریخ بازبینی انتخاب کنید.
جلسات پیشنهادی، حداقلی و هدفدار
Flow Review کوتاه برای آیتمهای فعال؛ Replenishment برای انتخاب کار آماده؛ Delivery/Service Review برای SLE و انتظار ذینفع؛ و Improvement Review برای تغییر DoW. نام و cadence اجباری نیستند مگر روش مکمل شما آنها را لازم کند.
اگر board و asynchronous update کافیاند، جلسه status نسازید. هر جلسه باید تصمیم، owner و تغییر مشخص تولید کند.
خطاهای رایج کانبان
- تخته سهستونه بدون DoW و policy؛
- WIP limit بر اساس نفر و برای ۱۰۰٪ utilization؛
- بالابردن limit هنگام هر فشار؛
- شروع کار پنهانی بیرون board؛
- کارتهای بسیار بزرگ یا taskهای بیارزش مستقل؛
- Expedite lane نامحدود؛
- متوقفکردن ساعت Waiting برای زیباترشدن گزارش؛
- میانگین cycle time بدون distribution و mix؛
- Throughput فردی و سرزنش blocker؛
- خرید ابزار پیش از تعریف جریان.
کانبان چه چیزی را تضمین نمیکند؟
کانبان شفافیت، داده و پرسش بهتر فراهم میکند؛ تضمین کاهش استرس، سرعت، رضایت، همکاری یا پیشبینی دقیق نمیدهد. اگر تقاضا از ظرفیت بیشتر، کیفیت ضعیف، اختیار مبهم یا سیاست پاداش مخرب باشد، board فقط مسئله را مرئی میکند.
راهنمای رسمی Kanban Method در Kanban University بر شروع از روش فعلی و تغییر تکاملی تأکید دارد؛ این یکی از سنتهای معتبر کانبان است، اما Kanban Guide ۲۰۲۵ حتی تغییر بزرگِ شواهدمحور را ممنوع نمیکند. «تغییر همیشه کوچک» را قانون مطلق ندانید.
Open Guide چه چیزی اضافه میکند؟
Open Guide to Kanban ژوئیه ۲۰۲۵ شرح گستردهتری از pull، rightsizing، blocked time، value invalidated و انواع WIP control میدهد. خود سند اقتباسی از Kanban Guide مه ۲۰۲۵ است و برخی پیشنهادهایش اختیاری یا مورد اختلاف جامعهاند؛ بنابراین آن را منبع تکمیلی بدانید، نه مجموعه الزامهای جدید.
جمعبندی: جریان را مدیریت کنید، نه کارت را
برای اجرای کانبان، scope و value unit را تعریف کنید، Started/Finished را انتخاب، وضعیت و policy را بصری، WIP را کنترل، SLE را احتمالی و چهار سنجه WIP/Throughput/Age/Cycle Time را جمع کنید. سپس هر روز آیتمهای پیر و مسدود را مدیریت و هر دوره یک فرضیه بهبود را آزمایش کنید.
نرمافزار آخر کار میآید. اگر board با جریان واقعی، اختیار و سیاست همسو نیست، automation و داشبورد بیشتر فقط فاصله میان کار واقعی و گزارش را بزرگتر میکنند.
پرسشهای متداول
آیا سه ستون To Do، Doing و Done برای کانبان کافی است؟
برای اولین تصویر شاید کافی باشد، اما Kanban Guide ۲۰۲۵ حداقل DoW، کنترل WIP، policy، SLE و سنجههای جریان را نیز لازم میداند. سه ستون بدون Started/Finished و تعریف حرکت، تنها تخته وظایف است. پیچیدگی را تدریجی اضافه کنید اما اجزای گمشده را فراموش نکنید.
بهترین WIP Limit چند است؟
عدد جهانشمول وجود ندارد. WIP فعلی، نوع و اندازه کار، مهارت، dependency و کیفیت را ببینید؛ limit اولیه را بهعنوان فرضیه انتخاب و اثرش را بر Age، Cycle Time، Throughput، کیفیت و فشار تیم بررسی کنید. برخورد مکرر با limit داده است، نه دلیل خودکار برای بالا بردن آن.
آیا کانبان برای کار شخصی مناسب است؟
بله، اگر جریان ساده، WIP کم، Waiting واقعی و مرور منظم داشته باشید. board نباید تقویم، آرشیو یا فهرست همه آرزوها شود. پروژه را به Next Action قابل پایان تبدیل و اطلاعات حساس را روی تخته عمومی نگذارید.
فرق SLE با deadline و SLA چیست؟
SLE پیشبینی احتمالی elapsed time بر پایه داده تاریخی یک DoW است. Deadline یک تاریخ مورد نیاز و SLA توافق خدمت با تعهدها و پیامدهای خودش است. SLE میتواند مذاکره آنها را مطلع کند اما جای قرارداد یا الزام را نمیگیرد.
اگر همه کارها فوری باشند چه کنیم؟
فوریت را با policy اثر، دامنه، هزینه تأخیر، safety/legal و workaround تعریف کنید. expedite ظرفیت محدود و مجوز مشخص داشته باشد. اگر تقاضای واقعاً فوری از ظرفیت بیشتر است، intake، staffing، scope یا سطح خدمت باید تغییر کند؛ رنگ قرمز بیشتر ظرفیت تولید نمیکند. برای شکاف فوری، از راهنمای تریاژ حجم کار استفاده کنید.
