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