En el mundo de hoy, se demandan aplicaciones que puedan satisfacer de manera más efectiva los intereses de todas las partes. A menudo, esto se implementa utilizando varios tipos de restricciones. Por ejemplo, no permiten que el usuario realice acciones que serían desventajosas para sí mismo o para el propietario del sistema. En este caso, es necesario minimizar las molestias causadas por tales restricciones.
Por ejemplo, el propietario del sistema necesita un número de teléfono en el formulario de comentarios en el formato +7 () -- para un mayor uso automatizado. Para la comodidad del usuario, es mejor usar no solo una pista o validación al enviar el formulario, sino una máscara de entrada que excluya la entrada de datos en el formato incorrecto. Resulta que los lobos están llenos y las ovejas están intactas.
En algunos casos, el sistema limita al usuario a protegerse contra posibles pérdidas. Entonces, por ejemplo, de manera similar a los requisitos para abrocharse el cinturón de seguridad antes de conducir, en los servicios de pago en línea no solo debe ingresar los datos de la tarjeta, sino también confirmar el pago por código de un mensaje SMS, lo que reduce significativamente la probabilidad de robo de dinero. Y debe tenerse en cuenta que esa preocupación por la seguridad del usuario es beneficiosa para el propietario del servicio, ya que reduce los riesgos de reputación, de lo contrario puede surgir como en el trabajo de Alexei Apukhtin: "... si le robó o le fue robado ... Lo principal es que estuvo involucrado en cosa desagradable ... ".
Por lo tanto, al desarrollar una aplicación, es necesario pensar en la funcionalidad de tal manera que complazca tanto al cliente directo como al usuario promedio. Con esto en mente, existen cinco niveles de limitaciones del sistema:
- No hay forma de limitar al usuario , es decir, confiar en él para no cometer errores y no hacerse daño a sí mismo o al propietario del sistema.
- Límite parcial : el usuario puede cometer un error, pero es menos probable (o menos grave).
- Introduzca las restricciones necesarias , pero no excesivas: el usuario es tan limitado que no puede cometer un error, pero las restricciones no crean problemas al usar el sistema. Esta es una opción ideal.
- No es necesario limitarlo : el usuario está limitado para evitar que use el sistema.
- Limite al usuario por completo , es decir, bloquee la función.
Para el primer y quinto nivel, un ejemplo familiar es la situación familiar cuando un cajero grita "¡Galya, cancela!" En la tienda, y el todopoderoso Galya viene al rescate. En este caso, el cajero ha bloqueado por completo la función de eliminar los artículos perforados del cheque, y Gali no tiene restricciones en esta operación. Es decir, estos grados de restricción a menudo se pueden usar como parte de la implementación del modelo a seguir.
Y en el caso cuando no estamos hablando de extremos, se crea una de las opciones intermedias en el sistema. Y luego, la tarea importante de cualquier proyecto es introducir todas las restricciones necesarias, pero no excesivas (tercer nivel). Entonces, por ejemplo, no en cada etapa de llenar una solicitud para completar un captcha (cuarto nivel), sino solo antes de enviar el formulario completo. O para que el campo de entrada del teléfono contenga no solo una máscara de entrada (segundo nivel), sino también una verificación de que el usuario ha ingresado 11 dígitos del número.
Damos un ejemplo. Teníamos un proyecto para desarrollar una aplicación para acompañar el proceso de recopilación (en adelante, software de recopilador). Como parte del inicio del proyecto, redactamos y acordamos los términos de referencia, después de lo cual el trabajo del analista se completó en su mayoría. Vale la pena señalar que el cliente era una empresa que recién estaba comenzando a cobrar deudas, es decir, como resultó más tarde, el proceso aún se encuentra en la etapa de depuración.
Y en ese momento, cuando el desarrollo del proyecto ya era de unos seis meses, se recibió nueva información sobre las características del trabajo de los usuarios potenciales del sistema, así como sobre las mejoras planificadas. Cabe señalar de inmediato que en ese momento, implementamos las siguientes tareas funcionales, que incluyen:
- asignación de una tarea para hacer una llamada al deudor;
- la implementación de la tarea asignada;
- arreglando el resultado de la interacción (manualmente por el usuario);
- garantizar el cumplimiento de los requisitos de la legislación de la Federación de Rusia sobre la frecuencia de las interacciones con los deudores 1 .
Permítanos aclarar que la última de las funcionalidades enumeradas fue la siguiente: el software del recopilador limitó la posibilidad de asignar tareas que podrían violar los requisitos de la ley. En este caso, si no fue posible pasar (el usuario establece el resultado de la llamada correspondiente), la tarea se pospone y el operador puede volver a ella más tarde. Es decir, un intento fallido de acceso telefónico no puede considerarse una interacción, y puede intentar completar la tarea nuevamente.
¿Qué se sabe sobre las características de la experiencia del usuario? Resultó que en caso de un intento fallido de comunicarse con el móvil del deudor, el operador no solo pospondrá la tarea, sino que también, si se asignan otros números al deudor, inmediatamente tratará de comunicarse con ellos.
Debido a los plazos ajustados, no era práctico volver a sumergir al analista en el proyecto, por lo que nuestro especialista en control de calidad tuvo la tarea de considerar si la implementación existente es coherente con la forma en que se planea utilizar la aplicación del lado del cliente. Durante el análisis, construimos la siguiente cadena lógica:
- El deudor puede tener varios números (móvil, hogar, trabajo), pero puede programar una llamada a un solo número.
- Si el operador no puede comunicarse con el cliente, la tarea se pospondrá, pero aún será imposible llamar a otro número, porque la tarea pendiente también bloqueará la cita de una llamada a otros números.
- Por lo tanto, para intentar alcanzar otro número, el usuario debe cancelar manualmente la tarea pendiente y asignar una nueva.
- Pero al mismo tiempo, es posible que otros números no puedan pasar. Y luego, las tareas pospuestas debido a la falta de marcación, resultaron en vano canceladas. Debe designarlos nuevamente para volver a llamar más tarde.
Cabe señalar que según la información del cliente, los intentos fallidos de marcar en la práctica ocurren con bastante frecuencia.
Además, se planificó desarrollar una funcionalidad para la integración del software Collector con un sistema analítico para la cita automática de eventos (en adelante, ASANM), que se creó en el lado del cliente. La esencia era la siguiente:
- diariamente (una vez al día) ASANM forma una lista de tareas que deben realizarse según los contratos y envía una solicitud al software del recopilador;
- Software El recopilador de la lista recibida asigna aquellas tareas que no exceden el límite de interacciones.
Según la conclusión del especialista en control de calidad, en la implementación existente, tanto el operador como ASANM no podrían programar una llamada a todos los números del deudor.
En general, se entendió que se implementó el cuarto nivel de restricciones (restricciones innecesarias): para realizar una llamada a otros números, debe cancelar manualmente la tarea pendiente. De hecho, resultó que la ley no limita el número de intentos de contactar al deudor, sino el número de intentos exitosos de interacción. Y esto significaba que el límite de interacción debería calcularse en función de los resultados de las tareas.
En este sentido, iniciamos un cambio en el formato de implementación y se eligió una forma más conveniente de cumplir con los requisitos:
- contar el número de interacciones en función de los resultados de las actividades;
- si no se alcanza el límite, entonces permita al usuario / ASANM programar eventos sin restricciones;
- Si se alcanza el límite, cancele los eventos innecesarios y prohíba su cita.
Tomó toda una carrera para hacer los cambios, pero definitivamente podemos decir que esta vez no se desperdició en vano y ahora, como los usuarios comunes no experimentarán ningún inconveniente mientras trabajan en la aplicación, por lo que el propietario del sistema podrá planificar el trabajo de los operadores que usan ASANM.
Conclusión
Se aconseja a todos aquellos que, al implementar restricciones, se preocupan por el usuario y el cliente, que se adhieran a dos reglas simples:
- "Con un número suficiente de niñeras, el niño no perderá su ojo", es decir, debe proteger suficientemente al usuario de cometer errores que puedan dañarlo a él o al propietario del sistema.
- “Tener miedo a los lobos, pero ir al bosque”: se deben evitar restricciones innecesarias, porque de lo contrario se pierde el valor del producto desarrollado para el usuario.
1 Los requisitos están establecidos por la Ley Federal de 03.07.2016 N 230- "Sobre la protección de los derechos e intereses legales de las personas cuando realizan actividades para devolver deudas vencidas y sobre la modificación de la Ley Federal" sobre actividades de microfinanzas y organizaciones de microfinanzas ".