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