Communication Skills — التواصل الفعّال كـ Delivery Lead

Communication Skills — التواصل الفعّال كـ Delivery Lead

---

إطار المحادثة الصعبة — SBI + Intent

S — Situation:  "في اجتماع Refinement أمس..."
B — Behavior:   "لاحظت أنك قاطعت QA 3 مرات..."
I — Impact:     "هذا جعل QA يتوقف عن المشاركة."
Intent:         "أريد أن أفهم وجهة نظرك."

❌ لا تقل: "أنت دائماً تسيطر على الاجتماعات"
✅ قل:     "في اجتماع أمس، لاحظت أن QA لم يكمل أفكاره ثلاث مرات، وأثّر هذا على مشاركة الفريق"

---

نموذج COIN للمحادثات الصعبة

C — Context:    اذكر السياق بدقة وبدون حكم
O — Observation: ما رأيته أو سمعته بالضبط
I — Impact:     ما أثره على الفريق / المشروع / الشخص
N — Next:       ماذا تريد أن يحدث بعد ذلك

مثال — Dev يرسل Code بدون Review:
C: "في آخر 3 Sprints..."
O: "لاحظت أن 4 PRs مُرسلة للـ Merge مباشرة بدون Approval"
I: "هذا أدى لـ Bug في Production الأسبوع الماضي وأخّرنا يوماً كاملاً"
N: "أريد نفهم لماذا يحدث هذا، وكيف نمنع تكراره"

---

التأثير على Management بلا سلطة رسمية

قاعدة: Management يتحرك بـ 3 أشياء فقط:
1. البيانات التي تؤثر على أهدافهم
2. المخاطر التي يخشونها
3. الحلول الجاهزة — لا المشاكل فقط

إطار رسالة لـ Management:
┌─────────────────────────────────────────────┐
│ الوضع الحالي: [خبر واحد بالأرقام]          │
│ التأثير على الهدف: [ربطه بأولويتهم]         │
│ الخيارات: A / B / C [مع trade-offs]         │
│ توصيتي: [خيار واحد + سببه]                  │
│ ما أحتاجه منك: [طلب محدد وقابل للتنفيذ]    │
└─────────────────────────────────────────────┘

مثال:
"Sprint Velocity انخفضت 30% (الوضع).
هذا سيؤثر على موعد التسليم Q2 (التأثير).
عندنا 3 خيارات: نضيف Dev، نقلص الـ Scope، أو نؤجل Release.
أوصي بتقليص الـ Scope في Feature X لأنها أقل أولوية.
أحتاج موافقتك اليوم حتى نعدّل الخطة مع PO."

---

أنماط التواصل الصعبة وكيف تتعامل معها

النمط 1: الشخص الدفاعي
───────────────────────
السلوك: يفسر كل Feedback كهجوم
التقنية: Validate أولاً، ثم اطرح السؤال
"أنا واضح إنك بذلت جهداً كبيراً في هذا.
ولدي سؤال — ما الذي كان يمكن أن يكون أفضل؟"

النمط 2: الصامت في الاجتماعات
────────────────────────────────
السلوك: لا يتكلم في المجموعة، لكنه يتذمر خارجها
التقنية: اسأله مباشرة + أعطِه وقتاً للتفكير
"أحمد، أنت الأقرب لهذا الموضوع — ما رأيك؟"
أو: "خليكم تفكروا دقيقتين وبعدين نشارك"

النمط 3: الـ Blocker — "مستحيل / لن يعمل"
──────────────────────────────────────────
السلوك: يرفض كل مقترح بدون بديل
التقنية: اسأل عن الشرط لا عن الاتفاق
"ما الذي يحتاج أن يتغير حتى يصبح ممكناً؟"

النمط 4: الـ People Pleaser
────────────────────────────
السلوك: يوافق على كل شيء ثم لا يُنفّذ
التقنية: احصل على التزام محدد + موعد
"رائع. بالضبط ماذا ستفعل؟ ومتى ستنتهي؟"

النمط 5: الخبير المتعجرف
──────────────────────────
السلوك: يرفض آراء الآخرين بسبب "خبرته"
التقنية: استخدم خبرته، لا تتحداها
"خبرتك في هذا مهمة. كيف تقترح أن نحل X؟"

---

Storytelling بالبيانات

البشر يتذكرون القصص — لا الأرقام.

إطار Data Storytelling:
1. الشخصية:    "الفريق / العميل / المشروع"
2. التحدي:     "واجهنا X"
3. البيانات:   "الأرقام تظهر Y"
4. القرار:     "لذلك قررنا Z"
5. النتيجة:    "وحققنا W"

بدلاً من: "Velocity انخفضت من 45 إلى 30"
قل: "كان الفريق ينجز 45 نقطة — ما يكفي لتسليم Feature X في الموعد.
في Sprint الأخير وصلنا 30 — والفجوة الـ 15 نقطة تعني تأخيراً بأسبوعين.
السبب: 3 Stories دخلت Sprint بدون DoR واضح.
الحل الذي طبقناه: Three Amigos في كل Refinement.
النتيجة المتوقعة: عودة الـ Velocity في Sprint القادم."

---

Psychological Safety — كيف تبنيه

5 سلوكيات تبنيه فوراً:

1. اعترف بعدم معرفتك أولاً
   "لا أعرف الإجابة — من يعرف أكثر مني هنا؟"

2. اشكر الأخطاء علناً
   "شكراً لرفعك هذا Bug مبكراً — هذا أنقذنا"

3. اسأل عن الرأي بدل الأمر
   "ما رأيكم قبل أن أشارككم فكرتي؟"

4. تحمّل المسؤولية عن أخطاء الفريق للخارج
   أمام Management: "هذا قصور في التخطيط — مسؤوليتي"
   للداخل: "ما الذي يمكننا تحسينه معاً؟"

5. افصل بين الشخص والفكرة
   "هذه الفكرة لا تناسب السياق الحالي"
   لا: "هذه فكرة غير ناضجة"