No mundo de hoje, os aplicativos estão em demanda, capazes de atender da maneira mais eficaz aos interesses de todas as partes. Geralmente isso é implementado usando vários tipos de restrições. Por exemplo, eles não permitem que o usuário execute ações que seriam desvantajosas para si ou para o proprietário do sistema. Nesse caso, é necessário minimizar o desconforto causado por essas restrições.
Por exemplo, o proprietário do sistema precisa de um número de telefone no formulário de feedback no formato +7 () -- para uso automatizado adicional. Para maior comodidade do usuário, é melhor usar não apenas uma dica ou validação ao enviar o formulário, mas uma máscara de entrada que exclui a inserção de dados no formato errado. Acontece que os lobos estão cheios e as ovelhas intactas.
Em alguns casos, o sistema limita o usuário a se proteger contra possíveis perdas. Por exemplo, como usar o cinto de segurança antes de dirigir, nos serviços de pagamento on-line, você precisa não apenas inserir dados do cartão, mas também confirmar o pagamento por código de uma mensagem SMS, o que reduz significativamente a probabilidade de roubo de dinheiro. E deve-se notar que essa preocupação com a segurança do usuário é benéfica para o proprietário do serviço, pois reduz os riscos à reputação, caso contrário, pode surgir como no trabalho de Alexei Apukhtin: “... se ele roubou ou foi roubado dele ... O principal é que ele estava envolvido em coisa desagradável ... ".
Assim, ao desenvolver um aplicativo, é necessário refletir sobre a funcionalidade de forma a agradar o cliente direto e o usuário médio. Com isso em mente, cinco níveis de limitações do sistema podem ser distinguidos:
- Não há como limitar o usuário , ou seja, confiar nele para não cometer erros e não prejudicar a si mesmo ou ao proprietário do sistema.
- Limite parcial - o usuário pode cometer um erro, mas é menos provável (ou menos sério).
- Introduzir as restrições necessárias , mas não excessivas - o usuário é tão limitado que não pode cometer um erro, mas as restrições não criam problemas no uso do sistema. Esta é uma opção ideal.
- Não é necessário limitar - o usuário é limitado, impedindo-o de usar o sistema.
- Limite completamente o usuário , ou seja, bloqueie o recurso.
Para o primeiro e o quinto níveis, um exemplo familiar é a situação familiar quando um caixa grita “Galya, cancele!” Na loja, e o todo-poderoso Galya vem em socorro. Nesse caso, o caixa bloqueou completamente a função de remover mercadorias perfuradas do cheque, e Gali não tem restrições a esta operação. Ou seja, esses graus de restrição geralmente podem ser usados como parte da implementação do modelo.
E no caso em que não estamos falando de extremos, uma das opções intermediárias é criada no sistema. E a tarefa importante de qualquer projeto é introduzir todas as restrições necessárias, mas não excessivas (terceiro nível). Portanto, por exemplo, não em cada estágio do preenchimento de um aplicativo para preencher um captcha (quarto nível), mas apenas antes de enviar o formulário completo. Ou para que o campo de entrada do telefone contenha não apenas uma máscara de entrada (segundo nível), mas também uma verificação de que o usuário inseriu 11 dígitos do número.
Nós damos um exemplo. Tivemos um projeto para desenvolver um aplicativo para acompanhar o processo de coleta (doravante - software Collector). Como parte do lançamento do projeto, redigimos e concordamos com os termos de referência, após os quais o trabalho do analista na maior parte foi concluído. Vale ressaltar que o cliente era uma empresa que estava apenas começando a cobrar dívidas, ou seja, como se viu mais adiante, o processo ainda está na fase de depuração.
E, naquele momento, quando o desenvolvimento do projeto já estava em torno de seis meses, novas informações foram recebidas sobre os recursos do trabalho dos usuários em potencial do sistema, bem como sobre as melhorias planejadas. Deve-se notar imediatamente que, naquele momento, implementamos as seguintes tarefas funcionais, incluindo:
- atribuição de uma tarefa para fazer uma ligação para o devedor;
- a implementação da tarefa atribuída;
- fixando o resultado da interação (manualmente pelo usuário);
- garantir o cumprimento dos requisitos da legislação da Federação da Rússia sobre a frequência das interações com os devedores 1 .
Esclareçamos que a última das funcionalidades listadas foi a seguinte: O software Collector limitou a possibilidade de atribuir tarefas que potencialmente violariam os requisitos da lei. Nesse caso, se não foi possível concluir (o usuário define o resultado da chamada correspondente), a tarefa é adiada e o operador pode retornar mais tarde. Ou seja, uma tentativa de discagem com falha não pode ser considerada uma interação e você pode tentar concluir a tarefa novamente.
O que se tornou conhecido sobre os recursos da experiência do usuário? Verificou-se que, no caso de uma tentativa malsucedida de acessar o celular do devedor, o operador não apenas adiará a tarefa, mas também, se outros números forem atribuídos ao devedor, tente alcançá-los imediatamente.
Dado os prazos apertados, era impraticável imergir novamente o analista no projeto; portanto, nosso especialista em QA teve a tarefa de considerar se a implementação existente é consistente com a forma como o aplicativo está planejado para ser usado no cliente. Durante a análise, criamos a seguinte cadeia lógica:
- O devedor pode ter vários números (celular, casa, trabalho), mas você pode agendar uma chamada para apenas um número.
- Se o operador não chegar ao cliente, a tarefa será adiada, mas ainda será impossível ligar para outro número, porque a tarefa pendente também bloqueará o compromisso de uma chamada para outros números.
- Portanto, para tentar alcançar outro número, o usuário precisa cancelar manualmente a tarefa pendente e atribuir um novo.
- Mas, ao mesmo tempo, outros números podem não conseguir passar. E, em seguida, as tarefas adiadas devido à falta de discagem foram canceladas em vão. Você precisa nomeá-los novamente para ligar novamente mais tarde.
Note-se que, de acordo com as informações do cliente, tentativas malsucedidas de discagem na prática ocorrem com bastante frequência.
Além disso, foi planejado o desenvolvimento de uma funcionalidade para integração do software Collector com um sistema analítico para nomeação automática de eventos (doravante - ASANM), criada no lado do cliente. A essência era a seguinte:
- diariamente (uma vez por dia), o ASANM forma uma lista de tarefas que devem ser executadas sob os contratos e envia uma solicitação ao software Collector;
- Software O coletor da lista recebida atribui as tarefas que não excedem o limite de interações.
De acordo com a conclusão do especialista em controle de qualidade, na implementação existente, o operador e a ASANM não poderiam agendar uma chamada para todos os números do devedor.
Em geral, havia um entendimento de que o quarto nível de restrições foi implementado (restrições desnecessárias): para fazer uma chamada para outros números, é necessário cancelar manualmente a tarefa pendente. De fato, a lei não limita o número de tentativas de contato com o devedor, mas o número de tentativas bem-sucedidas de interação. E isso significava que o limite de interação deveria ser calculado com base nos resultados das tarefas.
Nesse sentido, iniciamos uma mudança no formato de implementação e uma maneira mais rápida de atender aos requisitos foi escolhida:
- conte o número de interações com base nos resultados das atividades;
- se o limite não for atingido, permita ao usuário / ASANM agendar eventos sem restrições;
- se o limite for atingido, cancele eventos desnecessários e proíba sua nomeação.
Demorou um sprint inteiro para fazer as alterações, mas podemos dizer definitivamente que esse tempo não foi desperdiçado em vão e agora, como usuários comuns não experimentarão qualquer inconveniente ao trabalhar no aplicativo, para que o proprietário do sistema possa planejar o trabalho dos operadores usando o ASANM.
Conclusão
Todos aqueles que, ao implementar restrições, se preocupam com o usuário e o cliente, são aconselhados a seguir duas regras simples:
- “Com um número suficiente de babás, a criança não perde o olho” - ou seja, você precisa proteger suficientemente o usuário de cometer erros que possam prejudicá-lo ou ao proprietário do sistema.
- “Ter medo dos lobos, mas ir para a floresta” - restrições desnecessárias devem ser evitadas, pois, caso contrário, o valor do produto desenvolvido para o usuário será perdido.
1 Os requisitos são estabelecidos pela Lei Federal de 07.03.2016 N 230- “Sobre a proteção dos direitos e interesses jurídicos dos indivíduos ao realizar atividades para devolver dívidas vencidas e emendar a lei federal“ Sobre atividades de microfinanças e organizações de microfinanças ”.