🌎 🌭 🚸 سبب بطء المطورين: المشكلات الشائعة وحلولهم 🖖🏻 🕶️ 🤚🏼

مرحبا يا هابر! أقدم لكم ترجمة المقال لماذا تكون فرق التطوير بطيئة: انحرافات وحلول برامج مشتركة بقلم إيريك إليوت.

إذا كنت تحب الاستماع أكثر من القراءة ، فبالتنسيق الصوتي ، تتوفر الترجمة على Yandex.Music و Apple Podcasts.

دعنا نلقي نظرة على أسباب حدوث اضطرابات في عملية تطوير البرامج ، وما يمكنك القيام به كمدير حيال ذلك. يمكن أن يكون هناك العديد من الأسباب ، لذا فإن قائمتنا ، بالطبع ، ستكون بعيدة عن أن تكون شاملة. بدلاً من ذلك ، سنركز على بعض المشكلات الأكثر شيوعًا :

توقعات غير واقعية
عدد كبير من التذاكر المفتوحة
نطاق المهام غير المنضبط
مراجعة كود التراكم
إعداد ضعيف
نضوب المطورين
البق
انقلاب الموظفين

التطور البطيء ليس جذر المشكلة. هذا عرض من المشاكل الأخرى المذكورة. في 100٪ من الحالات ، إذا كان فريق التطوير يعمل ببطء شديد ، فهذا خطأ من القائد. لكن الخبر السار هو أنه يمكنك إصلاحه. دعونا نلقي نظرة على كل عنصر من العناصر بمزيد من التفصيل لفهم ما يمكننا القيام به مع كل منها.

توقعات غير واقعية

لا تؤثر معظم مشكلات إنتاجية المطورين بشكل عام على التطوير نفسه. بل هي مشكلة تصورنا لعملية التنمية كمديرين وأصحاب مصلحة.

إن أصعب جزء من عمل المدير هو فهم أن كتابة التعليمات البرمجية تستغرق وقتًا طويلاً ومحاولة تسريع هذه العملية لن تؤدي إلا إلى إبطائها وزيادة عدد الأخطاء. الصبر هو كل شيء لدينا.

في معظم الأحيان ، لا تتمثل مشكلة سرعة العمل في أن الفريق ليس منتجًا بما فيه الكفاية ، ولكنه يواجه توقعات عالية. وهذه مسؤوليتك بالكامل. إذا كان الضغط يأتي من قيادة أعلى ، فأنت لم تشكل رؤيتهم الصحيحة للوضع. إذا جاء الضغط منك ، تابع القراءة.

غالبًا ما ننسى أن البرنامج الذي نقوم بإنشائه هو شيء جديد بشكل أساسي. إذا كان لديك بالفعل برنامج يقوم بنفس الشيء ، فقم بشرائه واستخدامه واستيراد الوحدة النمطية وما إلى ذلك. لا حاجة لإعادة كتابته من الصفر. البرنامج الجديد فريد من نوعه. يفعل شيئا جديدا أو يفعل شيئا مختلفا. ثم نقوم بإنشائه. وبما أننا لم نقم بذلك بعد ، فكيف نعرف كم سيستغرق الأمر؟

يبني البناؤون جدرانًا مسبقة الصنع بنفس الوتيرة ، وبالتالي يمكنهم إعطاء تقديرات دقيقة أكثر أو أقل بناءً على الملاحظات. ليس لدى مطوري البرامج بيانات موثوقة يمكن الاعتماد عليها. تتفاقم هذه المشكلة بسبب السرعات المختلفة للمطورين المختلفين ، ويمكن أن تختلف حسب الحجم.

كما كتب ستيف ماكونيل ، مؤلف كتاب The Perfect Code: "لقد أكدت العديد من الدراسات التي قام بها مطورو محترفون (Curtis 1981، Mills 1983، DeMarco and Lister 1985، Curtis et al. 1986، Card 1987 ، الاستنتاج بأن هناك اختلافًا كبيرًا بين إنتاجية المبرمجين المختلفين). ، Boehm and Papaccio 1988 ، Valett and McGarry 1989 ، Boehm et al.2000). ليس لدينا بيانات كافية للتنبؤ بالوقت الذي سيستغرقه استكمال مشروعنا. سنكتشف ما هو النطاق والتعقيد الذي بدأ العمل به بالفعل وهذه العملية غالبًا ما تكون محفوفة بالعديد من المفاجآت. "إن التنمية ليست فقط التخطيط ، ولكن أيضا البحث ، مهما حاولنا بعناية توقع كل شيء."

