
يمكن للشركات مساعدة مطوريها على زيادة الإنتاجية بعدة طرق ، بدءًا من تغيير المساحات المكتبية إلى الحصول على أدوات أفضل وتنظيف الكود المصدري. لكن ما هي القرارات التي سيكون لها التأثير الأكبر؟ بالاعتماد على الأدبيات المتعلقة بتطوير البرمجيات وعلم النفس الصناعي / التنظيمي ، حددنا العوامل المتعلقة بالإنتاجية وقابلنا 622 مطورًا من ثلاث شركات. كنا مهتمين بالعوامل المذكورة وكيف يقيم الناس إنتاجيتهم بأنفسهم. تشير نتائجنا إلى أن تقدير الذات يتأثر بشكل كبير بالعوامل غير الفنية: الحماس في العمل ، ودعم زملائك للأفكار الجديدة ، وردود الفعل المفيدة على إنتاجيتك. مقارنة بعمال المعرفة الآخرين ،يعتمد تقييم مطوري البرمجيات لإنتاجيتهم بشكل أكبر على تنوع المهام والقدرة على العمل عن بُعد.
1 المقدمة
تحسين إنتاجية المطور أمر مهم. بحكم التعريف ، عندما يكملون مهامهم ، يمكنهم قضاء وقت الفراغ في مهام مفيدة أخرى: تقديم ميزات جديدة وفحوصات جديدة. لكن ما الذي يساعد المطورين على أن يكونوا أكثر إنتاجية؟
تحتاج الشركات إلى إرشادات عملية حول العوامل التي يجب معالجتها لزيادة الإنتاجية. على سبيل المثال ، هل ينبغي أن يقضي المطور وقتًا في البحث عن أدوات وأساليب أفضل ، أم يجب عليه إيقاف تشغيل الإشعارات أثناء النهار؟ هل يجب على القائد الاستثمار في إعادة البناء لتقليل تعقيد التعليمات البرمجية ، أو منح المطورين مزيدًا من الاستقلالية؟ هل يجب على الرؤساء الاستثمار في أدوات تطوير أفضل أم مكتب أكثر راحة؟ في عالم مثالي ، نستثمر في عوامل مختلفة لزيادة الإنتاجية ، لكن الوقت والمال محدودان ، لذلك علينا الاختيار.
تتناول هذه المقالة أوسع دراسة لتوقعات إنتاجية مطوري البرامج حتى الآن. كما هو موضح في القسم 3.1 ، يمكن قياس الإنتاجية بشكل موضوعي (على سبيل المثال ، في سطور التعليمات البرمجية شهريًا) أو بشكل شخصي (وفقًا لتقدير المطور نفسه). بينما لا يُفضل أي من النهجين ، فقد حاولنا تغطية الموضوع على نطاق واسع بحكم شخصي للإجابة على ثلاثة أسئلة:
- ما هي أفضل العوامل التي تنبئ بكيفية قيام المطور بتقييم إنتاجيته؟
- كيف تتغير هذه العوامل من شركة إلى أخرى؟
- ما الذي يتنبأ بتقييم المطور لإنتاجيته ، على وجه الخصوص ، مقارنة بالعاملين الآخرين في مجال المعرفة؟
للإجابة على السؤال الأول ، أجرينا دراسة في شركة برمجيات كبيرة.
للإجابة على السؤال الثاني ، الذي يساعد على فهم إلى أي مدى يمكن تعميم النتائج التي تم الحصول عليها ، أجرينا دراسة في شركتين من صناعات مختلفة.
للإجابة على السؤال الثالث الذي يساعد على فهم مدى اختلاف المطورين عن غيرهم ، قمنا بإجراء دراسة بين ممثلي المهن الأخرى ومقارنتها بالنتائج التي تم الحصول عليها في دراسة المطورين.
تظهر نتائجنا أنه في الشركات التي درسناها ، يتأثر تقدير الذات لإنتاجيتها بشدة بالحماس في العمل ، ودعم الأقران للأفكار الجديدة ، وردود الفعل المفيدة حول إنتاجيتهم. بالمقارنة مع العاملين الآخرين في مجال المعرفة ، فإن تقييم مطوري البرمجيات لإنتاجيتهم يعتمد بشكل أكبر على مجموعة متنوعة من المهام والقدرة على العمل عن بعد. يمكن للشركات استخدام النتائج التي توصلنا إليها لتحديد أولويات المبادرات المتعلقة بالإنتاجية (القسم 4.7).
يصف القسم 2 الشركات التي درسناها. يصف القسم 3 منهجية البحث. القسم 4 يصف ويحلل النتائج التي تم الحصول عليها. يصف القسم 5 أعمالًا أخرى حول هذا الموضوع.

2. الشركات المبحوثة
2.1. جوجل
تمتلك Google حوالي 40 مكتب تطوير حول العالم ، ويعمل بها عشرات الآلاف من المطورين. تقدر الشركة التعاون الوثيق داخل الفرق ، وعادة ما تكون المكاتب ذات خطة مفتوحة لتقريب أعضاء الفريق من بعضهم البعض. الشركة صغيرة نسبيًا (تأسست في أواخر التسعينيات) ، هيكلها التنظيمي مسطح نوعًا ما ، ويتمتع المطورون بالكثير من الاستقلالية. تتضمن عملية الترقية تعليقات من الزملاء ، ولا يحتاج المطورون إلى الانتقال إلى المناصب الإدارية للتقدم. يخطط المطورون لوقتهم بأنفسهم ، ويتم عرض التقويمات الخاصة بهم على شبكة الشركة. تستخدم Google عمليات تطوير رشيقة (مثل Agile) التي يتم تطبيقها عادةً على الفريق بأكمله.
تقدر Google الانفتاح. يعمل معظم المطورين على قاعدة كود متجانسة مشتركة ، ويتم تشجيعهم على إجراء تغييرات على كود مشاريع الآخرين. تتمتع الشركة بثقافة قوية للاختبار ومراجعة الكود: تتم مراجعة الكود المقدم إلى المستودع بواسطة مطور آخر ، وعادةً ما يستخدم الاختبارات. يكتب معظم الكود من جانب الخادم الذي يتم إصداره بشكل متكرر ويسهل نسبيًا طرح الإصلاحات. مجموعة أدوات التطوير موحدة إلى حد كبير (باستثناء المحررين) ومبنية داخليًا ، بما في ذلك أدوات التحليل والتكامل المستمر والبنية التحتية للإصدار.
2.2. ABB
لدى ABB أكثر من 100،000 موظف حول العالم. بصفتها تكتلاً هندسيًا ، توظف الشركة مجموعة متنوعة من المهن. يوجد حوالي 4000 مطور برامج مشترك وأكثر من 10000 مطور تطبيقات يقومون ببناء أنظمة صناعية باستخدام لغات مرئية ونصية خاصة بالصناعة. لتشغيل بنيتها التحتية الكبيرة لتكنولوجيا المعلومات ، تحتفظ الشركة بعدد كبير من الموظفين الذين تشمل مسؤولياتهم البرمجة النصية والبرمجة المبسطة.
على الرغم من أن ABB قد استحوذت على عدد من الشركات الأصغر ، إلا أن لديها منظمة مركزية مسؤولة عن توحيد عمليات تطوير البرمجيات. لذلك ، على الرغم من الاختلافات بين الأقسام ، فإن معظم الأدوات والأساليب متسقة. وينطبق الشيء نفسه على معظم المسارات الوظيفية: للتقنيين ، من المبتدئين إلى كبار المطورين ، والمديرين التنفيذيين ، من قائد المجموعة إلى قائد القسم والإدارة المركزية.
2.3 الصكوك الوطنية
تأسست الآلات الوطنية في السبعينيات. يتركز تطوير البرمجيات بشكل أساسي في أربعة مراكز بحث وتطوير دولية. تقاويم الموظفين مرئية للشركة بأكملها ، ويمكن لأي شخص تحديد موعد مع أي موظف آخر.
تسهل مسؤوليات الوظيفة عمليات التطوير. لا يمكن للمطورين اختيار مشروع بشكل مستقل ، ولكن يمكنهم تولي مهام أو ميزات محددة. يعمل معظمها بقاعدة كود متجانسة مشتركة ، بأجزائها المنطقية المختلفة التي لها مالكون محددون. يجب أن يوافق "المالك" على الرمز الذي تم إدخاله. من المستحسن أن يتم تحليل الكود بواسطة العملاء المحتملين التقنيين. هذه السياسة اختيارية ، لكن الكثيرين يتبعونها.
يتمتع المطورون بالكثير من الحرية في اختيار الأدوات. لا توجد أدوات عامة إلا إذا كانت هناك فائدة فورية. على سبيل المثال ، يعتمد اختيار IDE بشكل كبير على المهمة. يتوفر عدد من أدوات الإنشاء والاختبار المخصصة. قامت أجزاء مختلفة من الشركة بتوحيد أنظمة مختلفة لإدارة وتحليل كود المصدر. عادةً ما يتم إصدار تحديثات البرامج كل ثلاثة أشهر أو سنويًا ، باستثناء التصحيحات الهامة النادرة.
الجدول 1. لمحات عن الشركات الثلاث المدروسة:
| جوجل | ABB | الصكوك الوطنية | |
| الحجم | كبير. | كبير. | صغيرتي. |
| مكاتب | مكاتب مفتوحة. | مكاتب مفتوحة ومغلقة. | مكاتب مفتوحة. |
| أدوات | في الغالب أدوات تطوير موحدة. | نفس الأدوات. | المرونة في اختيار الأدوات |
| نوع التطوير | في الغالب من جانب الخادم وكود الهاتف المحمول. | مزيج من تطوير الويب والبرامج المضمنة وبرامج سطح المكتب. | برامج سطح المكتب المضمنة في الغالب. |
| مخزن | مستودع متآلف. | مستودعات منفصلة. | مستودع متآلف. |
| ميل | تطوير البرمجيات. | تكتل هندسي. | تطوير البرمجيات والمعدات. |
3. المنهجية
هدفنا: معرفة العوامل التي يمكنها توقع إنتاجية مطوري البرمجيات. للقيام بذلك ، أجرينا دراسة تحتوي على مجموعة من الأسئلة ، ومجموعة من عوامل الإنتاجية ، ومجموعة من المتغيرات الديموغرافية.
3.1 تقييم إنتاجيتك
أولاً ، دعنا نصف كيف سنقيس الإنتاجية. اقترح راميريز ونيمبارد تصنيفًا لتقنيات قياس الإنتاجية الموضحة في الأدبيات ، بما في ذلك تحليل نقطة الوظيفة ، والتقييم الذاتي ، وتقييم الأقران ، وتناسب النتائج والجهود ، والاستخدام المهني للوقت [2]. يمكن تقسيم هذه الأساليب إلى موضوعية (على سبيل المثال ، عدد سطور التعليمات البرمجية التي تتم كتابتها في الأسبوع) وذاتية (على سبيل المثال ، التقييم الذاتي أو مراجعة الأقران).
لا يُفضل أي من الأسلوبين ؛ فكلتا الفئتين لها عيوب. القياسات الموضوعية تفتقر إلى المرونة والمرح. لنأخذ عدد سطور الشفرة في الأسبوع. يمكن للمطور المنتج كتابة إصلاح من سطر واحد لخلل يصعب العثور عليه. ويمكن للمطور غير المنتج أن يضخم بسهولة عدد الخطوط. من ناحية أخرى ، يمكن أن تكون القياسات الذاتية غير دقيقة بسبب التحيزات المعرفية. خذ تقييمات الأقران: قد يكرهون مطورًا منتجًا ، وبالتالي ، ستكون تقييماتهم أسوأ ، حتى لو سعى الزملاء إلى الموضوعية.
مثل فريق الباحثين بقيادة ماير الذي حلل إنتاجية مطوري البرمجيات [3] ، استخدمنا أسئلة البحث كمقياس شخصي للإنتاجية. هناك سببان رئيسيان. أولاً ، كما لاحظ راميريز ونيمهاردت ، فإن البحث "طريقة بسيطة وشائعة لقياس إنتاجية [العاملين في مجال المعرفة]." ثانيًا ، يوفر البحث إجابات من المطورين في أدوار مختلفة ، كما يسمح للمستجيبين بإضافة معلومات مختلفة إلى درجات أدائهم.
الشكل: 1. منهجية البحث:

