الاكتشاف ومخرجات الـ BA

الهدف من مرحلة الاكتشاف هو استبدال الافتراضات بـ backlog مُحدَّد النطاق يمكن تقديره. إنها ليست “جمع متطلبات إلى ما لا نهاية” — تنتهي عند مخرج محدَّد، لا حين يتوقف العميل عن الكلام.

من الـ lead إلى backlog مُحدَّد النطاق

flowchart LR
  L["Lead / Sales"] --> D["Discovery kickoff<br/>with BA"]
  D --> A1["Problem statement"]
  D --> A2["MoSCoW scope"]
  D --> A3["User flows"]
  D --> A4["Lightweight SRS"]
  D --> A5["Risk register"]
  A1 --> X["Scoped backlog<br/>ready for estimation"]
  A2 --> X
  A3 --> X
  A4 --> X
  A5 --> X

المخرجات

المخرَج	ما الذي يُجيب عنه	المسؤول
Problem statement	لماذا يوجد هذا المشروع، ومن المستخدمون، وما شكل النجاح. صفحة واحدة.	BA
MoSCoW scope	Must / Should / Could / Won’t — يرسم أول خط صارم حول النطاق.	BA + العميل
User flows	الرحلات الأساسية، من شاشة إلى شاشة. diagram أولًا، لا نصًّا.	BA
Lightweight SRS	متطلبات وظيفية + قيود غير وظيفية (performance، security، تكاملات). ليست وثيقة من ٦٠ صفحة.	BA
Risk register	المجاهيل المعروفة، الاعتماديات على العميل، الأنظمة الخارجية، والافتراضات التي قد تُفسد التقدير.	BA + PM

معايير الخروج

يكون الاكتشاف مكتملًا عندما:

• يرتبط كل عنصر Must بعنصر backlog واحد على الأقل مكتوب وفق معيار الـ Definition of Ready.
• تُسجَّل الأسئلة المفتوحة كمخاطر أو افتراضات، لا أن تُترك ضمنيّة.
• يكون الـ backlog مُفصَّلًا بما يكفي لتُنتج مرحلة التقدير نطاق PERT.

تنبيه

“عقدنا اجتماعات كثيرة” ليس مخرجًا. إن تعذّر تقدير الـ backlog، فالاكتشاف لم ينتهِ.

الـ backlog وكل مخرجات الاكتشاف تعيش في Azure DevOps Boards — هذه الصفحة تصف النيّة، والـ Boards تحتفظ بالحالة. المحطة التالية: التقدير وتحديد النطاق.