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