1.10 انجینئرنگ کی اثر انگیزی اور ڈویلپر پیداواریت

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

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

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

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

بنیادی اصول

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

سفارشات

ایک اشاریے کے جال کو مسترد کریں

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

جو ناپتے ہیں اسے ترتیب دینے کے لیے SPACE استعمال کریں

SPACE فریم ورک وہ پانچ جہتیں دیتا ہے جنہیں اکٹھا رکھنا قابل قدر ہے: Sاطمینان اور فلاح (Satisfaction and well-being)، Pکارکردگی (Performance)، Aسرگرمی (Activity)، Cابلاغ اور تعاون (Communication and collaboration)، اور Eکارکردگی اور بہاؤ (Efficiency and flow)۔ SPACE کا نکتہ یہ ہے کہ آپ کو کم از کم چند جہتیں چننی چاہئیں، کبھی صرف ایک نہیں، اور کبھی سب ایک ہی زمرے سے نہیں۔ سرگرمی کے اشاریے (کمٹ، تعیناتیاں) دلکش ہیں کیونکہ جمع کرنا آسان ہے، لیکن اکیلے وہ بگاڑ دیتے ہیں۔ انہیں اطمینان کے اشارے اور کارکردگی کے اشارے کے ساتھ جوڑیں تاکہ کوئی ایک جہت بغیر دوسروں کے بے نقاب کیے کھیلی نہ جا سکے۔ جو ٹیم زیادہ تعیناتیاں کر رہی ہو جبکہ اطمینان گر رہا ہو اور تبدیلی کی ناکامی کی شرح چڑھ رہی ہو وہ زیادہ پیداواری نہیں، اور متوازن مجموعہ آپ کو یہ فوراً دکھا دیتا ہے۔

ڈویلپر تجربے کو فیڈبیک کے چکروں، ذہنی بوجھ اور بہاؤ کے طور پر سمجھیں

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

تاثرات کو نظام کے اشاریوں سے ملائیں

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

DORA کو ترسیل کے اشارے کے طور پر استعمال کریں، درجہ بندی کی فہرست کے طور پر نہیں

چار DevOps Research and Assessment (DORA) اشاریے (تعیناتی کی تعدد، تبدیلیوں کا لیڈ ٹائم، تبدیلی کی ناکامی کی شرح، اور سروس بحال کرنے کا وقت) آپ کی ترسیل کی صلاحیت کی مضبوط، تحقیق پر مبنی پڑھت ہیں، جو رفتار کو استحکام کے ساتھ جوڑتے ہیں تاکہ کسی ایک کی دوسرے کے لیے قربانی نہ ہو۔ ان کی گہرائی باب 11.5 کے پاس ہے، اور جس ترسیلی پائپ لائن کو وہ ناپتے ہیں اسے باب 11.2 سنبھالتا ہے؛ وہاں استعمال کریں۔ یہاں رہنمائی ان کو رکھنے کے طریقے کے بارے میں ہے۔ DORA کو ٹیم کی سطح کا صحت کا اشارہ سمجھیں جو دکھائے کہ آیا آپ کا ترسیلی نظام بہتر ہو رہا ہے، ٹیموں یا افراد کو درجہ دینے والے اسکور بورڈ کے طور پر نہیں۔ جس لمحے DORA کے اعداد کسی کے کارکردگی جائزے میں آتے ہیں، ٹیمیں تعدد بڑھانے کے لیے تعیناتیاں توڑنا اور ناکامی کی شرح بچانے کے لیے واقعات چھپانا شروع کر دیتی ہیں، اور اشارہ مر جاتا ہے۔

نظام کو ناپیں، فرد کی کبھی نگرانی نہ کریں

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

بے کار مشقت اور رگڑ پر براہ راست حملہ کریں

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

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

