В современном мире востребованы приложения, которые способны максимально эффективно соблюсти интересы всех сторон. Часто это реализуется с помощью различного рода ограничений. Например, они не позволяют пользователю совершить действия, которые будут невыгодны ему самому или владельцу системы. При этом необходимо свести к минимуму дискомфорт, который вызывают такие ограничения.
К примеру, владельцу системы необходимо, чтобы в форме обратной связи номер телефона был указан в формате +7 (ХХХ) ХХХ-ХХ-ХХ для дальнейшего автоматизированного использования. Для удобства пользователя лучше использовать не просто подсказку или валидацию при отправке формы, а маску ввода, исключающую внесение данных в неверном формате. Получается, и волки сыты, и овцы целы.
В некоторых случаях система ограничивает пользователя, чтобы уберечь от потенциально возможных потерь. Так, например, подобно требованиям пристегивать ремень безопасности перед началом движения, в сервисах онлайн-оплаты необходимо не только ввести данные с карты, но и подтвердить оплату кодом из смс-сообщения, что значительно сокращает вероятность хищения денежных средств. И следует отметить, что подобная забота о безопасности пользователя выгодна и владельцу сервиса, так как сокращает репутационные риски, а иначе может выйти, как в произведении Алексея Апухтина: «… он ли украл или у него украли… Главное то, что он был замешан в гадком деле...».
Таким образом, при разработке приложения необходимо продумать функциональные возможности так, чтобы угодить и непосредственному заказчику, и рядовому пользователю. С учетом этого можно выделить пять уровней ограничений системы:
По первому и пятому уровням ярким примером может послужить всем знакомая ситуация, когда в магазине кассир кричит «Галя, отмена!», и всемогущая Галя приходит на помощь. В этом случае у кассира полностью заблокирована функция удаления пробитого товара из чека, а у Гали нет ограничения на совершение этой операции. То есть эти степени ограничения часто могут быть использованы в рамках реализации ролевой модели.
А в случае, когда мы не говорим о крайностях, в системе создается один из промежуточных вариантов. И тогда важная задача любого проекта — ввести все необходимые ограничения, но не избыточные (третий уровень). Чтобы, например, не на каждом этапе заполнения заявки заполнять капчу (четвертый уровень), а только перед отправкой полной формы. Или чтобы поле для ввода телефона содержало не только маску ввода (второй уровень), но и проверку того, что пользователь ввел 11 цифр номера.
Приведем пример. Был у нас проект по разработке приложения для сопровождения процесса взыскания (далее — ПО Коллектор). В рамках старта проекта мы составили и согласовали техническое задание, после чего работа аналитика по большей части была завершена. Стоит отметить, что заказчиком была компания, которая только начинает заниматься сбором долгов, то есть, как выяснилось в дальнейшем, процесс работы еще находится на стадии отладки.
И вот на тот момент, когда разработка на проекте велась уже около полугода, поступила новая информация об особенностях работы потенциальных пользователей системы, а также о планируемых доработках. Следует сразу оговориться, что на тот момент, мы реализовали в том числе следующие функциональные задачи:
Уточним, что последняя из перечисленных функциональностей заключалась в следующем: ПО Коллектор ограничивало возможность назначения задач, которые потенциально могли нарушить требования закона. При этом в случае, если не удалось дозвониться (пользователь ставит соответствующий результат звонка), задача откладывается и оператор может повторно вернуться к ней позже. То есть неудачная попытка дозвона не может считаться взаимодействием, а задачу можно попробовать выполнить повторно.
Что же стало известно об особенностях работы пользователей? Оказалось, что при неудачной попытке дозвониться на мобильный должника оператор будет не только откладывать задачу, но и также, если за должником закреплены какие-либо другие номера, сразу осуществлять попытку дозвониться по ним.
В условиях сжатых сроков было нецелесообразно вновь погружать в проект аналитика, поэтому наш QA-специалист получил задачу рассмотреть, соответствует ли существующая реализация тому, как планируется использовать приложение на стороне заказчика. В ходе анализа мы выстроили следующую логическую цепочку:
Следует отметить, что по информации от заказчика неудачные попытки дозвона на практике случаются достаточно часто.
Кроме того, планировалась разработка функционала по интеграции ПО Коллектор с аналитической системой автоматического назначения мероприятий (далее — АСАНМ), которая создана на стороне заказчика. Суть подразумевалась следующая:
По заключению QA-специалиста, в существовавшей реализации как оператор, так и АСАНМ не смогли бы запланировать обзвон всех номеров должника.
В общем сложилось понимание того, что был реализован четвертый уровень ограничений (излишние ограничения): для совершения звонка на другие номера нужно вручную отменять отложенную задачу. По факту же получалось, что закон ограничивает не количество попыток связаться с должником, а количество успешных попыток взаимодействия. И это означало, что лимит взаимодействий нужно подсчитывать, исходя из результатов выполнения задач.
В связи с этим мы инициировали изменение формата реализации и был выбран более целесообразный способ соблюдения требования:
На внесение изменений ушел целый спринт, но точно можно сказать, что это время потрачено не зря и теперь как рядовые пользователи не будут испытывать неудобств при работе в приложении, так и владелец системы будет иметь возможность планировать работу операторов с помощью АСАНМ.
Всем тем, кто при реализации ограничений заботится о пользователе и заказчике, советуем придерживаться двух простых правил:
1 Требования устанавливаются Федеральным законом от 03.07.2016 N 230-ФЗ «О защите прав и законных интересов физических лиц при осуществлении деятельности по возврату просроченной задолженности и о внесении изменений в Федеральный закон «О микрофинансовой деятельности и микрофинансовых организациях».
К примеру, владельцу системы необходимо, чтобы в форме обратной связи номер телефона был указан в формате +7 (ХХХ) ХХХ-ХХ-ХХ для дальнейшего автоматизированного использования. Для удобства пользователя лучше использовать не просто подсказку или валидацию при отправке формы, а маску ввода, исключающую внесение данных в неверном формате. Получается, и волки сыты, и овцы целы.
В некоторых случаях система ограничивает пользователя, чтобы уберечь от потенциально возможных потерь. Так, например, подобно требованиям пристегивать ремень безопасности перед началом движения, в сервисах онлайн-оплаты необходимо не только ввести данные с карты, но и подтвердить оплату кодом из смс-сообщения, что значительно сокращает вероятность хищения денежных средств. И следует отметить, что подобная забота о безопасности пользователя выгодна и владельцу сервиса, так как сокращает репутационные риски, а иначе может выйти, как в произведении Алексея Апухтина: «… он ли украл или у него украли… Главное то, что он был замешан в гадком деле...».
Таким образом, при разработке приложения необходимо продумать функциональные возможности так, чтобы угодить и непосредственному заказчику, и рядовому пользователю. С учетом этого можно выделить пять уровней ограничений системы:
- Никак не ограничивать пользователя, то есть рассчитывать, что он сам не будет ошибаться и не нанесет вред себе или владельцу системы.
- Частично ограничить — пользователь может совершить ошибку, но менее вероятно (или менее серьезную).
- Ввести необходимые ограничения, но не избыточные — пользователь ограничен настолько, что не может совершить ошибку, но при этом ограничения не создают проблем в использовании системы. Это идеальный вариант.
- Излишне ограничить — пользователь ограничен так, что это мешает ему пользоваться системой.
- Полностью ограничить пользователя, то есть заблокировать фичу.
По первому и пятому уровням ярким примером может послужить всем знакомая ситуация, когда в магазине кассир кричит «Галя, отмена!», и всемогущая Галя приходит на помощь. В этом случае у кассира полностью заблокирована функция удаления пробитого товара из чека, а у Гали нет ограничения на совершение этой операции. То есть эти степени ограничения часто могут быть использованы в рамках реализации ролевой модели.
А в случае, когда мы не говорим о крайностях, в системе создается один из промежуточных вариантов. И тогда важная задача любого проекта — ввести все необходимые ограничения, но не избыточные (третий уровень). Чтобы, например, не на каждом этапе заполнения заявки заполнять капчу (четвертый уровень), а только перед отправкой полной формы. Или чтобы поле для ввода телефона содержало не только маску ввода (второй уровень), но и проверку того, что пользователь ввел 11 цифр номера.
Приведем пример. Был у нас проект по разработке приложения для сопровождения процесса взыскания (далее — ПО Коллектор). В рамках старта проекта мы составили и согласовали техническое задание, после чего работа аналитика по большей части была завершена. Стоит отметить, что заказчиком была компания, которая только начинает заниматься сбором долгов, то есть, как выяснилось в дальнейшем, процесс работы еще находится на стадии отладки.
И вот на тот момент, когда разработка на проекте велась уже около полугода, поступила новая информация об особенностях работы потенциальных пользователей системы, а также о планируемых доработках. Следует сразу оговориться, что на тот момент, мы реализовали в том числе следующие функциональные задачи:
- назначение задачи на осуществление звонка должнику;
- осуществление назначенной задачи;
- фиксирование результата взаимодействия (пользователем вручную);
- обеспечение соблюдения требований законодательства РФ по частоте взаимодействий с должниками 1.
Уточним, что последняя из перечисленных функциональностей заключалась в следующем: ПО Коллектор ограничивало возможность назначения задач, которые потенциально могли нарушить требования закона. При этом в случае, если не удалось дозвониться (пользователь ставит соответствующий результат звонка), задача откладывается и оператор может повторно вернуться к ней позже. То есть неудачная попытка дозвона не может считаться взаимодействием, а задачу можно попробовать выполнить повторно.
Что же стало известно об особенностях работы пользователей? Оказалось, что при неудачной попытке дозвониться на мобильный должника оператор будет не только откладывать задачу, но и также, если за должником закреплены какие-либо другие номера, сразу осуществлять попытку дозвониться по ним.
В условиях сжатых сроков было нецелесообразно вновь погружать в проект аналитика, поэтому наш QA-специалист получил задачу рассмотреть, соответствует ли существующая реализация тому, как планируется использовать приложение на стороне заказчика. В ходе анализа мы выстроили следующую логическую цепочку:
- У должника может быть несколько номеров (мобильный, домашний, рабочий), но звонок запланировать можно только на один номер.
- Если же оператору не удастся дозвониться до клиента, то задача будет отложена, но позвонить на другой номер по-прежнему будет нельзя, т.к. отложенная задача также будет блокировать назначение звонка на остальные номера.
- Поэтому пользователю для попытки дозвониться на другой номер нужно вручную отменить отложенную задачу и назначить новую.
- Но при этом и по другим номерам возможно не удастся дозвониться. И тогда отложенные из-за недозвона задачи, получается, зря были отменены. Нужно назначать их снова, чтобы вновь позвонить попозже.
Следует отметить, что по информации от заказчика неудачные попытки дозвона на практике случаются достаточно часто.
Кроме того, планировалась разработка функционала по интеграции ПО Коллектор с аналитической системой автоматического назначения мероприятий (далее — АСАНМ), которая создана на стороне заказчика. Суть подразумевалась следующая:
- ежедневно (один раз в день) АСАНМ формирует список задач, которые необходимо выполнить по договорам, и направляет запрос в ПО Коллектор;
- ПО Коллектор из полученного списка назначает те задачи, которые не превышают лимит взаимодействий.
По заключению QA-специалиста, в существовавшей реализации как оператор, так и АСАНМ не смогли бы запланировать обзвон всех номеров должника.
В общем сложилось понимание того, что был реализован четвертый уровень ограничений (излишние ограничения): для совершения звонка на другие номера нужно вручную отменять отложенную задачу. По факту же получалось, что закон ограничивает не количество попыток связаться с должником, а количество успешных попыток взаимодействия. И это означало, что лимит взаимодействий нужно подсчитывать, исходя из результатов выполнения задач.
В связи с этим мы инициировали изменение формата реализации и был выбран более целесообразный способ соблюдения требования:
- подсчет количества взаимодействий осуществлять по результатам выполнения мероприятий;
- если лимит не достигнут, то разрешить пользователю/АСАНМ назначать мероприятия без ограничений;
- если лимит достигнут, то отменять излишние мероприятия и запретить их назначение.
На внесение изменений ушел целый спринт, но точно можно сказать, что это время потрачено не зря и теперь как рядовые пользователи не будут испытывать неудобств при работе в приложении, так и владелец системы будет иметь возможность планировать работу операторов с помощью АСАНМ.
Вывод
Всем тем, кто при реализации ограничений заботится о пользователе и заказчике, советуем придерживаться двух простых правил:
- «У достаточного количества нянек дитя не потеряет глаз» — то есть нужно в достаточной мере оберегать пользователя от совершения ошибок, которые могут навредить ему самому или владельцу системы.
- «Волков бояться, но в лес ходить»- необходимо избегать излишних ограничений, потому что иначе теряется ценность разрабатываемого продукта для пользователя.
1 Требования устанавливаются Федеральным законом от 03.07.2016 N 230-ФЗ «О защите прав и законных интересов физических лиц при осуществлении деятельности по возврату просроченной задолженности и о внесении изменений в Федеральный закон «О микрофинансовой деятельности и микрофинансовых организациях».
