Context Bridge — جسر السياق بين BA/PM والفريق التقني

Context Bridge — جسر السياق بين BA/PM والفريق التقني

المشكلة الحقيقية

المعلومة موجودة — لكنها تموت في الطريق.

BA يعرف: لماذا هذا الـ Feature مهم
PM يعرف: ما أولويات العميل
Dev يعرف: كيف يُبنى

لكن الثلاثة يعيشون في عوالم منفصلة.
النتيجة: Dev ينفذ بدون سياق — أو يسأل وقت غلط.

---

لماذا السياق لا يصل؟

الأسباب الشائعة في الفرق:

1. BRD مكتوب للـ BA — لا للـ Dev
   → مليء بمصطلحات business، خالٍ من سياق تقني

2. السياق يُشرح شفهياً في Refinement
   → يُنسى في اليوم التالي

3. "Dev لا يحتاج يعرف لماذا — فقط كيف"
   → ثقافة تُقتل فيها الـ Product Thinking

4. BA يكتب للـ System — Dev يبني للـ User
   → فجوة في الفهم من البداية

---

نموذج Context Card — بطاقة السياق

كل Story يجب أن تحمل Context Card:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🎯 CONTEXT CARD — [اسم الـ Story]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

👤 المستخدم الحقيقي:
الاسم/الدور: [مثال: سارة — مديرة عقود]
يومه الآن:  [كيف يعيش المشكلة يومياً؟]

😣 المشكلة التي يعيشها:
[جملتان بحد أقصى — بلغة إنسانية لا تقنية]

✅ كيف سيتغير يومه بعد هذه الـ Story:
[ماذا سيستطيع يفعل لم يكن يستطيعه قبل؟]

🔗 السياق التجاري:
[لماذا هذا مهم للـ Business الآن؟]

📊 مقياس النجاح:
[رقم واحد نعرف به أننا نجحنا]

⚠️ الافتراض الأكثر خطورة:
[ما الذي إذا كان خاطئاً يفشل كل شيء؟]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

---

متى تُكتب Context Card؟

من يكتبها:  BA أو PM
متى:        قبل Refinement بيوم على الأقل
أين تُحفظ:  في Jira Ticket (Description أو Custom Field)
من يراجعها: Tech Lead يتأكد أنها واضحة للـ Dev

القاعدة: إذا Dev لا يستطيع شرح "لماذا نبني هذا"
         بعد قراءة الـ Ticket — الـ Context Card ناقصة

---

Three Amigos بعقلية Product

الـ Three Amigos التقليدي:
BA + Dev + QA يتفقون على الـ AC

الـ Three Amigos بعقلية Product:
نفس الثلاثة + سؤال إضافي في البداية:

"قبل ما نتكلم عن الـ AC —
 من هو المستخدم الذي سيستخدم هذا؟
 ما المشكلة التي يحلها؟
 كيف نعرف أننا نجحنا؟"

هذا السؤال وحده يغير طبيعة النقاش كاملاً.

---

قنوات إيصال السياق للفريق

القناة 1 — Context Card في كل Ticket (دائم)
القناة 2 — "Story Intro" في أول دقيقتين من Refinement
           BA يشرح: من المستخدم؟ ما مشكلته؟
           قبل أي حديث تقني
القناة 3 — User Quote حقيقي في الـ Ticket
           "المستخدم قال: '...'" — جملة واحدة تكفي
القناة 4 — Sprint Goal مكتوب بلغة المستخدم
           لا: "إنهاء Feature X و Y"
           نعم: "سارة ستستطيع تعديل عقد في 3 دقائق"
القناة 5 — Review Demo من منظور المستخدم
           لا: "بنينا زر الحفظ"
           نعم: "سارة الآن تستطيع..."

---

كيف تبني العادة تدريجياً

الأسبوع 1-2: Context Card في Story واحدة فقط
→ اختبر الفكرة بأمان

الأسبوع 3-4: كل Story جديدة تحمل Context Card
→ BA يبدأ يكتبها بشكل عفوي

الشهر 2: Three Amigos يبدأ بالسؤال عن المستخدم
→ Dev يبدأ يسأل "لماذا" بشكل طبيعي

الشهر 3: Sprint Goal يُكتب بلغة المستخدم
→ الفريق كله يفكر بالـ Outcome

علامة النجاح الأولى:
Dev يرفض تقدير Story لأن Context ناقص

---

تكامل مع knowledge-base

إذا كان knowledge-base مفعّلاً:
/index-brd يحفظ السياق التجاري
Context Card تُشير له: "BRD-XXX القسم 3.2"

هذا يعني: Dev يستطيع يقرأ السياق كاملاً
           بدون أن يُزعج BA في كل مرة