ماذا تبني قبل أن تبنيه؟ اكتشاف المنتج Product Discovery

في مقال إدارة المنتج قلنا إن عمل مدير المنتج أن يكون ما يبنيه الفريق يستحق البناء، فكيف تعرف ذلك قبل أن تبنيه؟ الطريقة المعتادة في أغلب الفرق أن تبني الميزة كاملة ثم تطلقها ثم تنتظر، وإذا لم يستخدمها أحد فقد ضاع شهر أو ثلاثة من عمل فريق كامل، ثم تبقى الميزة في الكود سنوات لأن أحداً لا يجرؤ على حذفها. واكتشاف المنتج Product Discovery هو مجموعة الممارسات التي تجيب عن هذا السؤال بأرخص طريقة ممكنة: مقابلات ونماذج أولية وتجارب صغيرة تقتل أغلب الأفكار الضعيفة في أيام، قبل أن تأكل أسابيع من التطوير.

ودليل الخدمات الحكومية البريطاني يقول هذا صراحة في صفحة How the discovery phase works: لا تبدأ في بناء الخدمة أثناء مرحلة الاكتشاف Discovery Phase، والمدة المعتادة لها من 4 إلى 8 أسابيع، وإذا انتهى الاكتشاف بقرار عدم البناء فهذه نتيجة مفيدة وليست فشلاً. وسوف نناقش في هذا المقال ما يلي:

• الفرق بين مساحة المشكلة ومساحة الحل، وفكرة المهام التي يوظف المستخدم المنتج لإنجازها Jobs To Be Done.
• كيف تجري مقابلة مع مستخدم User Interview تخرج منها بحقائق لا بمجاملات، مع قالب جاهز.
• المخاطر الأربع Four Big Risks التي يختبرها الاكتشاف، وخريطة الافتراضات Assumption Map لتختار ما تختبره أولاً.
• التجارب من الأرخص إلى الأغلى: النموذج الأولي Prototype، والباب الوهمي Fake Door، واختبار A/B مع حساب حقيقي لحجم العينة.
• المسار المزدوج Dual-Track Agile، ثم مثال كامل على مشروع العيادة الذي استخدمناه في المثال العملي للمتطلبات.

مساحة المشكلة Problem Space ومساحة الحل Solution Space

أغلب الطلبات تصل في صورة حل: «نبغى تطبيق جوال»، «نبغى تصدير Excel»، «نبغى إشعارات». وقد شرحنا في هندسة المتطلبات كيف تسأل «لماذا؟» حتى تصل من الحل إلى الحاجة. والاكتشاف يأخذ هذه الفكرة خطوة أبعد، فيقسم العمل إلى مساحتين: مساحة المشكلة، وفيها تفهم من يعاني، وكم مرة، وماذا يفعل اليوم ليتجاوز المشكلة، وكم تساوي عنده، وتنتهي ببيان مشكلة Problem Statement واحد واضح. ثم مساحة الحل، وفيها تفكر في أكثر من حل لنفس المشكلة، وتختبرها برخص، ثم تبني الحل الذي نجح. والصورة التالية تبين المساحتين والطريق المختصر الذي يتجاوزهما:

وقد يتساءل البعض: أليس هذا ما يفعله محلل المتطلبات Requirements Analyst؟ والإجابة أن هناك تداخلاً كبيراً، والفرق في السؤال: هندسة المتطلبات Requirements Engineering تسأل «ما الذي يجب أن يفعله النظام بالضبط؟» بعد أن تقرر بناءه، والاكتشاف يسأل قبلها «هل نبنيه أصلاً، وأي حل منه؟»، ولذلك تستخدم الممارستان نفس الأدوات أحياناً، مثل المقابلة والنموذج الأولي، لأغراض مختلفة.

المهمة التي يوظف المستخدم المنتج لإنجازها Jobs To Be Done

