تعريف المشكلة: من الاستكشاف إلى اختيار المشكلة الصحيحة
في مرحلة Discover، قمنا بدراسة المشكلة من زوايا مختلفة، وجمعنا الأدلة، وتوصلنا إلى مجموعة من المشكلات المحتملة. ولكن لا يمكننا حل جميع هذه المشكلات في الوقت نفسه. لذلك، ننتقل في المرحلة الثانية، وهي Define، من الاستكشاف إلى التركيز، ونختار مشكلة محددة تستحق الحل.
في هذه المرحلة، نقوم بتجميع النتائج التي توصلنا إليها وترتيب أولوياتها، حتى نتمكن من تعريف المشكلة التي تستحق التركيز والجهد.
ما الذي يجعل تعريف المشكلة جيداً؟
لنأخذ المثال التالي:
«المستخدمون الذين يقومون بشكل متكرر بتحويل الأموال إلى مستلمين سابقين يضطرون إلى بذل الكثير من الوقت والجهد للعثور على معلومات المستلم وإدخالها مرة أخرى. ويؤدي هذا الاحتكاك إلى زيادة احتمال حدوث الأخطاء والتخلي عن العملية.»
يتضمن هذا التعريف عدة عناصر مهمة:
المستخدم: يحدد الفئة التي تواجه المشكلة؛ وهم في هذا المثال المستخدمون الذين يقومون بتحويل الأموال بشكل متكرر إلى مستلمين سابقين.
السياق: يوضح الظروف التي تظهر فيها المشكلة؛ أي أثناء إجراء تحويل مالي متكرر.
نقطة الألم: توضح الصعوبة التي يواجهها المستخدم، مثل البحث عن معلومات المستلم وإدخالها مرة أخرى.
التأثير: يوضح نتائج المشكلة، مثل زيادة احتمال الأخطاء والتخلي عن العملية.
يجب أن يصف تعريف المشكلة المشكلة نفسها، وليس الحل.
يجب أن يكون وصف المشكلة مستقلاً عن الحل.
إذا ركزنا على حل محدد منذ البداية، فقد ينتهي بنا الأمر إلى الدفاع عن الحل الذي اخترناه بدلاً من فهم المشكلة الحقيقية ومعالجتها.
من «ماذا يجب أن نبني؟» إلى «ما المشكلة التي نريد حلها؟»
في الأسلوب التقليدي القائم على الميزات، يطلب فريق الأعمال عادةً ميزة محددة، بينما يركز الفريق التقني على كيفية تنفيذها:
الأعمال: نريد هذه الميزة.
الفريق التقني: كيف نبنيها؟
أما في التفكير المنتجّي، فتختلف الأسئلة:
الأعمال: نريد هذه الميزة.
فريق المنتج: ما المشكلة التي نريد حلها من خلال هذه الميزة؟
فريق المنتج: ما الأدلة التي تثبت وجود هذه المشكلة فعلاً؟
فريق المنتج: ما المستخدمون الذين يواجهون هذه المشكلة، وفي أي سياق؟
يمكننا الإجابة عن هذه الأسئلة من خلال مصادر مختلفة مثل تذاكر الدعم، والسجلات (Logs)، وبيانات المنتج، ومقابلات المستخدمين، ومراقبة سلوكهم.
كلما فهمنا المشكلة بشكل أفضل، زادت احتمالية الوصول إلى حل أكثر ملاءمة.
الفرصة التي يخلقها الذكاء الاصطناعي لفرق الهندسة
في الأساليب التقليدية، كان يُفترض غالباً أن المتطلبات قد تم تحليلها بشكل كامل وأنها جاهزة للتنفيذ. أما اليوم، وبمساعدة الذكاء الاصطناعي، فإذا كان المتطلب واضحاً وكاملاً بالفعل، يمكن تنفيذ جزء كبير من عملية تطويره بسرعة أكبر بكثير.
وهذا يخلق فرصة مهمة أمام فرق الهندسة:
بدلاً من بناء الميزات بشكل أسرع فقط، يمكن للفرق توسيع دورها والمشاركة بشكل أكبر في اكتشاف المشكلات وفهمها.
لا ينبغي أن يكون الهدف النهائي مجرد زيادة سرعة التطوير، بل استخدام هذه القدرة الجديدة من أجل بناء منتجات أفضل وحل المشكلات الحقيقية التي يواجهها المستخدمون.