النموذج التفاعلي قبل العقد: ماذا ترى ولماذا يوفر عليك

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

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

لماذا لا يكفي الوصف المكتوب وحده

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

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

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

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

ما هو النموذج التفاعلي

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

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

ما ليس هو النموذج

حتى تكون التوقعات واضحة من البداية:

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

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

لماذا يوفر عليكم

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

التعديل على الشاشة رخيص. التعديل نفسه في الكود مكلف.

وهذه ملاحظات معتادة تظهر عند مراجعة نماذج أنظمة العمليات، وليست من مشروع بعينه:

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

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

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

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

كيف تراجعون النموذج

لتستفيدوا من النموذج إلى أقصى حد:

1. شاهدوا الفيديو أولا، حتى تعرفوا المسار الذي بنيت حوله الشاشات.
2. افتحوا النموذج على الجوال، وتخيلوا طلبا حقيقيا من أمس: كيف وصل، ومن استلمه، ومتى أغلق. جربوا أن تمروا به في الشاشات.
3. أرسلوه إلى الأشخاص الذين سيستخدمون النظام فعلا، وليس إلى الإدارة فقط.
4. اكتبوا ملاحظاتكم مع اسم الشاشة التي تخصها، حتى لا تضيع.
5. ركزوا على المسار والمعلومات قبل الألوان والخطوط.

ماذا يحدث بعد النموذج

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

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

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

قائمة مراجعة قبل التوقيع

أجيبوا بنعم أو لا عن المشروع الذي تفكرون فيه:

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

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

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

مرتبط بهذا المقالديموهات