2.7 قطار کا نظریہ

جائزہ اور محرک

قطار کا نظریہ (queueing theory) انتظار کی قطاروں کا ریاضیاتی مطالعہ ہے۔ سافٹ ویئر انجینئرنگ کے میٹرکس کی کتاب میں یہ عجیب لگتا ہے جب تک آپ نوٹس نہ کریں کہ ڈیلیوری پائپ لائن کتنی دراصل قطار ہے: جائزہ لینے والے کا انتظار کرتی پل ریکویسٹ، CI رنر کا انتظار کرتا کمٹ، اٹھائے جانے کا انتظار کرتا ٹکٹ، جواب کا انتظار کرتا صارف کی مدد کا پیغام۔ موضوع 2.4 پہلے ہی بہاؤ کا بوجھ اور بہاؤ کا وقت متعارف کرا چکا ہے اور دکھا چکا ہے کہ قدر کے سلسلے کو ضرورت سے زیادہ بوجھ دینا ڈیلیوری کو تیزی سے سست کرتا ہے، اور موضوعات 2.5 اور 2.6 نے دکھایا کہ زیادہ تر ڈیلیوری کا وقت انتظار کا وقت ہے، کام کا وقت نہیں۔ قطار کا نظریہ وہ بنیادی ریاضی ہے جو سمجھاتی ہے کہ یہ سب کیوں درست ہے، نہ کہ محض مشاہدہ شدہ نمونہ۔

سب سے مفید واحد نتیجہ Little کا قانون ہے، وہ مسئلہ جو آپریشنز ریسرچر John Little نے 1961 میں ثابت کیا: مستحکم نظام میں آئٹمز کی اوسط تعداد اس اوسط شرح کے برابر ہے جس سے آئٹمز آتے ہیں، ضرب اس اوسط وقت کے جو ہر آئٹم نظام میں گزارتا ہے۔ موضوع 2.4 یہی نتیجہ Flow Framework کے اپنے ناموں میں پہلے ہی استعمال کر چکا ہے، بہاؤ کا بوجھ آمد کی شرح ضرب بہاؤ کے وقت کے برابر ہے۔ اس کتاب کے وسیع ذخیرۂ الفاظ میں یہ یوں بھی پڑھا جاتا ہے کہ جاری کام (موضوع 2.5) نئے کام کی آمد کی شرح ضرب سائیکل ٹائم (موضوع 2.6) کے برابر ہے۔ یہ انگوٹھے کا اصول یا کچھ مطالعات میں مشاہدہ شدہ ہم رشتگی نہیں۔ یہ ایسا ثبوت ہے جو کسی بھی مستحکم قطار کے لیے درست ہے، چاہے قطار کیا پروسیس کر رہی ہو یا یہ کیسے طے کرتی ہو کہ آگے کس پر کام کرنا ہے۔

بڑی ٹیم کے لیے یہی عمومیت نکتہ ہے۔ Little کا قانون آپ کو ایسی عقل مندی کی جانچ دیتا ہے جو یکساں کام کرتی ہے چاہے قطار کانبان بورڈ ہو، میسج بروکر ہو، یا مشترکہ CI پائپ لائن۔ اگر آپ کا ناپا گیا جاری کام، آمد کی شرح، اور سائیکل ٹائم تقریباً مساوات کو پورا نہیں کرتے، تو آپ کے تین اعداد میں سے ایک غلط ہے، عموماً اس لیے کہ “جاری” یا “آیا” کی تعریف غیر یکساں ہے۔ بڑے اور حکومتی ادارے ایک وقت میں ایسی درجنوں قطاریں چلاتے ہیں، مشترکہ کوڈ ریویو پول، مشترکہ ٹیسٹ ماحول، مشترکہ منظوری کے بورڈ، اور Little کا قانون ناقص میٹرک کی تعریف کو برے عملے یا عمل کے فیصلے کو چلانے سے پہلے پکڑنے کا سب سے سستا دستیاب ٹول ہے۔

بنیادی اصول

