Одобрение должно происходить до значимого действия
Проверка человеком полезна только тогда, когда рецензент может понять, отклонить и изменить предлагаемое действие. Уведомление, отправленное после необратимой операции, не является этапом одобрения.
Классифицируйте действия по последствиям и обратимости. Составление резюме сервиса отличается от отправки обязательства клиенту, изменения доступа или удаления записи. Оставьте полномочия по последним действиям вне модели.
Делайте одобрение конкретным
Экран одобрения должен идентифицировать объект, предлагаемое изменение, исходную информацию и ожидаемое последствие. Утвержденная полезная нагрузка должна быть той, которую сервер позже выполняет. Если запись изменилась в это время, требуйте повторного рассмотрения, а не применения устаревшего решения.
| Контроль | На какой вопрос он отвечает |
|---|---|
| Проверка личности и роли | Может ли это лицо одобрить это действие? |
| Точная предлагаемая полезная нагрузка | Что изменится? |
| Срок действия и версия записи | Актуально ли одобрение? |
| Идентификатор одноразовой операции | Выполнено ли оно уже? |
| Событие аудита | Кто одобрил и что фактически произошло? |
Общее «да» в длинном чате может быть двусмысленным. Привязывайте его к видимому предложению или четко определенному идентификатору действия. Не выводите одобрение из молчания.
Проектирование отклонения и восстановления
Позвольте рецензенту редактировать, отклонять или запрашивать дополнительную информацию. Сохраняйте рассуждения и исправления, где это уместно. Если выполнение не удалось после одобрения, честно отобразите это состояние и сделайте поведение при повторном выполнении безопасным.
Усталость от проверок имеет значение: направление каждого тривиального действия человеку может привести к привычному одобрению. Используйте детерминированные правила для работы с низким риском и четко определенной задачей и резервируйте значимый обзор для неопределенности или последствий. Граница должна быть документированным бизнес-решением.
Проверка состояний гонки
Попробуйте двойное одобрение, истекшее одобрение, измененные записи и рецензента, у которого отозвана роль. Подтвердите, что проверки на стороне сервера по-прежнему защищают операцию. Отключенная кнопка в браузере недостаточна.
Используйте проектирование рабочих процессов ИИ, чтобы сделать подотчетность видимой, включая путь, когда рецензент отклоняет предложение.
Практический вопрос
Что делать, если запись изменилась после одобрения?
Сравните её версию перед выполнением. Измененная запись должна требовать повторного рассмотрения точного предлагаемого действия. Повторное использование устаревшего одобрения может применить решение к другой ситуации.