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