مراحل تحليل وتصميم وبرمجة المنصة التعليمية

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

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

ما يخرج من كل مرحلة

التحليل: الفهم قبل البناء

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

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

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

تصميم التجربة

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

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

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

تصميم البنية

هذه المرحلة تقنية بحتة لكنها تحدد ما ستستطيع فعله لسنوات، وتستحق أسئلة منك وإن لم تفهم تفاصيلها.

واسأل عن: كيف ستتوسع البنية مع نمو المستخدمين؟ وأين تُخزَّن البيانات وكيف تُحمى؟ وكيف تُبنى التكاملات بحيث لا تنكسر مع التحديثات؟ وما التقنيات المستخدمة وهل تجد لها كفاءات في السوق؟

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

دورات التطوير

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

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

واستفد منها بحضور مراجعة كل دورة وتجربة ما سُلّم فعلًا لا مشاهدة عرضه. فالفارق بين مشاهدة عرض وتجربة النظام بيدك كبير، وما يظهر لك في عشر دقائق من التجربة لا يظهر في أي عرض تقديمي.

دورك في كل مرحلة

المشروع لا يمضي بلا مشاركة فعالة منك، وغيابك يُترجم إلى قرارات يتخذها المزود بافتراضاته.

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

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

التوثيق الذي يُسلَّم معك

النظام بلا توثيق أصل ناقص. فمن يخلفك في المهمة، أو أي جهة تتولى التطوير لاحقًا، تحتاج ما يشرح كيف بُني وكيف يُشغَّل.

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

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

أسئلة شائعة

الخلاصة

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

والقاعدة الجامعة: كل مرحلة تُصحَّح أخطاؤها بكلفة أقل مما يليها. فسوء الفهم في التحليل يُصلح بجملة، وفي التصميم بساعات، وفي البرمجة بأيام، وبعد الإطلاق بمشروع — ومن يستثمر انتباهه في المراحل المبكرة يشتري بذلك أرخص تأمين متاح.

الاختبار كمرحلة لا كخطوة

الاختبار يُعامل أحيانًا كخطوة أخيرة قبل التسليم، والصحيح أنه يجري مع كل دورة تطوير لا بعدها كلها.

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

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

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

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