من أشهر الأفكار في مساحة المشكلة فكرة Clayton Christensen من Harvard Business School أن الناس لا يشترون المنتجات، وإنما «يوظفونها» لإنجاز مهمة في حياتهم. والقصة التي تشرحها كما ترويها مقالة HBS Working Knowledge سنة 2011 أن سلسلة مطاعم أرادت زيادة مبيعات الحليب المخفوق Milkshake، فسألت أشخاصاً يشبهون عملاءها المعتادين عن صفات الحليب المخفوق المثالي، وعدلت المنتج بحسب إجاباتهم، ولم تتغير المبيعات. ثم قضى أحد زملاء Christensen يوماً كاملاً في المطعم يسجل من يشتري ومتى، فوجد أن 40% من المبيعات في الصباح الباكر، لأشخاص يأخذونها معهم إلى السيارة، ولما سألهم تبين أنهم «يوظفونها» لمهمة واحدة: طريق طويل وممل إلى العمل، ويد فارغة، وجوع سيأتي قبل الظهر، والمنافس الحقيقي لها لم يكن حليباً مخفوقاً آخر، وإنما الكعك والموز. ويشرح مقال Know Your Customers' Jobs to Be Done في Harvard Business Review سنة 2016 الفكرة نفسها بتفصيل أكبر.

وفي مثال العيادة، المريض لا يريد «نظام حجز»، وإنما يريد أن يعرف أن لديه موعداً مؤكداً في وقت يناسبه، دون أن يتصل في وقت الدوام وينتظر، والمنافس الحقيقي للنظام هو الهاتف ورسالة واتساب للاستقبال، وليس نظام حجز آخر. وهذا يغير ما تقيسه: النجاح ليس عدد الحجوزات في النظام، وإنما أن تنخفض المكالمات، وأن يحضر المريض في موعده.

في مقابلات العملاء Customer Interviews اسأل عن الماضي لا عن المستقبل

الحل البسيط أن تشرح فكرتك للعميل ثم تسأله: «هل ستستخدم هذا؟». وهذا يفشل في كل مرة تقريباً، والسبب أن الناس مهذبون، فيقولون «فكرة رائعة» حتى لا يحرجوك، ويتوقعون سلوكهم في المستقبل بشكل أفضل مما سيكون. ويسمي Rob Fitzpatrick هذا في كتابه The Mom Test مشكلة أن الجميع يكذب عليك بلطف، وفكرة الكتاب أن تسأل أسئلة لا يستطيع أحد أن يكذب عليك فيها حتى أمك: أسئلة عن حياة الشخص وما فعله فعلاً في مرة محددة في الماضي، لا عن رأيه في فكرتك ولا عما سيفعله في المستقبل. ويقول دليل هندسة المنتج في PostHog في صفحة Product engineering نفس الشيء بسؤال واحد يستخدمه مهندسوها: «هل حاولت أن تحل هذه المشكلة من قبل؟ ماذا فعلت؟».

والفرق بين السؤالين واضح في الجدول التالي:

وقد شرحنا في خطة المقابلات قالباً لجمع المتطلبات بعد أن تقرر البناء، أما القالب التالي فهو لمقابلة الاكتشاف، وهدفه أن تتحقق هل المشكلة حقيقية ومهمة عند هذا الشخص، ولا يذكر الحل إلا في آخر دقائق إن ذكره أصلاً:

# دليل مقابلة اكتشاف (30 دقيقة)
المشكلة التي نتحقق منها: ............................
الشخص: ............  نوعه: (مريض / استقبال / طبيب / مالك)
المقابل: ............  من يكتب الملاحظات: ............

## 1. السياق (5 دقائق)
- صف لي آخر أسبوع لك له علاقة بـ [المواعيد / الحجز].
- من غيرك يشارك في هذا؟

## 2. آخر مرة حدثت فيها المشكلة (10 دقائق)
- احك لي عن آخر مرة [فاتك موعد / ألغيت موعداً]. متى كان ذلك؟
- ماذا فعلت بالضبط؟ ومن كلمت؟ وكم أخذ من وقتك؟
- ماذا حدث بعدها؟

## 3. الحلول الحالية (7 دقائق)
- هل حاولت أن تحل هذا من قبل؟ ماذا جربت؟
- ماذا تستخدم الآن (تقويم الجوال، منبه، ورقة، تطبيق آخر)؟ لماذا هذا؟
- هل دفعت شيئاً، مالاً أو وقتاً، لتحل هذه المشكلة؟

## 4. الأهمية (5 دقائق)
- كم مرة يحدث هذا في الشهر تقريباً؟
- لو اختفت هذه المشكلة غداً، ما الذي سيتغير عندك؟

## 5. الإغلاق (3 دقائق)
- من غيرك يجب أن أكلمه عن هذا؟
- هل يمكنني أن أعود إليك بعد أسبوعين لأريك شيئاً صغيراً؟