سألنا المستجيبين عن مدى اتفاقهم مع البيان:
أحقق إنتاجية عالية بانتظام.
مع ذلك ، أردنا قياس الإنتاجية على أوسع نطاق ممكن. قمنا أولاً بصياغة ثمانية خيارات للسؤال ، ثم اختزلناها إلى ما سبق من خلال التحدث بشكل غير رسمي مع خمسة من مطوري Google حول تفسيرهم للعبارة (الشكل 1 ، أسفل اليسار). أضفنا الكلمات "عالية" و "بانتظام" إلى السؤال لثلاثة أسباب. أولاً ، أردنا الاستيلاء على حالة يمكن للناس أن يقارنوا أنفسهم بها. ثانياً ، أردنا أن تكون هذه الحالة عالية من أجل تجنب آثار الوصول إلى الحد الأقصى في ردود المبحوثين. ثالثًا ، أردنا أن يركز المستجيبون على مقياسين محددين للإنتاجية - الكثافة والتكرار. في المستقبل ، يمكن للباحثين تطبيق تدابير أكثر تفصيلاً من خلال قسمة الكثافة والتكرار على مسألتين منفصلتين.
لقد وضعناها على المحك من خلال مطالبة ثلاثة مدراء تنفيذيين في Google بإرسالها إلى فرقهم متسائلين ، "ما الذي فكرت به عند الرد على بيان الإنتاجية؟" تلقينا ردودًا من 23 مطورًا (الشكل 1 ، أسفل الوسط). تم اعتبار الخيار مقبولاً لأغراضنا لأن اعتبارات المبحوثين تتوافق مع توقعاتنا فيما يتعلق بقيمة الإنتاجية. غطت هذه الاعتبارات مشاكل سير العمل ، ونتائج العمل ، والتواجد في منطقة أو تدفق ، والسعادة ، والأهداف التي تم تحقيقها ، وكفاءة البرمجة ، والتقدم ، وتقليل الهدر. لم نحلل هذه الردود في هذه الورقة ، لكن الدراسة تضمنت أربعة مقاييس إضافية محسَّنة للإنتاجية مأخوذة من الأعمال السابقة [2] ، [4] ، [5].
لقد اخترنا مقياسين مناسبين للإنتاجية لإضافة بيانات موضوعية لتأطير احترام الذات ، ثم ربطناها ببعضها البعض على Google. كان أول مقياس موضوعي هو عدد سطور التعليمات البرمجية التي يغيرها المطور في الأسبوع - وهو مقياس شائع ولكنه صعب للإنتاجية [6] ، [7]. كان المقياس الثاني هو عدد التغييرات التي أجراها المطور على قاعدة بيانات Google الرئيسية لكل وحدة زمنية. يكاد يكون مكافئًا لطلب السحب الشهري الذي يستخدمه الفريق بقيادة Vasilescu [8]. لتقييم إنتاجيتنا ، استخدمنا الردود على استطلاع مشابه على Google (العدد = 3344 إجابة). لم نتمكن من استخدام البيانات من دراستنا لهذا التحليل لأن الردود لم تحتوي على معرفات المشاركين.التي يمكن من خلالها مقارنة مقاييس الإنتاجية الموضوعية. في تلك الدراسة ، طرحوا سؤالاً مماثلاً: "كم مرة تشعر أنك منتج بدرجة عالية في العمل؟" يمكن للمشاركين الإجابة "نادرًا أو أبدًا" و "أحيانًا" و "حوالي نصف الوقت" و "معظم الوقت" و "دائمًا أو دائمًا تقريبًا". ثم أنشأنا انحدارًا خطيًا بأداء تم الإبلاغ عنه ذاتيًا كمتغير تابع ترتيبي (مرمز 1 و 2 و 3 و 4 و 5 على التوالي). يفترض الانحدار الخطي مسافة متساوية بين تصنيفات الإنتاجية. بالنظر إلى الكلمات المستخدمة في السؤال ، فإننا نعتبر هذا الافتراض مبررًا. بالنسبة للانحدار اللوجستي المرتب ، هذا الافتراض غير مطلوب. يعطي تطبيق هذه التقنية هنا نتائج موثوقة: نفس المعاملات لها أهمية في الخطي ،وفي نموذج مرتب.
نستخدم المقاييس الموضوعية اللوغاريتمية كمتغيرات توضيحية ، لأن كلاهما منحرف بشكل إيجابي. من أجل التحكم ، أخذنا رمز الوظيفة (على سبيل المثال ، مهندس برمجيات ، مهندس بحث ، إلخ) كمتغير فئوي ، بالإضافة إلى الرتبة (مبتدئ ، متوسط ، كبير ، إلخ) كرقم (على سبيل المثال ، 3 للبرامج مهندس مبتدئ في Google). كان رمز الوظيفة ذا دلالة إحصائية لدورين عامل في كل نموذج خطي. كان هناك ثلاثة نماذج إجمالاً: اثنان بهما أحد المقاييس الموضوعية والآخر به كلا المقاييس الموضوعية.

الشكل: 2: نماذج تتنبأ بتقييم شخصي للإنتاجية على أساس مقياسين موضوعيين. ns تعني عاملًا غير مهم إحصائيًا مع p> 0.05 ، ** تعني p <0.01 ، *** تعني p <0.001. ويرد وصف كامل للنماذج في المواد التكميلية.
تظهر نتائج السياق في الشكل. 2. يوضح كل نموذج مستوى ذي دلالة إحصائية بتصنيف سلبي ، وهو ما فسرناه على أنه: يميل المطورون الأعلى مرتبة إلى تصنيف أنفسهم على أنهم أقل إنتاجية قليلاً. هذه حجة قوية للتحكم في الرتبة (القسم 3.7.). يوضح النموذجان الأولان علاقة إيجابية مهمة بين المقاييس الموضوعية والذاتية للإنتاجية. بمعنى أنه كلما تمت كتابة المزيد من سطور التعليمات البرمجية أو إجراء التغييرات ، كلما اعتبر المطور نفسه أنه أكثر إنتاجية. يشير النموذج المجمع الناتج والتقديرات للنموذجين الأولين إلى أن عدد التغييرات التي تم إجراؤها هو مؤشر أكثر أهمية للإنتاجية من عدد الأسطر المكتوبة. لكن لاحظ أنه في جميع النماذج ، تكون المعلمة R 2، التي تمثل نسبة التباين الموضحة ، منخفضة نوعًا ما - أقل من 3٪ لكل نموذج.
بشكل عام ، تشير النتائج التي تم الحصول عليها إلى أن عدد سطور التعليمات البرمجية والتغييرات التي تم إجراؤها تؤثر على تقييم المطورين لإنتاجيتهم ، ولكن ليس بشكل كبير.
3.2 عوامل الإنتاجية
بعد ذلك ، خلال فترة الدراسة ، سألنا المشاركين عن العوامل التي تعتبر في أعمال أخرى مرتبطة بالإنتاجية. لقد جمعنا أسئلة من أربعة مصادر (الشكل 1 ، وسط اليسار). تم أخذ هذه المصادر لأنها ، على حد علمنا ، تمثل النظرات العامة الأكثر شمولاً لعوامل الإنتاجية الفردية في بحث المبرمجين وغيرهم من العاملين في مجال المعرفة.
المصدر الأولهي أداة تم إنشاؤها بواسطة فريق بقيادة Palvalin لمراجعة تدابير الإنتاجية للعاملين في مجال المعرفة [4]. تم استخدام الأداة ، التي تسمى SmartWoW ، من قبل أربع شركات وتغطي جوانب مساحة العمل المادية والافتراضية والاجتماعية وممارسات العمل الشخصية والرفاهية في العمل. لقد غيرنا بعض الأسئلة لتعكس بشكل أفضل مصطلحات المطور الحالية وتتوافق بشكل أفضل مع اللغة الإنجليزية الأمريكية. على سبيل المثال ، يسأل SmartWoW:
غالبًا ما أعمل عن بُعد لأداء المهام التي تتطلب تركيزًا مستمرًا.
لقد أعدنا صياغة ما يلي:
غالبًا ما أعمل عن بُعد لتنفيذ المهام التي تتطلب تركيزًا غير منقطع.
من SmartWoW ، اخترنا أولاً 38 سؤالاً لدراستنا.
المصدر الثاني هو مراجعة قام بها هيرناوس وميكوليتش لتأثير خصائص بيئة العمل على إنتاجية العاملين في مجال المعرفة [9]. يعكس عملهم المثبت دراسات الإنتاجية السابقة: استبيان تصميم بيئة العمل [10] ، دراسة بيئة العمل التشخيصية [11] ، تقييم التعاون الجماعي [12] تقييم "طبيعة المهام" [13]. لقد قمنا بتغيير الأسئلة لتكون قصيرة ومتسقة. للغرض نفسه ، أخذنا أسئلة مباشرة من العمل [12] ، والمخصص لمجموعات العمل مع القليل من الاعتبارات حول الإنتاجية الشخصية.
المصدر الثالث- مراجعة منظمة لفاجنر وروهي لعوامل الإنتاجية في تطوير البرمجيات [14]. على عكس المصادر الأخرى ، لم تتم مراجعة هذا العمل بدقة من قبل المجتمع العلمي ولا يحتوي على بحث تجريبي أصلي. ولكن على حد علمنا ، فإن هذا هو المسح الأكثر شمولاً لبحوث إنتاجية البرمجة. تنقسم العوامل التي صاغها Wagner و Rouet إلى عوامل فنية وغير قابلة للقياس الكمي ، ثم يتم أيضًا إبراز عوامل البيئة وثقافة الشركة والمشروع وبيئة المنتج والتطوير والقدرات والخبرة.
المصدر الرابعهي دراسة لمطوري Microsoft بقيادة فريق بقيادة ماير. استخلصنا منه خمسة أسباب رئيسية لأيام العمل المنتج ، بما في ذلك تحديد الأهداف ، واجتماعات العمل ، وفترات الراحة من العمل [15].
أضفنا أيضًا ثلاثة عوامل ، في رأينا ، لم يتم أخذها في الاعتبار بشكل صحيح في الأعمال السابقة ، ولكن تبين أنها مهمة في سياق Google. أحدهما هو تقييم إنتاجية العاملين في مجال المعرفة [16] ، وهو مقدمة غير منشورة لـ SmartWoW. قمنا بتكييفها على النحو التالي:
المعلومات المقدمة لي (تقارير الأخطاء ونصوص المستخدم وما إلى ذلك) دقيقة.
العامل الثاني مأخوذ من استبيان تصميم بيئة العمل ومواءمته على النحو التالي:
أحصل على تعليقات مفيدة حول إنتاجية عملي.
وقمنا بإنشاء عامل ثالث كان مهمًا في بيئة ABB:
أحتاج إلى وصول مباشر إلى أجهزة معينة لاختبار برنامجي.
أولاً ، اخترنا 127 عاملاً. لتقليلها إلى مثل هذا العدد من الأسئلة التي يمكن للمستجيبين الإجابة عليها دون إجهاد كبير [17] ، استخدمنا المعايير الموضحة في وسط الشكل. 1:
- تمت إزالة التكرارات. على سبيل المثال ، في SmartWoW [4] وعمل ماير مع زملائه [15] ، يعتبر تحديد الهدف عاملاً مهمًا في الإنتاجية.
- عوامل متشابهة مجتمعة. على سبيل المثال ، يصف Hernaus و Mikulich جوانب مختلفة من التفاعل بين مجموعات العمل التي تزيد الإنتاجية ، لكننا قمنا بتقليلها إلى عامل واحد [9].
- أعطيت الأفضلية للعوامل ذات الفائدة الواضحة. على سبيل المثال ، SmartWoW [4] له مثل هذا العامل:
يتمتع الموظفون بفرصة مشاهدة تقاويم بعضهم البعض.
في Google ، هذا صحيح في كل مكان ومن غير المرجح أن يتغير ، لذا فإن العامل ذو فائدة منخفضة.
لقد طبقنا هذه المعايير بشكل مشترك ومتكرر. أولاً ، تمت طباعة ملصق كبير لجميع الأسئلة المرشحة للاستخدام في الدراسة. ثم وضعنا ملصق Google بجوار مكتبنا. ثم قام كل منا بتحليل الأسئلة بشكل مستقل بناءً على المعايير المذكورة أعلاه. تم تعليق الملصق لعدة أسابيع ، وقمنا بشكل دوري باستكمال ومراجعة القائمة مرة أخرى. أخيرًا ، تم وضع قائمة نهائية بالأسئلة.
تضمنت دراستنا 48 عاملاً في شكل بيانات (الشكل 4 ، العمود الأيسر). وأشار المشاركون في الاستطلاع إلى درجة موافقتهم على هذه البيانات على مقياس من خمس نقاط ، من "أعارض بشدة" إلى "أوافق بشدة". يمكن تجميع العوامل في كتل تتعلق بالمنهجية والتركيز والخبرة والوظيفة والفرصة والأشخاص والمشروع والبرمجيات والسياق. لقد طرحنا أيضًا سؤالًا مفتوحًا واحدًا حول العوامل التي شعر المستجيبون أننا ربما فاتناها. يتم توفير الاستبيان الكامل من دراستنا في المواد التكميلية.

