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