## ملاحظات بعد المقابلة (يكتبها الفريق خلال ساعة)
- حقائق عن الماضي (ماذا حدث فعلاً):
- الحلول الحالية وكلفتها:
- مجاملات وآراء عن المستقبل (لا تحسب كدليل):
- التزام فعلي (وافق على موعد ثان، عرفنا على شخص، طلب أن يجرب):

في القالب أعلاه لاحظ التالي:

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

المخاطر الأربع Four Big Risks التي يختبرها الاكتشاف Discovery

بعد أن تعرف أن المشكلة حقيقية، يبقى السؤال عن الحل، ويقسم Marty Cagan في مقال The Four Big Risks سنة 2017 ما يمكن أن يفشل فيه أي حل إلى أربعة مخاطر، ولكل منها مسؤول في الفريق:

• خطر القيمة Value Risk: هل سيستخدمه المستخدمون أو يشترونه؟ وهو أكثر خطر تفشل فيه المنتجات، وأكثر خطر يتجاهله الفريق لأنه متحمس للفكرة.
• خطر قابلية الاستخدام Usability Risk: هل يستطيع المستخدم أن يفهم كيف يستخدمه دون شرح؟
• خطر إمكانية البناء Feasibility Risk: هل يستطيع المهندسون بناءه بالوقت والمهارات والتقنية المتاحة؟ ولهذا السبب يجب أن يكون مهندس في الاكتشاف من أوله.
• خطر جدوى العمل Business Viability Risk: هل يناسب بقية جوانب العمل، من التكلفة والمبيعات إلى الأنظمة والامتثال؟ ففي مثال العيادة، إرسال بيانات المرضى إلى مزود رسائل خارج المملكة سؤال جدوى قبل أن يكون سؤالاً تقنياً، وقد ذكرنا في المثال العملي ما يقوله نظام حماية البيانات الشخصية عن نقل البيانات.

ماذا تختبر أولاً؟ خريطة الافتراضات Assumption Map

كل فكرة تقوم على افتراضات Assumptions، وأغلبها لا يكتبها أحد. وطريقة خريطة الافتراضات Assumptions Mapping التي يشرحها كتاب Testing Business Ideas لDavid J. Bland وAlexander Osterwalder بسيطة: تكتب كل افتراض على ورقة، ثم تضعه على محورين: الأول أهميته Importance، أي لو كان خاطئاً هل يسقط المشروع؟ والثاني الدليل Evidence، أي هل لديك دليل عليه أم لا. والافتراضات في المربع المهم الذي لا دليل عليه هي ما تختبره أولاً:

ولاحظ أن «المرضى سيحجزون من الإنترنت بدل الاتصال» افتراض قيمة، وأنه في أعلى القائمة رغم أن الجميع «متأكد» منه، والسبب أن التأكد ليس دليلاً، وفي مقابلات المثال العملي قال أربعة من خمسة مرضى إنهم يفضلون الحجز من الجوال، وهذا رأي عن المستقبل وليس سلوكاً، لذلك يبقى في المربع الأحمر حتى يختبر.

التجارب Experiments من الأرخص إلى الأغلى

لكل سؤال تجربة تناسبه، والقاعدة أن تصعد في السلم بقدر ما يحتاج السؤال فقط، والسبب أن كل درجة أغلى من التي قبلها في الوقت والمال، والصورة التالية تبين الدرجات الأربع:

• المقابلات Interviews: شرحناها أعلاه، وتجيب عن خطر القيمة في مساحة المشكلة.
• اختبار النموذج الأولي Prototype Test: شاشات رمادية أو نموذج تفاعلي، وقد شرحنا طريقة عرضه في النموذج الأولي منخفض الدقة، أي أن تعطي الشخص مهمة وتصمت وتراقب. وهو يجيب عن خطر قابلية الاستخدام، ويمكن بناؤه في Penpot أو على الورق.
• الباب الوهمي Fake Door: زر أو رابط لميزة غير موجودة بعد، مثل «ادفع الآن» في صفحة الحجز، تقيس كم شخصاً يضغط عليه، وعندما يضغط تظهر له رسالة صريحة أن الميزة قادمة مع خيار أن يبلغ عند إطلاقها. ولا تقم بأخذ بيانات دفع أو وعود لا تستطيع الوفاء بها، والسبب أن ثقة المستخدم أغلى من أي تجربة، وأخف شكل لهذا الاختبار أن تضع الزر خلف Feature Flag لنسبة صغيرة من المستخدمين.
• اختبار A/B: تقسم المستخدمين عشوائياً إلى مجموعتين، وترى نسخة مختلفة لكل مجموعة، وتقارن مقياساً واحداً Metric. وهو أقوى دليل على أن التغيير سبب النتيجة، ولكنه يحتاج إلى عدد كبير من المستخدمين، وهذا ما يغفل عنه أغلب من يبدأ به.

