استفاده از کانبان در عملیات فناوری اطلاعات-بخش ششم

این مقاله، ادامه مقاله «استفاده از کانبان در عملیات فناوری اطلاعات- بخش اول» است. پیشنهاد می‌کنیم برای فهم بهتر، مطالعه را از بخش اول شروع کنید.

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

آن‌ها بین خودشان و سایر بخش‌ها اعتراض می‌کردند که «عملیات هیچ وقت پاسخگو نیست»، «آن‌ها شبیه جایی هستند که اقلام بدون ردیابی ناپدید می‌شوند» یا «چه تیم بیخودی(بی‌ارزشی)». تماشای از بین رفتن آبروی تیم عملیات فناوری اطلاعات ناامید کننده است. زمانی‌که تلاش می‌کنید تا کارهای زیادی را هم‌زمان انجام دهید، هیچ کاری را خوب انجام نمی‌دهید. استیو یوزل این وضعیت را به زیبایی تعبیر کرده است- «چند وظیفه‌گی فقط فرصتی برای خراب کردن بیش از یک کار در یک ‌زمان است»

در اینجا مثالی برای تمرین آورده ایم: سیستم ثبت قلم کاری(تیکتینگ) خود (ابزار ITSM یا مشابه آن) را جستجو کنید تا اقلام کاری که در یک بازه زمانی (برای مثال 60 روز) روی آن‌ها کار نشده است، آشکار شوند. نتیجه آن را با کارهایی مقایسه کنید که خاتمه بافته است. آیا نتیجه ناامیدکننده است؟ اگر بله، با تیم در مورد تمام کردن کارها پیش از شروع کردن کار جدید گفتگوی خوب و به سبک قدیم داشته باشید. سعی کنید این کار را به وسیله نوعی قلم کاری انجام دهید، پس مشاهده کنید که کدام قلم به آسانی حرکت کرده است و کدام قلم در مسیر گیر کرده است.
در یک سیستم کششی موثر، سقف‌های کار در جریان، نوعی گفتگورا آسان می‌کنند، این گفتگوها می‌توانند رویکرد سازمان را از تمرکز روی انجام شدن همه کارها، به مکالمه در مورد انجام بهترین کار در آن ‌لحظه، تغییر دهند، ظرفیت تیم برای انجام کار، براساس توافق جمعی، اهداف واقعی کسب‌وکاری و اهداف اقتصادی تعیین می‌شود.
کار در جریان زیاد علاوه بر ایجاد تاخیر در تحویل ارزش کسب و کار، دو مشکل اصلی دیگر را نیز پنهان می‌کند:

• مشغله کاری با بهره‌وری اشتباه گرفته می‌شود.
• از بازخورد سریع ممانعت می‌کند.

افراد مشغول بی‌حساب و کتاب «بله» می‌گویند. افراد نوآور آگاهانه «بله» می‌گویند. Busy people say ”yes” haphazadly. Productive people say ‘yes’ deliberately.


زمانی‌که مشغله‌کاری با بهره‌وری اشتباه می‌شود، به‌نظر می‌آید همه درگیر کار هستند، اما نتیجه͏های ملموس برای تحویل ارزش به مشتری، نقص دارد. اگر برای موفق شدن جدی هستید، این وضعیت خوبی نیست. مقدار زیاد کار در جریان که ناشی از گفتن «بله» به خیلی از کارها است. وقتی تمایل به انجام کار بیش از ظرفیت دارید، تعیین کردن و پایبند بودن به سقف کار در جریان روشی برای توقف برزخ و شلوغی است و به شما(و افراد شما) اجازه می͏دهد که بگویید «متاسفانه، امروز نمی͏شه».
هنگامی که افراد زمان زیادی را قبل از دریافت بازخورد صبر می͏کنند، ارزش بازخورد کم می‌شود.آن‌ها به سراغ کار دیگه‌ای می‌روند، و هیچ زمانی برای بازخوردهای روی تابلو ندارند. درنتیجه، آن‌ها فرصت بهبود کار را از دست می‌دهند، فلسفه ناب در حذف اتلاف برجسته است ، اما دیدن اتلاف سخت است مگر چیزی را تحویل بدهید و بازخورد آن را بگیرید. در دنیای کانبان، ارزش بر کاهش اتلاف برتری پیدا می‌کند، و بازخورد سریع یک روش عالی برای فراهم کردن ارزش است.

