هل انتهى عصر البرمجة حقاً… أم بدأ عصر مطور المنتجات؟

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

ومع نجاح هذا النموذج داخل المصانع بدأت موجات متتالية من محاولات التحسين Continuous Improvement، لم يكن الهدف منها فقط زيادة الإنتاجية Productivity بل تقليل الاعتماد على العمال أنفسهم، فظهرت مفاهيم تحسين الجودة Quality Control وتقليل الهدر Lean Thinking، ثم توسعت الأتمتة Automation، لكن النتيجة لم تكن اختفاء دور الإنسان، بل انتقاله من التنفيذ إلى الفهم واتخاذ القرار Decision Making، ومع الوقت اتضح أن التحدي الحقيقي لم يكن في التنفيذ بقدر ما كان في التعقيد الكامن داخل الأنظمة Complexity.

هذا النموذج انتقل لاحقاً إلى عالم البرمجيات Software Engineering، فتم تقسيم العمل إلى أدوار منفصلة Product Manager و Developer و QA و DevOps، ولكل منهم مهامه ومسؤولياته، ولم يكن هذا لأن النموذج مثالي، بل لأنه كان حلاً عملياً لمشكلة حقيقية، وهي بطء كتابة الكود وصعوبة تحويل الأفكار إلى أنظمة. كان التخصص Specialization أنسب وسيلة لتسريع العمل، لكنه في جوهره كان حلاً مؤقتاً workaround وليس نموذجاً نهائياً، يزداد تعقيداً مع زيادة عدد الفريق وارتفاع مستوى التنسيق Coordination بينهم، ويتحول جزء كبير من العمل إلى انتظار بين مراحل الربط Integration بين مخرجات الفرق المختلفة.

ومع تطور البرمجة ظهرت محاولات متكررة لتقليل الحاجة إلى المطورين كما حدث في المصانع، بدءاً بلغة COBOL التي وعدت الـ business بإمكانية بناء الأنظمة بدون الحاجة إلى المبرمجين، مروراً بـ CASE Tools، ثم Visual Basic وبيئات Drag & Drop، وصولاً إلى Low-Code و No-Code، وكلها وعدت بجعل البرمجة أسهل، لكن النتيجة كانت واحدة: لم تختف الحاجة إلى المطور، لأن المشكلة لم تكن في Coding بل في تصميم وهندسة الأنظمة System Thinking و Architecture Design والقرارات المرتبطة بها.

هذا التخصص أدى أيضاً إلى إضعاف كثير من المبرمجين فنياً، فأصبح من الشائع أن يعمل Backend Developer دون فهم حقيقي للبنية التحتية Infrastructure، أو Frontend Developer دون فهم كاف لـ Data Modeling، وهو ما عزز النظرة إلى المبرمج كمنفذ أو عامل فقط يمكن استبداله بسهولة كأن البرمجيات هي خط إنتاج مثل المصانع، بينما البرمجيات بطبيعتها ليست كذلك، بل System مترابط، وكل قرار يؤثر في بقية الأجزاء.

استمر هذا النموذج لسنوات طويلة، كنا عالقين في Syntax و Coding، نترجم الأفكار إلى أوامر، ونقضي وقتنا في الImplementation، وهذا ما جعلنا نعمل كطبقة ترجمة Translation Layer بين الفكرة والتنفيذ.

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

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

وهذا ما عبر عنه Fred Brooks في مقالته No Silver Bullet بقوله:

The hard thing about building software is deciding what to say, not saying it.

أي أن الصعوبة في بناء البرمجيات تكمن في تحديد ما نريد قوله، وليس في قوله.

وهنا يظهر التحول الحقيقي، لم يعد النجاح في التخصص الواحد، بل في القدرة على الجمع بين العمق المعرفي والمهارات المختلفة Deep skills و Broad skills، لم يعد المطلوب مختص يعرف جزءاً واحداً فقط، بل Product Developer يفهم النظام بعمق، ويرى الصورة كاملة، يتعاطف مع المستخدم، يمتلك حساً تصميمياً، يستطيع التواصل مع أصحاب المصلحة stakeholders، يلاحظ ويحلل، يفهم المشكلة Problem Space، يصمم الحل، يبنيه، يطلقه، ويراقب نتائجه عبر Metrics و Logs و Feedback.

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

الخطر الآن هو لكل من يقتصر دوره على التنفيذ، سواء كان Coder أو Analyst، فهذه الأدوار بالشكل التقليدي لم تعد آمنة، لأن AI اليوم قادر على تنفيذ جزء كبير منها، والاستمرار في نفس هذا الدور دون تطوير سيؤدي إلى الاستبدال، والمشكلة ليست في AI، بل في محاولة البقاء في نفس النموذج القديم.

انتهى عهد ما كنا نسميه بالمبرمج Coder الذي يكتب الكود فقط وينتظر Jira Ticket، ثم ينتظر QA ليخبره إن كان الكود قد اجتاز الاختبارات أم لا، هذا الدور لم يعد كافياً اليوم، لأن القيمة لم تعد في التنفيذ، بل في اتخاذ القرار Decision Making، وفهم ما يجب بناؤه، وتحويله إلى أنظمة فعالة تخدم المستخدمين وتحمل المسؤولية عن نتائجها.

لطالما كان هذا هو الجزء الأصعب، واليوم أصبح هو الجزء الوحيد المهم.