ابدأ بجرد ما تملكه، ثم أعد بناء نطاق المنتج من الرحلات وقواعد العمل والأدلة المتاحة. لا تبدأ بعدّ الشاشات أو قبول نسبة إنجاز متداولة. قد تبدو الواجهة مكتملة بينما تتوقف العملية عند موافقة الموظف، وقد تكون وظيفة مهمة موجودة لكن لم تُختبر أو لم يعرف الفريق كيف يصل إليها.
هذا العمل مختلف عن كتابة متطلبات تطبيق جديد. أنت تتعامل مع قرارات قديمة، ونسخ متعددة، ومعرفة موزعة بين أشخاص ووثائق وكود. الهدف من الاستعادة هو الوصول إلى خط أساس يمكن اعتماده: ماذا نحتاج فعلاً، ماذا ثبت أنه يعمل، ماذا لم يُفحص، وما القرار المطلوب قبل أي تقدير للاستكمال.
أمّن الوصول قبل إصدار الأحكام
اطلب قائمة الأصول من مالك المشروع: المستودع البرمجي، النسخة المنشورة، بيئة الاختبار، قاعدة بيانات تجريبية مناسبة، التصاميم، محاضر القرارات، ووثائق الخدمات الخارجية. سجّل صاحب كل أصل وصلاحية الوصول إليه. امتلاك رابط التطبيق لا يعني امتلاك الكود أو حساب النشر أو حق تعديل تكامل خارجي.
يجب أن يراجع الجانب التقني شخص مؤهل ومفوّض. إن تعذّر الوصول إلى المستودع، يمكن وصف السلوك الظاهر، لكن لا يمكن الجزم بقابلية صيانة الكود أو مقدار إعادة استخدامه. وإن كانت البيئة الوحيدة حية، فلا تنفّذ إجراءات قد تغيّر طلبات العملاء لمجرد إثبات وجود وظيفة. اتفق أولاً على طريقة اختبار مأمونة.
قبل بدء اكتشاف المنتج وتوثيق المتطلبات، عيّن شخصاً يملك اعتماد قواعد التشغيل. لا يستطيع المحلل أن يستنتج من زر «تأكيد» ما إذا كانت الموافقة ملزمة للعميل أو مجرد خطوة داخلية.
ابنِ جدولاً للرحلات لا معرضاً للشاشات
استخدم أربع خانات مستقلة لكل رحلة: السلوك المطلوب، السلوك المرصود، مصدر الإثبات، والحالة. ويمكن أن تكون الحالة: مثبت، مخالف، غير مختبر، أو قرار مفتوح. لا تضع «غير موجود» عندما لم تتمكن من الوصول، ولا «مكتمل» لأن الصفحة تفتح.
| البند | السؤال الذي يكشف النطاق |
|---|---|
| بداية الرحلة | من يبدأها، وبأي بيانات وصلاحية؟ |
| نتيجة الرحلة | ما الحالة التي يجب أن تصبح صحيحة في النهاية؟ |
| الاستثناء | ماذا يحدث عند التعارض أو الانقطاع أو رفض الطلب؟ |
| التشغيل | من يراجع النتيجة ويصلح الحالات العالقة؟ |
| الدليل | أي نسخة اختُبرت، وبأي حساب، وما الملاحظة المسجلة؟ |
يقدّم دليل GOV.UK معايير القبول بوصفها نتائج للتحقق من تلبية الحاجة. مرجع قصص المستخدم. استخدم هذا المبدأ لصياغة نتيجة قابلة للفحص، لا لإعادة وصف الشاشة بلغة أطول.
مثال افتراضي: بوابة لحجز قاعات التدريب
هذا مثال توضيحي، وليس مشروع عميل أو تقديراً لنسبة إنجاز حقيقية. تتسلم الشركة بوابة فيها صفحات للقاعات وطلب الحجز ولوحة موظف. الموجز السابق يقول «العميل يحجز القاعة»، لكن التشغيل الفعلي يشترط موافقة مسؤول الموقع.
أثناء المراجعة، يتبين أن إرسال الطلب يعمل في بيئة الاختبار، وأن الموظف يستطيع قبول الطلب. لا يوجد بعد دليل على منع طلبين متعارضين. أما رسالة التأكيد فتصل في تجربة واحدة فقط، ولا توجد ملاحظات عن فشل الإرسال. لا تختصر هذه النتائج بعبارة «باقي الإشعارات فقط».
يتفق مالك العملية على أن الإرسال ينشئ طلباً قيد المراجعة، وأن القبول وحده يحجز الفترة. تصبح معايير الاستكمال: لا يقبل النظام طلبين للقاعة والفترة نفسيهما؛ تظهر الحالة نفسها للعميل والموظف؛ يبقى الحجز محفوظاً عند فشل الإشعار؛ ويُسجّل من غيّر الحالة. هذه معايير تعليمية للمثال، ويجب تكييفها مع تشغيل المنشأة.
قد تكشف مراجعة تجربة وواجهة المستخدم مشكلة أخرى: تسمية الزر توحي بتأكيد فوري رغم أن العملية تحتاج مراجعة. هذا عيب في وضوح التجربة، بينما منع التعارض مسألة سلوك وظيفي. فصل النوعين يمنع معالجة المشكلة كلها بإعادة تصميم شكل الصفحة.
افصل النقص عن التغيير الجديد
أنشئ سجل قرارات يذكر تاريخ القرار وصاحبه ومصدره وأثره. إذا طلب الفريق دفعاً إلكترونياً لم يظهر في أي نطاق معتمد، فسجّله طلباً جديداً، لا عيباً مثبتاً في التسليم السابق. وإذا اختلفت المستندات، اعرض الاختلاف ليحسمه المالك بدلاً من اختيار الوثيقة الأكثر ملاءمة لتقديرك.
الاستعادة ليست حكماً تعاقدياً على الطرف السابق. يمكنها توثيق ما شوهد وما لم يتضح، أما تفسير الالتزامات والنزاعات فيحتاج مراجعة أصحاب الصلاحية والمختصين. هذا الفصل يحافظ على موضوعية التقرير ويجعل استخدامه عملياً لفريق التنفيذ التالي.
ماذا تطلب في تسليم مرحلة الاستعادة؟
اطلب خريطة رحلات وأدوار، وسجل أصول ووصول، ومصفوفة المطلوب مقابل المرصود، وقائمة قرارات مفتوحة، ومعايير قبول للجزء ذي الأولوية. ويجب أن يتضمن التقرير حدود الفحص: الأنظمة التي لم تتوفر، والحالات التي لم تُجرّب، والنسخة التي بُنيت عليها الملاحظات.
يمكن بعدها تحديد نطاق تطوير التطبيقات للاستكمال أو التعديل، مع افتراضات واضحة لا موعد نهائي غير مدعوم. ويحوّل اختبار وضمان جودة البرمجيات المعايير المعتمدة إلى حالات تحقق وأدلة استلام، بدلاً من الاعتماد على العرض التوضيحي وحده.
قبل اعتماد المرحلة، تحقّق من الآتي:
- كل وظيفة ذات أولوية مرتبطة بمستخدم ونتيجة، وليس باسم شاشة فقط.
- كل حكم على السلوك له دليل أو وسم واضح بأنه غير مختبر.
- القرارات الجديدة منفصلة عن العيوب والافتراضات القديمة.
- صاحب القرار التقني وصاحب القرار التشغيلي معروفان.
- التقدير التالي يذكر الاعتماديات وما الذي قد يغيّره.
أسئلة شائعة
هل يلزم استلام كل الكود قبل بدء العمل؟
يمكن بدء جرد المستندات والرحلات بدونه، لكن تقييم قابلية الاستكمال تقنياً يظل ناقصاً. اذكر هذا القيد صراحة ولا تحوّله إلى استنتاج بأن إعادة البناء واجبة.
هل عدد الشاشات مؤشر مناسب للإنجاز؟
هو وصف لحجم الواجهة فقط. شاشة واحدة قد تتضمن صلاحيات وتعارضات وحالات فشل أكثر من مجموعة صفحات عرض ثابتة. اطلب تقدماً مرتبطاً برحلات مقبولة.
ماذا نفعل إذا لم يعد الفريق السابق متاحاً؟
استخدم الأصول المصرّح بها وملاحظات أصحاب العملية، وسجّل ما تعذر التحقق منه. لا تعوّض غياب المعرفة بافتراض أن السلوك الحالي هو السلوك الصحيح.
هل نحصل على سعر نهائي بعد الاستعادة مباشرة؟
يمكن أن يصبح التقدير أوضح، لكن دقته تتوقف على ما حُسم من وصول وتكاملات وقرارات. قد تبقى تجربة تقنية صغيرة مطلوبة قبل الالتزام بالتنفيذ.
ابدأ بطلب مرحلة استعادة محددة المخرجات، وأرفق ما تملكه بالفعل وما ينقصك من وصول. بهذه البداية تستطيع مناقشة الاستكمال على أساس قابل للمراجعة.
مصدر المنهج
- GOV.UK: كتابة قصص المستخدم ومعايير القبول. مرجع منهجي، وليس اشتراطاً تنظيمياً سعودياً.