« 90 10 , . 10 90 »
— , Bell Labs

هناك عدة أسباب للتوقعات العالية التي يمكن للمدير التحكم بها. أحد الأسباب الأساسية هو قياس الأشياء الخاطئة.
قد تكون على دراية بالقول الشهير لبيتر دراكر: "ما يتم قياسه يتم التحكم فيه".

وبالطبع هذه نصيحة عظيمة. بالطبع يجب أن نقيس! لكننا نفتقد جوهر هذا الاقتباس ، علاوة على ذلك ، نقلب معناها رأساً على عقب.

الفكرة كلها هي: "ما يتم قياسه يتم التحكم فيه ، حتى لو تم قياسه ومحاولة التحكم فيه ، فهو عديم الفائدة تمامًا ، حتى لو كان يضر بأهداف المنظمة."

مثالان لأشياء لا تستحق القياس:

المخططات التنبؤية الاحترازية التي تظهر رسمًا بيانيًا لعدد التذاكر المفتوحة التي تتنبأ بتاريخ انتهاء المشروع بناءً على القياسات الأخيرة لسرعة العمل ؛
عدد التذاكر التي أغلقها المطور ، والتي توضح عدد المهام التي أكملها مطور فردي.

إن قياس هذين الشيئين يكلف الشركات خسائر لا حصر لها بسبب خسائر في الإنتاجية والموظفين والتكاليف الأخرى.

مخططات تقدم المهام

تحاول العديد من أدوات البرمجيات التنبؤ بتاريخ الانتهاء من المشروع ، بناءً على الحجم الحالي للمهام وسرعة العمل. المشكلة هي أنه لا أحد منهم يأخذ في الاعتبار الحجم غير المكتشف للمهام. علاوة على ذلك ، هذا مستحيل ، لأن الوقت الذي يستغرقه إغلاق مهمة واحدة يمكن أن يختلف بترتيب حجم المهام المختلفة ، مما يمكن أن يشوه بشكل كبير متوسط القيم التي تم حسابها للتذاكر المغلقة بالفعل.

إذا قمت بتعيين موعد نهائي بناءً على التاريخ من المخطط ، ففكر في أنك لم تلتزم بالمواعيد النهائية. الشيء الوحيد الذي يمكن أن ينقذك هو رمي أكبر عدد ممكن من المهام في المستقبل.

عندما تبني درجاتك على معلومات غير مكتملة ، ستدفع أنت وفريقك بالتأكيد مقابل ذلك. التقديرات غير الواقعية تخلق توقعات غير واقعية. يمكن أن يكون هذا كارثة حقيقية إذا شاركت أيضًا هذه التقييمات مع فريق التسويق والعملاء والصحافة.

ليست كل الرسوم البيانية شريرة. قد تكون تلك التي لا تحاول التنبؤ بالمستقبل مفيدة. يمكنهم تحذيرنا من انتشار المشروع والانفجارات التوافقية عندما ترى أن عدد التذاكر يزداد بدلاً من التناقص أو التحرك صعودا وهبوطا. توضح الرسوم البيانية المهمة للمهام بالفعل المهام الواقعية المغلقة بالفعل ، بدلاً من محاولة التنبؤ بالمستقبل.

المؤشر الجيد هو منحنى له صعود وهبوط ، ولكنه بشكل عام يتحرك للأسفل ، مما يظهر انخفاضًا في عدد المهام المفتوحة بحلول نهاية المشروع.

جدول المشروع حيث يتم تخفيض عدد التذاكر

سيتم عكس المشروع الذي يعاني من نطاق متزايد من منحنى ينحني إلى أعلى.

الجدول الزمني لمشروع غرق في مهام جديدة

ضع في اعتبارك أن الهدف من مراقبة هذا المنحنى ليس محاولة تغييره ، ولكن التعرف على المشكلات الأساسية وحلها. لا نريد أن يتوقف المبرمجون ببساطة عن فتح تذاكر جديدة.