الشكل: 3: مثال على سؤال من البحث.
3.3 الديموغرافيا
طرحنا أسئلة حول عدة عوامل ديموغرافية ، كما هو موضح في الشكل 1:
- أرضية.
- موضع.
- مرتبة.
اقترح مؤلفون سابقون أن الجنس مرتبط بعوامل إنتاجية مطوري البرمجيات ، مثل تصحيح الأخطاء [18]. لذلك كان للدراسة سؤال اختياري عن الجنس (ذكر ، أنثى ، أرفض الإجابة ، أنا). تم تعيين المستجيبين الذين لم يجيبوا على السؤال في مجموعة "رفض الإجابة" (Google n = 26 [6٪] ، ABB n = 4 [3٪] ، National Instruments n = 5 [6٪]). تعاملنا مع هذه البيانات على أنها قاطعة.
بالنسبة للمنصب ، أخذنا أقدميتنا في Google من قسم الموارد البشرية. لم يكن هذا ممكنًا مع ABB و National Instruments ، لذلك أضفنا سؤالًا اختياريًا إلى الدراسة. في ABB ، في حالة عدم وجود ردود (ن = 4 [3٪]) ، أخذنا 12 عامًا من الخبرة ، وهذا هو متوسط البيانات التي تم جمعها. في National Instruments ، استغرقنا 9 سنوات للسبب نفسه (العدد = 1 [1٪]). يمكن أن يكون الأمر أكثر صعوبة [19] ، على سبيل المثال ، استخدام البدائل للتنبؤ بالقيم المفقودة بناءً على البيانات المتاحة. لنفترض أنه يمكن ملء معلومات الرتبة المفقودة بدقة إلى حد ما بناءً على المنصب والجنس. ومع ذلك ، فقد استبدلنا القيم الإحصائية المتوسطة ببساطة ، نظرًا لأن العوامل الديموغرافية لم تكن ذات أهمية قصوى بالنسبة لنا ، فقد كانت مصاحبة للمعلومات للتحكم فقط. قمنا بمعالجة هذه البيانات كأرقام.
من حيث الترتيب ، طلبنا من المشاركين في Google تحديد مستواهم كرقم. كانت الإجابات المفقودة (ن = 26 [6٪]) هي القيمة الأكثر شيوعًا.
في ABB ، يمكن للمساهمين تحديد "مبتدئ أو كبير مطور برامج" ، على الرغم من أن العديد منهم أشار إلى مسمى "مختلف". إذا تضمنت الإجابة الكلمات:
- اكبر سنا
- قيادة
- مدير
- مهندس معماري
- الباحث
- الأساسية
- عالم
ثم أشرنا مثل هذه الإجابات إلى "كبار". ويشار إلى البقية باسم "المبتدئين". الإجابات المفقودة (ن = 4 [3٪]) نعزوها إلى المعنى الأكثر شيوعًا - "كبار".
كان للأدوات الوطنية خيارات:
- المتحدي
- العاملين
- اكبر سنا
- مهندس معماري رئيسي / مهندس
- كبير المهندسين المعماريين / المهندس
- مهندس شرف
- مشارك
- آخر
تبين أن "الآخر" الوحيد هو المتدرب ، الذي نقلناه إلى "المتقدمين". الإجابات المفقودة (ن = 3 [4٪]) نعزوها إلى المعنى الأكثر شيوعًا - "كبار".
لقد قمنا بترميز الرتب في جميع الشركات بالأرقام.
3.4. مقارنة مع غير المطورين
بعد ذلك ، كنا مهتمين بما يسمح لنا بالضبط بالتنبؤ بكيفية تقييم المطورين لإنتاجيتهم. على سبيل المثال ، افترضنا أن الإنتاجية تأثرت بالانقطاع عن العمل ، ولكن يمكن قول ذلك لأي عامل معرفة. لذلك يطرح سؤال طبيعي: هل يؤثر هذا بطريقة ما على إنتاجية المطور بطريقة خاصة؟
للإجابة على هذا السؤال ، اخترنا مهنًا مماثلة لمطوري البرمجيات. أولاً ، حاولنا الاختيار بناءً على الوظائف في Google. على الرغم من أن بعض المواقف أشارت إلى أنهم كانوا عاملين معرفيين ، إلا أن المؤشر الأكثر شيوعًا والأكثر موثوقية في رأينا لغير المطورين المناسبين هو وجود كلمة "محلل" في الوظيفة. قررنا مقارنة المحللين والمطورين في Google ، بدلاً من مقارنة محللي Google بالمطورين من الشركات الثلاث. قررنا أن هذا سيسمح لنا بالتحكم في خصائص معينة للشركة (على سبيل المثال ، إذا أصبح موظفو Google فجأة أكثر أو أقل حساسية من الناحية الإحصائية للانقطاع من موظفي الشركات الأخرى).
ثم قمنا بتكييف بحثنا للمحللين. تمت إزالة الأسئلة المتعلقة بتطوير البرامج بشكل واضح ، مثل "تتغير متطلبات البرامج الخاصة بي بشكل متكرر." لقد أعدنا صياغة أسئلة أخرى خصيصًا للمحللين. على سبيل المثال ، بدلاً من "أنا أستخدم أفضل الأدوات والتقنيات لتطوير البرامج" ، كتبنا "أستخدم أفضل الأدوات والأساليب للقيام بعملي".
تم قياس درجات الإنتاجية بنفس طريقة قياس المطورين. الشيء نفسه ينطبق على تقييم الجنس والموقف والرتبة. اختبرنا النسخة "التحليلية" من الدراسة على عينة ملائمة من خمسة محللين قالوا إن الدراسة كانت واضحة بشكل عام وقاموا ببعض التعديلات الطفيفة. قبلناها وأجرينا دراسة كاملة لغير المطورين.

3.5 سؤال مراقبة
من أجل استبعاد الإجابات التي تم تقديمها بدون تفكير ، بعد حوالي 70٪ من بداية الدراسة ، أدخلنا سؤالاً للانتباه [20]: "أجب عن هذا ،" أنا لا أوافق ". لم نأخذ بعين الاعتبار النماذج التي لم تتضمن مثل هذه الإجابة على هذا السؤال.
3.6 حصة من الردود
في Google ، اخترنا 1000 موظف عشوائي بدوام كامل من بين الموارد البشرية التي كانت لها أدوار في تطوير البرامج. تلقينا 436 نموذجًا مكتملًا منهم ، أي أن معدل الاستجابة كان 44٪ ، وهو مؤشر مرتفع جدًا للبحث بين المطورين [21]. بعد حذف النماذج ذات الإجابة الخاطئة على سؤال الأمان (ن = 29 [7٪]) ، بقيت 407 إجابة.
من أجل مسح للعاملين في مجال المعرفة ، اخترنا 200 موظفًا عشوائيًا بدوام كامل في Google مع كلمة "محلل" في عناوين وظائفهم. قررنا عدم البحث عن الكثير من المحللين لأن هدفنا كان مطوري البرمجيات. 94 شخصًا ، 47٪ ، أجابوا على أسئلتنا. بعد حذف الاستبيانات ذات الإجابة الخاطئة على سؤال الأمان (ن = 6 [6٪]) ، بقي 88.
أرسلنا استبياناتنا إلى ما يقرب من 2200 من مطوري البرامج المختارين عشوائيًا في ABB وتلقينا 176 ردًا. هذا هو 8 ٪ ، في الحد الأدنى لمثل هذه الدراسات [21]. بعد حذف الاستبيانات الخاطئة (العدد = 39 [22٪]) ، بقي 137.
أخيرًا ، أرسلنا الاستبيانات إلى حوالي 350 من مطوري البرمجيات في National Instruments وتلقينا 91 ردًا (26٪). بعد حذف الاستبيانات الخاطئة (ن = 13 [14٪]) ، بقي 78.
3.7 تحليل
لكل عامل في كل شركة ، طبقنا نماذج الانحدار الخطي الفردية ، باستخدام العامل كمتغير مستقل (على سبيل المثال ، "الموعد النهائي لمشروعي ضيق") وتقدير إنتاجيتنا كمتغير تابع. قمنا بتشغيل نماذج منفصلة لكل شركة من أجل الخصوصية ، بحيث لا تختلط البيانات الأولية من الشركات المختلفة. لتقليل تأثير متغيرات الضمانات ، أضفنا المتغيرات الديموغرافية الحالية إلى كل نموذج انحدار. في تفسير النتائج ، ركزنا على ثلاثة جوانب لنسبة عامل الإنتاجية:
- التقييم . يشير إلى درجة تأثير كل عامل مع الحفاظ على ثابت ديموغرافي. كلما زادت القيمة ، زاد التأثير.
- . . , .
- . p < 0,05. 48 , p -, [22].
عند تفسير النتائج ، ركزنا أكثر على درجة التأثير (التقييم) وبدرجة أقل على الأهمية الإحصائية ، لأنه يمكن استخلاصها من مجموعات بيانات كبيرة بما يكفي ، حتى لو كانت الأهمية العملية منخفضة. كما سنرى أدناه ، غالبًا ما تم العثور على نتائج ذات دلالة إحصائية على Google ، مع أعلى معدل استجابة ؛ على الأقل - في الصكوك الوطنية ، حيث كان معدل الاستجابة أقل. شعرنا أن هذا الاختلاف يرجع في جزء كبير منه إلى القوة الإحصائية. نحن نحثك على أن تكون أكثر ثقة في النتائج المهمة إحصائيًا.
لتوفير السياق ، قمنا أيضًا بتحليل كيفية ارتباط العوامل الديموغرافية بتصنيفات الأداء. للقيام بذلك ، قمنا بإجراء انحدار خطي متعدد لكل شركة ذات متغيرات ديموغرافية كمتغيرات مستقلة وتقدير إنتاجيتنا كمتغير تابع. ثم قمنا بتحليل القيمة التنبؤية الإجمالية للنموذج الناتج ، بالإضافة إلى تأثير كل متغير توضيحي.
3.8 حول السببية
تسمح لنا منهجيتنا بتقييم العلاقة بين عوامل الإنتاجية وتقييم إنتاجيتها ، على الرغم من أننا في جوهرها مهتمون بدرجة تأثير كل عامل على التغيير في الإنتاجية. ما مدى صحة الاعتقاد بوجود علاقة سببية بين العوامل والإنتاجية؟
يعتمد الصواب بشكل أساسي على قوة الدليل على السببية في العمل السابق. وهذه القوة تختلف باختلاف العوامل. على سبيل المثال ، أجرى فريق بقيادة Guzzo تحليلًا تلويًا لـ 26 مقالة حول التقييم وردود الفعل ، وقدمت النتائج دليلاً ممتازًا على أن التعليقات تزيد الإنتاجية في مكان العمل [23]. ومع ذلك ، فإن تحديد قوة الدليل لكل عامل يتم التحقيق فيه يتطلب الكثير من العمل ، وهو ما يتجاوز نطاق هذه المقالة.
للتلخيص: على الرغم من أن دراستنا لا تسمح بإقامة علاقة سببية ، ولكن بناءً على العمل السابق ، يمكننا أن نعتقد بثقة أن هذه العوامل تؤثر على الإنتاجية ، ولكن تفسير نتائجنا ببعض الحذر.

4. النتائج
بادئ ذي بدء ، نصف العلاقة بين جميع عوامل الإنتاجية وتقييم إنتاجيتها عند التحكم في الخصائص الديموغرافية. سيتم استخدام هذه البيانات للإجابة على كل استجابة استقصائية ، تليها مناقشة النتائج. سنناقش بعد ذلك العلاقة بين الخصائص الديموغرافية وقياس الأداء. أخيرًا ، دعونا نناقش الآثار والمخاطر.
4.1 عوامل الإنتاجية
في التين. يوضح الشكل 4 نتائج تحليلنا الموضحة في القسم 3.7. يسرد العمود الأول العوامل التي تم اقتراحها على المشاركين في شكل بيانات ؛ متبوعة بتسميات العوامل (F1 ، F2 ، إلخ) التي قمنا بتعيينها بعد اكتمال التحليل. يعني نقص البيانات أن هذه العوامل خاصة بالمطورين ولم يتم اقتراحها للمحللين (على سبيل المثال ، F10).
الشكل: 4: العلاقات بين 48 عاملاً وكيف يقوم المطورون والمحللون بتقييم إنتاجيتهم في ثلاث شركات:

