المشكلة ليست في مهندسيك... بل في النظام الذي يجبرهم على العمل بهذه الطريقة

يوم لم يُنجز فيه شيء

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

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

انتهى اليوم… ولم ينجز شيئاً مما خُطط له.

المشكلة ليست في المهندس... بل في النظام

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

الإنتاجية لم تعد تعتمد على الكود فقط

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

تجربة المطوّر أصبحت مؤشر أداء حقيقياً

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

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

التكلفة التي لا تظهر في أي تقرير مالي

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

عندما يخترع المهندسون حلولهم الخاصة: Shadow DevOps

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

كل حل مؤقت يولّد تعقيداً جديداً

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

DevOps لا يتعلق بالأدوات... بل بإزالة الاحتكاك

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

أفضل بنية تحتية هي التي لا تراها

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

هكذا ننظر إلى الأمر في Let'sOps

ففي Let'sOps، ننظر إلى البنية التحتية بالطريقة نفسها. قبل اقتراح أي أداة أو تنفيذ أي مشروع، نبدأ بفهم رحلة المطور اليومية، ونحدد أين يضيع الوقت، وأين تتكرر العمليات اليدوية، وما الذي يمنع الفريق من العمل بالكفاءة التي يستحقها.

ومن خلال Ops Audit Sprint، نراجع البنية التحتية الحالية، ونكتشف نقاط الاحتكاك، ونضع خطة عملية لتحويلها إلى منصة تدعم النمو بدل أن تعيقه.

الخلاصة

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

والاستقالة ليست سوى آخر عرضٍ لمشكلة بدأت قبلها بوقت طويل.

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