الهدف هو شفافية العمليات ، وليس منحنى جميل إلى الأسفل.

احذر من مبدأ جودهارت : "إذا أصبح البُعد هدفًا ، فإنه يتوقف عن أن يكون مفيدًا".

ليس أي توقع ضار. عندما يكون لديك موعد نهائي صعب (على سبيل المثال ، تحاول إصدار لعبة قبل الجمعة السوداء) ، يمكنك التحكم في النطاق بشكل منهجي بناءً على متوسط سرعة العمل ، حتى تعرف متى تبدأ في تقليم النطاق. إذا أخبرتك التوقعات بأنك ستنتهي في موعد لا يتجاوز ديسمبر ، ثق بها. لقد حان الوقت لتحديد الأولويات والحد منها.

القاعدة الأساسية للتنبؤات من هذا النوع هي:
"إذا كان التنبؤ يقول أنه يمكنك القيام بشيء ما في تاريخ معين ، فلا تصدقه ، إذا قال أنه لا يمكنك فعله ، صدقه.

تم إغلاق التذاكر من قبل مبرمج واحد

إن فكرة إعادة سرد جميع المهام التي يقوم بها مبرمج واحد ، ثم مقارنة هذا الرقم بمتوسط القيمة هي فكرة مغرية للغاية. لكني أحثكم على مقاومة هذا الإغراء. هناك الكثير من الطرق الأفضل لجمع بيانات إنتاجية المطورين.

هناك عيبان أساسيان في حساب المهام المغلقة. أولاً ، المهام ليست متطابقة مع بعضها البعض في التعقيد والأهمية ، وفي الواقع ، تعتمد قيمة العمل على قانون السلطة. إن حفنة صغيرة من المهام تمثل ترتيبًا من حيث الأهمية أكثر من "المتوسط". إنه مثل الفرق بين أساس ناطحة سحاب وآخر مسمار مسدود. وبالتالي ، ببساطة من خلال حساب عدد التذاكر المغلقة ، من المستحيل معرفة قيمة الموظف بالضبط.

منذ سنوات عديدة ، عملت على سلة تسوق لرائد تجزئة عالمي. بمجرد أن توقفت عن كتابة الرمز وإغلاق التذاكر في Jira وأضفت تذكرة أخرى: "دراسة سهولة الاستخدام".

لقد عملت على إعادة تصميم سلة لأكثر من عام ، ويقترب تاريخ الإصدار بسرعة. حتى تلك اللحظة ، لم يجر المستخدم أي اختبار قابلية الاستخدام لعملية الطلب الجديدة ، لذلك استغرق الأمر أسبوعًا. منحنا الوصول المبكر إلى آلاف المؤيدين الأكثر ولاءً وقمنا بمقابلتهما لجمع التعليقات.

لقد قمت بتحليل النتائج ووجدت اتجاهًا مثيرًا للقلق في الاستطلاعات والسجلات: كان تكرار المستخدمين الذين يغادرون الموقع في مرحلة السلة مرتفعًا جدًا وتم التعبير عنه برقم من رقمين. كانت كارثة حقيقية قادمة! لذلك بدأت العمل وخططت لتسجيل اختبارات جديدة للاستخدام مع وجود شخصي. جلست النوبي خلف السلة الجديدة ، وأعطتهم بعض المهام وتركتهم وحدهم مع الموقع. لم أقل أي شيء ، لقد شاهدتهم للتو يستخدمون الواجهة الجديدة.

لاحظت أنه في عملية تقديم الطلب ، يواجه الأشخاص صعوبات في أخطاء النماذج. بالحصول على هذه البيانات ، قمت بتصحيح مشروعنا مفتوح المصدر قليلاً على github (دون الإشارة إلى أي شيء في Gira). بعد مرور بعض الوقت ، أجرينا اختبارًا آخر. أصبح المستخدمون أقل عرضة بكثير لمغادرة صفحة السلة: فرق الدخل للشركة هو مليون دولار شهريًا.

