Customer Empathy — فهم المستخدم الحقيقي

Customer Empathy — فهم المستخدم الحقيقي

المبدأ الجوهري

Dev لا يبني للكود — يبني للإنسان.
الإنسان الذي يستخدم ما تبنيه له اسم، له مشكلة حقيقية،
وله سياق لا تراه من وراء الـ Ticket.

---

أداة 1 — User Persona (ليست وثيقة — بل ذاكرة)

بدلاً من: "المستخدم يريد تعديل العقد"
فكّر في:

👤 سارة — مديرة عقود في شركة توريد
├── مهمتها: تعديل 15-20 عقد يومياً
├── ألمها: كل تعديل يحتاج موافقة من 3 أشخاص
├── خوفها: أن ترسل عقداً بنسخة قديمة
├── بيئتها: تشتغل على 3 نوافذ بنفس الوقت
└── مقياس نجاحها: لا أخطاء + سرعة التسليم

الفرق الذي يصنعه هذا:
قبل: "أضف زر حفظ"
بعد: "أضف تأكيد قبل الحفظ + تاريخ آخر تعديل بارز"
     لأن سارة تخشى الإرسال الخاطئ

---

أداة 2 — Jobs To Be Done (JTBD)

الناس لا يشترون المنتج — يستأجرونه لإنجاز مهمة.

القالب:
"عندما [السياق]، أريد [الإجراء]، حتى [النتيجة]"

مثال — نظام العقود:
عندما: "أتلقى طلب تعديل عاجل من العميل"
أريد:  "تعديل العقد وإرساله في أقل من 5 دقائق"
حتى:  "لا أضيع صفقة بسبب بطء الإجراءات"

ما يكشفه JTBD:
- السرعة أهم من الجماليات
- الخوف من الخطأ أكبر من الخوف من البطء
- الـ Notification للعميل جزء من القيمة — ليس اختيارياً

---

أداة 3 — Empathy Map

ما يقوله المستخدم:
"النظام معقد"

ما يفكر فيه (لا يقوله):
"أخشى أن أرتكب خطأ أمام مديري"

ما يشعر به:
إحباط + قلق

ما يفعله:
يتجنب النظام ويعمل على Excel

الفجوة التي يجب أن تسدّها:
ليس تبسيط الـ UI فقط — بل إزالة الخوف من الخطأ
(Undo، Preview، تأكيد قبل الحفظ)

---

أداة 4 — User Story Mapping

بدلاً من قائمة Stories منفصلة:
ارسم رحلة المستخدم كاملة

رحلة سارة في تعديل العقد:
[تلقي الطلب] → [فتح العقد] → [التعديل] → [المراجعة] → [الإرسال] → [التأكيد]

لكل خطوة اسأل:
- ما الذي يجب أن يعمل بشكل مثالي؟ (Must Have)
- ما الذي يجعلها أسرع؟ (Nice to Have)
- ما الذي يسبب الألم الآن؟ (Pain Point)

هذا يكشف:
Stories مخفية لم تكتبها أحد
Dependencies غير واضحة
الـ Feature الأهم فعلاً

---

كيف تُدخل Customer Empathy في الفريق

الممارسة 1 — "من هو سارة؟" في كل Refinement
قبل أي Story: "من المستخدم الذي سيستخدم هذا؟
               ما مشكلته الحقيقية؟"

الممارسة 2 — شارك قصصاً حقيقية
"هذا Bug — أفضى إلى خسارة عقد بـ X ريال"
"هذه الـ Feature — وفّرت على سارة ساعة يومياً"

الممارسة 3 — اعرض Session Recording أو Feedback حقيقي
حتى لو مرة في الشهر — شاهد الفريق معاً كيف يستخدم الناس المنتج

الممارسة 4 — "لماذا" كسؤال رسمي في Ticket
كل Ticket يجب أن يجيب: "لماذا يحتاج المستخدم هذا؟"