عندما استغرق نموذج بسيط 20 يومًا

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

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

بعد الدراسة الأولية، حددت مدة تنفيذ المشروع بـ 20 يوم عمل. فسألني المسؤول الفني في الشركة باستغراب:

«ألا تُعد 20 يومًا مدة طويلة لتصميم نموذج بسيط؟»

من ناحية معينة، كان محقًا؛ فإذا كان المطلوب مجرد تصميم نموذج بسيط، فإن 20 يومًا ستكون مدة طويلة. لكن ما يبدو في الظاهر نموذجًا بسيطًا كان يتضمن في الخلفية مجموعة من العمليات الفنية والأمنية وآليات التحكم.

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

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

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

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

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

ومن جهة أخرى، كان موضوع أمن المعلومات ذا أهمية كبيرة.

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

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

في لوحة الإدارة، كان بإمكان المسؤول المختص إدارة المعلومات المسجلة، وإدخال الرموز الجديدة، وفحص حالة الرموز، والاطلاع على الحالات الخاطئة أو المحظورة.

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

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

لذلك كان سؤال المسؤول الفني الأول منطقيًا تمامًا:

«أليست 20 يومًا مدة طويلة لتصميم نموذج بسيط؟»

وكانت إجابتي واضحة أيضًا:

«لو كان المشروع مجرد نموذج واحد، فنعم؛ لكنه لم يكن مجرد نموذج.»

الدرس الذي تعلمته من هذه التجربة

أوضحت لي هذه التجربة مرة أخرى نقطة مهمة:

المظهر البسيط للبرنامج لا يعني بالضرورة أن المشروع بسيط.

قبل تقدير الوقت والتكلفة، يجب دراسة العمليات التي تجري في الخلفية، والمتطلبات الفنية، والأمن، والبيانات، وسيناريوهات الأخطاء، والوظائف المطلوبة بشكل دقيق.

قد لا يرى العميل سوى صفحة واحدة، لكن خلف هذه الصفحة قد توجد عشرات العمليات والقواعد البرمجية.

من الأخطاء الشائعة في تقدير المشاريع البرمجية تقدير مدى تعقيد المشروع بناءً على ما يراه المستخدم في الواجهة فقط.

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

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