می‌توان برای اطمینان ازاین‌که کار انجام می‌شود به دو عنصر اعتماد کرد:
سقف کار در جریان: محدود کردن کار در جریان تنش لازم در سیستم را ایجاد می‌کند تا افراد برای تکمیل کارشان تشویق شوند. نمی‌توانید پروژه B را شروع کنید تا زمانی‌که پروژهA تمام شود، فشار برای تمام کردن پروژهA رفتار تاثیر گذار است.
تیم اذیت می‌شود زمانی͏که به یک قلم کاری قدیمی که روزها و روزها در ستون درحال انجام روی تابلو کانبان است خیره می͏شود، و شما در معرض خطر از دست دادن احترام هستید. بیشتر و بیشتر، اعتبار شما زیر سوال می رود. آیا زمان زیادی برای این͏که چه کاری باید انجام دهید صرف می͏کنید؟ آیا اجازه می͏دهید پست الکترونیکی(ایمیل) شما را از مسیر خارج کند؟

اما درموارد ضروری چطور؟ مطمئنا، مواردی با اولویت 1 فورا مورد توجه قرار می‌گیرند و آن‌ها را نسبت به کارهایی که قبلا تعهد داده‌اید در اولویت قرار دهید. این درست است – تولید حرف اول را می‌زند! اگر تیم اسیر موارد فوری شده است، پس مطمئن شوید که ظرفیت کافی برای آن‌ها اختصاص داده شده است.

یک روش برای انجام آن، این است که اقلام ضروری‌را بررسی کنید و ببینید در 60 روز اخیر چند بار اتفاق افتاده‌اند و چه مقدار طول کشیده تا انجام شوند. سیستم ردیابی کار را بگردید- مجموعه‌ای از نمونه‌های، یازده قلم کاری ضروری تصادفی می‌تواند به صورت آماری کافی باشد که نشان دهد چند قلم ضروری در 60 روز بعدی آشکار می‌شوند. سقف کار در جریان را تنظیم کنید که شاید با این قلم‌های ضروری در آینده تطبیق یابند.
برای مثال، اگر 30 قلم کاری ضروری در طی60 روز گذشته اتفاق افتاده بود، و زمان اصلی رفع قلم ضروری(MTTR) برای شما 47 دقیقه باشد، پس می‌توانید ظرفیت رزرو برای یک قلم ضروری را در کل زمان درنظر بگیرید، 50% احتمال دارد قلم ضروری در یک ساعت بر طرف شود.

به هر حال فقط 50% احتمال دارد که اقلام ضروری بیشتر از یک ساعت طول بکشند. با توجه به قانون میانگین‌ها، استفاده از درصد‌های بالاتر مثل 75% تا 85% (برای مثال 135 تا 175 دقیقه) ممکن است رویکرد مطمئن‌تری باشد. اگر سازمان شما مخالف خطر کردن است، ممکن است در هر زمان ظرفیت رزرو برای دوقلم ضروری درنظر بگیرید، با توجه به این‌که 85% احتمال دارد قلم ضروری در سه ساعت یا کمتر رفع شود.
این به چند عامل وابسته است، همانند تعداد افراد تیم و سطح مهارت وتخصص آن‌ها. اگر فقط یک نفر در تیم بداند که چطور مجموعه‌ای از یک ابزار خاص را عیب‌یابی کند، و آن مجموعه ابزار مسائلی دارند، پس ممکن است نیازبه کاهش سقف کار باشد حتی بیشتر در جهت این‌که از گلوگاه‌های جدی جلوگیری شود.
توصیه‌های ما برای تنظیم سقف کار در جریان
چندین روش برای تنظیم سقف کار در جریان وجود دارد. در این‌جا چند نمونه وجود دارد:
– سقف کار در جریان برای هر فرد:برای نمونه، به ازای هر فرد دوقلم کاری.
– سقف کار در جریان با تیم: برای نمونه، دو برابر تعداد افراد تیم. یک تیم پنج نفری ممکن است سقف کار در جریان 10 برای تابلوی کانبان داشته باشند.
– سقف کار در جریان با وضعیت کاری: برای نمونه، سه برای طراحی، چهار برای پیاده سازی، و پنج برای تحویل.
– سقف کار در جریان با نوع قلم کاری: برای نمونه، یک پروژه بزرگ، دو پروژه کوچک‌تر، سه وظیفه نگه‌داری، و یک وظیفه بهبود در حال انجام در هرجایی روی تابلو.

