المقدمة

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

الإجابة الحاسمة: التطوير المدني ليس منصة للنسخة النهائية. جوهره هو «تطوير مسودة» يحوّل متطلبات المستخدمين إلى شكل يعمل فعليًا.

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


السلسلة كاملة


ما قيمة «تطوير المسودة»؟

غالبًا ما تُوصف التطبيقات أو الأدوات التي يصنعها العاملون عبر التطوير المدني بأنها «غير مكتملة» أو «خشنة». لكن تلك «الخشونة» هي موطن القيمة.

إبراز متطلبات المستخدمين بوضوح

تخيّل تطبيقًا لإدارة العملاء بناه قسم المبيعات باستخدام أداة قليلة الشفرة. سيعكس التطبيق مباشرة إحساسهم اليومي بما هو «مريح أو مزعج» في العمل.

  • درجة تفصيل حقول الإدخال
  • ما العناصر التي يجب أن تظهر في شاشة القائمة
  • مواضع الأزرار ومسارات الاستخدام الطبيعية

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

اكتشاف الأخطاء والنواقص مبكرًا

حين توجد مسودة تعمل يمكننا اكتشاف: «نحتاج إلى وظيفة بحث هنا»، أو «مسار الموافقات يجب أن يكون على مستويين لا ثلاثة».

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


فخ تحويل المسودة إلى إنتاج

مع ذلك لا يجوز تحويل المسودة إلى نظام إنتاج كما هي. فهناك فخاخ خطيرة.

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

إذًا «وجود قيمة للمسودة» لا يعني «جواز تشغيلها كأنها الإنتاج». سنكرر قصة «إكسل الإلهي» بحذافيرها إن فعلنا ذلك.


تقسيم الأدوار مع المتخصصين

كيف ينبغي التعامل مع مخرجات التطوير المدني إذن؟ الجواب واضح.

  • المستخدمون المدنيون = يرسمون المسودة: يحولون منظورهم اليومي إلى نموذج حي.
  • المتخصصون = يكتبون النسخة النهائية: يعيدون البناء بحيث يلبّي المتطلبات غير الوظيفية مثل التوسع والأمان والصيانة.

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

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


ما الذي يجب أن تحميه الحوكمة؟

لا يمكن للتطوير المدني أن يكون صحيًا دون قواعد مؤسسية واضحة.

  • التوضيح: ينص الدليل على أن «مخرجات التطوير المدني تبقى في خانة النماذج التجريبية ويُحدد نطاق استخدامها».
  • الجرد الدوري: وضع عملية دورية لتنظيف التطبيقات أو روبوتات RPA المهجورة والتخلص منها.
  • مسار الانتقال: إذا أثبتت المسودة فائدتها، تُسلَّم إلى قسم تقنية المعلومات لاستكمال النسخة النهائية قبل دخول الإنتاج.

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


خلاصة

التطوير المدني ليس «منصة سحرية تمكّن أي شخص من بناء النظام النهائي». لكن استخدامه كمسودة يقلل سوء الفهم والنواقص في تعريف المتطلبات، ويضمن انعكاس منظور المستخدمين بشكل كافٍ.

الإنتاج مسؤولية المتخصصين، والمسودة مسؤولية المواطنين. حين نحترم هذا التقسيم يتحول التطوير المدني من مصدر إرث سلبي إلى نقطة انطلاق لتحسين الإنتاجية.

المعنى الحقيقي للتطوير المدني هو «إتاحة تعريف المتطلبات بطريقة ديمقراطية». بهذا الفهم فقط يصبح التطوير المدني قوة مستدامة للمؤسسة.


المقال التالي: انحراف زاوية الرؤية يصنع الإرث السلبي بكميات ضخمة 6/7