Little کا قانون ثبوت ہے، اندازہ نہیں۔ جاری کام آمد کی شرح ضرب سائیکل ٹائم کے برابر ہے، کسی بھی مستحکم قطار کے لیے، اور یہ اس بات کی تیز جانچ ہے کہ آپ کے ڈیلیوری میٹرکس اندرونی طور پر یکساں ہیں یا نہیں۔
استعمال انتظار کے وقت کے ساتھ خطی طور پر نہیں بڑھتا۔ جب مشترکہ وسیلہ مکمل استعمال کے قریب پہنچتا ہے، قطار کی تاخیر بتدریج نہیں، تیزی سے بڑھتی ہے۔ 95 فیصد مصروف چلنے والا وسیلہ اکثر 80 فیصد پر چلنے والے سے کئی گنا زیادہ انتظار کر رہا ہوتا ہے، محض “تھوڑا بدتر” نہیں۔
قطار کا اوسط اس کی بدترین صورت چھپا دیتا ہے۔ صرف اوسط انتظار کا وقت رپورٹ کرنا گنجائش کے قریب لمبی، تکلیف دہ دم کو چھپا دیتا ہے، بالکل وہی جس کے خلاف موضوع 1.6 خبردار کرتا ہے جب اوسط کے بجائے پرسنٹائل استعمال کرنے کی بات ہو۔
قطار کی تعریف کو کسی بھی دوسرے میٹرک جتنی آسانی سے گیم کیا جا سکتا ہے۔ کوئی چیز “آئی”، “جاری”، یا “خدمت کی گئی” شمار ہوتی ہے یہ ایک انتخاب ہے، اور اسے ڈیش بورڈ کو خوشنما بنانے کے لیے بدلا جا سکتا ہے بغیر اس کے کہ کام کے ساتھ اصل میں کیا ہوتا ہے بدلے۔
پائپ لائن عموماً قطاروں کی قطار ہوتی ہے۔ ڈیلیوری پائپ لائن کئی مراحل کو زنجیر میں جوڑتی ہے، اور سب سے سست مرحلہ پوری زنجیر کی رفتار طے کرتا ہے چاہے دوسرے کتنے ہی تیز چلیں۔

سفارشات

اپنے اعداد پر بھروسا کرنے سے پہلے انہیں Little کے قانون سے جانچیں

اپنی ٹیم کا ناپا گیا اوسط جاری کام، نئے آئٹمز کی فی ہفتہ اوسط آمد کی شرح، اور اوسط سائیکل ٹائم لیں، اور جانچیں کہ جاری کام تقریباً آمد کی شرح ضرب سائیکل ٹائم کے برابر ہے یا نہیں۔ جب نہ ہو تو یہ فرض نہ کریں کہ نظریہ غلط ہے۔ اصل وجہ تلاش کریں: غیر یکساں گنا گیا مرحلے کی حد، ایسا کام جو “بلاک” پڑا ہے مگر پھر بھی جاری گنا جاتا ہے، یا سائیکل ٹائم سے مختلف کھڑکی میں ناپی گئی آمد کی شرح۔ یہ واحد جانچ زیادہ تر ٹیموں کو کسی اور طرح ملنے سے زیادہ ناقص انسٹرومینٹیشن پکڑتی ہے۔

ہر مشترکہ، صلاحیت سے محدود وسیلے کے لیے استعمال کو براہِ راست ٹریک کریں

اپنی ڈیلیوری پائپ لائن کے ان وسائل کی نشاندہی کریں جو بہت سی ٹیمیں بانٹتی ہیں، کوڈ ریویو پول، CI کلسٹر، اسٹیجنگ ماحول، اور ناپیں کہ ہر ایک اپنی دستیاب صلاحیت کے تناسب کے طور پر کتنا مصروف چلتا ہے، اسے اپنی حد کے قریب چلانے کا منصوبہ بنانے سے پہلے۔ مکمل صلاحیت کے قریب چلتا مشترکہ جائزہ لینے والوں کا گروپ جائزے کی قطار کے انتظار کے ایسے اوقات پیدا کرتا ہے جو انہیں پیدا کرنے والی طلب کے معمولی اضافے سے کہیں تیز بڑھتے ہیں، بالکل وہی حرکیات جو موضوع 2.9 کے پہلے جائزے تک کا وقت پیش رو اشارے کے طور پر دیکھنے کے مشورے کے پیچھے ہے۔