الأعمدة الثلاثة التالية هي بيانات من ثلاث شركات ، بالإضافة إلى بيانات من محللي Google. كل عمود من هذه الأعمدة مقسم إلى عمودين فرعيين. تقدير
العمود الفرعي(الدرجة) تحتوي على معاملات الانحدار التي تحدد قوة ارتباط العامل بتقدير إنتاجيته. كلما زاد العدد ، كان الارتباط أقوى. على سبيل المثال ، في العمود الأول من Google ، التقدير هو 0.414. في هذه الحالة ، هذا يعني أنه لكل نقطة اتفاق متزايد مع العبارة حول الحماس في العمل (F1) ، يتوقع النموذج زيادة في تصنيف إنتاجية المستفتى بمقدار 0.414 نقطة مع التحكم في المتغيرات الديموغرافية. يمكن أن تكون التقييمات سلبية. على سبيل المثال ، في جميع الشركات الثلاث ، كلما زاد معدل دوران الموظفين في الفريق (F48) ، انخفض تقييم إنتاجيتهم. بجانب كل درجة يوجد مؤشر يعكس النتيجة بوضوح.
لاحظ أن الدرجات لا تعني تصنيفات أعلى للعوامل ، بل تعني ارتباطًا أعلى بين العامل وتصنيف إنتاجيتك. على سبيل المثال ، تسجل National Instruments (F1) حماسًا أعلى من الشركات الأخرى. هذا لا يعني أن المطورين هناك أكثر حماسة: في هذه الشركة ، فهو عامل أقوى في التنبؤ بتقييم إنتاجيتهم. نحن لا نقدم التصنيفات بأنفسنا ، لأن هذا محظور بموجب شروط التعاون. بدون السياق الكامل ، يمكن أن يساء تفسير التصنيفات. على سبيل المثال ، إذا أبلغنا أن المطورين في شركة ما أقل حماسًا لعملهم من المطورين في شركة أخرى ، فقد يكون لديك انطباع بأنه من الأفضل عدم العمل في تلك الشركة الأخرى. خطأ
العمود الفرعي الثاني(خطأ) يحتوي على الأخطاء المعيارية للنموذج لكل عامل. كلما انخفضت القيمة ، كان ذلك أفضل. حدسيًا ، يبدو أن القيم المنخفضة تشير إلى أنه عندما تتغير العوامل ، يتنبأ النموذج بأدائه بشكل أكثر موثوقية. قيم الخطأ الإجمالية مستقرة إلى حد ما من عامل إلى آخر ، خاصة على Google مع عدد كبير من المستجيبين.
تشير علامة النجمة (*) إلى أن هذا العامل كان ذا دلالة إحصائية في النموذج. على سبيل المثال ، يعد الحماس للعمل (F1) ذا دلالة إحصائية في جميع الشركات الثلاث ، بينما يعد التحضير للاجتماعات (F17) مهمًا فقط في Google.
يحتوي العمود التالي على متوسط الدرجة ( μ ) لجميع الشركات الثلاث مع الانحراف المعياري بين قوسين ( σ). يوضح المؤشر الأول بوضوح قيمة متوسط الدرجة ، والمؤشر الثاني - قيمة الانحراف المعياري. على سبيل المثال ، كان متوسط درجة الحماس في العمل (F1) 0.43 ، وكان الانحراف المعياري 0.051. يتم فرز الجدول حسب متوسط التصنيف.
يحتوي العمود الأخير على الفروق بين تصنيفات مطور البرامج والمحللين في Google. القيم الإيجابية تعني تصنيفات مطور أعلى ، والسلبية تعني تصنيفات محللين أعلى. على سبيل المثال ، من حيث الحماس (F1) ، فإن المحللين لديهم تقييمات أقل قليلاً من المطورين.
4.2 ما هي أفضل العوامل التي تنبئ بكيفية تقييم المطورين لإنتاجيتهم؟
أقوى العوامل التنبؤية هي البيانات ذات أعلى متوسط درجات مطلق. أضعف العوامل التنبؤية هي تلك التي لديها أدنى متوسط درجة مطلقة. بمعنى آخر ، العوامل الموجودة أعلى الجدول في الشكل. 4 هم أفضل المتنبئين. لفهم العامل الذي يوفر أكبر قدر من الثقة في النتيجة ، قمنا بتسليط الضوء على النتائج ذات الأهمية الإحصائية لجميع الشركات الثلاث:
- الحماس للعمل (F1)
- دعم الأقران للأفكار الجديدة (F2)
- تعليقات مفيدة على أداء العمل (F11)
مناقشة . لاحظ أن أول 10 عوامل إنتاجية ليست فنية. هذا أمر مثير للدهشة بالنظر إلى أنه ، في تقديرنا ، تركز معظم الأبحاث التي يقوم بها مطورو البرمجيات على الجوانب التقنية. لذلك ، يمكن أن تؤدي إعادة التوجيه النشط نحو العامل البشري إلى زيادة كبيرة في تأثير الباحثين على الصناعة. على سبيل المثال ، يمكن أن تكون الإجابات على الأسئلة التالية مثمرة بشكل خاص:
- ما الذي يجعل مطوري البرمجيات متحمسين لعملهم؟ ما الذي يفسر الاختلاف في الحماس؟ ما هي التدخلات التي يمكن أن تزيد الحماس؟ يمكن أن تكمل هذه المقالة البحث عن السعادة [24] والتحفيز [25].
- ? , ? ?
- , ? ? ?
ميزة أخرى مهمة هي ترتيب العوامل من خط البحث COCOMO II. هذه العوامل ، التي تم الحصول عليها في سياق الدراسات التجريبية لمشاريع برمجيات الصناعة والتحقق منها من خلال التحليل العددي لـ 83 مشروعًا [26] ، تمت صياغتها في الأصل لتقدير تكلفة تطوير البرمجيات. على سبيل المثال ، تتضمن عوامل الإنتاجية من COCOMO II تقلب النظام الأساسي وتعقيد المنتج. من الغريب أن العوامل COCOMO II التي تم أخذها في الاعتبار في دراستنا (F5، F10، F14، F16، F24، F26، F28، F32، F33، F34، F36، F38، F39، F43، F44، F46، F47، F48) تلقت أقل القيم. يمكن الافتراض أنها تجعل من الممكن التنبؤ بالإنتاجية بشكل أسوأ. شمل النصف العلوي من العوامل التنبؤية (F1 - F24) 5 فقط من COCOMO II ، والنصف السفلي - 14 عاملاً. يمكننا أن نقدم تفسيرين مختلفين. أول:يفتقر COCOMO II إلى العديد من عوامل الإنتاجية المهمة ، وقد تكون التكرارات المستقبلية لـ COCOMO II أكثر تنبؤًا إذا تم تقديم المزيد من العوامل التي بحثناها ، مثل دعم استقلالية مناهج العمل في الشركة. تفسير آخر: تم تكييف COCOMO II للمهمة الحالية - تحديد الإنتاجية على مستوى المشروع [6] ، [27] ، [28] ، [29] ، [30] ، [31] - ولكنها أقل ملاءمة لإصلاح الإنتاجية على مستوى المطور الفردي. يؤكد هذا التفسير على أهمية وحداثة نتائجنا.تم تكييف COCOMO II للمهمة الحالية - تحديد الإنتاجية على مستوى المشروع [6] ، [27] ، [28] ، [29] ، [30] ، [31] - ولكنها أقل ملاءمة لإصلاح الإنتاجية على مستوى المطور الفردي. يؤكد هذا التفسير على أهمية وحداثة نتائجنا.تم تكييف COCOMO II للمهمة الحالية - تحديد الإنتاجية على مستوى المشروع [6] ، [27] ، [28] ، [29] ، [30] ، [31] - ولكنها أقل ملاءمة لإصلاح الإنتاجية على مستوى المطور الفردي. يؤكد هذا التفسير على أهمية وحداثة نتائجنا.
بالإضافة إلى ذلك ، كانت جميع عوامل COCOMO II منخفضة نسبيًا وعوامل تنبؤية غير مهمة إحصائيًا للإنتاجية في جميع الشركات الثلاث. على سبيل المثال:
- يحتاج برنامجي إلى قدر كبير من قوة المعالجة (F39).
- يحتاج برنامجي إلى مخزن بيانات كبير (F43).
- منصة البرامج الخاصة بي (مثل بيئة التطوير أو البرامج أو مجموعة الأجهزة) تتغير بسرعة (F46).
تفسير واحد: في العشرين عامًا منذ إنشاء واختبار COCOMO II ، أصبحت المنصات أقل تنوعًا من حيث الإنتاجية. من المحتمل أن أنظمة التشغيل الموحدة الآن تحمي المطورين من خسائر الإنتاجية بسبب تغييرات الأجهزة (على سبيل المثال ، Android في تطوير الأجهزة المحمولة). وبالمثل ، يمكن للمنصات السحابية حماية المطورين من خسائر الإنتاجية بسبب توسيع نطاق العمليات واحتياجات التخزين. ناهيك عن أن الأطر الحديثة والأنظمة الأساسية السحابية سهلة الاستخدام. بالإضافة إلى ذلك ، قد يكون الاختلاف في الإنتاجية عند معالجة كميات كبيرة وصغيرة من البيانات قد اختفى منذ إنشاء COCOMO II.
4.3 كيف تختلف هذه العوامل من شركة إلى أخرى؟
للإجابة على هذا السؤال ، يمكنك إلقاء نظرة على الانحراف المعياري في تقديرات الشركات الثلاث. فيما يلي العوامل الثلاثة الأقل تباينًا ، أي مع القيم الأكثر استقرارًا عبر الشركات:
- استخدام العمل عن بعد للتركيز (F40).
- ملاحظات مفيدة على أداء العمل (F4).
- دعم الأقران للأفكار الجديدة (F2).
نعتقد أن استقرار هذه العوامل يجعلها مرشحة جيدة للتعميم. من المحتمل أن ترى الشركات الأخرى نتائج مماثلة لهذه العوامل.
وإليك العوامل الثلاثة ذات التباين الأكبر ، أي مع أكبر انتشار للقيم عبر الشركات:
- استخدام أفضل الوسائل والأساليب (F15).
- إعادة استخدام الكود (F25).
- دقة المعلومات الواردة (F6).
مناقشة . العوامل الثلاثة الأقل تغيرًا (F40 و F4 و F2) لها سمة مشتركة - فهي لا تتعلق بالتكنولوجيا ، بل بالمجتمع والبيئة. ربما يشير هذا إلى أنه أينما يعمل المطورون ، فإنهم يتأثرون بنفس القدر بالعمل عن بُعد والتغذية الراجعة ودعم الأقران للأفكار الجديدة. قد يكون تغيير هذه العوامل الثلاثة هو التأثير الأكبر.
لماذا تختلف العوامل F15 و F25 و F6 في الشركات المختلفة؟ لكل واحد منهم ، لدينا تفسير محتمل بناءً على ما نعرفه عن هذه الشركات.
يرتبط استخدام أفضل الأدوات والأساليب (F15) بشدة بدرجة أداء Google ، ولكنه لا يرتبط بشكل كبير بـ National Instruments. تفسير محتمل: قاعدة بيانات Google أكبر بكثير. ومن ثم ، فإن استخدام أدوات وأساليب أفضل للتنقل وفهم قاعدة البيانات الأكبر بكفاءة له تأثير كبير على الإنتاجية. وفي National Instruments ، تكون الإنتاجية أقل اعتمادًا على الأدوات لأن قاعدة التعليمات البرمجية أصغر وأوضح.
ترتبط إعادة استخدام الكود (F25) ارتباطًا وثيقًا بدرجة أداء Google ، ولكن ليس بشكل كبير في ABB. تفسير محتمل: تسهل Google إعادة استخدام الكود. قاعدة الشفرة متجانسة ، ويمكن لجميع المطورين فحص كل سطر من التعليمات البرمجية في الشركة تقريبًا ، لذلك لا تتطلب إعادة الاستخدام الكثير من الجهد. ولدى ABB الكثير من المستودعات التي يجب عليك الوصول إليها. وفي هذه الشركة ، يمكن تعويض مكاسب الإنتاجية (من خلال إعادة الاستخدام) بخسائر الإنتاجية (من العثور على الكود الصحيح واستعادته).
ترتبط دقة المعلومات (F6) ارتباطًا وثيقًا بنتائج أداء الأجهزة الوطنية ، ولكنها لا ترتبط بشكل كبير بـ ABB. التفسير المحتمل: المطورون في ABB معزولون بشكل أفضل عن تأثير المعلومات غير الدقيقة. على وجه الخصوص ، في ABB ، تم تخصيص عدة مستويات من فريق الدعم للحصول على المعلومات الصحيحة حول الأخطاء من العملاء. إذا تلقى المطور معلومات غير دقيقة ، فقد تنخفض إنتاجيته ، لأنه يتعين عليه تفويض مهمة تحسين البيانات إلى فريق الدعم.
4.4. ما الذي يجعل من الممكن التنبؤ بتقييم المطور لإنتاجيته ، على وجه الخصوص ، مقارنة بالعاملين الآخرين في مجال المعرفة؟
للإجابة على هذا السؤال ، انتقل إلى العمود الأخير في الشكل. 4. إذا نظرنا إلى العديد من العلاقات بين الحد الأقصى من التصنيفات ، فسنرى أن تقييم المحللين لإنتاجيتهم يرتبط ارتباطًا وثيقًا بما يلي:
- تصور إيجابي لزملائهم في الفريق (F7).
- الاستقلالية في تنظيم اوقات العمل (F4).
من ناحية أخرى ، يرتبط تقييم المطورين لإنتاجيتهم ارتباطًا وثيقًا بما يلي:
- القيام بمهام متنوعة داخل العمل (F13).
- العمل بفعالية خارج أماكن عملهم (F30).
مناقشة . بشكل عام ، تشير النتائج إلى أن المطورين يشبهون إلى حد ما العاملين الآخرين في مجال المعرفة ، ومختلفون إلى حد ما. على سبيل المثال ، أفضل توقع لإنتاجية المطور هو الحماس في العمل ، والمحللون لديهم نفس الشيء. نعتقد أنه يمكن للشركات استخدام النتائج التي توصلنا إليها لتحديد مبادرات إنتاجية خاصة بالمطور أو مبادرات أوسع نطاقًا.
قد تشرح مجموعة أدوات التطوير الموحدة من Google سبب ارتباط زيادة تنوع المهام بتصنيفات إنتاجية أعلى من المطورين ، وليس المحللين. يمكن أن يؤدي تنوع المهام إلى تقليل الملل وزيادة الإنتاجية لكلا المجموعتين ، ولكن أدوات التطوير الموحدة من Google يمكن أن تعني أن المطورين يمكنهم استخدام نفس الأدوات لمهام مختلفة. وقد يحتاج المحللون إلى استخدام أدوات مختلفة لمهام مختلفة ، مما يزيد من الجهد المعرفي في تبديل السياق.
قد يفسر العمل خارج المكتب سبب ارتباط تحسين كفاءة العمل بعيدًا عن مكان العمل ارتباطًا وثيقًا بمكاسب الإنتاجية للمطورين أكثر من المحللين. نعتقد أن أخذ استراحة من العمل أكثر ضررًا أثناء البرمجة منه أثناء العمل التحليلي.
وجدت بارنين وروجابير أن العودة إلى العمل بعد الانقطاع هي مشكلة متكررة ومستمرة للمطورين [32] ، مما يؤدي إلى الحاجة إلى أدوات أفضل لمساعدتهم على العودة إلى العمل على حل مشكلة ما [33].