طریقہ	فوائد	نقصانات
واحد پیداواریت اشاریہ (LOC، ویلوسٹی، کمٹ)	سستا، آسان، قیادت کے لیے ایک عدد	فوراً کھیلا جاتا ہے؛ قدر نہیں سرگرمی ناپتا ہے؛ اعتماد کھوکھلا کرتا ہے
SPACE طرز کا متوازن مجموعہ	کھیلنے کے خلاف مزاحم؛ حقیقت کی عکاسی	جمع کرنے میں زیادہ کام؛ ایک شکل میں خلاصہ کرنا مشکل
DevEx سروے (تاثراتی)	وہ محسوس شدہ تکلیف پکڑتا ہے جو آلات سے چھوٹتی ہے	موضوعی؛ ایماندار رہنے کے لیے اعتماد اور پیروی چاہیے
نظام کے اشاریے (DORA، پائپ لائن کے اوقات)	معروضی، مسلسل، مجموعی طور پر جعلی کرنا مشکل	حوصلے اور سیاق سے نابینا؛ افراد پر لاگو ہوں تو خطرناک
دونوں کو ملانا	ہر ماخذ دوسرے کی اصلاح کرتا ہے؛ مضبوط	ٹولنگ اور سروے کے نظم و ضبط میں سرمایہ کاری چاہیے

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

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

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

شعبہ جاتی نقطۂ نظر

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

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

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

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

مثالیں

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

بڑا ادارہ۔ چالیس انجینئرنگ ٹیموں والا بینک اپنے اندرونی پلیٹ فارم میں مسلسل سرمایہ کاری کا جواز دینا چاہتا ہے۔ پلیٹ فارم گروپ متوازن پیمائش کا پروگرام اپناتا ہے: تمام ٹیموں میں سہ ماہی DevEx سروے، SPACE طرز کے اشارے، اور DORA اشاریے جو ٹیم کی سطح پر ترسیل کی صحت کے رجحان کے طور پر پڑھے جاتے ہیں (باب 11.5)۔ اہم بات یہ ہے کہ وہ ٹیموں کا منصفانہ بینچ مارک کرتے ہیں ہر ٹیم کا اپنے وقت کے ساتھ راستے سے موازنہ کر کے، ایک دوسرے سے نہیں، کیونکہ ٹیم کے سیاق بے حد مختلف ہیں۔ ڈیٹا دکھاتا ہے کہ پکی سڑکوں (باب 8.4) پر ٹیمیں نئے انجینئروں کو ہفتوں کے بجائے دنوں میں آغاز کار کراتی ہیں اور کہیں کم ذہنی بوجھ رپورٹ کرتی ہیں۔ وہ شواہد، سینکڑوں ڈویلپرز میں واپس حاصل کی گئی صلاحیت کے طور پر پیش، پلیٹ فارم کو مزید ایک سال کے لیے فنڈ کرتے ہیں۔ انفرادی ٹیلی میٹری جان بوجھ کر کبھی جمع نہیں کی جاتی۔

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

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

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

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

ضد نمونے اور خامیاں

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

پختگی کا ماڈل

سطح 1، آغاز: پیداواریت اندازے یا کوڈ کی لائنوں، ویلوسٹی یا گھنٹوں جیسے واحد قابل کھیل اشاریے سے پرکھی جاتی ہے۔ پیمائش فی البدیہہ اور ردعملی ہے، رگڑ غیر مرئی ہے، شکایتیں قصوں کی صورت میں ہیں، اور کوئی نہیں بتا سکتا کہ ادارہ بہتر ہو رہا ہے یا نہیں۔
سطح 2، ترقی: کچھ ٹیمیں بنیادی عمل اپناتی ہیں: چند اشاریے، اکثر سرگرمی کی گنتی، اور کبھی کبھار ڈویلپر تجربہ سروے۔ عمل ٹیم سے ٹیم غیر مستقل ہیں، ڈیٹا جمع ہوتا ہے مگر شاذ ہی اس پر عمل ہوتا ہے، خام بین ٹیم موازنے رینگ آتے ہیں، اور افراد کو درجہ بندی سے بچانے والا کوئی مشترک اصول نہیں۔
سطح 3، معیار بندی: متوازن پیمائشی پروگرام دستاویزی اور پورے ادارے میں لاگو ہے، SPACE طرز کی جہتوں، باقاعدہ DevEx سروے، اور ترسیل کے اشارے کے طور پر DORA (باب 11.5) کے ساتھ۔ اشاریے پالیسی کے ذریعے ٹیموں تک جمع ہوتے ہیں، افراد کو کبھی درجہ نہیں دیا جاتا، اور نتائج فیڈبیک کے چکر مختصر کرنے اور بے کار مشقت کاٹنے کے ٹھوس کام کو آگے بڑھاتے ہیں (باب 9.1)۔
سطح 4، انتظام: پروگرام کو بنیادی خطوط کے مقابل ناپا اور کنٹرول کیا جاتا ہے۔ فیڈبیک چکر کے اوقات، سروے کے اسکور اور DORA کے رجحانات متفقہ اہداف رکھتے ہیں اور وقت کے ساتھ ٹریک ہوتے ہیں؛ ہر ٹیم کا موازنہ پڑوسیوں کے بجائے اس کے اپنے راستے سے ہوتا ہے؛ پلیٹ فارم اور بے کار مشقت میں کمی کی سرمایہ کاریوں کا جواز واپس حاصل کی گئی صلاحیت کے پہلے اور بعد کے ڈیٹا سے دیا جاتا ہے؛ اور کسی بھی اشارے میں گراوٹ بغیر نوٹس گزرنے کے بجائے جائزہ متحرک کرتی ہے۔
سطح 5، ہم آہنگی: پیمائش قابل اعتماد، معمول کی اور موافق ہے۔ تاثراتی اور نظام کا ڈیٹا ملایا جاتا ہے، رجحانات مسلسل بہتری کو کھلاتے ہیں، رگڑ اور ذہنی بوجھ فعال طور پر تلاش اور ہٹائے جاتے ہیں، ادارہ بدلنے کے ساتھ پیمائش کے مجموعے پر نظر ثانی ہوتی ہے، اور اثر انگیزی کاروباری اور عوامی نتائج کے ساتھ مربوط ہے بغیر کسی اشاریے کو بگاڑنے والا ہدف بننے دیے۔

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

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