آمد کی شرح، کامیابی کی شرح، ناکامی کی شرح، اور چھوڑنے کی شرح کو الگ کریں

قطار سے نکلنے والی ہر چیز کو ایک “تھرو پٹ” یا “سروس ریٹ” کے عدد میں سمیٹنے کا مقابلہ کریں۔ چار چیزیں الگ ٹریک کریں: کام کتنی تیزی سے آتا ہے، اس میں سے کتنا کامیابی سے ختم ہوتا ہے، کتنا ناکام ہوتا ہے اور دوبارہ کام مانگتا ہے، اور کتنا کوئی ختم کرنے سے پہلے ترک یا خاموشی سے چھوڑ دیا جاتا ہے۔ وہ پائپ لائن جو تیز لگتی ہے کیونکہ اس کی چھوڑنے کی شرح خاموشی سے بڑھ گئی دراصل زیادہ ڈیلیور نہیں کر رہی، اور صرف ان چار شرحوں کو الگ ٹریک کرنا آپ کو یہ دکھائے گا۔

کثیر مرحلہ پائپ لائنوں کو قطاروں کی قطار کے طور پر ماڈل کریں

ڈیلیوری پائپ لائن، یا کوئی بھی کثیر مرحلہ عمل، واقعے کا زندگی کا چکر، بھرتی کی پائپ لائن، کو “وقت” کے غیر امتیازی گولے کے بجائے قطاروں کی زنجیر سمجھیں۔ مجموعی آمد کی شرح پہلا مرحلہ طے کرتا ہے، مجموعی تکمیل کی شرح آخری مرحلہ، اور پائپ لائن کی کل غلطی اور چھوڑنے کی گنتی ہر مرحلے کی اپنی گنتیوں کا مجموعہ ہے۔ یہ فریمنگ آپ کو فوراً بتاتی ہے کہ کس مرحلے میں سرمایہ کاری قابلِ قدر ہے: جس کا زیادہ استعمال اور زیادہ ناکامی یا چھوڑنے کی شرح کا بدترین امتزاج ہو، وہ نہیں جو انسٹرومینٹ کرنے میں سب سے آسان ہو۔

صرف تھرو پٹ نہیں بلکہ استعمال کو ذہن میں رکھ کر عملے اور WIP کی حدیں طے کریں

جب آپ فیصلہ کریں کہ ٹیم کو کتنے جائزہ لینے والے یا CI رنرز چاہییں، تو صلاحیت کو اوسط آمد کی شرح سے بالکل ملانے کے لیے سائز نہ کریں۔ اوسطاً 100 فیصد استعمال پر چلنے والی قطار عملاً لامحدود انتظار کا وقت رکھتی ہے، کیونکہ حقیقی آمد ناہموار ہوتی ہے، بالکل ہموار نہیں۔ دانستہ طور پر گنجائش کا منصوبہ بنائیں، اور “ہمارے جائزہ لینے والے تقریباً ہمیشہ مصروف ہوتے ہیں” کو آنے والے انتظار کے اوقات کے بارے میں انتباہی علامت سمجھیں، وسائل کی مؤثر تقسیم کے ثبوت کے طور پر نہیں۔

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات
کوئی رسمی قطار کا ماڈل نہیں، اندازے کا عملہ	شروع کرنا تیز؛ ٹیم کے لیے کوئی نیا ذخیرۂ الفاظ نہیں	مسلسل کم اندازہ لگاتا ہے کہ مکمل صلاحیت کے قریب انتظار کا وقت کیسے بھڑکتا ہے
موجودہ میٹرکس پر عقل مندی کی جانچ کے طور پر Little کا قانون	سستا، کوئی نیا ٹولنگ نہیں، ناقص تعریفیں جلد پکڑتا ہے	صرف یکسانیت جانچتا ہے، خود سے وجہ کی تشخیص نہیں کرتا
مکمل قطار کی نقالی (آمد کی تقسیمیں، متعدد سرور)	بوجھ تلے انتظار کے وقت کے برتاؤ کی سب سے درست پیش گوئی	حقیقی شماریاتی مہارت اور دیکھ بھال درکار جو زیادہ تر ٹیمیں برقرار نہیں رکھیں گی
گہرے ماڈل کے بغیر مشترکہ وسائل پر استعمال کی ٹریکنگ	سادہ، قابلِ عمل، انتظار کے بے قابو اوقات کی سب سے بڑی وجہ پکڑتی ہے	یہ نہیں بتاتی کہ استعمال زیادہ کیوں ہے یا بنیادی وجہ کے بارے میں کیا کرنا ہے