4.5 عوامل إنتاجية أخرى
في نهاية الاستبيان ، يمكن أن يشير المستجيبون إلى عوامل إضافية ، في رأيهم ، تؤثر على الإنتاجية. بالنسبة للجزء الأكبر ، كانت هذه الإضافات هي نفسها أو الأوصاف الأكثر دقة لـ 48 عاملاً لدينا. لقد تجاهلنا مثل هذه الإضافات ، ولكن إذا لزم الأمر ، أنشأنا عوامل جديدة. تحتوي المواد التكميلية على أوصاف لعوامل جديدة ، بالإضافة إلى أوصاف محدثة للعوامل التي اقترحناها في الأصل. قد يكون لدى الباحثين المحتملين سؤال جماعي مختلط جديد للعمل في مشروع ما ، أو تنقيح أو اقتراح المزيد من تقسيمات الأسئلة المحددة للعوامل F15 و F16 و F19.
4.6 الديموغرافيا
في Google و National Instruments ، لم تكن النماذج الديموغرافية العامة ولا المتغيرات المصاحبة الفردية منبئات ذات دلالة إحصائية لنتائج أدائهم.
بالنسبة لـ ABB ، تبين أن النموذج الديموغرافي مهم ( F = 3 ، 406 ، df = (5 ، 131) ، p <0.007). كما تبين أن الجنس عامل مهم من الناحية الإحصائية ( P = 0.007) ؛ تقدر النساء إنتاجيتهن بمقدار 0.83 نقطة أعلى من الرجال. أظهر المشاركون من الأجناس الأخرى ("أخرى") درجة أعلى بـ 1.6 نقطة من الرجال ( ع = 0.03). الموقف ( ص= 0.04) ، فكل سنة إضافية ترفع الشركة تقدير أدائها بمقدار 0.02 نقطة. وبقدر ما نعلم ، فإن الاختلافات بين ABB والشركتين الأخريين لا تفسر سبب توقع أن تكون هذه العوامل الديموغرافية مهمة فقط في ABB وليس في أي مكان آخر.
4.7 التطبيق في الممارسة والبحث
كيف نستخدم نتائجنا في الممارسة؟ لقد قدمنا قائمة مرتبة بأهم العوامل في توقع الإنتاجية التي يمكن استخدامها لتحديد أولويات المبادرات. يمكن العثور على أمثلة من المبادرات في الأوراق البحثية السابقة.
على سبيل المثال ، لزيادة الحماس في العمل ، اقترح ماركوس وسريديفي مساعدة العمال على النمو مهنيًا [34] من خلال ورش عمل حول التكنولوجيا والتواصل بين الأفراد. كما اقترح الباحثون ادخال ممارسة التقدير للعمل الجيد. على سبيل المثال ، تقوم ABB بتجربة التقدير العام للمطورين الذين نفذوا أدوات وتقنيات للتنقل في التعليمات البرمجية المنظمة [35].
لزيادة الدعم للأفكار الجديدة ، اقترح براون ودوجويد طرقًا رسمية وغير رسمية لتبادل أفضل الممارسات [36]. في Google ، يتم نشر المعرفة في اتجاه واحد من خلال مبادرة اختبار المرحاض: يكتب المطورون قصصًا إخبارية قصيرة حول الاختبار أو منطقة أخرى ، ثم يتم نشر هذه الملاحظات في المراحيض في جميع أنحاء الشركة.
لتحسين جودة التعليقات على إنتاجية العمل ، يقترح كل من London and Smither التركيز على التعليقات التي لا تصدر أحكامًا وقائمة على السلوك وقابلة للتفسير وموجهة نحو النتائج [37]. في Google ، يمكن الحصول على مثل هذه التعليقات من خلال عمليات ما بعد الوفاة غير الضارة: بعد الأحداث السلبية المهمة مثل انخفاض الخدمات ، يكتب المهندسون تقريرًا مشتركًا عن الإجراءات التي أثرت على السبب الأصلي للمشكلة ، دون لوم موظفين محددين.
نرى عدة اتجاهات للبحث المستقبلي بناءً على عملنا.
أولاً ، ستعمل المراجعة المنهجية للمقالات التي تميز تأثير وسياق الأدلة لكل عامل إنتاجية تمت مناقشته هنا على تحسين قابلية استخدام عملنا من خلال إنشاء علاقات سببية. عندما تكون ضعيفة ، يمكن تحسين قابلية التطبيق من خلال إجراء سلسلة من التجارب لتحديد السببية.
ثانيًا ، كما هو مذكور في القسمين 4.5 و 4.6 ، يمكن للباحثين المحتملين استخدام عوامل إضافية اقترحها المجيبون ودراسة تأثير الجنس والعوامل الديموغرافية الأخرى على إنتاجية المطور.
ثالثًا ، يمكن تحسين تأثير أبحاث الإنتاجية على تطوير البرمجيات باستخدام مجموعة متعددة الأبعاد من المقاييس والأدوات التي تم التحقق من صحتها من خلال البحث التجريبي والتثليث.
رابعًا ، إذا تمكن الباحثون من حساب تكلفة العوامل المتغيرة التي تؤثر على الإنتاجية ، فيمكن للشركات اتخاذ قرارات استثمارية أكثر ذكاءً.
4.8 المخاطر
عند تفسير نتائج هذه الدراسة ، يجب مراعاة العديد من المخاطر على صحتها.
4.8.1. مخاطر موثوقية البيانات
أولاً ، تحدثنا عن قياس واحد فقط - تقييم إنتاجيتك. هناك أبعاد أخرى ، بما في ذلك المقاييس الموضوعية ، مثل عدد سطور التعليمات البرمجية المكتوبة يوميًا ، وهو أسلوب يستخدمه Facebook [38]. كما أشرنا في القسم 3.1 ، فإن جميع مقاييس الإنتاجية بها عيوب ، بما في ذلك قياس إنتاجيتك. على سبيل المثال ، قد يقوم المطورون بتقييم إنتاجيتهم بشكل ضئيل للغاية ، أو يبالغون بشكل مصطنع في تقييمهم بسبب التحيز في المجتمع [39]. على الرغم من أوجه القصور هذه ، فإن الفريق بقيادة زيلينسكي يبني على العمل السابق للدفاع عن صحة تقييم الأداء [40] ، والذي تم استخدامه أيضًا في هذه المقالة.
ثانيًا ، قمنا بقياس إنتاجيتنا بسؤال واحد لا يكاد يغطي النطاق الكامل لإنتاجية المطورين. على سبيل المثال ، يركز السؤال على التكرار والشدة ، لكنه لا يأخذ في الاعتبار الجودة. كما أننا لم نطلب من المشاركين قصر ردودهم على إطار زمني محدد ، لذلك قد يستجيب بعض المشاركين بناءً على تجاربهم خلال الأسبوع الماضي ، بينما قام آخرون بتقييم تجاربهم خلال العام الماضي. في الماضي ، يجب أن تعمل الدراسة بفاصل زمني ثابت.
ثالثًا ، نظرًا للعدد المحدود من الأسئلة ، فقد اعتمدنا فقط على تلك العوامل التي تم التحقيق فيها في الأعمال السابقة. الأسئلة الـ 48 التي اخترناها قد لا تغطي جميع جوانب السلوكيات المتعلقة بالإنتاجية. أو قد تكون العوامل التي اخترناها عامة جدًا في حالات معينة. على سبيل المثال ، في وقت لاحق ، قد يكون العامل المتعلق بأفضل "الأدوات والأساليب" (F14) أكثر قوة إذا فصلنا الأدوات عن الطرق.
4.8.2. المخاطر الداخلية على الموثوقية
رابعًا ، كما ذكرنا في القسم 3.8 ، اعتمدنا على العمل السابق لإنشاء علاقات سببية بين العوامل والإنتاجية ، لكن قوة الأدلة على العلاقات يمكن أن تختلف. قد يتضح أن بعض العوامل تؤثر على تقييم إنتاجيتها بشكل غير مباشر فقط ، من خلال عوامل أخرى ، أو أن ارتباطها له اتجاه معاكس بشكل عام. على سبيل المثال ، من المحتمل أن يكون العامل الرئيسي في الإنتاجية ، وهو الحماس المتزايد للعمل (F1) ، ناتجًا في الواقع عن زيادة الإنتاجية.
4.8.3. المخاطر الخارجية على الموثوقية
خامساً ، على الرغم من أننا فحصنا ثلاث شركات مختلفة إلى حد ما ، إلا أن قابلية التعميم مع أنواع أخرى من الشركات والمؤسسات الأخرى وأنواع أخرى من العاملين المعرفيين محدودة. في هذه الورقة ، اخترنا المحللين كممثلين لغير المطورين ، لكن هذه الفئة تشمل عدة أنواع من العاملين في مجال المعرفة - الأطباء والمهندسين المعماريين والمحامين. خطر آخر على الموثوقية هو التحيز بسبب نقص الردود: الأشخاص الذين أجابوا على الاستبيانات تم اختيارهم بأنفسهم.
سادساً ، قمنا بتحليل كل عامل من عوامل الإنتاجية على حدة ، ولكن يمكن أن تصاحب العديد من العوامل بعضها البعض. هذه ليست مشكلة تحليل ، ولكن قابلية تطبيق النتائج. إذا كانت العوامل مترابطة ، فإن تغيير أحدهما يمكن أن يؤثر سلبًا على الآخر.
4.8.4. مخاطر
المصداقية البناءة سابعاً ، عند إنشاء هذه الدراسة ، كنا قلقين بشأن احتمالية أن يتعرف المستجيبون على منهجية التحليل لدينا ولا يجيبون بصدق. لقد حاولنا تقليل هذا الاحتمال من خلال فصل قضية الإنتاجية عن عواملها ، ولكن ربما يكون المشاركون قادرين على استخلاص استنتاجات حول منهجية التحليل لدينا.
أخيرًا ، أعدنا صياغة بعض الأسئلة لتكييف الدراسة للمحللين ، مما قد يغير معنى الأسئلة بشكل غير مرغوب فيه. وبالتالي ، قد تكون الاختلافات بين المطورين والمحللين قد نشأت من الاختلافات في الأسئلة ، وليس في المهنة.
5. الأعمال ذات الصلة
درس العديد من الباحثين عوامل الإنتاجية الفردية لمطوري البرمجيات. على سبيل المثال ، قام Moser و Nierstrasz بتحليل 36 مشروعًا لتطوير البرامج واستكشفا التأثير المحتمل للتقنيات الموجهة للكائنات على تحسين إنتاجية المطورين [41].
مثال آخر هو الدراسة التي أجراها DeMarco و Lister على 166 مبرمجًا من 35 منظمة يقومون بتمرين برمجة ليوم واحد. وجد المؤلفون أن مكان العمل والتنظيم مرتبطان بالإنتاجية [42].
المثال الثالث هو تجربة معملية بواسطة Kersten و Murphy مع 16 مطورًا. اتضح أن أولئك الذين استخدموا الأداة للتركيز على المهمة كانوا أكثر إنتاجية من الآخرين [43].
بالإضافة إلى ذلك ، يوفر التحليل المنهجي لفاغنر ورويت فكرة جيدة عن العلاقة بين العوامل الفردية والإنتاجية [14]. قدم الفريق بقيادة ماير تحليلاً أكثر حداثة للنظرة العامة لعوامل الإنتاجية [3]. بشكل عام ، يعتمد عملنا على هذه الدراسات للعوامل الفردية مع دراسة أوسع لتنوعها.
تنص المراجعة المنهجية لـ Petersen على أن سبع أوراق بحثية تقيم عددًا العوامل التي تتنبأ بإنتاجية مطور البرامج [44]. في كل عمل ، يتم استخدام الأساليب العددية للتنبؤ ، وعادةً ما يكون هذا هو الانحدار ، والذي استخدمناه أيضًا في بحثنا. ترتبط العوامل الأكثر شيوعًا بحجم المشروع ، وقد تمت صياغة 6 من أصل 7 عوامل بشكل صريح بناءً على محركات إنتاجية COCOMO II ([6] ، [27] ، [28] ، [29] ، [30] ، [31]). يستخدم نموذج التنبؤ الأكثر تعقيدًا في دراسة بيترسن 16 عاملاً [6].
عملنا له اختلافان رئيسيان. أولاً ، مقارنة بالأعمال السابقة ، نقدر عددًا أكبر من العوامل (48) ، وتنوعها أوسع. اخترنا عوامل تعتمد على علم النفس الصناعي والتنظيمي. ثانيًا ، كان لدينا موضوع مختلف للتحليل: درس الباحثون السابقون ما يمكن أن يتنبأ بالإنتاجية في إطار المشروع ، وكنا مهتمين بالإنتاجية الشخصية للأشخاص.
بالإضافة إلى تطوير البرمجيات ، قارنت الدراسات السابقة العوامل التي تتنبأ بالإنتاجية في المهن الأخرى ، ولا سيما في مجال علم النفس الصناعي والتنظيمي. في حين ركزت هذه الدراسات على الإنتاجية على مستوى الشركة [45] والعمل البدني مثل التصنيع [46] ، فإن المجال الأكثر ارتباطًا هو إنتاجية العاملين في مجال المعرفة. بمعنى أن الأشخاص يستخدمون المعرفة والمعلومات بنشاط في عملهم ، وعادة ما يستخدمون الكمبيوتر [47]. يتم تقديم مقارنة بين عوامل مثل هذه المهن في عملين رئيسيين. الأولى هي دراسة جماعية بقيادة Palwalin تستكشف 38 عاملاً قارنتها الدراسات السابقة بالإنتاجية. تشمل هذه العوامل مساحة العمل المادية والافتراضية والاجتماعية ،مناهج العمل الشخصية والرفاهية في العمل [4]. والثاني دراسة أجراها هرنوس وميكوليتش على 512 عامل معرفة. درس المؤلفون 14 عاملاً ، مقسمة إلى ثلاث فئات [9]. لقد اعتمدنا على هذين العملين في إعداد دراستنا (القسم 3.2).
ومع ذلك ، فإن الدراسات التي تقارن عوامل الإنتاجية للعاملين في مجال المعرفة لم تهتم بمطوري البرمجيات. هناك سببان رئيسيان لهذا. أولاً ، من غير الواضح إلى أي مدى يتم عرض النتائج الإجمالية التي تم الحصول عليها على المطورين. ثانيًا ، تُستخرج مثل هذه الدراسات عادةً من العوامل الخاصة بالمطور ، مثل إعادة استخدام البرامج وتعقيد قاعدة الكود [48]. لذلك ، هناك فجوة في الأدبيات في فهم العوامل التي تسمح بالتنبؤ بإنتاجية المطور. سد هذه الفجوة هو عملي. لقد أنشأنا ثلاث فرق بحثية في ثلاث شركات لتحسين الإنتاجية. يساعد سد هذه الفجوة المعرفية فرقنا على البحث والشركات للاستثمار في إنتاجية المطورين.
6. الخلاصة
تؤثر العديد من العوامل على إنتاجية المطور ، لكن المنظمات لديها موارد محدودة للتركيز على تحسين الإنتاجية. قمنا بإنشاء وإجراء دراسة في ثلاث شركات لتصنيف العوامل المختلفة ومقارنتها. يمكن للمطورين والقادة استخدام النتائج التي توصلنا إليها لتحديد أولويات جهودهم. لتوضيح الأمر ببساطة ، اقترحت الأوراق السابقة العديد من الطرق لتحسين إنتاجية مطوري البرامج ، وقد اقترحنا كيف يمكنك تحديد أولويات هذه الطرق.

