Dans le monde d'aujourd'hui, les demandes sont en demande et sont en mesure de répondre le plus efficacement possible aux intérêts de toutes les parties. Souvent, cela est mis en œuvre en utilisant différents types de restrictions. Par exemple, ils ne permettent pas à l'utilisateur d'effectuer des actions qui seraient désavantageuses pour lui-même ou pour le propriétaire du système. Dans ce cas, il est nécessaire de minimiser l'inconfort causé par de telles restrictions.
Par exemple, le propriétaire du système a besoin d'un numéro de téléphone dans le formulaire de rétroaction au format +7 () -- pour une utilisation automatisée ultérieure. Pour la commodité de l'utilisateur, il est préférable d'utiliser non seulement un indice ou une validation lors de la soumission du formulaire, mais un masque de saisie qui exclut la saisie de données au mauvais format. Il s'avère que les loups sont pleins et les moutons intacts.
Dans certains cas, le système limite l'utilisateur à se protéger contre les pertes potentielles. Ainsi, par exemple, comme porter une ceinture de sécurité avant de conduire, dans les services de paiement en ligne, vous devez non seulement saisir les données de la carte, mais également confirmer le paiement par code à partir d'un SMS, ce qui réduit considérablement la probabilité de vol d'argent. Et il convient de noter qu'une telle préoccupation pour la sécurité de l'utilisateur est bénéfique pour le propriétaire du service, car elle réduit les risques de réputation, sinon elle peut apparaître comme dans le travail d'Alexei Apukhtin: «... s'il l'a volé ou lui a été volé ... L'essentiel est qu'il ait été impliqué dans chose désagréable ... ".
Ainsi, lors du développement d'une application, il est nécessaire de réfléchir à la fonctionnalité de manière à plaire à la fois au client direct et à l'utilisateur moyen. Dans cette optique, il existe cinq niveaux de limitations système:
- Il n'y a aucun moyen de limiter l'utilisateur , c'est-à-dire de se fier à lui pour ne pas commettre d'erreurs et ne pas se blesser ni nuire au propriétaire du système.
- Limite partielle - l'utilisateur peut faire une erreur, mais moins probable (ou moins grave).
- Introduisez les restrictions nécessaires , mais pas excessives - l'utilisateur est si limité qu'il ne peut pas faire d'erreur, mais les restrictions ne créent pas de problèmes dans l'utilisation du système. C'est une option idéale.
- Il n'est pas nécessaire de limiter - l'utilisateur est limité de sorte qu'il l'empêche d'utiliser le système.
- Limitez complètement l'utilisateur , c'est-à-dire bloquez la fonctionnalité.
Pour les premier et cinquième niveaux, un exemple familier est la situation familière où un caissier crie «Galya, annule!» Dans le magasin, et le tout-puissant Galya vient à la rescousse. Dans ce cas, le caissier a complètement bloqué la fonction de retrait des articles perforés du chèque, et Gali n'a aucune restriction sur cette opération. Autrement dit, ces degrés de restriction peuvent souvent être utilisés dans le cadre de la mise en œuvre du modèle de rôle.
Et dans le cas où nous ne parlons pas d'extrêmes, l'une des options intermédiaires est créée dans le système. Et puis la tâche importante de tout projet est d'introduire toutes les restrictions nécessaires, mais pas excessives (troisième niveau). Ainsi, par exemple, pas à chaque étape du remplissage d'une candidature pour remplir un captcha (quatrième niveau), mais uniquement avant l'envoi du formulaire complet. Ou pour que le champ de saisie du téléphone contienne non seulement un masque de saisie (deuxième niveau), mais également une vérification que l'utilisateur a entré 11 chiffres du numéro.
Nous donnons un exemple. Nous avions un projet de développement d'une application pour accompagner le processus de collecte (ci-après - logiciel Collector). Dans le cadre du lancement du projet, nous avons rédigé et convenu des termes de référence, après quoi le travail de l'analyste pour la plupart a été achevé. Il convient de noter que le client était une entreprise qui commençait tout juste à recouvrer des dettes, c'est-à-dire, comme il s'est avéré plus tard, que le processus était encore au stade du débogage.
Et à ce moment, alors que le développement du projet était déjà d'environ six mois, de nouvelles informations ont été reçues sur les caractéristiques du travail des utilisateurs potentiels du système, ainsi que sur les améliorations prévues. Il convient de noter immédiatement qu'à cette époque, nous avions mis en œuvre les tâches fonctionnelles suivantes, notamment:
- assignation d'une tâche pour appeler le débiteur;
- la mise en œuvre de la tâche assignée;
- fixer le résultat de l'interaction (manuellement par l'utilisateur);
- assurer le respect des exigences de la législation de la Fédération de Russie sur la fréquence des interactions avec les débiteurs 1 .
Précisons que la dernière des fonctionnalités répertoriées était la suivante: le logiciel Collector limitait la possibilité d'attribuer des tâches susceptibles de violer les exigences de la loi. Dans ce cas, s'il n'a pas été possible de passer (l'utilisateur définit le résultat de l'appel correspondant), la tâche est reportée et l'opérateur peut y revenir ultérieurement. En d'autres termes, une tentative d'accès à distance échouée ne peut pas être considérée comme une interaction et vous pouvez essayer de terminer à nouveau la tâche.
Que sait-on des caractéristiques de l'expérience utilisateur? Il s’est avéré qu’en cas de tentative infructueuse d’atteindre le mobile du débiteur, l’opérateur reporterait non seulement la tâche mais, si d’autres numéros lui étaient attribués, tentait immédiatement de les atteindre.
Compte tenu des délais serrés, il n'était pas pratique de plonger à nouveau l'analyste dans le projet.Notre spécialiste en assurance qualité a donc eu la tâche de déterminer si la mise en œuvre existante était cohérente avec la manière dont l'application devait être utilisée côté client. Au cours de l'analyse, nous avons construit la chaîne logique suivante:
- Le débiteur peut avoir plusieurs numéros (mobile, domicile, travail), mais vous pouvez programmer un appel vers un seul numéro.
- Si l'opérateur ne parvient pas à joindre le client, la tâche sera reportée, mais il sera toujours impossible d'appeler un autre numéro, car la tâche en attente bloquera également la nomination d'un appel vers d'autres numéros.
- Par conséquent, afin d'essayer d'atteindre un autre numéro, l'utilisateur doit annuler manuellement la tâche en attente et en affecter une nouvelle.
- Mais en même temps et d'autres chiffres peuvent ne pas être en mesure de passer. Et puis les tâches reportées en raison du manque de numérotation, il s'avère, ont été en vain annulées. Vous devez les nommer à nouveau pour rappeler plus tard.
Il convient de noter que, selon les informations fournies par le client, les tentatives infructueuses de connexion par téléphone se produisent assez souvent.
En outre, il était prévu de développer une fonctionnalité d'intégration du logiciel Collector avec un système analytique de rendez-vous automatique des événements (ci-après - ASANM), qui a été créée côté client. L'essence était la suivante:
- quotidiennement (une fois par jour) ASANM établit une liste de tâches qui doivent être exécutées dans le cadre des contrats et envoie une demande au logiciel Collector;
- Logiciel Le collecteur de la liste reçue attribue les tâches qui ne dépassent pas la limite d'interactions.
Selon la conclusion du spécialiste de l'assurance qualité, dans la mise en œuvre existante, l'opérateur et l'ASANM ne pourraient pas programmer un appel vers tous les numéros du débiteur.
En général, il était entendu que le quatrième niveau de restrictions avait été appliqué (restrictions excessives): pour appeler d'autres numéros, vous devez annuler manuellement la tâche en attente. En fait, il s'est avéré que la loi ne limite pas le nombre de tentatives de contacter le débiteur, mais le nombre de tentatives d'interaction réussies. Et cela signifiait que la limite d'interaction devait être calculée en fonction des résultats des tâches.
À cet égard, nous avons initié un changement dans le format de mise en œuvre et une manière plus rapide de répondre aux exigences a été choisie:
- compter le nombre d'interactions en fonction des résultats des activités;
- si la limite n'est pas atteinte, alors autorisez l'utilisateur / ASANM à planifier des événements sans restrictions;
- si la limite est atteinte, annulez les événements inutiles et interdisez leur nomination.
Il a fallu un sprint pour effectuer les changements, mais nous pouvons certainement dire que ce temps n'a pas été perdu en vain et que les utilisateurs ordinaires ne subiront aucun inconvénient lorsqu'ils travailleront dans l'application, de sorte que le propriétaire du système pourra planifier le travail des opérateurs utilisant ASANM.
Conclusion
Tous ceux qui, lors de la mise en œuvre de restrictions, se soucient de l'utilisateur et du client, sont invités à respecter deux règles simples:
- «Avec un nombre suffisant de nounous, l'enfant ne perdra pas son œil», c'est-à-dire que vous devez protéger suffisamment l'utilisateur contre les erreurs qui peuvent lui nuire ou nuire au propriétaire du système.
- "Avoir peur des loups, mais aller dans la forêt" - des restrictions inutiles doivent être évitées, car sinon la valeur du produit développé pour l'utilisateur est perdue.
1 Les exigences sont établies par la loi fédérale du 03.07.2016 N 230- «Sur la protection des droits et des intérêts juridiques des particuliers lors de l'exécution d'activités de remboursement de dettes en souffrance et sur la modification de la loi fédérale sur les activités de microfinance et les organisations de microfinance».