مرکزی کشمکش سختی بمقابلہ اپنانے کی ہے۔ مکمل قطار کی نقالی سب سے درست جواب دیتی ہے، لیکن تقریباً کوئی انجینئرنگ ٹیم اسے بنا کر برقرار نہیں رکھے گی، اور وہ ماڈل جس پر کوئی بھروسا نہیں کرتا یا اپ ڈیٹ نہیں کرتا کسی ماڈل کے نہ ہونے سے بدتر ہے۔ Little کا قانون اور بنیادی استعمال کی ٹریکنگ کچھ درستگی چھوڑتے ہیں لیکن کسی خصوصی شماریاتی مہارت کی ضرورت نہیں رکھتے اور براہِ راست ان میٹرکس میں فٹ ہوتے ہیں جو ٹیم موضوعات 2.4 سے 2.6 کے لیے پہلے ہی جمع کرتی ہے۔ ان سستی، اپنائی جانے والی جانچوں کو ڈیفالٹ رکھیں، اور مکمل نقالی اس نادر صورت کے لیے رکھیں جہاں ایک مشترکہ وسیلہ، بڑا CI فلیٹ، مخصوص جائزے کا پول، سرمایہ کاری کا جواز دینے کے لیے کافی مہنگا ہو۔

اپنی ٹیم کے ساتھ زیرِ بحث لانے کے سوالات

کیا ہمارا ناپا گیا جاری کام، آمد کی شرح، اور سائیکل ٹائم واقعی Little کے قانون کو پورا کرتے ہیں، اور اگر نہیں تو کیوں نہیں؟ یہ ناقص میٹرک کی تعریف کے لیے دستیاب سب سے تیز تشخیص ہے۔ اصل اعداد پر مل کر چلیں، اور اگر مساوات تقریباً درست نہیں تو جانچ کو مسترد کرنے کے بجائے بے میلی کو کسی مخصوص تعریفی عدم یکسانیت تک ٹریس کریں۔
ہماری ڈیلیوری پائپ لائن کے کون سے مشترکہ وسائل مکمل استعمال کے قریب چل رہے ہیں، اور کیا ہم واقعی ان کا استعمال کا عدد جانتے ہیں؟ زیادہ تر ٹیمیں ایسا وسیلہ بتا سکتی ہیں جو “ہمیشہ مصروف محسوس ہوتا ہے” لیکن اس کا استعمال کبھی براہِ راست نہیں ناپا۔ دو یا تین سب سے محدود مشترکہ وسائل کی نشاندہی کریں اور ہر ایک کے لیے حقیقی عدد حاصل کریں۔
کیا ہم کامیابی، ناکامی، اور چھوڑنے کو ایک تھرو پٹ کے عدد میں ملا رہے ہیں، اور اگر انہیں الگ کریں تو ہم کیا دیکھیں گے؟ اکیلی “مکمل ہونے والے آئٹمز” کی گنتی بڑھ سکتی ہے جبکہ معیار گرے یا کام خاموشی سے ترک ہو۔ حالیہ دور کے تھرو پٹ کو تین الگ اعداد کے طور پر دوبارہ حساب کریں اور بحث کریں کہ تقسیم وہ کیا ظاہر کرتی ہے جو ملا ہوا عدد چھپاتا تھا۔
ہماری پائپ لائن میں حقیقی رکاوٹ کہاں ہے، وہ سب سے سست مرحلہ جو اپنے نیچے کی ہر چیز کی رفتار طے کرتا ہے؟ ٹیمیں اکثر اس مرحلے کو تیز کرنے میں سرمایہ کاری کرتی ہیں جسے بہتر بنانا سب سے آسان ہو، نہ کہ وہ جو کل تھرو پٹ کو دراصل محدود کرتا ہے۔ اس مرحلے کی نشاندہی کریں جس کا زیادہ استعمال اور زیادہ ناکامی یا چھوڑنے کی شرح کا بدترین امتزاج ہو۔
اگر ہم اپنے سب سے محدود مشترکہ وسیلے میں صلاحیت شامل کریں تو کیا انتظار کا وقت واقعی بہتر ہوگا، یا طلب محض اسے بھرنے کے لیے پھیل جائے گی؟ یہ سوال حقیقی صلاحیت کی کمی کو طلب کے مسئلے سے الگ کرتا ہے، اور جواب بدلتا ہے کہ درست حل زیادہ عملہ ہے، WIP کی حد، یا قطار میں داخل ہونے سے پہلے کام کی ترجیح کے طریقے میں تبدیلی۔
کیا ہم نے کبھی “جاری” یا “آیا” کی تعریف ایسے بدلی ہے جس سے کام کے ساتھ جو ہوتا ہے وہ بدلے بغیر ڈیش بورڈ بہتر نظر آیا؟ اسے محض فرضی تشویش سمجھنے کے بجائے پچھلے سال کی حقیقی مثالوں کے ساتھ ایمانداری اور خاص طور پر پوچھنا قابلِ قدر ہے۔

