Интеграции
Кастомная CRM: ТЗ на данные, права и рабочие процессы
Как подготовить требования к собственной CRM: модель данных, переходы статусов, права сотрудников, миграция и приёмка. Заполняемый бриф проекта.
Сначала докажите необходимость собственной CRM
Техническое задание на кастомную CRM начинается с процесса, который не помещается в готовое решение без существенных потерь. Список экранов «клиенты, сделки, отчёты» этого не объясняет: такие разделы есть почти везде. Зафиксируйте конкретное ограничение: сложное согласование расчёта, несколько объектов одного заказчика, отраслевые документы, особая модель доступа или связь продажи с производством. Покажите, как сотрудники обходят ограничение сейчас и какую работу выполняют повторно. Это исходные данные для решения о разработке, а не обещание окупаемости.
Сравните три варианта: настройку существующей системы, отдельный модуль рядом с ней и полную замену. Для каждого запишите стоимость владения в одинаковых границах: лицензии, обмен данными, сопровождение, обновления, обучение и возможность выгрузить историю. Если причина проекта сводится к неудобной карточке или одному отчёту, отдельное расширение может быть разумнее собственной платформы. В ТЗ следует сохранить причины выбора, чтобы через полгода команда понимала, ради чего приняла дополнительную ответственность за продукт.
Определите первый сквозной результат: например, менеджер принимает обращение, рассчитывает предложение, согласует исключение и передаёт оплаченный заказ исполнителю. Этот учебный сценарий описывает границу первой версии, а не результаты конкретного клиента. Для каждой операции укажите исходный документ, роль, решение и наблюдаемое изменение. Функции, которые не помогают пройти этот путь, вынесите в отдельную очередь. У неё должен быть собственный приоритет, а не скрытое обещание включить всё в первоначальную цену.
Опишите сущности до проектирования карточек
Разделите человека, организацию, обращение, сделку, заказ и объект выполнения. Один человек может представлять несколько организаций, а одна сделка включать несколько объектов. Если назвать всё «клиентом», разработчики вынужденно придумают связи самостоятельно. Приложите несколько обезличенных примеров: повторное обращение старого покупателя, два заказа одновременно, смена контактного лица и отменённая сделка с сохранёнными документами. На этих примерах проверяется модель, пока её изменение ещё не требует миграции реальных данных.
Для каждого поля задайте смысл, формат, обязательность и владельца. «Сумма» может обозначать предварительную оценку, подписанный договор, выставленный счёт или полученную оплату. Это разные значения, даже если иногда они совпадают. Укажите валюту, правила округления, историю изменений и источник подтверждения. Отсутствующее значение не должно превращаться в ноль. Ноль означает известную нулевую величину; неизвестная сумма требует отдельного состояния, иначе отчёт станет выглядеть точным при неполных исходных данных.
Заранее решите, какие идентификаторы сохраняются при импорте и объединении записей. Совпадение телефона помогает найти кандидатов на сопоставление, но не доказывает одинаковый заказ. Слияние должно сохранять исходные связи и объяснение решения. Опишите, кто может объединять записи, как увидеть последствия до подтверждения и как разбирать ошибочное объединение. Полезный результат этого раздела — словарь сущностей с примерами, таблица связей и перечень действий, которые нельзя выполнять автоматически.
Превратите этапы в проверяемые переходы
У каждого статуса нужны условия входа, разрешённые действия и условия выхода. «В работе» само по себе ничего не говорит о наличии договора, оплаты или назначенного исполнителя. Если бизнес различает эти события, система тоже должна различать их. Для перехода укажите исполнителя, обязательные поля, уведомления и последствия для отчётов. Отдельно перечислите переходы назад: пересогласование цены, возврат на исправление, отмена после частичной оплаты и повторное открытие закрытого обращения.
Ручное действие и автоматическое правило могут происходить одновременно. Учебный пример: менеджер уже взял заявку, а распределитель пытается назначить её другому сотруднику. Требование должно описывать победившее решение и след в журнале, а не только интерфейс кнопки. В документации PostgreSQL об изоляции транзакций показано, что конкурентные изменения требуют осознанного выбора поведения. Конкретный механизм выбирает разработчик; заказчик задаёт бизнес-инвариант: у заявки один действующий ответственный, а подтверждённое ручное назначение не исчезает молча.
Добавьте исключения с владельцами. Если не удалось получить реквизиты, отправить документ или связаться с внешней системой, карточка не должна бесконечно висеть в неопределённом статусе. Опишите очередь разбора, уведомление сотруднику и допустимый способ продолжения. Не требуйте автоматического повторения любой операции: повторное чтение и повторное списание денег имеют разные последствия. При неизвестном результате внешнего действия сначала нужна сверка, затем решение о повторе.
Согласуйте доступ к данным на уровне действий
Матрица доступа должна отвечать не только на вопрос «какой раздел виден». Уточните, какие записи доступны сотруднику, какие поля он может менять, разрешены ли экспорт и массовые операции. Руководителю филиала может быть нужен общий отчёт без права читать личные комментарии другого подразделения. Внешнему исполнителю достаточно задания и адреса объекта, но не всей истории переговоров. Такие различия следует описать до разработки, потому что они влияют на запросы, интерфейс и журналирование.
Для каждой роли составьте положительный и отрицательный сценарий. Сотрудник видит свой заказ и не получает чужой при прямом обращении по его идентификатору. Закрытая кнопка в интерфейсе не является доказательством ограничения серверного доступа. PostgreSQL поддерживает политики доступа к строкам, однако наличие такого механизма не заменяет проектирование ролей и проверку приложения. В ТЗ фиксируйте требуемый результат независимо от выбранной базы: ограничение действует в карточке, поиске, отчёте, выгрузке и API.
Продумайте жизненный цикл сотрудника: приглашение, смену подразделения, временное замещение и увольнение. После изменения прав старая сессия не должна бесконечно сохранять прежние возможности. Укажите владельца выдачи доступа и способ регулярной проверки. Для сервисных интеграций нужны отдельные учётные записи с понятной областью действий. Общий административный пароль для всех подключений затрудняет расследование ошибок и не позволяет безопасно отключить только один источник.
Опишите обмен и перенос истории
Составьте карту интеграций: канал обращений, телефония, почта, учётная система, сайт, документы. Для каждой связи определите направление, владельца данных, частоту обновления и допустимое отставание. Если адрес изменяется и в CRM, и в учётной системе, правило выбора версии должно быть явным. Иначе обмен начнёт перезаписывать данные по очереди. Укажите также, какие поля доступны только для чтения и какие изменения требуют подтверждения сотрудника.
Перенос истории проверяйте на отдельной копии. Нужны исходные количества записей, контрольные суммы бизнес-показателей и выборочная проверка сложных случаев. Приложенные файлы, авторы заметок, даты и связи часто важнее красивой основной карточки. Зафиксируйте часовой пояс и правило преобразования старых статусов. Не переносите неподтверждённый текст «оплатил» в подтверждённую выручку. Если значение невозможно восстановить достоверно, сохраните исходный факт и пометку о происхождении вместо выдуманного уточнения.
Опишите переходный период. Когда прекращается запись в старую систему, кто разрешает запуск новой и как сверяются изменения между пробным импортом и переключением? Возврат к прежней версии приложения не обязательно возвращает прежние данные. Поэтому план восстановления должен отдельно рассматривать код, структуру базы и новые записи, появившиеся после запуска. Сотрудники должны знать, где продолжать работу при остановке миграции, чтобы не вести две расходящиеся истории параллельно.
Задайте нагрузку через рабочие операции
Фраза «CRM должна работать быстро» не позволяет принять результат. Укажите число одновременно работающих сотрудников, объём истории, типичные фильтры и самые тяжёлые операции. Для открытия списка, поиска, сохранения карточки и построения отчёта согласуйте отдельные пределы времени и условия измерения. Эти пределы выбираются под ваш процесс; универсальное число без данных о среде не является обоснованным требованием. Проверяйте не только среднее, но и медленные случаи, с которыми сталкиваются сотрудники.
Испытание должно включать фоновые задачи. Пока один сотрудник ищет клиента, другой сохраняет сделку, а система импортирует обращения и строит отчёт. Маленькая демонстрационная база не воспроизводит такую нагрузку. Подготовьте обезличенный набор сопоставимого размера и контролируйте память, очередь запросов, ошибки и время ответа. При недостатке ресурсов тяжёлая выгрузка должна ограничиваться или переноситься в фон, сохраняя доступность основных действий. Это требование к поведению, а не к конкретной технологии.
Для исходящих сообщений различайте принятие задания системой и подтверждение доставки внешним сервисом. Быстрое появление сообщения в истории удобно, но не должно скрывать окончательную ошибку. Нужны устойчивый идентификатор, порядок отправки и понятный способ повторить безопасную операцию. На приёмке отключите внешний сервис, обновите страницу и восстановите соединение. Сообщение должно сохранить свой статус и место в очереди, а повторное нажатие не должно незаметно создать вторую отправку.
Подготовьте приёмку как набор доказательств
Каждому важному требованию сопоставьте сценарий с исходными данными, действием и ожидаемым результатом. «Работает интеграция» замените проверкой: одно обращение поступает дважды, но создаёт одну заявку; изменённый телефон обновляется по согласованному правилу; недоступный сервис формирует задачу разбора. Укажите, где виден результат: карточка, журнал, отчёт или запись очереди. Скриншот успешного экрана полезен, но не доказывает отсутствие дублей и соблюдение прав в остальных путях доступа.
Разделите обязательные блокеры запуска и допустимые недочёты. Потеря заявки, неверное списание или раскрытие чужих данных не должны растворяться в общем проценте пройденных тестов. Для некритичных замечаний зафиксируйте срок и владельца исправления. Приёмочная комиссия должна понимать, какая версия программы и какой набор данных проверялись. После существенного изменения повторяются затронутые сценарии, а не автоматически переносится отметка об успешной проверке с предыдущей сборки.
Включите обучение на реальных ролях. Менеджер должен самостоятельно пройти свой путь без подсказок разработчика, руководитель — получить согласованный отчёт, администратор — восстановить доступ сотруднику. Запишите вопросы, которые возникают во время этой проверки: они показывают пробелы в интерфейсе или инструкции. Передача считается законченной, когда у команды есть рабочие материалы и доступы, а не только видеозапись общей демонстрации продукта на встрече.
Передайте продукт вместе с правилами сопровождения
В договорённостях о результате перечислите исходный код, схему данных, описание API, инструкции запуска, резервного копирования и восстановления. Назначьте владельца домена, инфраструктуры и интеграционных учётных записей. Уточните, кто получает уведомления об ошибках вне рабочего времени и какие действия может выполнить самостоятельно. Если критический процесс зависит от одного разработчика, собственная CRM остаётся организационно уязвимой даже при хорошем коде. Это необходимо обсудить до начала проекта.
Согласуйте порядок изменений после запуска. Новое поле может повлиять на импорт, отчёт, права и экспорт, поэтому запрос должен содержать цель и затронутые сценарии. Ведите историю решений и версии правил. Обратную связь сотрудников полезно собирать отдельно от аварий: неудобная сортировка и потеря данных требуют разной срочности. Для оценки пользы сравнивайте одинаковые операции до и после изменения, учитывая сезонность и состав команды; рост числа карточек сам по себе не доказывает рост продаж.
Заполняемый бриф в источниках статьи помогает собрать границы, модель данных, роли и приёмочные примеры. Перед оценкой приложите несколько обезличенных рабочих документов и список нерешённых вопросов с ответственными. Хорошее ТЗ не обязано заранее содержать каждую кнопку, но должно отделять подтверждённые правила от гипотез. Тогда подрядчик оценивает понятный объём, а заказчик принимает систему по наблюдаемой работе, сохраняя возможность безопасно развивать её дальше.
Источники
- Row Security Policies
PostgreSQL Documentation / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Transaction Isolation
PostgreSQL Documentation / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Скачать заполняемый бриф / ТЗ (.txt)
Малевич — практическое приложение / доступ 2026-10-18
Сохраните файл и заполните данные проекта, открытые решения и критерии приёмки.
FAQ
Когда собственная CRM оправдана вместо доработки готовой?
Когда существенные особенности данных и процесса нельзя устойчиво реализовать доступными настройками и расширениями. Решение принимают после сравнения конкретных сценариев, ограничений и стоимости владения, а не только по удобству макета.
Нужно ли описывать права до разработки экранов CRM?
Да. Доступ к карточке, полям, выгрузке и изменению статуса влияет на модель и API. Для каждой роли нужны разрешённые и запрещённые действия с контрольными примерами.
Как принять перенос истории в новую CRM?
Сверить количество записей и связей, выборочные цепочки событий, суммы там, где они подтверждены, и список исключений. Отдельно проверить, что повтор импорта не создаёт дублей и не меняет уже исправленные данные.
