في عالم اليوم ، هناك حاجة إلى تطبيقات قادرة على تلبية مصالح جميع الأطراف بفعالية أكبر. في كثير من الأحيان يتم تنفيذ ذلك باستخدام أنواع مختلفة من القيود. على سبيل المثال ، لا تسمح للمستخدم بتنفيذ إجراءات من شأنها أن تكون غير مؤذية لنفسه أو لمالك النظام. في هذه الحالة ، من الضروري تقليل الانزعاج الناجم عن هذه القيود.
على سبيل المثال ، يحتاج مالك النظام إلى رقم هاتف في نموذج الملاحظات بتنسيق +7 () -- لمزيد من الاستخدام الآلي. من أجل راحة المستخدم ، من الأفضل عدم استخدام التلميح أو التحقق من الصحة فقط عند تقديم النموذج ، ولكن قناع الإدخال الذي يستبعد إدخال البيانات في تنسيق خاطئ. اتضح ، والذئاب ممتلئة ، والأغنام سليمة.
في بعض الحالات ، يحد النظام المستخدم من الحماية ضد الخسائر المحتملة. لذلك ، على سبيل المثال ، مثل ارتداء حزام الأمان قبل القيادة ، في خدمات الدفع عبر الإنترنت ، لا تحتاج فقط إلى إدخال البيانات من البطاقة ، ولكن أيضًا تأكيد الدفع عن طريق الرمز من رسالة SMS ، مما يقلل بشكل كبير من احتمال سرقة المال. وتجدر الإشارة إلى أن هذا الاهتمام بسلامة المستخدم مفيد لمالك الخدمة ، لأنه يقلل من مخاطر السمعة ، وإلا فإنه قد يظهر كما هو الحال في أعمال Alexei Apukhtin: "... سواء سرق أو سرق منه ... الشيء الرئيسي هو أنه شارك في شيء سيء ... ".
وبالتالي ، عند تطوير تطبيق ما ، من الضروري التفكير في الوظيفة بطريقة ترضي كل من العميل المباشر والمستخدم العادي. مع وضع ذلك في الاعتبار ، يمكن تمييز خمسة مستويات من قيود النظام:
- لا توجد وسيلة للحد من المستخدم ، أي الاعتماد عليه في عدم ارتكاب الأخطاء وعدم الإضرار بنفسه أو بمالك النظام.
- حد جزئي - قد يرتكب المستخدم خطأ ، ولكن أقل احتمالًا (أو أقل خطورة).
- قدم القيود اللازمة ، ولكن ليس بشكل مفرط - المستخدم محدود جدًا لدرجة أنه لا يستطيع ارتكاب أي خطأ ، لكن القيود لا تخلق مشاكل في استخدام النظام. هذا هو الخيار المثالي.
- ليس من الضروري الحد - المستخدم محدود بحيث يمنعه من استخدام النظام.
- حدد المستخدم تمامًا ، أي حظر الميزة.
بالنسبة إلى المستويين الأول والخامس ، هناك مثال مألوف هو الوضع المألوف عندما يصرخ أمين الصندوق "Galya ، ألغِ!" في هذه الحالة ، قام أمين الصندوق بمنع وظيفة إزالة البضائع المثقوبة من الشيك تمامًا ، وليس لدى Gali أي قيود على هذه العملية. بمعنى أنه يمكن غالبًا استخدام درجات التقييد هذه كجزء من تنفيذ نموذج الدور.
وفي حالة عدم الحديث عن التطرف ، يتم إنشاء أحد الخيارات الوسيطة في النظام. ثم المهمة المهمة لأي مشروع هي إدخال جميع القيود اللازمة ، ولكن ليس المفرط (المستوى الثالث). لذلك ، على سبيل المثال ، ليس في كل مرحلة من مراحل ملء طلب لملء كلمة التحقق (المستوى الرابع) ، ولكن فقط قبل إرسال النموذج الكامل. أو حتى لا يحتوي حقل إدخال الهاتف على قناع إدخال فقط (المستوى الثاني) ، ولكن أيضًا على التحقق من قيام المستخدم بإدخال 11 رقمًا من الرقم.
نعطي مثالا. كان لدينا مشروع لتطوير تطبيق لمرافقة عملية التجميع (المشار إليها فيما يلي - برنامج Collector). كجزء من إطلاق المشروع ، قمنا بصياغة الاختصاصات واتفقنا عليها ، وبعد ذلك تم الانتهاء من عمل المحلل بالنسبة للجزء الأكبر. تجدر الإشارة إلى أن العميل كان شركة بدأت للتو في تحصيل الديون ، أي كما اتضح فيما بعد ، فإن العملية لا تزال في مرحلة تصحيح الأخطاء.
وفي تلك اللحظة ، عندما كان التطوير في المشروع بالفعل حوالي ستة أشهر ، تم تلقي معلومات جديدة حول ميزات عمل المستخدمين المحتملين للنظام ، وكذلك حول التحسينات المخطط لها. تجدر الإشارة على الفور إلى أننا في ذلك الوقت ، قمنا بتنفيذ المهام الوظيفية التالية ، بما في ذلك:
- إسناد مهمة لإجراء مكالمة إلى المدين ؛
- تنفيذ المهمة المسندة ؛
- تحديد نتيجة التفاعل (يدوياً من قبل المستخدم) ؛
- ضمان الامتثال لمتطلبات تشريعات الاتحاد الروسي على وتيرة التفاعلات مع المدينين 1 .
دعونا نوضح أن آخر الوظائف المدرجة كانت كما يلي: لقد حدّد برنامج Collector من إمكانية تعيين المهام التي يمكن أن تنتهك متطلبات القانون. في هذه الحالة ، إذا لم يكن من الممكن الوصول (يعين المستخدم نتيجة المكالمة المقابلة) ، يتم تأجيل المهمة ويمكن للمشغل العودة إليها لاحقًا. وهذا يعني أن محاولة الطلب الهاتفي الفاشلة لا يمكن اعتبارها تفاعلًا ، ويمكنك محاولة إكمال المهمة مرة أخرى.
ما الذي أصبح معروفًا عن ميزات تجربة المستخدم؟ اتضح أنه في حالة محاولة فاشلة للوصول إلى هاتف المدين المحمول ، فلن يقوم المشغل فقط بتأجيل المهمة ، ولكن أيضًا ، إذا تم تخصيص أي أرقام أخرى للمدين ، حاول الوصول إليها على الفور.
بالنظر إلى المواعيد النهائية الضيقة ، كان من غير العملي غمر المحلل مرة أخرى في المشروع ، لذا فإن اختصاصي ضمان الجودة قد حصل على مهمة النظر فيما إذا كان التنفيذ الحالي متسقًا مع كيفية تخطيط التطبيق لاستخدامه من جانب العميل. أثناء التحليل ، قمنا ببناء السلسلة المنطقية التالية:
- قد يكون للمدين عدة أرقام (الجوال ، المنزل ، العمل) ، لكن يمكنك جدولة مكالمة لرقم واحد فقط.
- إذا فشل المشغل في الوصول إلى العميل ، فسيتم تأجيل المهمة ، لكن سيكون من المستحيل الاتصال برقم آخر ، لأنه المهمة المعلقة سوف تمنع أيضًا تعيين مكالمة إلى أرقام أخرى.
- لذلك ، لمحاولة الوصول إلى رقم آخر ، يحتاج المستخدم إلى إلغاء المهمة المعلقة يدويًا وتعيين رقم جديد.
- ولكن في الوقت نفسه ، قد لا تتمكن الأرقام الأخرى من الوصول. ثم تم إلغاء المهام التي تم تأجيلها بسبب قلة الطلب ، كما تبين. تحتاج إلى تعيينهم مرة أخرى للاتصال مرة أخرى لاحقًا.
تجدر الإشارة إلى أنه وفقًا للمعلومات الواردة من العميل ، تحدث المحاولات غير الناجحة للاتصال الهاتفي في الممارسة العملية كثيرًا.
بالإضافة إلى ذلك ، تم التخطيط لتطوير وظيفي لتكامل برنامج Collector مع نظام تحليلي للتعيين التلقائي للأحداث (المشار إليها فيما يلي - ASANM) ، والذي تم إنشاؤه على جانب العميل. كان الجوهر كما يلي:
- يوميًا (مرة واحدة يوميًا) تشكل ASANM قائمة بالمهام التي يجب تنفيذها بموجب العقود ، وترسل طلبًا إلى برنامج Collector ؛
- البرنامج يقوم القائم بالتجميع من القائمة المستلمة بتعيين تلك المهام التي لا تتجاوز حد التفاعلات.
وفقًا لاستنتاج أخصائي ضمان الجودة ، في التنفيذ الحالي ، لن يتمكن كل من المشغل و ASANM من جدولة مكالمة لجميع أرقام المدين.
بشكل عام ، كان هناك فهم بأنه تم تنفيذ المستوى الرابع من القيود (قيود غير ضرورية): لإجراء مكالمة للأرقام الأخرى ، تحتاج إلى إلغاء المهمة المعلقة يدويًا. في الواقع ، اتضح أن القانون لا يحد من عدد محاولات الاتصال بالمدين ، ولكن عدد المحاولات الناجحة للتفاعل. وهذا يعني أن حد التفاعل يجب أن يحسب بناءً على نتائج المهام.
في هذا الصدد ، بدأنا تغييرًا في شكل التنفيذ وتم اختيار طريقة أكثر ملائمة للوفاء بالمتطلبات:
- حساب عدد التفاعلات بناءً على نتائج الأنشطة ؛
- إذا لم يتم الوصول إلى الحد الأقصى ، فسمح للمستخدم / ASANM بجدولة الأحداث دون قيود ؛
- إذا تم الوصول إلى الحد الأقصى ، فقم بإلغاء الأحداث غير الضرورية وحظر تعيينها.
لقد تطلب الأمر إجراء تغييرات كاملة ، ولكن يمكننا بالتأكيد القول إن هذه المرة لم تضيع هباءً ، والآن لأن المستخدمين العاديين لن يواجهوا أي إزعاج أثناء العمل في التطبيق ، لذلك سيكون مالك النظام قادرًا على تخطيط عمل المشغلين باستخدام ASANM.
الخاتمة
يُنصح جميع أولئك الذين يهتمون بالمستخدم والعميل ، عند تطبيق القيود ، بالالتزام بقاعدتين بسيطتين:
- "مع وجود عدد كافٍ من المربيات ، لن يفقد الطفل عينه" - أي أنك تحتاج إلى حماية المستخدم بشكل كافٍ من ارتكاب الأخطاء التي يمكن أن تضر به أو بمالك النظام.
- "للخوف من الذئاب ، ولكن للذهاب إلى الغابة" - من الضروري تجنب القيود غير الضرورية ، لأنه بخلاف ذلك يتم فقد قيمة المنتج المطور للمستخدم.
1 تم تحديد المتطلبات بموجب القانون الاتحادي بتاريخ 03.07.2016 N 230- "بشأن حماية حقوق الأفراد ومصالحهم القانونية عند القيام بأنشطة لإعادة ديون متأخرة وإلى تعديل القانون الاتحادي" بشأن أنشطة التمويل الأصغر ومنظمات التمويل الأصغر ".