شعبے کا زاویہ

اسٹارٹ اپ۔ مٹھی بھر انجینئروں کے ساتھ، زیادہ تر قطاریں اتنی چھوٹی ہیں کہ رسمی قطار کا تجزیہ ضرورت سے زیادہ ہے۔ مفید عادت چھوٹی ہے: نوٹس کریں جب ایک شخص، اکثر سب سے سینئر انجینئر، حقیقی مشترکہ وسیلہ بن جائے جس کا باقی سب انتظار کرتے ہوں، اور اسے استعمال کا مسئلہ سمجھیں جس کا نام لینا مفید ہے، پیچھے کسی رسمی ماڈل کے بغیر بھی۔

چھوٹا کاروبار۔ چھوٹے کاروبار کی ٹیم کو شاذ و نادر اس سے زیادہ نفیس چیز چاہیے کہ اپنے ایک یا دو واقعی مشترکہ وسائل، اکثر ایک جائزہ لینے والا یا ایک ڈیپلائے پائپ لائن، پر استعمال ٹریک کرے، اور اس نقطے پر نظر رکھے جہاں “عموماً دستیاب” خاموشی سے “عموماً رکاوٹ” بن جاتا ہے۔ اسپریڈ شیٹ کافی ہے؛ اس پیمانے پر مخصوص ٹولنگ ضروری نہیں۔

بڑا ادارہ۔ بڑے ادارے کے پیمانے پر مشترکہ وسائل تیزی سے بڑھتے ہیں: مرکزی پلیٹ فارم ٹیم، مشترکہ سیکیورٹی جائزہ بورڈ، درجنوں پروڈکٹ ٹیموں کو خدمت دینے والا مشترکہ CI فلیٹ۔ یہ بالکل وہ وسائل ہیں جہاں استعمال کی ٹریکنگ اپنی قیمت کماتی ہے، کیونکہ اکیلا ضرورت سے زیادہ بوجھ والا مشترکہ وسیلہ ہر اس ٹیم کے لیے ڈیلیوری کا وقت خاموشی سے بگاڑ سکتا ہے جو اس پر منحصر ہے، اور کسی انفرادی ٹیم کے اپنے میٹرکس وہ وجہ ظاہر نہیں کریں گے جو ان کی اپنی پائپ لائن سے باہر رہتی ہے۔

حکومت۔ کثیر ایجنسی اور کثیر وینڈر ڈیلیوری پروگرام اکثر کام کو مشترکہ منظوری کے بورڈز، مشترکہ سیکیورٹی تصدیق کے عمل، اور مشترکہ ٹیسٹنگ ماحول سے گزارتے ہیں جنہیں کوئی ایک ٹیم کنٹرول یا اکیلے سائز نہیں کر سکتی۔ ان مشترکہ دروازوں کا قطار کا تجزیہ، آمد کی شرح، صلاحیت، استعمال، اکثر صلاحیت بڑھانے کے لیے یا کام کے دروازے تک پہنچنے سے پہلے اس کے بیچ بنانے کے طریقے کو بدلنے کے لیے کاروباری جواز کا سب سے واضح دستیاب ثبوت ہوتا ہے۔