في هذه الأثناء ، أغلق زملائي 10-15 تذكرة. يمكنك أن تجادل بأنني يمكنني فقط الحصول على المزيد من تذاكر اختبار قابلية الاستخدام لتعكس الواقع. ولكن بعد ذلك ، سيكون علي عمل ألف تذكرة إضافية ، الأمر الذي سيسبب ضوضاء فقط ويتطلب الكثير من الوقت.

سبب آخر لعدم فعالية حساب التذاكر المغلقة هو أن أعضاء الفريق الأكثر فعالية هم أيضًا الأشخاص الذين يلجأ إليهم الجميع للحصول على المساعدة. إنهم يعرفون أكثر عن قاعدة التعليمات البرمجية ، أو أنهم مطورون رائعون ، أو لديهم مهارات تواصل متميزة. فهي تساعدك على اجتياز تراكم طلبات السحب ، ومراجعة رمز المبرمجين الآخرين ، وتدريب وإرشاد زملائك في الفريق. هم الأكثر إنتاجية في الفريق ، لأنهم يساعدون بقية الفريق على مضاعفة سرعة العمل. ربما التذاكر التي يغلقونها هي إنشاء أطر عمل أو مكتبات تزيد من إنتاجية الفريق بأكمله. يقومون بمعظم العمل بينما يحصل الباقون على التقدير.

إذا لم تكن حذرا، ثم اطلع على مساهمة أكثر مطوريك إنتاجية. أفضل طريقة لاكتشاف ما يفعله المبرمجون لمشروع ما هي سؤالهم. اسأل الفريق عمن يعتقدون أنه زميلهم الأكثر فائدة.

عادةً ما تختلف المعلومات التي تظهر في هذه الملاحظات اختلافًا كبيرًا عن البيانات التي يمكن الحصول عليها ببساطة عن طريق حساب عدد التذاكر.

اجمع بيانات الأداء ، ولكن لا تتعامل مع كل مطور بمقياس واحد. التطوير هو رياضة جماعية ويلعب كل مشارك في العملية دورًا فيه. لا توجد طريقة سحرية واحدة مناسبة لتقييم الجميع ، دون استثناء.

الكثير من المهام المفتوحة

قد يبدو الأمر بسيطًا - افتح تذكرة في أداة التتبع وتابع. لكن كل مهمة في المتعقب تتطلب دورة معالجة كاملة.

يجب فرزهم وتحديد أولوياتهم وتعيين فنان قبل أن يتمكن المطورون من البدء في تنفيذها. يتكرر هذا العمل في كل مرة يقوم فيها المطورون بإغلاق مهمة واحدة واختيار المهمة التالية. إذا كان لديك مدير مشروع أو خبير سكروم ، فإنهم يفعلون ذلك في كل مرة يعيدون فيها ترتيب قائمة المهام (التي تحدث عادة في بداية السباق أو مرة واحدة فقط كل أسبوعين).

ثم يحتاج المطور إلى الخوض في سياق المهمة ، وفهم جوهر المشكلة ، وتفكيك المهام المعقدة إلى مهام فرعية ، وعندها فقط يمكنك أخيرًا البدء في التنفيذ.

يعد إنشاء وقراءة التذاكر الكثير من العمل ، ولكنه يشبه وظيفة وهمية. هذه مهمة تعريفية. هي مطلوبة لبدء مهام حقيقية. في حد ذاتها ، لا قيمة لها. ويستغرق هذا وقتًا في كل مرة يختار فيها المبرمجون المهمة التالية. كلما قل عدد التذاكر في المرة الواحدة ، كان التتبع أفضل. كلما كانت المهام الأقل أولوية منخفضة معلقة في العمل المتراكم ، زادت فرصة اختيار المطور لمهمة ذات أولوية عالية.

إذا كان هناك خطأ ذكره مستخدم واحد فقط ، فما مدى أهميته بالنسبة لنا؟ لقد لمس شخصًا واحدًا ، ولكن هل لدينا أخطاء لاحظها المزيد من الناس؟ هل هناك أي ميزات جديدة ستكون أكثر فائدة من إصلاح هذا الخطأ؟
ربما نعم.

إزالة الضوضاء من تراكم. احذف ما لا تخطط للقيام به في المستقبل القريب.
إذا كان هذا مهمًا حقًا ، أضف لاحقًا عندما يكون هناك وقت لذلك.