كم مستخدماً يحتاج اختبار A/B؟ حساب حجم العينة Sample Size

لنفرض أن 50% من العيادات الجديدة تحجز أول موعد خلال أسبوع من التسجيل، ونريد أن نعرف هل قائمة خطوات البداية Onboarding Checklist ترفع هذه النسبة. كم عيادة نحتاج في كل مجموعة؟ هذا يعتمد على أربعة أشياء: النسبة الحالية، وأصغر فرق تريد أن تكتشفه Minimum Detectable Effect، ومستوى الدلالة Significance Level وهو في العادة 5%، أي احتمال أن تظن أن هناك فرقاً وهو غير موجود، وقوة الاختبار Statistical Power وهي في العادة 80%، أي احتمال أن تكتشف الفرق إذا كان موجوداً فعلاً. والسكربت التالي يحسبها بنفس المعادلة التي يستخدمها حاسب Evan Miller المشهور:

// stats.mjs: sample size for comparing two conversion rates, and a two-proportion z-test.
// z values: 1.959964 for a two-sided 5% significance level, 0.841621 for 80% power.
const Z_ALPHA = 1.959964, Z_BETA = 0.841621;

// the same formula as Evan Miller's calculator: baseline p1, the rate you want to detect p2
function sampleSize(p1, p2) {
    const d = Math.abs(p2 - p1);
    const a = Z_ALPHA * Math.sqrt(2 * p1 * (1 - p1));
    const b = Z_BETA * Math.sqrt(p1 * (1 - p1) + p2 * (1 - p2));
    return Math.ceil(((a + b) / d) ** 2);
}

// normal CDF (Abramowitz and Stegun 26.2.17)
function phi(z) {
    const t = 1 / (1 + 0.2316419 * Math.abs(z));
    const p = 0.3989423 * Math.exp(-z * z / 2) * t * (0.3193815 + t * (-0.3565638 + t * (1.781478 + t * (-1.821256 + t * 1.330274))));
    return z > 0 ? 1 - p : p;
}
function zTest(x1, n1, x2, n2) {
    const p1 = x1 / n1, p2 = x2 / n2, p = (x1 + x2) / (n1 + n2);
    const z = (p2 - p1) / Math.sqrt(p * (1 - p) * (1 / n1 + 1 / n2));
    return { p1, p2, z, pValue: 2 * (1 - phi(Math.abs(z))) };
}

const [cmd, ...a] = process.argv.slice(2);
if (cmd === 'size') {
    const [p1, p2] = a.map(Number);
    console.log(`baseline ${(p1 * 100).toFixed(0)}% -> ${(p2 * 100).toFixed(0)}%: ${sampleSize(p1, p2)} users per group (alpha 5% two-sided, power 80%)`);
} else if (cmd === 'ztest') {
    const [x1, n1, x2, n2] = a.map(Number);
    const r = zTest(x1, n1, x2, n2);
    console.log(`A ${x1}/${n1} = ${(r.p1 * 100).toFixed(1)}%  B ${x2}/${n2} = ${(r.p2 * 100).toFixed(1)}%  z = ${r.z.toFixed(2)}  p-value = ${r.pValue.toFixed(5)}`);
}

ونشغله في Container من Node.js دون أن نثبت شيئاً على الجهاز، لأربع حالات:

for args in "size 0.2 0.25" "size 0.5 0.6" "size 0.5 0.55" "size 0.05 0.06"; do
  docker run --rm --name lab-product-stats -v "$PWD/gen:/gen:ro" \
    node:22.23.3-bookworm-slim node /gen/stats.mjs $args
done

والمخرج سوف يكون كما يلي:

baseline 20% -> 25%: 1031 users per group (alpha 5% two-sided, power 80%)
baseline 50% -> 60%: 391 users per group (alpha 5% two-sided, power 80%)
baseline 50% -> 55%: 1568 users per group (alpha 5% two-sided, power 80%)
baseline 5% -> 6%: 7663 users per group (alpha 5% two-sided, power 80%)