مثالیں

بڑا ادارہ۔ ایک کلاؤڈ انفراسٹرکچر فراہم کنندہ کی اندرونی پلیٹ فارم ٹیم نے نوٹس کیا کہ تبدیلیوں کا لیڈ ٹائم (موضوع 2.10) ہر اس پروڈکٹ ٹیم میں بڑھ رہا تھا جو اس کے مشترکہ CI فلیٹ پر منحصر تھی، حالانکہ کسی انفرادی ٹیم نے اپنا کام کا طریقہ نہیں بدلا تھا۔ استعمال کے تجزیے نے پایا کہ فلیٹ بنیادی اوقات میں 90 فیصد سے اوپر مصروف چل رہا تھا، اس نقطے سے بہت آگے جہاں قطار کا نظریہ پیش گوئی کرتا ہے کہ انتظار کا وقت بتدریج نہیں تیزی سے بڑھتا ہے۔ پلیٹ فارم ٹیم نے CI کی صلاحیت بڑھائی اور منصفانہ حصہ شیڈیولنگ کی پالیسی متعارف کرائی تاکہ کسی ایک ٹیم کی سرگرمی کا جھونکا قطار پر اجارہ داری نہ کر سکے۔ اوسط CI انتظار کا وقت ایک ماہ کے اندر آدھے سے زیادہ گر گیا، ثبوت کہ رکاوٹ شروع سے مشترکہ، غیر مرئی قطار تھی۔

حکومت۔ ایک قومی پرمٹنگ ایجنسی کی ڈیجیٹل سروس ٹیم نے دو سال تک درخواستوں کی پروسیسنگ کو ایک “فی ہفتہ بند کیے گئے کیسز” کے تھرو پٹ کے عدد کے طور پر ٹریک کیا، اور عدد مستحکم لگتا تھا۔ قریب تر تجزیے نے، اس عدد کو منظور، مسترد، اور لمبی تاخیر کے بعد درخواست گزاروں کی طرف سے ترک کیے گئے کیسز میں تقسیم کر کے، پایا کہ اسی مدت میں ترک کرنے کی شرح تقریباً تین گنا ہو گئی تھی جبکہ منظوریاں برقرار تھیں۔ کیس ورکر کی قطار پر لاگو Little کے قانون نے دکھایا کہ جاری کام ٹیم کے بیان کردہ اوسط پروسیسنگ کے وقت کے مفہوم سے کہیں زیادہ بڑھ گیا تھا، یعنی کیسز خاموشی سے ایسی حالت میں جمع ہو رہے تھے جو “انتظار” شمار نہیں ہوتی تھی۔ ایجنسی نے ہر کھلے کیس کو ایمانداری سے گننے کے لیے کیس ٹریکنگ کی تعریفیں دوبارہ ترتیب دیں اور کیس ورکر کی صلاحیت اس حساب سے بڑھائی کہ استعمال 85 فیصد سے نیچے رہے، جو اب تھرو پٹ کے عدد کے ساتھ مستقل عملی ہدف کے طور پر ٹریک ہوتی ہے۔

کاروباری جواز: محرکات، ROI، اور TCO

بنیادی قطار کے تجزیے کا منافع یہ ہے کہ یہ “پائپ لائن سست محسوس ہوتی ہے” کو ایک مخصوص، قابلِ دفاع فیصلے میں بدل دیتا ہے، اس مشترکہ وسیلے میں گنجائش شامل کریں، اس ملے ہوئے میٹرک کو اس کے حقیقی اجزا میں توڑیں، بجائے “تیز کام کریں” کی مبہم دھکیل کے جو اصل وجہ چھوڑ دیتی ہے۔ اوپر کی کلاؤڈ انفراسٹرکچر کی مثال، انفرادی ٹیموں کے رویے میں تبدیلی کے بجائے صلاحیت اور شیڈیولنگ کی اصلاح سے آدھا انتظار کا وقت، وہ نمونہ ہے جو یہ تجزیہ قابلِ اعتماد طور پر پیدا کرتا ہے: حل تقریباً ہمیشہ ہر نیچے کی ٹیم سے ایسی رکاوٹ کے گرد تیز چلنے کو کہنے سے سستا ہوتا ہے جسے وہ دیکھ ہی نہیں سکتیں۔