حجم المهمة غير المنضبط

أحب أن أطلب من المطورين في فريقي تقسيم العمل إلى مهام يمكنهم إكمالها في يوم واحد. هذا أكثر تعقيدًا مما يبدو ، لأنه يتطلب القدرة على تقسيم المهام المعقدة إلى مهام صغيرة ، والتي يمكن أيضًا اختبارها بشكل منفصل عن بقية التطبيق.

مثال: أنت تقوم بعملية سحب جديدة على الموقع. لا تحتاج إلى مزج مكونات واجهة المستخدم وإدارة الدولة والتواصل مع الخادم في التزام عملاق واحد يتضمن 13 ملفًا ، وكلها مرتبطة ارتباطًا وثيقًا بقاعدة الشفرة الحالية ، لأن النتيجة ستكون طلب سحب ضخم يصعب مراجعته ودمجه.

بدلاً من ذلك ، ابدأ بوحدة حالة سلة من جانب العميل تم اختبارها بشكل مستقل وقم بطلب سحب لهذا. ثم قم ببناء واجهة برمجة تطبيقات الخادم وقم بعمل علاقات عامة منفصلة له أيضًا. ثم اكتب مكونًا لواجهة المستخدم من شأنه استيراد الحالة من الوحدة والتواصل مع واجهة برمجة تطبيقات الخادم. يمكن تقسيم كل من هذه المهام إلى مهام منفصلة ، على الرغم من أن كل هذا هو في الأساس ميزة واحدة كبيرة. كمكافأة ، يمكن أن تنتشر المهام بين العديد من المبرمجين وتسريع التطوير ، والاستفادة من حجم الفريق.

سيجعل مبدل الميزات هذه العملية أسهل وأكثر أمانًا ، مما يسمح لك بإيقاف الوظائف المتقدمة حتى تصبح جاهزة للتضمين في الإنتاج.

ملحوظة:لا تحاول القيام بذلك دون تغطية جيدة لاختبارات الدخان. يجب أن تكون قادرًا على التأكد من أنك لم تكسر أي شيء عن طريق نشر الميزات شبه النهائية. تأكد من التحقق من كيفية تشغيله وإيقافه.

تراكم المهام عن طريق مراجعة التعليمات البرمجية

عندما يبتدع المطورون أكثر مما يمكنهم ابتلاعه ، تكون النتيجة طلب سحب ضخم في انتظار المراجعة والتحقق.

هذه هي مرحلة التكامل في "التكامل المستمر" (CI). تكمن المشكلة في أنه كلما بقيت العلاقات العامة مفتوحة ، كلما تم قضاء المزيد من الوقت عليها. سيفتحه المطورون لمعرفة ما إذا كان بإمكانهم المساعدة في الحد منه. سيتركون التعليقات ويطلبون التغييرات وسيعود الطلب إلى المؤلف لإجراء التغييرات والموافقة على هذه التغييرات. في هذه الأثناء ، سيتحرك كل طلب السحب هذا بعيدًا عن الرئيسي.
عندما يعتاد العديد من المطورين على تنفيذ عمليات كبيرة جدًا ، يبدأ عدد طلبات السحب في النمو مثل كرة الثلج ويصبح التكامل أكثر تعقيدًا.

مثال: يُجري بوب تغييرات على ملف تحكمه جين أيضًا ، ولكن لم يتم رهنه بعد. يتم طلب بوب للسحب أولاً ويصبح PR Jane التزامًا أكثر من المعلم. الآن لا يمكنها الاحتفاظ بفرعها حتى تُصلح جميع النزاعات مع رمز بوب. اضرب هذه الحالة في عدد المبرمجين الذين يعملون بنفس الكود في مشروعك. تؤدي "الاختناقات المرورية" إلى زيادة الإجراءات.

نحسب عدد هذه الإجراءات في السيناريو القياسي:

يبدأ بوب وجين العمل في نفس الفرع (0 إجراءات)
يقوم بوب بإجراء التغييرات ويلتزم بفرعه. جين تفعل نفس الشيء (2 إجراءات)
يذهب رمز بوب لإتقان. تقوم جين بتنزيل تغييرات بوب وتكتشف وجود تعارض. تصحح ذلك وترتب النتيجة على خيطها. (3 إجراءات)
تفتح جين طلب سحب. تشير بوب إلى أن التغييرات التي أجرتها على رمزه ستكسر شيئًا لم تأخذها في الاعتبار. تقوم جين بإجراء التغييرات بناءً على تعليقات بوب وتقوم بتنفيذ الكود مرة أخرى (4 إجراءات)
دمج PR جين أخيرا. 4 إجراءات فقط.

ضع في اعتبارك الآن موقفًا تكون فيه عمليات التنفيذ أقل ، وستومض طلبات السحب بشكل أسرع:

يقوم بوب بتغيير طفيف ويقع رمزه في سيد (إجراء واحد)
تقوم Jane بتنزيل الإصدار الجديد من المعالج وكتابة التعليمات البرمجية الخاصة بها مع مراعاة تغييرات Bob. (2 عمل)
بما أن ارتكاب جين صغير أيضًا ، فإنه يتم احتجازه بسرعة في السيد. إجمالي إجراءين فقط.

عندما نقوم بإنشاء PRs صغيرة ، فإننا نقلل بشكل كبير من الحاجة إلى إعادة الشفرة ، والتي تنتج عن الصراعات وتعقيد التعليمات البرمجية.

إعداد ضعيف

صناعة تكنولوجيا المعلومات رهيبة من حيث التدريب والدعم. تقوم الجامعات بتدريس خوارزميات مدمجة بالفعل في مكتبات قياسية ويكتبها عدد قليل من المبرمجين من الصفر.

في حين يتم تجاهل أساسيات التنمية مثل مبادئ التجريد والاتصال والمشاركة والوحدات النمطية مقابل التصميم المترابط والعمل مع الوحدات وتكوين الوظائف وتكوين الأشياء وتصميم الأطر وبنية التطبيق. بسبب النمو الهائل للصناعة ، ما يقرب من نصف المطورين لديهم أقل من خمس سنوات من الخبرة ويعتقد 88 ٪ من المتخصصين أن التدريب لن يضرهم.

تعمل الفرق ببطء لأن لديهم فهمًا ضعيفًا لما يقومون به ولا أحد يريد تعليمهم.

مهمتنا كمديرين هي توظيف متخصصين ذوي خبرة يمكنهم توجيه فرقنا وتخصيص الوقت لهم للقيام بذلك.

ماذا يمكن ان يفعل:

مراجعة الكود: يتعلم المطورون الكثير من خلال تعلم كود بعضهم البعض
إنشاء أزواج من كبار المهندسين والصغار: ليس من الضروري إنشاء أزواج دائمة ، فإن اتحادًا لمرة واحدة لحل مشكلة معينة يعمل بشكل جيد.
وقت خاص مكرس للتوجيه: توظيف مهنيين ذوي خبرة يحبون التعلم والتواصل ومنحهم الوقت لتبادل الخبرات مع المطورين الصغار ، وهذا سيساعدهم على فهم كيفية تطوير مهاراتهم.

احترق

إن إحراق فريقك هو نكسة كبيرة للقائد من الفشل في الوفاء بالمواعيد النهائية.

الإرهاق مشكلة خطيرة يمكن أن تؤدي إلى فقدان المطورين ، دوران الموظفين ، تكاليف باهظة ، زيادة عامل الجهير ( عامل الحافلات - مقياس لتركيز المعلومات بين أعضاء المشروع الفرديين ؛ العامل يعني عدد المشاركين في المشروع ، بعد أن لا يمكن إكمال المشروع من قبل المشاركين المتبقيين) .

ولكن الأهم من ذلك أن الإرهاق يؤدي إلى مشاكل صحية. يمكن أن تؤدي عواقب الإرهاق إلى زعزعة استقرار الجسم وحتى الموت بسبب نوبة قلبية أو سكتة دماغية. في اليابان ، تنتشر هذه الظاهرة على نطاق واسع لدرجة أنها تحمل كلمة خاصة: "كاروشي".

يمكن للزعيم أن يحرق الفريق بأكمله ، مما يبطل إنتاجيته تمامًا. مشكلة حرق فرق بأكملها شائعة بشكل خاص في صناعة تطوير ألعاب الكمبيوتر ، حيث يكون Black Friday دائمًا موعدًا نهائيًا صعبًا.