راهبرد تنظیم سقف کار در جریان مورد علاقه ما، این است که آن‌چه الان-امروز دارید را محاسبه کنید. عدد را روی تابلو مشخص کنید و بپرسید: کار به ‌نرمی در تولید جریان دارد، یا با هم درگیر هستید تا کار انجام شود؟ آیا متوجه می‌شوید که در حال حاضر کارهای زیادی در حال انجام دارید؟ اغلب پاسخ این است که کار درجریان زیادی وجود دارد.
برای نمونه، اگر تیم در یک زمان روی 13 قلم اولیه کار می‌کند، و کل کارها در انبار است، پس-پاسخ را دارید- کار در جریان را کاهش دهید. علاوه بر این، کار در جریان مدت انجام کار را نشان می‌هد. با بیشترین اقلام کاری، نمی‌دانیم چقدر طول می‌کشد تا آن‌ها تمام شوند.
ما پیشنهاد می‌دهیم که با کار در جریان کم آزمایش کنید، پیشرفت را محاسبه کنید(4.5 را ببینید) و سپس اگر نیاز به تنظیم مجدد وجود دارد با تیم درین مورد صحبت کنید
راز بهینه سازی روند کار در سراسر جریان ارزش، تاکید بر اتمام یک درخواست پیش از شروع درخواست جدید دارد. «شروع کردن را متوقف کنید و تمام کردن را شروع کنید» یک شعار هوشمندانه کانبان است،(و این فقط بخش کوچکی از راهنمایی فوق العاده‌ای است که هسته مفهمومی کانبان برای کار دانش محور را پوشش می دهد).
خلاصه بخش 4.4
کارهای برنامه‌ریزی شده اولیه که تیم‌ها انجام می‌دهند باید کار در جریان در نظر گرفته شود. قراردادهای سازمان‌یافته‌ای را تنظیم کنید تا درخواست‌هایی که به تیم‌ وارد می‌شود با ظرفیتی که تیم برای انجام کار دارد متعادل باشد- و بازخورد کار را بگیرید. کار در جریان فشار لازم در سیستم است تا به تیم کمک کند که به موفقیت‌های فوق‌العاده‌ای دست یابد و می‌توان آن‌را در طول زمان تنظیم کرد. میزان درست فشار کار در جریان برای رسیدن به خلاقیت و نوآوری حیاتی است. مطمئن شوید کار در جریان به قدری زیاد نیست که باعث شود کارکنان از پا در بیایند.
محاسبه پیشرفت
هرکاری خیلی طول می‌کشد.
در نتیجه، اغلب ما به کارهای که امروز بیشترین اهمیت را دارد، بی‌توجهی ‌می‌کنیم پس می‌توانیم روی اولویت‌های دیروز کار کنیم که فکر می‌کردیم قبلا انجام شده است. انتظارات در مورد زمانی که کارها تمام می‌شوند به طرز فجیعی محقق نمی‌شود، و مشتری نارحت است، بسیار ناراحت است.
راه‌حل این است که مسیر برای انجام سریع بیشتر کارهای با اهمیت مشخص شود واز دید مشتری به اندازه کافی خوب باشد. اولین گام برای دستیابی به این هدف، محاسبه مقدار کار واقعی است که باید در سرتا سر سیستم انجام شود.


همانند نیرو‌های پیش‌آهنگی که در بخش 3.2 توضیح داده شد، برای یک شرکت خیلی خوب نیست که تیمی کار را سریع‌تر از زمانی‌که تیم پایین دستی صرف می‌کند، انجام دهد. محصول نهایی یا خدمت به مشتری زود‌تر تحویل نمی‌شود. شرکت، به عنوان یک تیم، فقط به‌سرعت کند‌ترین تیم حرکت می‌کند- حرکت بخشی از سیستم – این یک محدودیت است.
وقتی گروه پیش‌آهنگی نیاز دارند سریع‌تر حرکت کنند، آن‌ها باید درک کنند که چه‌چیزی هاربی را عقب نگه‌داشته است. معلوم می‌شود که در کوله‌پشتی او شش بسته نوشابه، 4 قوطی کنسرو، و یک دیگچه آهنی است. دسته پیش‌آهنگی بار کوله‌پشتی هاربی را تقسیم کرد و به مسیر خود ادامه داد. او از بیشتر وزن کوله خلاص شد، و سریع‌تر از قبلش گام بر می‌داشت، به این معنی که کل دسته می‌توانست با سرعت دو برابر قبل حرکت کند. هاربی دیگر گلوگاه نبود. محدودیت به سراغ مورد بعدی رفت و جلوی حرکت تیم با سریع مورد نظرش را ‌گرفت. ممکن است یک پیش‌آهنگ مجروح شود، ممکن است درختی افتاده باشد.
هر سیستمی محدودیت‌هایی دارد. و هنگامی‌که یک محدودیت حل می‌شود به کندترین بخش سیستم «منتقل» می‌شود. تمرکز برای پیدا کردن گلوگاه، باعث می‌شود تا کار متوقف نشود، و اجازه می‌دهد که به جلو حرکت کنید، بنابراین ارزش را سریع‌تر تحویل می‌دهید.

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

ادامه دارد…

مترجمین: حمید خاتمی، شبنم ربیعی

برای مطالعه قسمت اول، دوم، سوم، چهارم و پنجم کلیک کنید.

منبع: axelos.com