اپنانے کی کل لاگت واقعی کم ہے۔ Little کا قانون اور استعمال کی ٹریکنگ کو اس سے آگے کسی نئی ٹولنگ کی ضرورت نہیں جو موضوعات 2.4 سے 2.6 پہلے ہی جمع کرنے کو کہتے ہیں: آمد کی شرح، جاری کام، اور سائیکل ٹائم۔ سرمایہ کاری زیادہ تر تجزیاتی نظم ہے، اعداد کو ایک دوسرے سے جانچنا اور مشترکہ وسائل کے استعمال کا دورانیہ وار جائزہ لینا اس سے پہلے کہ وہ ادارے کا اگلا غیر واضح لیڈ ٹائم کا بگاڑ بنیں۔

منفی نمونے اور خطرات

مشترکہ وسیلے کی صلاحیت کو اس کی اوسط آمد کی شرح سے بالکل ملانے کے لیے سائز کرنا: زیادہ استعمال اور بے قابو انتظار کے اوقات کی ضمانت دیتا ہے جب بھی طلب مختصراً ناہموار ہو۔
صرف اوسط انتظار کا وقت رپورٹ کرنا، کبھی پرسنٹائل نہیں: وہ لمبی دم چھپا دیتا ہے جو اس میں انتظار کرنے والے لوگوں کے لیے سب سے اہم ہے۔
کامیابی، ناکامی، اور چھوڑنے کو ایک تھرو پٹ کے عدد میں ملانا: اس موضوع کے مرکز میں گیمنگ کا طریقہ۔ دباؤ میں ٹیم چھوڑنے کی شرح کو خاموشی سے بڑھنے دے کر، ترک شدہ ٹکٹ، خاموشی سے گرائی گئی درخواستیں، وہ کام جو ناکامی کے طور پر کبھی نہیں گنا جاتا، تھرو پٹ کو صحت مند دکھا سکتی ہے۔ حفاظتی حد آمد، کامیابی، ناکامی، اور چھوڑنے کی شرح کو چار الگ، نظر آنے والے اعداد کے طور پر ٹریک کرنا ہے، وہی نظم جو موضوع 1.2 اس کتاب کے ہر میٹرک سے مانگتا ہے، تاکہ بڑھتی چھوڑنے کی شرح چپٹے تھرو پٹ کے چارٹ کے پیچھے چھپ نہ سکے۔
“ہمارے لوگ ہمیشہ مصروف ہیں” کو تعریف سمجھنا: یہ زیادہ استعمال کی علامت ہے، لمبے، غیر متوقع انتظار کے اوقات کی بنیادی وجہ۔
جاری کام کو خاموشی سے چھوٹا کرنے کے لیے “جاری” کی تعریف بدلنا: کام کو غیر شمار حالت میں، “بلاک”، “روکا ہوا”، منتقل کرتا ہے بغیر ختم کرنے کا وقت بدلے، اور Little کے قانون کی وہ جانچ توڑ دیتا ہے جو اسے پکڑ لیتی۔
یہ فرض کرنا کہ قطار کے ماڈل کو ایک بار بننے کے بعد دیکھ بھال کی ضرورت نہیں: آمد کے نمونے اور صلاحیت مسلسل بدلتے ہیں، اور باسی ماڈل اعتماد کے ساتھ غلط پیش گوئیاں پیدا کرتا ہے۔

پختگی کا نمونہ