كتلة الأسئلة
ما الذي يجعل المطور منتجًا؟
سيستغرق هذا البحث المجهول المكون من صفحة واحدة 15 دقيقة وسيساعدنا على فهم أفضل لما يؤثر على إنتاجية المطور. الرجاء الإجابة بصراحة وصدق.
سيطرح البحث أسئلة عنك وعن مشروعك وعن برنامجك. يرجى تذكر:
برنامجي يشير إلى البرامج الأساسية التي تقوم بتطويرها في ABB، بما في ذلك المنتجات والبنية التحتية. إذا كنت تعمل على برامج مختلفة ، فأجب فقط على البرنامج الرئيسي. ينتمي
مشروعي إلى الفريق الذي تنشئ معه البرامج. الرجاء الإجابة على أي أسئلة ذات صلة حول مطوري البرامج الآخرين في ABB.
تتطرق بعض الأسئلة إلى مواضيع يحتمل أن تكون حساسة. املأ الإجابات حتى لا يتمكن أي شخص من إلقاء نظرة على كتفك ، وامسح سجل المتصفح وملفات تعريف الارتباط بعد ملء الاستبيان.
يرجى تقييم موافقتك على البيانات التالية.
قائمة أسئلة البحث
تم تصميم هذه الأسئلة لتقديم تقييم شامل للعوامل التي يمكن أن تؤثر على الإنتاجية. هل نفتقد شيئا؟
الجنس (اختياري)
ما هو لقبك؟ (اختياري)
في أي سنة انضممت إلى ABB؟
مواد إضافية
عوامل الإنتاجية التي لاحظها المستجيبون
في هذا القسم ، ندرج العوامل التي وصفها المستجيبون في ردودهم على السؤال المفتوح. أولاً ، سنصف عدة عوامل جديدة ، ثم سنقدم وصفًا للعوامل المتعلقة بتلك المتوفرة بالفعل في الدراسة. استكملنا تعليقات المستجيبين برموز باستخدام عواملنا. نحن هنا لا نناقش أو نقيم إجابات الأشخاص ، ولا نكمل الأوصاف الحالية لعواملنا.
عوامل جديدة
في التعليقات ، تم طرح 4 مواضيع لم تنعكس في دراستنا. أثارت ستة ردود مواضيع فريق المشروع المختلط ، ولا سيما نسبة المديرين إلى المطورين ؛ وجود عدد كاف من الموظفين في المشروع ؛ وما إذا كانت الإدارة قادرة على الحفاظ على ملكية قوية للمنتج. أشار أحد المشاركين إلى تأثير نوع البرنامج على الإنتاجية (الخادم ، والعميل ، والجوال ، وما إلى ذلك). وأشار آخر إلى تأثير العوامل الفسيولوجية مثل عدد ساعات النوم. ذكر آخر فرص النمو الشخصي.
العوامل المتاحة
F1. ذكر خمسة من المجيبين العوامل المتعلقة بالحماس في العمل: ذكر اثنان دافع العمل والتقدير ، الأول - الأخلاق ، والآخر - مبنى المكتب المحبط.
F3. وأشار أربعة من المستجيبين إلى عوامل تتعلق بالاستقلالية في اختيار أساليب العمل. ذكر أحدهم الاستقلالية على مستوى الفريق ، وآخر عن السياسة التي تمنع استخدام نظام جيد مفتوح المصدر ، والثالث حول الأولويات المعتمدة في الشركة والتي تحد من استخدام تقنيات معينة في الفرق.
F4. أشار أحد المشاركين إلى الاستقلالية في جدولة ساعات العمل ، والتي تقتصر على الأولويات التي تمليها الحاجة إلى الترقية.
F5. وأشار ثلاثة مشاركين إلى الكفاءة القيادية. ذكر أحدهما القيادة باستراتيجية متماسكة ، والثاني - الأولويات المتضاربة التي تمررها الإدارة ، والثالث - إدارة إنتاجية الموظفين.
F6. قال ثمانية من المجيبين إنهم قدموا معلومات دقيقة. ذكرت ثلاثة منها التواصل بين الفريق من خلال التوثيق (والقنوات الأخرى) ، وذكر اثنان التعريف الواضح لأهداف وخطط الفريق.
F7. لاحظ اثنان من المشاركين مشاعر إيجابية تجاه الزملاء في ضوء تماسك الفريق والفريق.
F8. أشار أحد المشاركين إلى الاستقلالية في القيام بالعمل: تحدد سياسة الشركة الموارد التي يمكن استخدامها.
F9. أشار أحد المشاركين إلى حل النزاعات ، مشيرًا إلى أن العادات الشخصية لزملائه في الفريق تتعارض مع الأعراف الاجتماعية.
F10. وأشار أربعة مستجيبين إلى كفاءة المطورين. ذكر أحدهما الصعوبات في فهم الكود ، والآخر - معرفة مجال الموضوع ، والثالث - جدية الموقف تجاه الاختبار.
F11. أشار أحد المشاركين إلى التعليقات حول إنتاجية العمل: الحصول على تقدير من الزملاء والإدارة ، والترقية.
F12. لاحظ أحد المستجيبين تعقيد تنفيذ البرامج "من ذهني إلى المنتج المشحون".
F13. لاحظ اثنان من المشاركين تنوع المهام ، ولا سيما اعتراض المهام نيابة عن فريقهم وتبديل السياق.
F14 صنف أربعة مستجيبين المتطلبات وأفراد الهندسة المعمارية على أنهم أكفاء. أشار أحدهم إلى عدم الاهتمام الكافي بالمشكلات ، وذكر آخر - سهولة قراءة الوثائق المعمارية ، والثالث - جودة خطط المشروع ، والرابع - توافر "الدعم الكافي في تطوير المتطلبات".
F15. أفاد 32 مستجيبًا باستخدام أفضل الأدوات والأساليب. ذكر اثنا عشر أداء الأدوات ، لا سيما مشكلات السرعة والكمون في الإنشاء والاختبار. ذكر خمسة أشخاص الميزات المتاحة ، وذكر ثلاثة منهم مشكلات التوافق والترحيل ، وذكر اثنان أنه حتى أفضل أداة متاحة قد لا تلبي الاحتياجات. وأشارت تعليقات أخرى على الأدوات والنهج إلى مستوى الأتمتة الذي توفره الأدوات ؛ مصححات ومحاكيات متخصصة ؛ نهج رشيقة الاختبارات غير المستقرة والأدوات ذات الصلة ؛ الأدوات التي تعمل بشكل جيد عن بعد ؛ اختيار لغات البرمجة أدوات عفا عليها الزمن فصل التفضيلات الشخصية في الأدوات عن تلك المعتمدة في الشركة.
اف 16. لاحظ 19 مجيبًا نقلًا مناسبًا للمعرفة بين الناس. ذكر تسعة أشخاص صعوبات التواصل مع الفرق الأخرى: ثلاثة - الاتفاق على الأهداف بين الفرق ، واحد - الاتفاق على الأهداف ضمن فريق كبير ، والآخر - التوصل إلى اتفاق بين الفرق. وأشار اثنان إلى صعوبة تنسيق العمل في فريق دولي أو فريق المنطقة الزمنية. ذكر اثنان آخران الحاجة إلى الاعتماد على توثيق الفرق الأخرى. علق اثنان على مدة مراجعة الكود. وأشار اثنان آخران إلى وعي مرافق عمل الزملاء. ذكر أحدهما البحث عن الشخص المناسب ، وذكر آخر - التأخير في التفاعل ، والثالث - التواصل بين المهندسين والمتخصصين في مجال الموضوع. أخيرًا ، ذكر أحدهم أهمية توضيح الأمرما هي قنوات الاتصال الأفضل لاستخدامها في مواقف معينة.
F18. وأشار اثنان من المجيبين إلى نهج لعقد الاجتماعات ، وذكر أحدهم أن فعالية الاجتماعات تعتمد على توافر غرف الاجتماعات.
F19. لاحظ أربعة وعشرون مجيبًا الانقطاعات والتشتت عن العمل. ذكرت عشر بيئات صاخبة ، وسبعة أشارت إلى أن المكاتب المفتوحة تقلل من الإنتاجية. ذكر أربعة صعوبات في تعدد المهام وتبديل السياق. وأفاد أربعة آخرون عن الحاجة إلى التركيز إما على وظيفتهم الرئيسية أو على مهام "اختيارية" مثل إجراء المقابلات. ذكر اثنان صعوبة التركيز عند التنقل من وإلى العمل.
F25. أشار أحد المستجيبين إلى إعادة استخدام الكود ، مشيرًا إلى أن واجهات برمجة التطبيقات ذات السطر 2-3 تزيد من التعقيد مع الحد الأدنى من المساهمة في تقليل التكرار.
F26. علق أحد المشاركين على تجربة استخدام منصة برمجية ، مشيرًا إلى أن المشكلات تتفاقم عندما ينتقل المطور بين المشاريع.
F27. لاحظ ثلاثة من المجيبين هندسة البرمجيات والحد من المخاطر. وأشار أحدهم إلى "مدى شهرة بنية المنتج ، ومدى ترابطها ، وكيف تدعم الأشخاص الذين يعرفون أدوارهم وقادرون على التركيز ، والذين يعرفون مسؤولياتهم وحدودهم ، وما يمتلكونه." وأشار آخر إلى أن العمارة ، من خلال نمطية ، يمكن أن تسهل التبادل بين مكونات البرمجيات. واقترح الثالث أن تكون البنية متسقة مع هيكل المنظمة.
F32. ذكر أربعة مشاركين الحاجة إلى تبديل السياق. ذكر اثنان أن التبديل ضروري عند الانتقال بين المشاريع. أوضح أحدهم أن الحاجة إلى تبديل السياق تختلف عن متعة التبديل. وذكر آخر أن "المشاريع الإنتاجية" في حد ذاتها يمكن أن تقلل من الإنتاجية.
F34. وأشار خمسة من المجيبين إلى ضيق المواعيد النهائية. وأشار أحدهم إلى أن هذا يساهم في نمو الديون الفنية ، بينما أشار الآخر - إلى أن مثل هذه المواعيد النهائية يمكن أن تؤدي إلى إهدار الموارد.
F42. لاحظ ثلاثة مستجيبين قيود البرامج. أشار اثنان إلى قيود الخصوصية والآخر إلى قيود أمنية خطيرة.
F44. لاحظ أحد عشر مجيبًا مدى تعقيد البرنامج. أشار اثنان إلى التعقيد الخاص للشفرة القديمة ، وأشار اثنان إلى الديون الفنية ، وكل من الإصدار الملحوظ ، وصيانة البرامج ،
وفهم الكود.
Coefficients:
Estimate Std. Error t value Pr(>|t|)
(Intercept) 2.786969 0.111805 24.927 < 0.0000000000000002 ***
log(lines_changed + 1) 0.045189 0.009296 4.861 0.00000122 ***
level -0.050649 0.015833 -3.199 0.00139 **
job_codeENG_TYPE2 0.194108 0.172096 1.128 0.25944
job_codeENG_TYPE3 0.034189 0.076718 0.446 0.65589
job_codeENG_TYPE4 -0.185930 0.084484 -2.201 0.02782 *
job_codeENG_TYPE5 -0.375294 0.085896 -4.369 0.00001285 ***
---
Signif. codes: 0 `***` 0.001 `**` 0.01 `*` 0.05 `.` 0.1 ` ` 1
Residual standard error: 0.8882 on 3388 degrees of freedom
Multiple R-squared: 0.01874, Adjusted R-squared: 0.017
F-statistic: 10.78 on 6 and 3388 DF, p-value: 0.000000000006508
الشكل: 5: النموذج 1: استكمال نتائج الانحدار الخطي
Coefficients:
Estimate Std. Error t value Pr(>|t|)
(Intercept) 2.74335 0.09706 28.265 < 0.0000000000000002
log(changelists_created + 1) 0.11220 0.01608 6.977 0.00000000000362
level -0.04999 0.01574 -3.176 0.00151
job_codeENG_TYPE2 0.27044 0.17209 1.571 0.11616
job_codeENG_TYPE3 0.02451 0.07644 0.321 0.74847
job_codeENG_TYPE4 -0.21640 0.08411 -2.573 0.01013
job_codeENG_TYPE5 -0.40194 0.08559 -4.696 0.00000275538534
(Intercept) ***
log(changelists_created + 1) ***
level **
job_codeENG_TYPE2
job_codeENG_TYPE3
job_codeENG_TYPE4 *
job_codeENG_TYPE5 ***
---
Signif. codes: 0 `***` 0.001 `**` 0.01 `*` 0.05 `.` 0.1 ` ` 1
Residual standard error: 0.885 on 3388 degrees of freedom
Multiple R-squared: 0.02589, Adjusted R-squared: 0.02416
F-statistic: 15.01 on 6 and 3388 DF, p-value: < 0.00000000000000022
الشكل: 6: النموذج 2: استكمال نتائج الانحدار الخطي
Coefficients:
Estimate Std. Error t value Pr(>|t|)
(Intercept) 2.79676 0.11141 25.102 < 0.0000000000000002
log(lines_changed + 1) -0.01462 0.01498 -0.976 0.32897
log(changelists_created + 1) 0.13215 0.02600 5.082 0.000000394
level -0.05099 0.01578 -3.233 0.00124
job_codeENG_TYPE2 0.27767 0.17226 1.612 0.10706
job_codeENG_TYPE3 0.02226 0.07647 0.291 0.77102
job_codeENG_TYPE4 -0.22446 0.08452 -2.656 0.00795
job_codeENG_TYPE5 -0.40819 0.08583 -4.756 0.000002057
(Intercept) ***
log(lines_changed + 1)
log(changelists_created + 1) ***
level **
job_codeENG_TYPE2
job_codeENG_TYPE3
job_codeENG_TYPE4 **
job_codeENG_TYPE5 ***
---
Signif. codes: 0 `***` 0.001 `**` 0.01 `*` 0.05 `.` 0.1 ` ` 1
Residual standard error: 0.885 on 3387 degrees of freedom
Multiple R-squared: 0.02616, Adjusted R-squared: 0.02415
F-statistic: 13 on 7 and 3387 DF, p-value: < 0.00000000000000022
الشكل: 7: النموذج 3: نتائج الانحدار الخطي الكاملة.
فهرس
[1] R. S. Nickerson, “Confirmation bias: A ubiquitous phenomenon in many guises.” Review of general psychology, vol. 2, no. 2, p. 175, 1998.
[2] Y. W. Ramírez and D. A. Nembhard, “Measuring knowledge worker productivity: A taxonomy,” Journal of Intellectual Capital, vol. 5, no. 4, pp. 602–628, 2004.
[3] A. N. Meyer, L. E. Barton, G. C. Murphy, T. Zimmermann, and T. Fritz, “The work life of developers: Activities, switches and perceived productivity,” IEEE Transactions on Software Engineering, 2017.
[4] M. Palvalin, M. Vuolle, A. Jääskeläinen, H. Laihonen, and A. Lönnqvist, “Smartwow–constructing a tool for knowledge work performance analysis,” International Journal of Productivity and Performance Management, vol. 64, no. 4, pp. 479–498, 2015.
[5] C. H. C. Duarte, “Productivity paradoxes revisited,” Empirical Software Engineering, pp. 1–30, 2016.
[6] K. D. Maxwell, L. VanWassenhove, and S. Dutta, “Software development productivity of european space, military, and industrial applications,” IEEE Transactions on Software Engineering, vol. 22, no. 10, pp. 706–718, 1996.
[7] J. D. Blackburn, G. D. Scudder, and L. N. Van Wassenhove, “Improving speed and productivity of software development: a global survey of software developers,” IEEE transactions on software engineering, vol. 22, no. 12, pp. 875–885, 1996.
[8] B. Vasilescu, Y. Yu, H.Wang, P. Devanbu, and V. Filkov, “Quality and productivity outcomes relating to continuous integration in github,” in Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering. ACM, 2015, pp. 805–816.
[9] T. Hernaus and J. Mikulic, “Work characteristics and work performance of knowledge workers,” EuroMed Journal of Business, vol. 9, no. 3, pp. 268–292, 2014.
[10] F. P. Morgeson and S. E. Humphrey, “The work design questionnaire (wdq): developing and validating a comprehensive measure for assessing job design and the nature of work.” Journal of applied psychology, vol. 91, no. 6, p. 1321, 2006.
[11] J. R. Idaszak and F. Drasgow, “A revision of the job diagnostic survey: Elimination of a measurement artifact.” Journal of Applied Psychology, vol. 72, no. 1, p. 69, 1987.
[12] M. A. Campion, G. J. Medsker, and A. C. Higgs, “Relations between work group characteristics and effectiveness: Implications for designing effective work groups,” Personnel psychology, vol. 46, no. 4, pp. 823–847, 1993.
[13] T. Hernaus, “Integrating macro-and micro-organizational variables through multilevel approach,” Unpublished doctoral thesis). Zagreb: University of Zagreb, 2010.
[14] S. Wagner and M. Ruhe, “A systematic review of productivity factors in software development,” in Proceedings of 2nd International Workshop on Software Productivity Analysis and Cost Estimation, 2008.
[15] A. N. Meyer, T. Fritz, G. C. Murphy, and T. Zimmermann, “Software developers’ perceptions of productivity,” in Proceedings of the International Symposium on Foundations of Software Engineering. ACM, 2014, pp. 19–29.
[16] R. Antikainen and A. Lönnqvist, “Knowledge work productivity assessment,” Tampere University of Technology, Tech. Rep., 2006.
[17] M. Galesic and M. Bosnjak, “Effects of questionnaire length on participation and indicators of response quality in a web survey,” Public opinion quarterly, vol. 73, no. 2, pp. 349–360, 2009.
[18] L. Beckwith, C. Kissinger, M. Burnett, S. Wiedenbeck, J. Lawrance, A. Blackwell, and C. Cook, “Tinkering and gender in end-user programmers’ debugging,” in Proceedings of the SIGCHI conference on Human Factors in computing systems. ACM, 2006, pp. 231–240.
[19] D. B. Rubin, Multiple imputation for nonresponse in surveys. John Wiley & Sons, 2004, vol. 81.
[20] A. W. Meade and S. B. Craig, “Identifying careless responses in survey data.” Psychological methods, vol. 17, no. 3, p. 437, 2012.
[21] E. Smith, R. Loftin, E. Murphy-Hill, C. Bird, and T. Zimmermann, “Improving developer participation rates in surveys,” in Proceedings of Cooperative and Human Aspects on Software Engineering, 2013.
[22] Y. Benjamini and Y. Hochberg, “Controlling the false discovery rate: a practical and powerful approach to multiple testing,” Journal of the royal statistical society. Series B (Methodological),
pp. 289–300, 1995.
[23] R. A. Guzzo, R. D. Jette, and R. A. Katzell, “The effects of psychologically based intervention programs on worker productivity: A meta-analysis,” Personnel psychology, vol. 38, no. 2, pp.
275–291, 1985.
[24] D. Graziotin, X. Wang, and P. Abrahamsson, “Happy software developers solve problems better: psychological measurements in empirical software engineering,” PeerJ, vol. 2, p. e289, 2014.
[25] J. Noll, M. A. Razzak, and S. Beecham, “Motivation and autonomy in global software development: an empirical study,” in Proceedings of the 21st International Conference on Evaluation
and Assessment in Software Engineering. ACM, 2017, pp. 394–399.
[26] B. Clark, S. Devnani-Chulani, and B. Boehm, “Calibrating the cocomo ii post-architecture model,” in Proceedings of the International Conference on Software Engineering. IEEE, 1998, pp. 477–480.
[27] B. Kitchenham and E. Mendes, “Software productivity measurement using multiple size measures,” IEEE Transactions on Software Engineering, vol. 30, no. 12, pp. 1023–1035, 2004.
[28] S. L. Pfleeger, “Model of software effort and productivity,” Information and Software Technology, vol. 33, no. 3, pp. 224–231, 1991.
[29] G. Finnie and G. Wittig, “Effect of system and team size on 4gl software development productivity,” South African Computer Journal, pp. 18–18, 1994.
[30] D. R. Jeffery, “A software development productivity model for mis environments,” Journal of Systems and Software, vol. 7, no. 2, pp. 115–125, 1987.
[31] L. R. Foulds, M. Quaddus, and M. West, “Structural equation modelling of large-scale information system application development productivity: the hong kong experience,” in Computer and Information Science, 2007. ICIS 2007. 6th IEEE/ACIS International Conference on. IEEE, 2007, pp. 724–731.
[32] C. Parnin and S. Rugaber, “Resumption strategies for interrupted programming tasks,” Software Quality Journal, vol. 19, no. 1, pp. 5–34, 2011.
[33] C. Parnin and R. DeLine, “Evaluating cues for resuming interrupted programming tasks,” in Proceedings of the SIGCHI conference on human factors in computing systems. ACM, 2010, pp. 93–102.
[34] S. Markos and M. S. Sridevi, “Employee engagement: The key to improving performance,” International Journal of Business and Management, vol. 5, no. 12, pp. 89–96, 2010.
[35] W. Snipes, A. R. Nair, and E. Murphy-Hill, “Experiences gamifying developer adoption of practices and tools,” in Companion Proceedings of the 36th International Conference on Software Engineering. ACM, 2014, pp. 105–114.
[36] J. S. Brown and P. Duguid, “Balancing act: How to capture knowledge without killing it.” Harvard business review, vol. 78, no. 3, pp. 73–80, 1999.
[37] M. London and J. W. Smither, “Feedback orientation, feedback culture, and the longitudinal performance management process,” Human Resource Management Review, vol. 12, no. 1,
pp. 81–100, 2002.
[38] T. Savor, M. Douglas, M. Gentili, L. Williams, K. Beck, and M. Stumm, “Continuous deployment at facebook and oanda,” in Proceedings of the 38th International Conference on Software Engineering Companion. ACM, 2016, pp. 21–30.
[39] R. J. Fisher, “Social desirability bias and the validity of indirect questioning,” Journal of consumer research, vol. 20, no. 2, pp. 303–315, 1993.
[40] J. M. Zelenski, S. A. Murphy, and D. A. Jenkins, “The happyproductive worker thesis revisited,” Journal of Happiness Studies, vol. 9, no. 4, pp. 521–537, 2008.
[41] S. Moser and O. Nierstrasz, “The effect of object-oriented frameworks on developer productivity,” Computer, vol. 29, no. 9, pp. 45–51, 1996.
[42] T. DeMarco and T. Lister, “Programmer performance and the effects of the workplace,” in Proceedings of the International Conference on Software Engineering. IEEE Computer Society
Press, 1985, pp. 268–272.
[43] M. Kersten and G. C. Murphy, “Using task context to improve programmer productivity,” in Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering. ACM, 2006, pp. 1–11.
[44] K. Petersen, “Measuring and predicting software productivity: A systematic map and review,” Information and Software Technology, vol. 53, no. 4, pp. 317–343, 2011.
[45] M. J. Melitz, “The impact of trade on intra-industry reallocations and aggregate industry productivity,” Econometrica, vol. 71, no. 6, pp. 1695–1725, 2003.
[46] M. N. Baily, C. Hulten, D. Campbell, T. Bresnahan, and R. E. Caves, “Productivity dynamics in manufacturing plants,” Brookings papers on economic activity. Microeconomics, vol. 1992, pp. 187–267, 1992.
[47] A. Kidd, “The marks are on the knowledge worker,” in Proceedings of the SIGCHI conference on Human factors in computing systems. ACM, 1994, pp. 186–191.
[48] G. K. Gill and C. F. Kemerer, “Cyclomatic complexity density and software maintenance productivity,” IEEE transactions on software engineering, vol. 17, no. 12, pp. 1284–1288, 1991.
[2] Y. W. Ramírez and D. A. Nembhard, “Measuring knowledge worker productivity: A taxonomy,” Journal of Intellectual Capital, vol. 5, no. 4, pp. 602–628, 2004.
[3] A. N. Meyer, L. E. Barton, G. C. Murphy, T. Zimmermann, and T. Fritz, “The work life of developers: Activities, switches and perceived productivity,” IEEE Transactions on Software Engineering, 2017.
[4] M. Palvalin, M. Vuolle, A. Jääskeläinen, H. Laihonen, and A. Lönnqvist, “Smartwow–constructing a tool for knowledge work performance analysis,” International Journal of Productivity and Performance Management, vol. 64, no. 4, pp. 479–498, 2015.
[5] C. H. C. Duarte, “Productivity paradoxes revisited,” Empirical Software Engineering, pp. 1–30, 2016.
[6] K. D. Maxwell, L. VanWassenhove, and S. Dutta, “Software development productivity of european space, military, and industrial applications,” IEEE Transactions on Software Engineering, vol. 22, no. 10, pp. 706–718, 1996.
[7] J. D. Blackburn, G. D. Scudder, and L. N. Van Wassenhove, “Improving speed and productivity of software development: a global survey of software developers,” IEEE transactions on software engineering, vol. 22, no. 12, pp. 875–885, 1996.
[8] B. Vasilescu, Y. Yu, H.Wang, P. Devanbu, and V. Filkov, “Quality and productivity outcomes relating to continuous integration in github,” in Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering. ACM, 2015, pp. 805–816.
[9] T. Hernaus and J. Mikulic, “Work characteristics and work performance of knowledge workers,” EuroMed Journal of Business, vol. 9, no. 3, pp. 268–292, 2014.
[10] F. P. Morgeson and S. E. Humphrey, “The work design questionnaire (wdq): developing and validating a comprehensive measure for assessing job design and the nature of work.” Journal of applied psychology, vol. 91, no. 6, p. 1321, 2006.
[11] J. R. Idaszak and F. Drasgow, “A revision of the job diagnostic survey: Elimination of a measurement artifact.” Journal of Applied Psychology, vol. 72, no. 1, p. 69, 1987.
[12] M. A. Campion, G. J. Medsker, and A. C. Higgs, “Relations between work group characteristics and effectiveness: Implications for designing effective work groups,” Personnel psychology, vol. 46, no. 4, pp. 823–847, 1993.
[13] T. Hernaus, “Integrating macro-and micro-organizational variables through multilevel approach,” Unpublished doctoral thesis). Zagreb: University of Zagreb, 2010.
[14] S. Wagner and M. Ruhe, “A systematic review of productivity factors in software development,” in Proceedings of 2nd International Workshop on Software Productivity Analysis and Cost Estimation, 2008.
[15] A. N. Meyer, T. Fritz, G. C. Murphy, and T. Zimmermann, “Software developers’ perceptions of productivity,” in Proceedings of the International Symposium on Foundations of Software Engineering. ACM, 2014, pp. 19–29.
[16] R. Antikainen and A. Lönnqvist, “Knowledge work productivity assessment,” Tampere University of Technology, Tech. Rep., 2006.
[17] M. Galesic and M. Bosnjak, “Effects of questionnaire length on participation and indicators of response quality in a web survey,” Public opinion quarterly, vol. 73, no. 2, pp. 349–360, 2009.
[18] L. Beckwith, C. Kissinger, M. Burnett, S. Wiedenbeck, J. Lawrance, A. Blackwell, and C. Cook, “Tinkering and gender in end-user programmers’ debugging,” in Proceedings of the SIGCHI conference on Human Factors in computing systems. ACM, 2006, pp. 231–240.
[19] D. B. Rubin, Multiple imputation for nonresponse in surveys. John Wiley & Sons, 2004, vol. 81.
[20] A. W. Meade and S. B. Craig, “Identifying careless responses in survey data.” Psychological methods, vol. 17, no. 3, p. 437, 2012.
[21] E. Smith, R. Loftin, E. Murphy-Hill, C. Bird, and T. Zimmermann, “Improving developer participation rates in surveys,” in Proceedings of Cooperative and Human Aspects on Software Engineering, 2013.
[22] Y. Benjamini and Y. Hochberg, “Controlling the false discovery rate: a practical and powerful approach to multiple testing,” Journal of the royal statistical society. Series B (Methodological),
pp. 289–300, 1995.
[23] R. A. Guzzo, R. D. Jette, and R. A. Katzell, “The effects of psychologically based intervention programs on worker productivity: A meta-analysis,” Personnel psychology, vol. 38, no. 2, pp.
275–291, 1985.
[24] D. Graziotin, X. Wang, and P. Abrahamsson, “Happy software developers solve problems better: psychological measurements in empirical software engineering,” PeerJ, vol. 2, p. e289, 2014.
[25] J. Noll, M. A. Razzak, and S. Beecham, “Motivation and autonomy in global software development: an empirical study,” in Proceedings of the 21st International Conference on Evaluation
and Assessment in Software Engineering. ACM, 2017, pp. 394–399.
[26] B. Clark, S. Devnani-Chulani, and B. Boehm, “Calibrating the cocomo ii post-architecture model,” in Proceedings of the International Conference on Software Engineering. IEEE, 1998, pp. 477–480.
[27] B. Kitchenham and E. Mendes, “Software productivity measurement using multiple size measures,” IEEE Transactions on Software Engineering, vol. 30, no. 12, pp. 1023–1035, 2004.
[28] S. L. Pfleeger, “Model of software effort and productivity,” Information and Software Technology, vol. 33, no. 3, pp. 224–231, 1991.
[29] G. Finnie and G. Wittig, “Effect of system and team size on 4gl software development productivity,” South African Computer Journal, pp. 18–18, 1994.
[30] D. R. Jeffery, “A software development productivity model for mis environments,” Journal of Systems and Software, vol. 7, no. 2, pp. 115–125, 1987.
[31] L. R. Foulds, M. Quaddus, and M. West, “Structural equation modelling of large-scale information system application development productivity: the hong kong experience,” in Computer and Information Science, 2007. ICIS 2007. 6th IEEE/ACIS International Conference on. IEEE, 2007, pp. 724–731.
[32] C. Parnin and S. Rugaber, “Resumption strategies for interrupted programming tasks,” Software Quality Journal, vol. 19, no. 1, pp. 5–34, 2011.
[33] C. Parnin and R. DeLine, “Evaluating cues for resuming interrupted programming tasks,” in Proceedings of the SIGCHI conference on human factors in computing systems. ACM, 2010, pp. 93–102.
[34] S. Markos and M. S. Sridevi, “Employee engagement: The key to improving performance,” International Journal of Business and Management, vol. 5, no. 12, pp. 89–96, 2010.
[35] W. Snipes, A. R. Nair, and E. Murphy-Hill, “Experiences gamifying developer adoption of practices and tools,” in Companion Proceedings of the 36th International Conference on Software Engineering. ACM, 2014, pp. 105–114.
[36] J. S. Brown and P. Duguid, “Balancing act: How to capture knowledge without killing it.” Harvard business review, vol. 78, no. 3, pp. 73–80, 1999.
[37] M. London and J. W. Smither, “Feedback orientation, feedback culture, and the longitudinal performance management process,” Human Resource Management Review, vol. 12, no. 1,
pp. 81–100, 2002.
[38] T. Savor, M. Douglas, M. Gentili, L. Williams, K. Beck, and M. Stumm, “Continuous deployment at facebook and oanda,” in Proceedings of the 38th International Conference on Software Engineering Companion. ACM, 2016, pp. 21–30.
[39] R. J. Fisher, “Social desirability bias and the validity of indirect questioning,” Journal of consumer research, vol. 20, no. 2, pp. 303–315, 1993.
[40] J. M. Zelenski, S. A. Murphy, and D. A. Jenkins, “The happyproductive worker thesis revisited,” Journal of Happiness Studies, vol. 9, no. 4, pp. 521–537, 2008.
[41] S. Moser and O. Nierstrasz, “The effect of object-oriented frameworks on developer productivity,” Computer, vol. 29, no. 9, pp. 45–51, 1996.
[42] T. DeMarco and T. Lister, “Programmer performance and the effects of the workplace,” in Proceedings of the International Conference on Software Engineering. IEEE Computer Society
Press, 1985, pp. 268–272.
[43] M. Kersten and G. C. Murphy, “Using task context to improve programmer productivity,” in Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering. ACM, 2006, pp. 1–11.
[44] K. Petersen, “Measuring and predicting software productivity: A systematic map and review,” Information and Software Technology, vol. 53, no. 4, pp. 317–343, 2011.
[45] M. J. Melitz, “The impact of trade on intra-industry reallocations and aggregate industry productivity,” Econometrica, vol. 71, no. 6, pp. 1695–1725, 2003.
[46] M. N. Baily, C. Hulten, D. Campbell, T. Bresnahan, and R. E. Caves, “Productivity dynamics in manufacturing plants,” Brookings papers on economic activity. Microeconomics, vol. 1992, pp. 187–267, 1992.
[47] A. Kidd, “The marks are on the knowledge worker,” in Proceedings of the SIGCHI conference on Human factors in computing systems. ACM, 1994, pp. 186–191.
[48] G. K. Gill and C. F. Kemerer, “Cyclomatic complexity density and software maintenance productivity,” IEEE transactions on software engineering, vol. 17, no. 12, pp. 1284–1288, 1991.