اہم نکات

انجینئروں کی پیداواریت کثیر جہتی ہے۔ کسی بھی ایک عدد (کوڈ کی لائنیں، ویلوسٹی، کمٹ، گھنٹے) کو وہی پیمانہ ہونے سے مسترد کریں، کیونکہ گڈہارٹ کا قانون ضمانت دیتا ہے کہ اس سے کھیلا جائے گا۔
کئی جہتیں اکٹھی رکھنے کے لیے SPACE فریم ورک (اطمینان اور فلاح، کارکردگی، سرگرمی، ابلاغ اور تعاون، کارکردگی اور بہاؤ) استعمال کریں تاکہ کوئی ایک جہت اکیلے نہ کھیلی جا سکے۔
ڈویلپر تجربہ فیڈبیک کے چکروں، ذہنی بوجھ اور بہاؤ پر آتا ہے۔ چکروں کو مختصر کرنا اور بوجھ ہٹانا حقیقی پیداواریت ہے جسے سرگرمی کی گنتی کبھی نہیں دکھاتی۔
DevEx سروے کے تاثراتی ڈیٹا کو اپنے ٹولز کے نظام کے ڈیٹا کے ساتھ ملائیں؛ ہر ایک دوسرے کی اصلاح کرتا ہے۔
DORA اشاریوں کو ٹیم کی سطح کے ترسیل کے اشارے کے طور پر سمجھیں، درجہ بندی کی فہرست نہیں؛ ان کی گہرائی باب 11.5 اور پائپ لائن باب 11.2 میں ہے۔
نظام کو ناپیں، فرد کو کبھی نہیں۔ ٹیموں تک جمع کریں، جائزہ باب 1.3 کے الگ انسانی ذرائع میں رکھیں، اور پیمائش کو کبھی نگرانی نہ بننے دیں۔
واپس حاصل شدہ وقت بے کار مشقت کاٹنے (باب 9.1)، کوڈ ریویو تیز کرنے (باب 2.5)، اور سڑکیں پکی کرنے (باب 8.4) پر خرچ کریں۔ کسی اشاریے کو بگاڑنے والا ہدف بنائے بغیر اثر انگیزی کو کاروباری نتائج سے جوڑیں۔

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

Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity” (ACM Queue, 2021): the multidimensional framework.
Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler, “DevEx: What Actually Drives Productivity” (ACM Queue, 2023): feedback loops, cognitive load, and flow.
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps (the DORA metrics and their research basis).
DORA, Accelerate State of DevOps Report (annual): the ongoing research programme behind the four metrics.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds., Site Reliability Engineering (toil and its elimination).
Matthew Skelton and Manuel Pais, Team Topologies (cognitive load as a first-class design concern).
Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (the origin of flow state).
Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams (focus, interruption, and the human side of productivity).
Goodhart, C. A. E., “Problems of Monetary Management: The UK Experience” (1975): the origin of Goodhart’s law; see also Marilyn Strathern’s widely quoted formulation.
U.S. Government Accountability Office (GAO) guidance on performance measurement: measuring value in non-market public-sector settings.