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