لسوء الحظ ، "يموت ، ولكن افعل ذلك" هو مبدأ مشترك لتنظيم عمل هذه الفرق ، على الرغم من أن المديرين نادرا ما يدركون مخاطر مثل هذا النهج.

بدلاً من إجبار المطورين على العمل أكثر ، يجب أن يدرك المديرون أن 100٪ من مسؤولية الوفاء بالمواعيد النهائية تقع على عاتق الإدارة ، وليس المطورين.

الموعد النهائي أسهل إذا كنت تستخدم الأساليب التالية:

تحديد أولويات المهام بشكل أفضل وتقليل النطاقات
تبسيط العمليات
التعرف على الارتباك والتشويش على رمز إعادة التصنيع

انقلاب الموظفين

أظهرت البيانات التي جمعتها Linkedin في عام 2018 أن معدل دوران موظفي تكنولوجيا المعلومات يفوق ذلك في أي عمل آخر. وهذا أمر سيئ ، لأنه يسبب خطر عامل الجهير ، خطر فقدان المتخصصين الرئيسيين في مشروعك.

العديد من الشركات لا تعلق أهمية على الاحتفاظ المتخصصين. دعونا نلقي نظرة فاحصة على تكاليف دوران الموظفين.

تكليف الشواغر يكلف 15-30 ألف دولار. يكلف وقت المهندس ما متوسطه 90 دولارًا في الساعة. اضرب هذا في حوالي 50 مقابلة وساعات عديدة كثيرة للإجابة على أسئلة المبتدئ ومساعدته على التعود على الفريق. وهكذا ، فقد أنفقنا بالفعل 50 ألف دولار ، ولكن هذا ليس كل شيء.

قد يستغرق وصول الموظف الجديد إلى مستوى المطور الذي حل محله ما يصل إلى عام ، في المرة الأولى التي يرتكب فيها الكثير من الأخطاء ويقضي الكثير من الوقت في إصلاحها.

وبالتالي ، فإن توظيف وتدريب مطور جديد ، وتكاليف الفرصة الضائعة وفقدان إنتاجية الفريق الذي عليه تدريب مبتدئ لبعض الوقت وفي نفس الوقت تنفيذ جزء من عمله هو ما يقرب من 90 ٪ من راتب المطور الراحل. قد يستغرق البحث عن بديل عدة أشهر ، ومن ثم سيستغرق المبتدئ مزيدًا من الوقت لتحقيق فعاليته الكاملة.

كل هذا يستهلك الكثير من الوقت ، وتعاني فرق كبيرة باستمرار من العمل المستمر ، لأنه وفقًا لمسح أجرته شركة Stack Overflow عام 2019 ، قام 60٪ من المطورين بتغيير وظائفهم على مدار العامين الماضيين.

في الوقت الذي يبدأ فيه المطور أخيراً العمل بأقصى قدر من الكفاءة ، ستفقده.

كيف تتجنب السيولة؟ فيما يلي بعض النصائح من مصادر مختلفة:

ادفع بصدق
ارفع راتبك بانتظام
دع الناس يذهبون في إجازات طويلة
اعرض العمل عن بُعد
حافظ على التوقعات الواقعية
توفير المهام التي تهم المطور
لا تدع مكدس التكنولوجيا يصبح قديمًا جدًا
توفير التدريب وفرص العمل
توفير الفوائد الصحية
لا تجبر المطورين على العمل أكثر من 40 ساعة في الأسبوع
تزويد الموظفين بالمعدات الحديثة

البق

إذا كنت تعتقد أنه ليس لديك وقت لتنفيذ عملية تطوير عالية الجودة ، فلا يمكنك الاستغناء عنها حقًا.

وفقًا لتقييم تقنيات هندسة البرمجيات (David N. Card ، Frank E. Mc Garry ، Gerald T. Page ، 1978) ، يمكن للعمليات المحسنة بشكل جيد أن تقلل الأخطاء دون زيادة التكاليف. السبب الرئيسي هو أنه وفقًا لكتاب آخر ، "تقييمات البرامج ، والمعايير ، وأفضل الممارسات" (Casper Jones 2000) ، فإن اكتشاف العيوب وتصحيحها يعد من أكثر المهام التي تستغرق وقتًا طويلاً ومكلفة في التطوير.

