اكتشاف المشكلة: من طلب الميزة إلى فهم المشكلة الحقيقية
تركز المرحلة الأولى من نموذج الماسة المزدوجة (Double Diamond) على اكتشاف المشكلة (Discover). في هذه المرحلة، لا ننتقل مباشرة إلى أول مشكلة أو حل يخطر في أذهاننا، بل نحاول دراسة المشكلة من زوايا مختلفة وبناء فهم أكثر دقة للوضع الحالي.
خلال مرحلة Discover، يتم جمع الأدلة من خلال الملاحظة، وإجراء مقابلات مع المستخدمين، وتحليل البيانات والسجلات (Logs)، ودراسة الفرضيات المختلفة. ثم تأتي مرحلة Define لمراجعة هذه النتائج وتجميعها وترتيب أولوياتها، بهدف تحديد المشكلة التي تستحق الحل فعلاً.
الفكرة الأساسية هي:
الماسة الأولى لا تسأل: ماذا يجب أن نبني؟ بل تسأل: ما المشكلة التي تستحق الحل فعلاً؟
طلب الميزة لا يعني بالضرورة أنه المشكلة الحقيقية
في العديد من فرق البرمجيات، تصل المشكلة إلى الفريق على شكل متطلب أو طلب لإضافة ميزة معينة. لكن طلب ميزة محددة لا يعني بالضرورة أنه يعبر عن المشكلة الأساسية التي يواجهها العميل.
على سبيل المثال، قد يصل الطلب بالشكل التالي:
«أضيفوا سجل تحويلات الأموال إلى التطبيق.»
إذا بدأنا مباشرة في تصميم هذه الميزة، فقد نفترض أن المشكلة هي عدم وجود سجل للتحويلات. لكن التفكير القائم على المنتج يبدأ بسؤال مختلف:
«لماذا يحتاج المستخدم إلى سجل تحويلات الأموال؟»
قد يكشف تحليل سلوك المستخدمين أن الأشخاص الذين يريدون تحويل الأموال مرة أخرى إلى مستلمين سابقين يضطرون في كل مرة إلى البحث عن رقم بطاقة المستلم ونسخه من تطبيقات المراسلة أو من مصادر أخرى. وهذه العملية تستغرق وقتاً وتزيد من احتمالية حدوث الأخطاء.
في هذه الحالة، قد تكون المشكلة الحقيقية هي:
«إعادة تحويل الأموال إلى مستلمين سابقين عملية تستغرق وقتاً وجهداً بالنسبة للمستخدم.»
وبالتالي، فإن «سجل تحويلات الأموال» يمثل أحد الحلول الممكنة فقط، ولا ينبغي افتراض أنه أفضل حل قبل فهم المشكلة بشكل صحيح.
مصادر اكتشاف المشكلة
لفهم المشكلة بصورة أفضل، لا ينبغي الاعتماد على مصدر واحد فقط. ويمكن الاستفادة من ثلاثة مصادر رئيسية:
المستخدمون وسلوكهم: مقابلات المستخدمين، وملاحظة سلوكهم، وتذاكر الدعم، والملاحظات والآراء التي يتم جمعها منهم.
البيانات والسجلات: تحليل Customer Journey، وFunnel Analysis، ودراسة تفاعل المستخدم مع المنتج خطوة بخطوة.
الأعمال والسوق: دراسة المنافسين، والميزات الموجودة في المنتجات المشابهة، والحلول المتوفرة في السوق.
يساعد الجمع بين هذه المصادر على دراسة المشكلة من زوايا متعددة، ويقلل من خطر اتخاذ القرارات بناءً على طلب واحد أو مؤشر منفرد.
من مؤشرات الأداء التقنية إلى تجربة المستخدم
من المهام المهمة لمدير المنتج بناء علاقة واضحة بين المؤشرات التقنية وسلوك المستخدم وتجربته.
في العديد من المشاريع والعقود البرمجية، يتم التركيز على مؤشرات مثل Latency، وError Rate، وAvailability، وUptime، وTPS، وزمن استجابة API. لكن أهمية هذه المؤشرات تصبح أكثر وضوحاً عندما نفهم تأثيرها على تجربة المستخدم الفعلية.
على سبيل المثال، إذا ارتفع زمن استجابة إحدى واجهات API، فالأمر لا يقتصر على كونه مشكلة تقنية. عندما يتأخر ظهور النتيجة، قد يعتقد المستخدم أن التطبيق متوقف عن الاستجابة أو أن طلبه لم يتم تنفيذه. وبالتالي، قد يعيد إرسال الطلب نفسه.
يمكن أن تؤدي الطلبات المتكررة إلى زيادة الحمل على النظام، وفي حال عدم التعامل معها بشكل صحيح، قد تتسبب حتى في إنشاء معاملات مكررة وتقليل ثقة المستخدم.
لذلك، يمكن لمؤشر أداء تقني أن يؤثر بشكل مباشر في سلوك المستخدم وجودة تجربته.
يجب أن يكون مدير المنتج قادراً على فهم العلاقة بين أربعة مجالات رئيسية:
المؤشرات التقنية، تجربة المستخدم، سلوك المستخدم، ونتائج الأعمال
وبالإضافة إلى المؤشرات التقنية مثل زمن الاستجابة ومعدل الأخطاء والاستقرار، فإن مؤشرات مثل السرعة المدركة، ومعدل نجاح المستخدم في إنجاز المهمة، والرضا، والثقة، ومعدل تكرار الإجراءات مهمة أيضاً لتقييم الجودة الفعلية للمنتج.
وفي النهاية، يجب أن يعمل مدير المنتج كحلقة وصل فعالة بين الفريق التقني، وفريق تجربة المستخدم، وفريق الأعمال.
تتحقق القيمة الحقيقية عندما نتمكن من ربط مؤشرات الأداء التقنية بمؤشرات تجربة المستخدم، وفهم تأثيرها على سلوك المستخدم، وتحديد ارتباطها بالنتائج والأهداف التجارية.