درجہ 1، آغاز (Initiate): کوئی قطار صریح طور پر نہیں ناپی جاتی؛ انتظار کے وقت پر قصے کہانیوں سے بات ہوتی ہے “چیزیں سست محسوس ہوتی ہیں۔”
درجہ 2، ترقی (Develop): کم از کم ایک پائپ لائن کے لیے آمد کی شرح، جاری کام، اور سائیکل ٹائم ٹریک ہوتے ہیں، لیکن Little کے قانون یا مشترکہ وسائل پر استعمال کے مقابلے میں کبھی نہیں جانچے جاتے۔
درجہ 3، معیار بندی (Standardize): Little کا قانون ڈیلیوری پائپ لائنوں میں معمول کی یکسانیت کی جانچ ہے، اور سب سے اہم مشترکہ وسائل کے لیے استعمال صریح طور پر ٹریک ہوتا ہے۔
درجہ 4، انتظام (Manage): ہر اہم قطار کے لیے کامیابی، ناکامی، اور چھوڑنے کی شرح الگ ٹریک ہوتی ہیں، اور صلاحیت کے فیصلے صرف اوسط طلب نہیں بلکہ استعمال کے اہداف استعمال کرتے ہیں۔
درجہ 5، ہم آہنگی (Orchestrate): ادارہ اپنی بڑی پائپ لائنوں کو قطاروں کی قطار کے طور پر ماڈل کرتا ہے، حقیقی رکاوٹوں کی منظم طور پر نشاندہی کرتا ہے، اور صلاحیت یا عمل کی ان مخصوص تبدیلیوں کی نشاندہی کر سکتا ہے جو قطار کے تجزیے کی وجہ سے کی گئیں، ناپے گئے انتظار کے وقت میں بہتری کے ساتھ۔

بحث کے لیے خیالات

ہماری ڈیلیوری پائپ لائنوں میں سے ایک چنیں اور جانچیں کہ آج اس کے اعداد Little کے قانون کو پورا کرتے ہیں یا نہیں۔
ہمارے ادارے کے اس واحد مشترکہ وسیلے کا نام لیں جس کے بارے میں زیادہ تر لوگ متفق ہوں گے کہ وہ “ہمیشہ مصروف” ہے، اور اس کا اصل استعمال کا عدد معلوم کریں۔
اگر ہم پچھلی سہ ماہی کے لیے اپنے تھرو پٹ کے چارٹ کو کامیابی، ناکامی، اور چھوڑنے کی شرحوں میں تقسیم کریں تو وہ کیسا دکھے گا؟
اگر ہمیں اس سال بالکل ایک مشترکہ وسیلے میں صلاحیت بڑھانی ہو تو کون سا، اور کون سا ثبوت اس کا جواز دے گا؟

اہم نکات

Little کا قانون، جاری کام آمد کی شرح ضرب سائیکل ٹائم کے برابر، ثبوت ہے، اندازہ نہیں، اور یہ اس بات کی سب سے سستی دستیاب جانچ ہے کہ آپ کے ڈیلیوری میٹرکس اندرونی طور پر یکساں ہیں یا نہیں۔
مکمل صلاحیت کے قریب پہنچنے پر انتظار کا وقت بتدریج نہیں، تیزی سے بڑھتا ہے۔ “ہمیشہ مصروف” کو تعریف نہیں، انتباہی علامت سمجھیں۔
آمد کی شرح، کامیابی کی شرح، ناکامی کی شرح، اور چھوڑنے کی شرح کو الگ ٹریک کریں؛ انہیں ایک تھرو پٹ کے عدد میں ملانا اس موضوع کا مرکزی گیمنگ کا طریقہ ہے۔
کثیر مرحلہ پائپ لائن کو قطاروں کی قطار کے طور پر ماڈل کریں، اور اس مرحلے میں سرمایہ کاری کریں جس کا زیادہ استعمال اور زیادہ ناکامی یا چھوڑنے کی شرح کا بدترین امتزاج ہو، نہ کہ اس میں جو بہتر بنانا سب سے آسان ہو۔
مکمل قطار کی نقالی کے بجائے سستی، اپنائی جانے والی جانچوں، Little کا قانون اور استعمال کی ٹریکنگ، کو ترجیح دیں جسے چند ٹیمیں برقرار رکھیں گی۔

حوالہ جات اور مزید مطالعہ

Little, John D. C. “A Proof for the Queuing Formula: L = λW.” Operations Research, 1961.
Kleinrock, Leonard. Queueing Systems, Volume 1: Theory. Wiley-Interscience, 1975.
Wescott, Bob. The Every Computer Performance Book: How to Avoid and Solve Performance Problems on the Computer Systems You Work With. CreateSpace Independent Publishing Platform, 2013.
Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
Vacanti, Daniel S. Actionable Agile Metrics for Predictability. Actionable Agile Press, 2015.