تشتهر الأخطاء بإحداث الحاجة إلى معالجة التعليمات البرمجية ، وكلما وجدتها ، زادت تكلفة إصلاحها. عندما يُطلب من المطور إصلاح خطأ تم اكتشافه بالفعل في الإنتاج ، غالبًا ما يمزقه هذا مما كان يفعله. في كتاب "دراسة يومية لتبديل المهام وانقطاعها" (Mary Czerwinski ، Eric J. Horvitz ، Susan Wilhite) ، يقول أن المهمة التي يتم صرف انتباهنا عنها يمكن أن تستغرق ضعف الوقت وتحتوي على ضعف عدد الأخطاء ، مما يوحي أن الحشرات ذات الأولوية العالية معدية من بعض النواحي: من خلال إصلاح واحدة ، من المحتمل أن نولد ثغرات جديدة.

تتطلب الأخطاء في الإنتاج أيضًا أن نولي المزيد من الاهتمام للدعم وهم مزعجون ومتعبون للغاية ، مما سيكلفك في النهاية المال. سيكون عليك الاستثمار في إصلاح الوظيفة القديمة بدلاً من إنشاء وظيفة جديدة.

يمكن إصلاح الخلل الذي تم العثور عليه في مرحلة التطوير في غضون دقيقتين ، بينما يمر الخلل الموجود في الإنتاج عبر العديد من المراحل الإضافية: الإبلاغ عن خلل ، والتحقق ، وتحديد الأولويات ، وتعيين فنان ، وأخيرًا التطوير.

لكن هذا ليس كل شيء. سيكون لهذا الخطأ التزامه الخاص به ، وطلب السحب ، ورمز المراجعة ، والتكامل ، وربما حتى نشره الخاص. وفي أي مرحلة ، قد ينخفض بعض الاختبارات ويتعين بدء دورة CI / CD بأكملها من جديد.

كما ذكرنا سابقًا ، سيكلفك خطأ في الإنتاج أكثر بكثير من خطأ تم العثور عليه أثناء التطوير.

ستساعد النصائح التالية في تحسين جودة العملية.

تبطئ لتسريع. بطيء يعني متواصل ، غير متقطع يعني سريع.
قم بإجراء مراجعة للتصميم. يتيح لك الجمع بين التحقق من التعليمات البرمجية ومتطلباته اللحاق بما يصل إلى 70٪ من الأخطاء.
مراجعة الرمز البريدي. يسهل الحفاظ على التعليمات البرمجية التي تم اختبارها بنسبة 90٪. ساعة واحدة من المراجعة توفر لك 33 ساعة من الدعم. المبرمجون الذين يجرون مراجعات الكود أكثر إنتاجية بنسبة 20٪.
استخدم نهج TDD. أنه يقلل من عدد الأخطاء بنسبة 30-40 في المئة.
CI/CD. , , . , . CI/CD .
زيادة تغطية الاختبار . يجب أن تجري عملية CI / CD الخاصة بك اختبارات وتتوقف في حالة تعطل واحد على الأقل. سيساعد هذا على تجنب نشر الأخطاء في الإنتاج ويوفر لك الكثير من المال والوقت. هدفك هو تغطية 70٪ على الأقل ، لكن حاول البقاء على مقربة من 80٪. مع اقترابك من 100٪ ، ستلاحظ أن تغطية عمليات المستخدم المهمة بالاختبارات الوظيفية ستمنحك أكثر من زيادة أخرى في اختبارات الوحدات.

استنتاج

هناك العديد من الطرق للتأثير على أداء الفريق ، بما في ذلك:

ضع توقعات واقعية
تتبع عدد المهام المفتوحة وتحكم فيها
التحكم في أحجام المهام
لا تسمح بتراكم المهام من خلال مراجعة التعليمات البرمجية
تدريب المطورين
توفير توازن جيد بين العمل والترفيه
تنفيذ عمليات تطوير فعالة
انتبه للاحتفاظ بالموظفين

سبب بطء المطورين: المشكلات الشائعة وحلولهم