3.7 ڈویلپر کے تجربے کے سروے اور DevEx میٹرکس

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

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

ڈویلپر کا تجربہ (DevEx) وسیع، زیادہ حالیہ فریمنگ ہے جو اسی بنیادی خیال کے گرد ابھری جسے SPACE نے رسمی بنایا: انجینئروں کا کام مکمل کرنے کا اصل، روزمرہ کا تجربہ، رگڑ، ٹولنگ، ذہنی بوجھ، فیڈ بیک کے لوپ، خود ایک ناپنے کے قابل، بہتر کیا جا سکنے والی چیز ہے، محض نرم ثقافتی تشویش نہیں۔ DevEx کی تحقیق، خاص طور پر Abi Noda، Margaret-Anne Storey، Nicole Forsgren، اور Michaela Greiler کا تجویز کردہ فریم ورک، اس تجربے کو تین جہتوں کے گرد منظم کرتی ہے: فیڈ بیک کے لوپ، ذہنی بوجھ، اور بہاؤ کی حالت، جو اس حصے میں پہلے ہی گہرائی میں احاطہ کی گئی SPACE کی جہتوں سے قریبی ملتی اور انہیں بڑھاتی ہیں۔

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

بنیادی اصول

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

سفارشات

سوالات کو وضاحت کے لیے ڈیزائن کریں اور رہنما یا دوہرے الفاظ سے بچیں

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

یکساں جواب کے پیمانے استعمال کریں اور وسیع پیمانے پر نافذ کرنے سے پہلے نئے سوالات کی آزمائش کریں

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

جواب دینے کی شرح کو اپنے طور پر تشخیصی اشارہ سمجھیں

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

سروے کے ڈیٹا کو معروضی DevEx انسٹرومینٹیشن کے ساتھ ملائیں

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

لوپ بند کریں: نتائج اور نظر آنے والی فالو اپ کارروائی شائع کریں

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

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

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

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

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

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

شعبے کا زاویہ

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

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

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

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

مثالیں

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

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

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

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

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

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

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

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

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

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

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

اہم نکات

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

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

Noda, Abi, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler, “DevEx: What Actually Drives Productivity,” ACM Queue (2023): فیڈ بیک کے لوپ، ذہنی بوجھ، اور بہاؤ کی حالت کا DevEx فریم ورک۔
Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity,” ACM Queue (2021).
Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century, by Jeff Lawson (ڈویلپر کے تجربے میں ادارہ جاتی سرمایہ کاری)۔
Designing and Conducting Survey Research: A Comprehensive Guide, by Louis M. Rea and Richard A. Parker (سروے کے ڈیزائن کا عمومی طریقہ جو DevEx کے آلات پر لاگو ہے)۔