Писали ли пользовательскую часть для CRM системы
Что проверяют
Работали ли вы на стыке с интерфейсом или только с внутренними сервисами. В CRM сложность не в вёрстке, а в правах на записи, истории изменений и списках, которые на боевых данных вырастают до сотен тысяч строк.
Как отвечать
Сначала очертите свою часть: серверный рендеринг форм и шаблонов, API для отдельного фронта или и то и другое. Дальше по существу:
- модель данных: клиент, сделка, этап, ответственный, история смены статуса и владельца;
- права: менеджер видит своих, руководитель отдел, проверка на уровне записи, а не только на уровне страницы;
- списки: пагинация, фильтры, сортировка, предзагрузка связей против запроса на каждую строку;
- формы: серверная валидация, защита от повторной отправки, понятный текст ошибки;
- фон: импорт и выгрузка уходят в очередь задач, а не выполняются в обработчике запроса.
Если интерфейс писал кто-то другой, скажите прямо и расскажите, как договаривались о контракте: форма ответа, коды ошибок, кто правит документацию при изменении. Отдельный плюс, если можете объяснить, как в вашей системе устроены справочники и настраиваемые поля: в CRM их почти всегда просят добавлять без выката новой версии.
Где спотыкаются
Отвечают цифрами вроде ускорения работы пользователей на треть. Замера не было, и первый же вопрос про методику заканчивает тему. Надёжнее назвать изменение по факту: отчёт перестали собирать вручную.
Описывают только внешний вид и теряются на модели данных: куда пишется смена ответственного, что видно в истории, можно ли вернуть сделку на прошлый этап и что при этом произойдёт с задачами.
Не думают про объём. Список сделок без пагинации и с обращением к базе на каждую строку прекрасно работает на демонстрационных данных и встаёт колом на боевых.