في المخرج أعلاه لاحظ التالي:

• السطر الأول هو المثال الافتراضي في حاسب Evan Miller، أي نسبة 20% وفرق مطلق 5 نقاط، والحاسب يعرض 1,030 لكل مجموعة، والفرق واحد لأننا نقرب إلى الأعلى بالدالة Math.ceil، فالمعادلة نفسها.
• عندما يكون الفرق الذي تريد اكتشافه كبيراً، من 50% إلى 60%، تكفيك 391 عيادة في كل مجموعة، ولكن إذا أردت اكتشاف فرق خمس نقاط فقط تحتاج 1,568 عيادة في كل مجموعة، أي أن تصغير الفرق إلى النصف يضاعف العينة أربع مرات تقريباً.
• والسطر الأخير هو الواقع في أغلب صفحات التسجيل والدفع: نسبة 5% وتريد أن تعرف هل وصلت إلى 6%، وهذا يحتاج 7,663 زائراً في كل مجموعة.

وقد يتساءل البعض: ماذا يعني هذا لمنتج مثل نظام العيادات؟ والإجابة أنه إذا كان يسجل فيه 100 عيادة جديدة في الأسبوع، فإن اختبار فرق الخمس نقاط يحتاج 3,136 عيادة، أي أكثر من 31 أسبوعاً، وهذا غير عملي، ولذلك فإن أغلب منتجات الشركات الصغيرة والمنتجات التي تبيع للشركات B2B لا تستطيع أن تعتمد على اختبار A/B إلا للفروق الكبيرة جداً، وتعتمد أكثر على المقابلات والنماذج والقياس قبل الإطلاق وبعده مع الحذر في التفسير، وسوف نرى في مقال مقاييس المنتج Product Metrics لماذا يجب الحذر.

المسار المزدوج Dual-Track Agile

قد تفهم مما سبق أن الاكتشاف مرحلة تأتي قبل التطوير ثم تنتهي، وهذا هو الشلال Waterfall القديم باسم جديد. والطريقة التي يصفها Cagan في مقال Dual-Track Agile سنة 2012، وينسب التسمية فيه إلى Jeff Patton، أن الاكتشاف Discovery والتسليم Delivery يعملان في نفس الوقت: مسار الاكتشاف ينتج عناصر Backlog تم التحقق منها بسرعة، ومسار التسليم ينتج برنامجاً يصل إلى الإنتاج بجودة. ويكتب Patton في Dual Track Development is not Duel Track أن المسارين نوعان من العمل ونوعان من التفكير، وليسا فريقين، وأن أصل النمط ورقة لDesiree Sy سنة 2007 عن دمج أبحاث قابلية الاستخدام في Agile. والصورة التالية تبين المسارين:

وفي الإعداد العملي لفريق Scrum يعني هذا أن مدير المنتج والمصمم ومهندساً واحداً على الأقل يقضون جزءاً من كل سبرنت في مقابلات ونماذج للعمل القادم، وأن تحسين القائمة Backlog Refinement لا يدخله عنصر لم يمر على الأقل بمقابلة أو نموذج، وأن مراجعة السبرنت Sprint Review تعرض ما تعلمه الفريق في الاكتشاف بجانب ما بناه.

مثال كامل: اكتشاف لميزة تقليل المواعيد الضائعة No-shows

لنرجع إلى مشروع العيادة، وهدف المنتج Product Goal للربع كما كتبناه في مقال إدارة المنتج: أن تنخفض نسبة المواعيد التي لا يحضر أصحابها إلى النصف. وكل ما يلي مثال توضيحي لطريقة العمل، وليس نتائج مشروع حقيقي.

الخطوة الأولى أن نقيس القيمة الحالية Baseline أسبوعين من سجل المواعيد قبل أي شيء، ثم نجري ثماني مقابلات بالقالب أعلاه: خمسة مرضى فاتهم موعد في الشهرين الماضيين، وموظفتا الاستقبال، وطبيب. والخطوة الثانية أن نكتب ما سمعناه على شكل شجرة فرص وحلول Opportunity Solution Tree كما شرحناها في تقنيات إدارة المنتج:

النتيجة: نسبة عدم الحضور من [القيمة المقاسة] إلى النصف خلال ربع سنة

