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