يؤثر أداء المطور بشكل مباشر على صافي أرباح الشركة. فإذا كانت فرق الهندسة بطيئة، فلن تتمكن الشركة من مواكبة المنافسة وستكون متأخرة عن المنافسة في توفير الميزات المبتكرة التي يطلبها المستهلكون.
عندما تصبح تحسينات التكلفة ضرورية، يتعين على قادة التكنولوجيا أن يقرروا من يبقى ومن يغادر. ومن المؤكد أنهم لا يريدون أن يطردوا عن طريق الخطأ أصحاب الأداء العالي الذين ربما لا يكونون صاخبين مثل بعض اللاعبين من الفئة ب. أو الأسوأ من ذلك، الاستغناء عن أشخاص بناءً على فترة عملهم فقط.
أخيرًا، يمكن أن يساعد قياس أداء المطور في اكتشاف عدم الكفاءة في تخصيص الموارد في وقت مبكر وتوزيع المهام بما يتناسب مع نقاط القوة لدى كل زميل في الفريق.
ولكن كيف يمكنك قياس شيء تجريدي ومعقد وإبداعي مثل تطوير البرمجيات؟ دعنا نكتشف ذلك.
تحديات قياس أداء المطور
سواء كنت تفكر دورا, فضاء, ماكينزيأو أي إطار عمل آخر، تذكر أنه قد لا يناسب مؤسستك تمامًا، خاصة وأن العديد من المهندسين إما غير ملمين به أو أجدهم غير فعالين.
التحدي الآخر في قياس أداء المطور هو إنشاء برمجة إن الأمر يتطلب جهدًا جماعيًا. وقد تفقد السياق الضروري عند استخدام DORA لقياس الأداء الفردي. كما يتعامل المطورون مع مهام متفاوتة التعقيد ــ يقوم البعض ببناء ميزات جديدة، بينما يتولى آخرون عمليات المراجعة والاختبار.
كلما قدمت مقياسًا، سيحاول الناس الحصول على درجة عالية فيه بأي وسيلة ممكنة. سيحاولون التلاعب بالنظام لأن لا أحد يريد أن يخسر مكافأة بسبب إحصائية غبية.
تجنب استخدام مقاييس الغرور
قد تدفع الشركات ثمنًا باهظًا بسبب التركيز على الأرقام الخاطئة – بدءًا من انخفاض معنويات الفريق إلى انخفاض كبير في الإنتاجية.
فيما يلي بعض الأمثلة على المقاييس الباطلة التي، بالإضافة إلى كونها غير مفيدة، يمكن أن تحفز السلوك الخاطئ:
-
ساعات العمل. إن مساواة ساعات العمل الطويلة بالإنتاجية يخلق ثقافة الإفراط في العمل و”العمل المزدحم” الذي لا معنى له. فالوقت المستغرق في العمل لا يترجم بالضرورة إلى إنتاج فعال.
-
أسطر من التعليمات البرمجيةعادةً ما يكون طول الكود علامة على رداءة الجودة. وإذا ربط القادة الأداء بأسطر الكود المكتوبة يوميًا، فإنهم بذلك يدفعون المطورين إلى الالتزام بالممارسات السيئة لتلبية مؤشرات الأداء الرئيسية الخاصة بهم.
-
التزامات الكود. مرة أخرى، لا تشير عمليات الالتزام الأكثر بالضرورة إلى كفاءة أكبر أو نتيجة أعمال إيجابية. قد يقوم المطورون عمدًا بإرسال تغييرات أصغر بشكل متكرر لخداع النظام أو التعجيل بعمليات الالتزام الخاصة بهم، متجاهلين جودة الكود.
-
تم إصلاح الأخطاء. ليست كل الأخطاء معقدة بنفس الدرجة. قد يختار بعض المطورين عمدًا أخطاءً يمكن إصلاحها بسهولة لزيادة أعداد الأخطاء مع إهمال المشكلات الأكثر صعوبة.
-
تردد النشر. على الرغم من أن تكرار النشر يعد مفيدًا لتقييم الفرق أو الأنظمة، إلا أنه يعتمد على مدى قيام كل شخص بدوره ولا يعد مؤشرًا موثوقًا به للأداء الفردي.
ما الذي يجب قياسه فعليًا؟
لا تبالغ في التفكير. اختر بعض المقاييس المعقولة واجمع بينها وبين البيانات النوعية المستمدة من الاجتماعات الفردية واستطلاعات التقييم الذاتي ومراجعات الأقران. في شركتنا، نكرر هذه العملية كل ربع سنة. سيكون لديك بيانات كافية لفهم مدى قدرة المطور على التعامل مع عبء العمل، ومدى مشاركته واستثماره، والمهارات التي يحتاجها للتحسين.
مواعيد الاجتماعات
قبل البدء في أي عملية برمجة، يقوم المطورون بتقدير المدة التي قد يستغرقها إنجاز ميزة معينة. وهذا مهم للغاية للتخطيط السليم للمشروع. ومع ذلك، إذا تأخر المطور باستمرار عن الالتزام بالمواعيد النهائية، فإنه يخلق عقبات ويطيل وقت طرح المنتج في السوق. إن النظر إلى البيانات التاريخية للمشاريع المماثلة يمكن أن يساعد مديري المشروعات على فهم ما إذا كانت المشكلة تكمن في التقديرات غير الدقيقة أو تباطؤ المطور.
جودة الكود
تؤثر جودة الكود بشكل كبير على ربحية الأعمال على المدى الطويل. من الصعب إعادة استخدام الكود المكتوب بشكل سيئ وسيتطلب إعادة هيكلة باهظة الثمن. أيضًا، قد يقضي الوافدون الجدد ساعات في فك شفرته، مما يبطئ تطوير الميزات. لمنع هذا، تجري الفرق مراجعات منتظمة بين الأقران أو تستأجر خبراء خارجيين التدقيق الشامل للكود.
يعد تتبع معدل الأخطاء (عدد الأخطاء التي تم العثور عليها أثناء الاختبار) طريقة أخرى لتحديد مشكلات جودة الكود. يكشف هذا المقياس، الذي يكون عادةً نسبة أو نسبة مئوية من الأخطاء لكل وحدة، مثل أسطر الكود، عن مشكلات محتملة في قاعدة الكود. يشير معدل الأخطاء المرتفع إلى مشكلات كبيرة، بينما يشير المعدل المنخفض إلى الاستقرار النسبي.
مهارات حل المشاكل
نظرا لوفرة مساعدو البرمجة المدعومون بالذكاء الاصطناعيإن كتابة أكواد عالية الجودة تتوافق مع معايير الصناعة أصبحت الآن أقل تحديًا بالنسبة للمطورين. تكمن القيمة الحقيقية للمطور في قدرته على حل المشكلات. هل يرفض التحديات بسهولة باعتبارها “مستحيلة”، أم يبحث بنشاط ويقترح حلولاً؟
التواصل والتعاون
المهندس ذو الأداء العالي هو الشخص الذي ينتج باستمرار أكوادًا عالية الجودة ويتعاون جيدًا مع بقية الفريق. وهو استباقي في التواصل بشأن المخاطر أو العوائق المحتملة، ويبادر إلى إدخال تحسينات على تنفيذ إحدى الميزات، ويشرح بوضوح لماذا قد يكون هذا النهج أفضل، وهو مستعد لدعم زملائه في الفريق لتحقيق نتيجة عالية الجودة.
الرضا الوظيفي والرفاهية
يتطلب تطوير البرمجيات، مثل أي وظيفة إبداعية أو متطلبة أخرى، العقلية الصحيحة. وبالتالي، ثقافة الفريقإن الأدوات والعوامل الأخرى تؤثر على إنتاجية المطور. فالمطورون المرهقون أو المشتتون أو غير المرتاحين هم أكثر عرضة للانخراط في “عمل سلبي” — عمل يتم تنفيذه بشكل سيئ للغاية بحيث يتطلب إصلاحًا كاملاً.
الأفكار النهائية
يجب استخدام قياس أداء المطورين لتحسين الأداء، وليس مقارنة مطور بآخر بناءً على مقاييسه. استخدمه لتحديد العوامل التي قد تؤدي إلى زيادة الإنتاجية أو انخفاضها. كما يجب أن يكون هناك جهد تعاوني بين المديرين والمطورين لإنشاء بيئة يمكن فيها لكل مطور أن ينجح ويساهم في نجاح الشركة.