الفرصة 1: المريض ينسى الموعد (3 من 5 مرضى، كل منهم بقصة محددة)
  الحل أ: رسالة SMS قبل الموعد بيوم
  الحل ب: إضافة الموعد إلى تقويم الجوال عند الحجز
  الحل ج: اتصال من الاستقبال للمواعيد الطويلة فقط

الفرصة 2: المريض يعرف أنه لن يحضر لكن الإلغاء صعب (2 من 5)
  "ما أبغى أتصل وأنتظر عشان ألغي"
  الحل د: رابط إلغاء أو تأجيل داخل رسالة التذكير
  الحل هـ: الإلغاء من صفحة الحجز دون دخول

الفرصة 3: الموعد المحجوز قبل شهر أو أكثر (ملاحظة الاستقبال)
  لم نختر لها حلاً بعد، تبقى في عمود "لاحقاً"

والخطوة الثالثة أن نكتب الافتراضات خلف الحلين الأقوى (أ ود)، ونضعها على خريطة الافتراضات، فيظهر في المربع الأحمر افتراضان: أن المرضى سيقرؤون رسالة SMS في وقتها، وأنهم سيستخدمون رابط الإلغاء بدل تجاهل الموعد. والخطوة الرابعة اختيار أرخص تجربة لكل افتراض:

في المثال أعلاه لاحظ التالي:

• أول تجربة لا تحتاج سطر كود واحد، فموظفة الاستقبال ترسل الرسائل بيدها لطبيب واحد، وهذا ما يسمى أحياناً تجربة Concierge، والسبب أن السؤال هنا «هل التذكير يغير السلوك؟»، وليس «هل نستطيع أن نرسل SMS؟»، فالثاني سؤال إمكانية بناء نعرف جوابه.
• معيار النجاح مكتوب قبل البدء، والسبب أن الفريق الذي يكتب المعيار بعد أن يرى النتيجة سوف يجد دائماً سبباً ليقول إنها نجحت.
• مع عدد مواعيد عيادة واحدة في أسبوعين لن نصل إلى دلالة إحصائية Statistical Significance، ولا نتظاهر بذلك، فنحن نبحث عن إشارة واضحة تبرر بناء الميزة، أو غيابها الذي يوفر علينا شهراً من العمل. والقياس الحقيقي يأتي بعد البناء خلف Feature Flag، كما سنشرح في مقال هندسة المنتج.

وإذا نجحت التجربتان يدخل التذكير مع رابط الإلغاء إلى قائمة التسليم، وتكتب له قصص User Stories ومعايير قبول Acceptance Criteria كما في المثال العملي، وإذا فشلت نعود إلى الشجرة ونختار حلاً آخر، وفي الحالتين نكون قد صرفنا أسبوعين من وقت الاستقبال وبعض ساعات الفريق بدل شهر من التطوير.

أخطاء شائعة في الاكتشاف Discovery

• الاكتشاف لتأكيد قرار متخذ: إذا كانت الميزة ستبنى مهما كانت النتيجة فلا تسمها اكتشافاً، والسبب أن الفريق سيقرأ كل إشارة على أنها دليل لصالحها.
• عرض الحل في أول المقابلة: كل ما يقوله الشخص بعدها رأي في حلك، وليس وصفاً لمشكلته.
• مدير المنتج يكتشف وحده: إذا لم يسمع المهندسون والمصمم المستخدم بأنفسهم فسوف يبنون ما فهموه من ملخص، والعلاج أن يحضر مهندس واحد على الأقل كل مقابلة أو يسمع تسجيلها بموافقة صاحبها.
• تجربة دون معيار نجاح مكتوب مسبقاً: أي نتيجة تصبح نجاحاً بعد أن تراها.
• اختبار A/B على عدد قليل: إذا كان الحساب يقول إنك تحتاج ثلاثين أسبوعاً فلا تشغله أسبوعين ثم تعلن الفائز.
• الباب الوهمي دون شفافية: رسالة واضحة أن الميزة قادمة، ولا تقم بأخذ بيانات لا تحتاجها، والسبب أن المستخدم الذي يشعر بالخداع لا يعود.
• الاكتشاف كمرحلة تنتهي: المسار العلوي يستمر ما دام المنتج حياً، وبيانات ما بعد الإطلاق تعود إليه.

قائمة تحقق Checklist قبل أن يدخل عنصر جديد إلى قائمة التسليم Backlog

