2.1 Flow Framework

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

Flow Framework (بہاؤ کا فریم ورک) انتظامی اور ساختی ماڈل ہے جسے Mik Kersten نے بنایا اور اپنی 2018 کی کتاب Project to Product میں شائع کیا۔ یہ اس سوال کا جواب دینے کے لیے ہے جس کا جواب خالص پائپ لائن کے میٹرکس نہیں دے سکتے: صرف یہ نہیں کہ کوڈ کمٹ سے پروڈکشن تک کتنی تیزی سے اور کتنی حفاظت سے چلتا ہے، بلکہ یہ کہ پائپ لائن میں کس قسم کی قدر بہہ رہی ہے، اور کیا یہ مرکب کاروبار کی اصل حکمتِ عملی کی عکاسی کرتا ہے۔ فریم ورک سافٹ ویئر کی ڈیلیوری کو قدر کا سلسلہ (value stream) سمجھتا ہے، یعنی سرگرمیوں کا وہ ابتدا سے انتہا تک کا سلسلہ جو کسی خیال کو ایسی قدر میں بدلتا ہے جو صارف کو ملتی ہے، اور یہ براہِ راست لین مینوفیکچرنگ کی قدر کے سلسلے کی نقشہ سازی کی روایت سے لیتا ہے۔

یہ کتاب Flow Framework کو حصہ 2 کے تنظیمی ڈھانچے کے طور پر استعمال کرتی ہے۔ موضوع 2.2 اس کے چار بہاؤ کے آئٹمز متعارف کراتا ہے، موضوعات 2.3 اور 2.4 اس کے پانچ بہاؤ کے میٹرکس متعارف کراتے ہیں، موضوع 2.8 ان میٹرکس کو کلاسیکی Lean قدر کے سلسلے کی نقشہ سازی میں ان کے ماخذ تک واپس لے جاتا ہے، اور موضوع 2.10 DORA میٹرکس کا احاطہ ایک زیادہ تنگ، پائپ لائن پر مرکوز حوالہ جاتی فریم ورک کے طور پر کرتا ہے جس کے ساتھ یہ حصہ اب آغاز نہیں کرتا۔ یہ دانستہ انتخاب ہے، DORA کی تحقیق کی تردید نہیں۔ DORA نظام کے تھرو پٹ اور استحکام کو حقیقی شماریاتی سختی سے ناپتا ہے، لیکن وہ اس سوال پر خاموش ہے جس کی کاروباری رہنما کو سب سے زیادہ فکر ہوتی ہے: اس سہ ماہی میں انجینئرنگ کے ادارے نے جو کچھ بھیجا اس میں سے کتنا نئی صارف قدر تھا، اور کتنا خاموشی سے نقائص ٹھیک کرنے، خطرہ سنبھالنے، یا قرض اتارنے میں کھپ گیا۔ Flow Framework اسی مرکب کو نظر آنے والا بنانے کے لیے بنا ہے۔

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

بنیادی اصول

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

سفارشات

کچھ بھی انسٹرومینٹ کرنے سے پہلے اپنے قدر کے سلسلے کا نقشہ بنائیں

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

بہاؤ کے میٹرکس کو ان ٹولز سے جوڑیں جو آپ کی ٹیمیں پہلے سے استعمال کرتی ہیں

Flow Framework مسلسل، خودکار قدر کے سلسلے کے انتظام کے لیے بنا ہے، دورانیہ وار دستی نقشہ سازی کی مشق کے لیے نہیں۔ بہاؤ کے آئٹم کی ٹریکنگ براہِ راست ان ٹولز میں ضم کریں جن سے کام پہلے ہی گزرتا ہے، Jira، Azure DevOps، GitHub، بجائے اس کے کہ متوازی ٹریکنگ سسٹم بنائیں جسے ٹیموں کو ہاتھ سے اپ ڈیٹ کرنا پڑے۔ بہاؤ کے آئٹم کی حالت بنیادی ٹکٹ یا پل ریکویسٹ کے آگے بڑھنے کے ساتھ خود اپ ڈیٹ ہونی چاہیے، وہی انسٹرومینٹیشن بمقابلہ خود رپورٹ کا نظم جو موضوع 1.5 اس کتاب کے ہر میٹرک کے لیے تجویز کرتا ہے۔

بہاؤ کی تقسیم براہِ راست کاروباری اسٹیک ہولڈرز کو پیش کریں، صرف انجینئرنگ کی قیادت کو نہیں

