3.3 کارکردگی کے میٹرکس اور نتائج کے نائب

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

کارکردگی (Performance)، SPACE کا P (موضوع 3.1)، وہ جہت ہے جو سب سے اکثر سرگرمی سے الجھائی جاتی ہے، اور یہی الجھن بالکل وہ چیز ہے جسے روکنے کے لیے یہ موضوع موجود ہے۔ کارکردگی پوچھتی ہے کہ کیا انجینئر یا ٹیم کے کام نے واقعی اچھا نتیجہ پیدا کیا: ایسی فیچر جو بھیجی گئی اور کام کی، ایسا نظام جو قابلِ اعتماد رہا، ایسی تبدیلی جس نے کاروبار یا صارف کے میٹرک کو صحیح سمت میں حرکت دی۔ سرگرمی (موضوع 3.4) صرف پوچھتی ہے کہ کتنی حرکت ہوئی۔ ٹیم بہت زیادہ فعال اور کم کارکردگی والی ہو سکتی ہے، مسلسل چھوٹی تبدیلیاں بھیجتی ہوئی جو کبھی کسی نتیجے کو حرکت نہیں دیتیں، اور الٹا بھی اتنا ہی ممکن ہے: ایسی ٹیم جو شاذ و نادر بھیجتی ہے لیکن جس کی تبدیلیاں قابلِ اعتماد طریقے سے بالکل درست جگہ لگتی ہیں۔

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

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

بنیادی اصول

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

سفارشات

ایک کارکردگی کے اسکور کے بجائے کئی ملتے ہوئے اشارے ملائیں

کارکردگی کا ثبوت متعدد ماخذ سے لیں: معیار کے لیے تبدیلی کی ناکامی کی شرح (موضوع 2.10) اور نقصان کے بچ نکلنے کی شرح (موضوع 5.1)، کام اہم تھا یا نہیں اس کے لیے اصل فیچر کے اپنانے سے جڑے ڈیپلائمنٹ کے نتائج (موضوع 5.2)، اور ایسے سیاق کے لیے جسے خالص میٹرک نہیں پکڑ سکتا ٹیم کے اسٹریٹجک اہداف میں حصے کا معیاری ہم مرتبہ یا مینیجر کا جائزہ۔ ان میں سے کوئی ایک اکیلا قابلِ اعتماد نہیں؛ مل کر، جب وہ ایک ہی نتیجے پر ملیں، تو وہ کسی بھی ایک عدد سے کہیں زیادہ قابلِ اعتماد ہیں۔

ٹیم کی سطح پر ناپیں، انفرادی انتساب کا مقابلہ کریں

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

معیار کو کارکردگی کی تعریف میں براہِ راست شامل کریں

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

کارکردگی کا ڈیٹا سرمایہ کاری اور عمل کے فیصلوں کو باخبر کرنے کے لیے استعمال کریں، انفرادی درجہ بندی کے لیے نہیں

کارکردگی کے ڈیٹا کا پیداواری استعمال یہ طے کرنا ہے کہ مزید کہاں سرمایہ کاری کی جائے (جو ٹیم مسلسل مضبوط نتائج دیتی ہے وہ مزید وسائل اور خود مختاری کی مستحق ہے) اور کہاں تحقیق کی جائے (جس ٹیم کا کام مسلسل نہیں لگتا وہ مدد کی مستحق ہے، الزام کی نہیں، موضوع 1.1 کے تشخیصی انداز کے مطابق)۔ کارکردگی کے ڈیٹا پر افراد یا ٹیموں کی ایک دوسرے کے مقابل مسابقتی درجہ بندی بالکل اس گیمنگ اور حوصلے کے نقصان کو دعوت دیتی ہے جس کے خلاف یہ کتاب خبردار کرتی ہے اور شاذ و نادر تشخیصی استعمال سے بہتر نتائج پیدا کرتی ہے۔

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

جو ٹیمیں مشترکہ بنیادی ڈھانچہ، اندرونی ٹولز، یا پلیٹ فارم کی صلاحیتیں بناتی ہیں (ساتھی software-engineering-guide کتاب کا پلیٹ فارم انجینئرنگ کا موضوع اسے براہِ راست احاطہ کرتا ہے) اکثر نتائج میں اپنا حصہ کسی بھی ایک صارف کے سامنے والے میٹرک سے کئی قدم دور رکھتی ہیں۔ ان ٹیموں کی کارکردگی ان ٹیموں پر ان کے اثر، اپنے پلیٹ فارم کے اپنانے، استعمال کرنے والی ٹیموں کی رپورٹ کردہ رگڑ میں کمی، سے ناپیں، بجائے اس کے کہ فطری طور پر بالواسطہ کام پر غیر موزوں براہِ راست نتیجے کا میٹرک مسلط کریں۔

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

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

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

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

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

شعبے کا زاویہ

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

چھوٹا کاروبار۔ ڈیلیوری اور معیار کا جو ڈیٹا آپ کے پاس پہلے سے ہے (موضوع 2.10، موضوع 5.1) اسے اس بارے میں براہِ راست، ایماندار گفتگو کے ساتھ ملائیں کہ حالیہ کام نے کاروبار کی مدد کی یا نہیں، بجائے اس کے کہ رسمی کثیر اشارہ انسٹرومینٹیشن بنائیں جسے برقرار رکھنے کی گنجائش آپ کے پاس نہیں۔

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

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

مثالیں

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

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

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

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

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

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

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

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

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

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

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

اہم نکات

کارکردگی ناپتی ہے کہ کام نے اچھا نتیجہ پیدا کیا، یہ نہیں کہ کتنی حرکت ہوئی؛ اسے سرگرمی (موضوع 3.4) سے نہ ملائیں۔
متعدد، ملتے ہوئے اشارے استعمال کریں، کبھی کارکردگی کا واحد عدد نہیں، اور جھوٹی درستگی پر شک کریں۔
ٹیم یا نظام کی سطح پر ناپیں؛ انفرادی نتیجے کا انتساب عموماً ناقابلِ اعتماد ہے اور تعاون کو نقصان پہنچاتا ہے۔
معیار کارکردگی کا حصہ ہے، الگ، منقطع تشویش نہیں۔
پلیٹ فارم اور معاون ٹیموں کو ان کے کام پر غیر موزوں براہِ راست نتیجے کا میٹرک مسلط کرنے کے بجائے مناسب طور پر بالواسطہ کارکردگی کے پیمانے دیں۔

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

Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity,” ACM Queue (2021).
Accelerate: The Science of Lean Software and DevOps, by Nicole Forsgren, Jez Humble, and Gene Kim (نتائج پر مبنی کارکردگی کی پیمائش)۔
Team Topologies, by Matthew Skelton and Manuel Pais (پلیٹ فارم اور معاون ٹیم کے ڈھانچے اور ان کے حصے کو کیسے ناپا جائے)۔
Measuring and Managing Performance in Organizations, by Robert D. Austin (جھوٹی درستگی والے کارکردگی کے میٹرکس کے خطرات)۔