• هل المشكلة مكتوبة في بيان مشكلة، وسمعناها من أكثر من مستخدم بقصة محددة من الماضي؟
• هل نعرف ماذا يفعل المستخدم اليوم ليتجاوزها، وكم تكلفه؟
• هل فكرنا في أكثر من حل لنفس المشكلة؟
• هل كتبنا الافتراضات خلف الحل المختار، واختبرنا المهم الذي لا دليل عليه؟
• هل جرب مستخدم حقيقي النموذج الأولي دون شرح منا؟
• هل شارك مهندس في الاكتشاف وأكد إمكانية البناء وتكلفته التقريبية؟
• هل نعرف المقياس الذي سيتغير، وقيمته الحالية، وكيف سنقيسه بعد الإطلاق؟

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• الاكتشاف يجيب عن «هل نبني هذا، وأي حل منه؟» بأرخص طريقة، قبل أن تجيب هندسة المتطلبات عن «ماذا يفعل النظام بالضبط؟».
• ابدأ بمساحة المشكلة: من يعاني، وكم مرة، وماذا يفعل اليوم، وفكرة Jobs To Be Done تذكرك بأن المنافس الحقيقي قد يكون الهاتف لا منتجاً آخر.
• في المقابلة اسأل عن الماضي المحدد لا عن رأي في المستقبل، وأقوى دليل هو ما جربه الشخص ودفعه فعلاً.
• المخاطر الأربع وخريطة الافتراضات تحددان ما تختبره أولاً، والتجارب تتدرج من المقابلة إلى النموذج إلى الباب الوهمي إلى اختبار A/B.
• اختبار A/B يحتاج عينة كبيرة: 1,568 لكل مجموعة لفرق خمس نقاط عند 50%، و7,663 لفرق نقطة عند 5%، فاحسب قبل أن تبدأ ولا توقف الاختبار مبكراً.
• الاكتشاف والتسليم يعملان معاً في نفس الفريق، وأغلب الأفكار يجب أن تموت في مسار الاكتشاف.

وفي المقال التالي في هذه المرحلة سوف نتحدث بإذن الله عن مهندس المنتج Product Engineer، أي المطور الذي يشارك في كل هذا بدل أن يستلم التذكرة في آخره.

دليلإدارة المنتج: ماذا يفعل مدير المنتج Product Manager؟الفرق بين مدير المنتج ومدير المشروع ومالك المنتج Product Owner، وكيف يختار مدير المنتج ما يبنى ويرتب أولوياته ويقيس نتيجته.دليلمهندس المنتج Product Engineer يملك النتيجة لا المهمةماذا تعني هندسة المنتج Product Engineering كما تصفها الشركات التي تعمل بها، وكيف ينتقل المطور من تنفيذ المهام إلى امتلاك نتيجتها.دليلمقاييس المنتج Product Metrics وكيف تعرف أن الميزة نجحتكيف تختار مقياساً رئيسياً North Star لمنتجك، وتبني قمع التحويل Funnel وجدول العودة Retention من أحداث تطبيقك بأدوات تستضيفها على سيرفرك.دليلمن فكرة غامضة إلى متطلبات Requirements واضحة: مثال عملي مع القوالبكيف تحول جملة «نبغى نظام حجز مواعيد لعيادة» إلى متطلبات Requirements واضحة يمكن بناؤها واختبارها، مع قوالب جاهزة للنسخ.دليلFeature Flags: انشر الكود وفعل الميزة لاحقاًكيف يفصل ال Feature Flag بين نشر الكود وإطلاق الميزة، وكيف تطلقها لجزء من المستخدمين أولاً وتوقفها فوراً إذا تعطلت.دليلFormbricks: استبيانات ونماذج حديثة على سيرفرككيف تثبت Formbricks وتنشئ استبياناً عربياً بالرابط أو داخل تطبيقك، وتبقى الإجابات في قاعدة بياناتك على سيرفرك.

سجل التحديثات

• أكتوبر 2026: كتابة المقال من دليل GOV.UK ومقالات SVPG وJeff Patton وHBS Working Knowledge وHBR وكتاب The Mom Test وTesting Business Ideas، مع قالب مقابلة اكتشاف، وسكربت لحساب حجم عينة اختبار A/B شغلناه في Container من Node.js 22.23.3 وطابقنا نتيجته مع حاسب Evan Miller، ومثال كامل على مشروع العيادة.