اس فریم ورک کا سب سے بڑا ضائع شدہ موقع اسے اندرونی انجینئرنگ ٹول سمجھنا ہے۔ بہاؤ کی تقسیم، فیچرز بمقابلہ نقائص، خطرے، اور قرض کی طرف جانے والے کام کا تناسب (موضوع 2.3)، خاص طور پر پروڈکٹ اور کاروباری قیادت کے ساتھ ہونے والی گفتگو کے لیے ڈیزائن کی گئی ہے، کیونکہ یہ ایک ضمنی ترجیحی فیصلے، نئی قدر بمقابلہ نظام کو چلتا رکھنے پر کتنی صلاحیت جاتی ہے، کو فرض کیے جانے کے بجائے صریح اور قابلِ گفت و شنید بنا دیتی ہے۔

چار بہاؤ کے آئٹمز کو حقیقی درجہ بندی سمجھیں، رسمی کارروائی نہیں

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

جب ادارہ بدلے تو اپنے قدر کے سلسلے کے نقشے پر نظرِ ثانی کریں، طے شدہ شیڈول پر نہیں

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

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

طریقہ	فوائد	نقصانات
صرف پائپ لائن میٹرکس (DORA، موضوع 2.10)	سادہ، اچھی طرح توثیق شدہ، موجودہ CI/CD ڈیٹا سے انسٹرومینٹ کرنا سستا	اس بارے میں خاموش کہ کس قسم کی قدر ڈیلیور ہو رہی ہے
مکمل Flow Framework اپنانا	ڈیلیوری کو کاروباری حکمتِ عملی سے جوڑتا ہے؛ قدر کے مرکب کو نظر آنے والا اور قابلِ گفت و شنید بناتا ہے	ایماندار قدر کے سلسلے کا نقشہ اور بہاؤ کے آئٹم کی یکساں درجہ بندی کا نظم درکار
جامد، ایک بار کی قدر کے سلسلے کی نقشہ سازی	سستی، ورکشاپ کی مشق کے طور پر جلدی چلتی ہے	جلد باسی ہو جاتی ہے؛ زندہ میٹرک نہیں، اسنیپ شاٹ دیتی ہے
مسلسل، ٹول سے مربوط قدر کے سلسلے کا انتظام	زندہ، ہمیشہ تازہ ڈیٹا؛ بہت سے قدر کے سلسلوں میں پھیلتا ہے	پہلے سے حقیقی ٹولنگ انضمام کا کام درکار

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

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

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

شعبے کا زاویہ

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

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

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

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

مثالیں

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

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

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

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

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

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

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

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

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

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

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

اہم نکات

Mik Kersten کی Project to Product سے Flow Framework یہ ناپتا ہے کہ ڈیلیوری پائپ لائن سے کس قسم کی قدر گزرتی ہے، صرف یہ نہیں کہ خود پائپ لائن کتنی تیز چلتی ہے۔
فریم ورک کی پیمائش کی اکائی قدر کا سلسلہ ہے، ٹیم یا پائپ لائن نہیں، اور کچھ بھی انسٹرومینٹ کرنے سے پہلے اس کا ایمانداری سے نقشہ بنانا آتا ہے۔
بہاؤ کے آئٹم کی درجہ بندی داخلے پر، بعد از وقوع نہیں، اس موضوع کے مرکزی گیمنگ کے طریقے کے خلاف حفاظتی حد ہے: زیادہ پیداواری دکھنے کے لیے قرض یا خطرے کے کام کو خاموشی سے فیچرز کے طور پر دوبارہ لیبل کرنا۔
بہاؤ کے میٹرکس کو موجودہ ٹولز سے جوڑیں، Jira، Azure DevOps، GitHub، نہ کہ متوازی دستی ٹریکنگ سسٹم سے جو حقیقی کام کے بوجھ تلے زندہ نہیں رہے گا۔
بہاؤ کا ڈیٹا براہِ راست کاروباری اسٹیک ہولڈرز کو پیش کریں؛ وہ گفتگو، نہ کہ اندرونی انجینئرنگ ڈیش بورڈ، صرف پائپ لائن والے میٹرکس پر فریم ورک کا بنیادی فائدہ ہے۔

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

Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018.
Rother, Mike, and John Shook. Learning to See: Value Stream Mapping to Create Value and Eliminate Muda. Lean Enterprise Institute, 1999.
Kim, Gene, Kevin Behr, and George Spafford. The Phoenix Project. IT Revolution Press, 2013.
Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook. IT Revolution Press, 2016.