Как поставить ТЗ на разработку CRM с нуля

По данным Standish Group (CHAOS Report), IT-проекты чаще срываются не из-за слабого кода, а из-за неполных, размытых и постоянно меняющихся требований — то есть из-за того, что должно было быть зафиксировано в техническом задании ещё до старта. Аналитики Gartner отдельно отмечают: значительная доля CRM-проектов не приносит ожидаемого результата, и главные причины — расплывчатые ожидания и слабая подготовка, а не сама технология. Для заказной CRM, которую пишут с нуля под ваши процессы, цена такой ошибки максимальна: править приходится не настройки, а архитектуру и код. Поэтому грамотное ТЗ на разработку CRM — это не бюрократия, а самый дешёвый способ застраховать бюджет и сроки.

В этой статье разберём, чем ТЗ на заказную разработку CRM отличается от ТЗ на внедрение готовой коробки, что подготовить до написания документа, из каких разделов он состоит и как описывать самые сложные части — модель данных, нефункциональные требования, интеграции, стек и критерии приёмки. Материал будет полезен собственникам и руководителям, которые заказывают собственную CRM, а также аналитикам и проджект-менеджерам, которым предстоит собрать это ТЗ и защитить его перед командой.

Что такое ТЗ на разработку CRM и зачем оно нужно

ТЗ на разработку CRM — это документ, который переводит бизнес-задачу «нам нужна своя система управления клиентами» в набор проверяемых требований к продукту. Он отвечает на три вопроса: что именно должна делать система, при каких ограничениях она должна это делать и по каким признакам мы поймём, что работа выполнена. Пока эти ответы не зафиксированы письменно, у заказчика и команды в головах живут разные картины — и расхождение вскрывается уже на приёмке, когда переделывать дорого.

Для заказной разработки ТЗ выполняет ещё и юридическую функцию: это приложение к договору, на которое ссылаются при оценке, приёмке и спорах. Именно поэтому размытые формулировки вроде «удобный интерфейс» или «быстрая работа» в нём недопустимы — их нельзя ни оценить, ни принять.

Что фиксирует документ

Качественное ТЗ закрывает сразу несколько зон ответственности:

• Объём работ (scope). Что входит в проект и — не менее важно — что в него НЕ входит. Явный out-of-scope спасает от бесконечного расширения задачи.
• Единую картину. Заказчик, аналитик, разработчики, тестировщики и дизайнер читают один документ и понимают систему одинаково.
• Основу для оценки. По детальному ТЗ можно декомпозировать работу и дать точные сроки и смету, а не диапазон «плюс-минус в два раза».
• Критерии приёмки. Заранее описанные условия, при которых функция считается готовой, — чтобы приёмка была проверкой по чек-листу, а не спором.

ТЗ на разработку с нуля vs ТЗ на внедрение готовой CRM

Главное различие: ТЗ на внедрение описывает, как настроить готовую систему, а ТЗ на разработку — как построить новую. При внедрении коробки (Битрикс24, amoCRM) базовые сущности, интерфейсы, права и большая часть логики уже существуют — вы адаптируете их под себя. При заказной разработке всего этого ещё нет, и каждую деталь нужно спроектировать и описать. Отсюда и разный объём, и разный состав разделов документа.

Когда хватает настройки коробки, а когда нужна заказная CRM

Готовой CRM обычно достаточно, если ваши процессы близки к типовым продажам: воронка, сделки, задачи, звонки, стандартные интеграции. Заказная разработка оправдана, когда:

• бизнес-логика нетиповая — сложные расчёты, отраслевые процессы, специфические статусы и автоматизации, которые коробка не тянет без костылей;
• CRM должна стать частью экосистемы продуктов и глубоко интегрироваться с вашими системами;
• критичны владение данными, размещение на своих серверах, требования безопасности и 152-ФЗ, которые в SaaS-коробке не выполнить;
• стоимость лицензий на большое число пользователей на горизонте нескольких лет превышает стоимость собственной системы.

Если вы ещё выбираете между этими путями, полезно сравнить их по стоимости владения и рискам — это отдельный стратегический разговор, но именно от него зависит, какое ТЗ вы будете писать.

Какие разделы ТЗ появляются только при разработке с нуля

При заказной разработке в ТЗ добавляются блоки, которых в ТЗ на внедрение коробки просто нет, потому что за вас их уже решил вендор:

• Модель данных — сущности, поля, типы, связи. В коробке структура задана, здесь её проектируете вы.
• Архитектура и стек — как устроена система технически, на чём написана, где размещается.
• Требования к API — как система общается с внешним миром и что должна отдавать наружу.
• Нефункциональные требования — нагрузка, производительность, безопасность, отказоустойчивость на уровне архитектуры.
• Критерии приёмки кода — тест-кейсы, покрытие, требования к качеству и документации.

Именно эти разделы — ядро ТЗ на заказную разработку CRM с нуля, и именно им мы уделим больше всего внимания дальше. Общие же разделы дадим сжато — они одинаковы для любого ТЗ.

Что подготовить до написания ТЗ

Хорошее ТЗ начинается не с текста, а с подготовки: писать раздел «функциональные требования», не разобравшись в процессах, — гарантированный способ получить документ, который придётся переписывать. До старта соберите четыре вещи.

• Цели и метрики. Зачем вам CRM и как вы поймёте, что она сработала: сократить время на обработку заявки, снять потери лидов на стыках, дать руководителю прозрачную воронку. Цели формулируйте измеримо.
• Аудит процессов as-is → to-be. Опишите, как работа идёт сейчас (as-is) и как должна идти в новой системе (to-be). CRM автоматизирует процессы, а не заменяет их — если процесс хаотичен, его нужно сначала выстроить, а не зашивать хаос в код.
• Роли и участники. Кто будет работать в системе: менеджеры, РОП, маркетолог, руководитель, возможно — клиент через личный кабинет. У каждой роли свои задачи и свой доступ.
• Приоритизация требований. Разложите функции по методу MoSCoW: Must have (критично к запуску), Should have (важно, но можно позже), Could have (желательно), Won't have (сейчас не делаем). Это основа для MVP и честной сметы.

Структура ТЗ на разработку CRM: обязательные разделы

Универсальный каркас ТЗ на CRM состоит из нескольких обязательных разделов — от общих сведений до критериев приёмки. Ниже сжатая карта документа: какой раздел за что отвечает и что в нём нужно описать. Дальше по статье мы углубимся в самые сложные из них.

Раздел ТЗ	Что описать
Общие сведения и цели	Назначение системы, бизнес-цели, метрики успеха, глоссарий терминов
Границы проекта (scope)	Что входит и что НЕ входит в разработку, ограничения
Бизнес-процессы и сценарии	Воронка, этапы сделки, пользовательские сценарии, автоматизации
Функциональные требования	Модули, экраны, функции, роли и права доступа
Модель данных	Сущности, поля, типы, связи, история изменений
Нефункциональные требования	Нагрузка, безопасность, отказоустойчивость, масштабируемость
Интеграции и API	Телефония, почта, мессенджеры, 1С, платёжки, требования к API
Требования к интерфейсу	Ключевые экраны, состояния, адаптив, доступность
Стек и архитектура	Тип архитектуры, СУБД, среды, требования к коду
Сроки и этапы	Декомпозиция, MVP и итерации, оценка трудозатрат
Критерии приёмки	Условия готовности, тест-кейсы, приёмочное тестирование

Общие сведения, цели и границы проекта

Этот раздел задаёт рамку. Здесь фиксируют назначение системы, бизнес-цели и метрики, а также глоссарий — единый словарь терминов, чтобы «сделка», «лид» и «заявка» понимались всеми одинаково. Отдельно и явно прописывают границы: scope (что делаем) и out-of-scope (что осознанно оставляем за рамками этого проекта). Практика показывает, что именно чёткий out-of-scope снимает большую часть будущих споров об объёме работ.

Описание бизнес-процессов и сценариев

CRM строится вокруг процессов, поэтому их описывают до функций. Здесь показывают воронку продаж, этапы сделки и переходы между ними, а также пользовательские сценарии — как менеджер заводит лид, как заявка превращается в сделку, что происходит при отказе. Автоматизации (постановка задач, уведомления, смена статусов) описывают правилами «если — то». Хорошо, когда каждый ключевой сценарий проиллюстрирован схемой процесса.

Функциональные требования: модули и роли

Функциональные требования отвечают на вопрос «что система должна уметь делать», и для CRM их удобно группировать по модулям. Типовой набор:

• Лиды и контакты — приём заявок из разных источников, карточки контактов и компаний, дедупликация.
• Сделки и воронки — карточка сделки, этапы, поля, история, несколько воронок под разные направления.
• Задачи и активности — постановка задач, напоминания, календарь, история коммуникаций.
• Отчёты и аналитика — воронка в разрезах, конверсии, нагрузка на менеджеров, дашборды руководителя.
• Администрирование — управление пользователями, ролями, справочниками, настройками.

Каждое требование формулируйте проверяемо: не «менеджер работает со сделкой», а «менеджер может создать сделку, изменить её этап, прикрепить файл и оставить комментарий; при смене этапа на "Оплачено" система автоматически создаёт задачу на отгрузку». Такое требование можно оценить и принять.

Как описывать роли и права доступа

Права доступа удобнее всего задавать матрицей ролей: по строкам — роли, по столбцам — объекты и действия. Это снимает двусмысленность и сразу вскрывает пробелы в логике доступа.

Роль / объект	Свои сделки	Чужие сделки	Отчёты	Настройки
Менеджер	Читать, изменять	Нет	Только свои	Нет
РОП	Читать, изменять	Читать, изменять	По отделу	Ограниченно
Маркетолог	Читать	Читать	Все	Нет
Администратор	Полный доступ	Полный доступ	Все	Полный доступ

Отдельно опишите нестандартные правила: например, менеджер видит телефон клиента, только пока сделка закреплена за ним, а после потери доступ закрывается. Такие нюансы в коробке настраиваются галочками, а в заказной системе их нужно спроектировать.

Модель данных: сущности, поля и связи

Модель данных — сердце ТЗ на заказную CRM, и именно её чаще всего забывают в типовых шаблонах. Здесь вы описываете, какие сущности хранит система, какие у них поля и как они связаны. Ошибка в модели данных — самая дорогая: перестроить структуру в работающей системе с накопленными записями почти всегда означает миграцию и переписывание логики.

Базовый набор сущностей для CRM: лид, контакт, компания, сделка, задача, товар/услуга, пользователь. Для каждой опишите:

• Поля — название, тип (строка, число, дата, справочник, файл), обязательность, значение по умолчанию, ограничения (маска телефона, диапазон суммы).
• Связи — один-ко-многим (у компании много сделок) и многие-ко-многим (у сделки несколько контактов, у контакта несколько сделок). Связи определяют, как данные соединяются в отчётах.
• Жизненный цикл и статусы — какие состояния проходит сущность и по каким правилам меняются.
• История изменений — какие поля версионируются, кто и когда менял; для сделок это часто критично для аудита.

Хорошая практика — приложить к ТЗ ER-диаграмму: визуальная схема сущностей и связей читается быстрее таблиц и сразу показывает нестыковки. Даже черновая схема на этапе ТЗ экономит недели на этапе разработки.

Нефункциональные требования

Нефункциональные требования описывают не то, что система делает, а то, как хорошо она это делает — и в заказной разработке их нельзя опускать. Их отсутствие — типовая причина, почему «формально всё работает», но система тормозит под нагрузкой или не проходит проверку по безопасности. Зафиксируйте:

• Нагрузка и производительность. Сколько одновременных пользователей, сколько записей в базе, какое допустимое время отклика ключевых операций (например, «список сделок открывается не дольше 2 секунд при 100 000 записей»).
• Безопасность и персональные данные. Разграничение доступа, шифрование, хранение данных на территории РФ и соответствие 152-ФЗ, журналирование действий, политика паролей.
• Отказоустойчивость. Допустимое время простоя, поведение при сбоях, резервное копирование и план восстановления.
• Масштабируемость. Как система будет расти: вертикально, горизонтально, готовность к росту числа пользователей и данных.
• Журналирование и аудит. Какие события логируются и как долго хранятся логи.

Каждое такое требование формулируйте измеримо — иначе его нельзя проверить на приёмке.

Интеграции и API

Интеграции превращают CRM из изолированной базы в рабочий центр, поэтому их описывают детально и по каждой отдельно. Для CRM это обычно телефония, электронная почта, мессенджеры, формы с сайта, 1С и платёжные системы. Для каждой интеграции в ТЗ укажите:

• Направление и сценарии — что и когда передаётся: например, звонок создаёт задачу и запись в истории сделки; оплата в 1С меняет статус сделки.
• Данные обмена — какие поля передаются, в каком формате, как сопоставляются сущности.
• Обработку ошибок — что делать, если внешний сервис недоступен: очередь, повторы, уведомление.

Отдельно опишите собственный API системы. Для заказной CRM почти всегда нужен REST API с понятной аутентификацией, а также вебхуки — исходящие уведомления о событиях (создана сделка, сменился статус), на которые смогут подписываться внешние системы. Зафиксируйте форматы обмена (обычно JSON), требования к версионированию API и документации. Если API — существенная часть проекта, имеет смысл выделить заказную разработку ПО и проектирование интеграционного слоя в отдельный блок работ с собственной оценкой.

Требования к интерфейсу и UX

Интерфейс CRM — рабочий инструмент, в котором сотрудники проводят весь день, поэтому требования к нему в ТЗ фиксируют осознанно, а не «на усмотрение дизайнера». Опишите ключевые экраны (рабочий стол, список и карточка сделки, воронка, отчёты), их состояния (пустое, загрузка, ошибка, много данных) и основные пользовательские пути. Укажите требования к адаптивности — нужна ли полноценная мобильная версия или достаточно десктопа, — и к доступности. На этапе ТЗ достаточно текстового описания и, при возможности, черновых схем экранов (wireframes); детальный дизайн — уже следующий этап.

Стек, архитектура и требования к разработке

Раздел про стек и архитектуру нужен, чтобы зафиксировать технические рамки — но не переусердствовать с навязыванием решений. Здесь описывают тип архитектуры (для CRM это обычно клиент-серверное веб-приложение), требования к СУБД (чаще всего реляционная — PostgreSQL или MySQL), окружения dev/stage/prod и требования к качеству кода и документации.

Важный нюанс: конкретный язык и фреймворк стоит жёстко фиксировать, только если систему будет поддерживать ваша команда или есть корпоративные стандарты. Если такой привязки нет, правильнее описать требования к результату (нагрузка, безопасность, наличие API, размещение данных), а выбор стека доверить подрядчику — он подберёт оптимальный вариант под задачу и бюджет. Навязанный «модный» стек без причины удорожает и разработку, и последующую поддержку. Подробнее о балансе технологий мы писали в материале про выбор технологического стека проекта. Отдельно опишите требования к репозиторию, код-ревью, ведению технической документации и передаче исходников — для заказной разработки это часть результата.

Сроки, этапы и оценка трудозатрат

Сроки и этапы выводятся из ТЗ, а не назначаются волевым решением: чем детальнее описаны требования, тем точнее декомпозиция и оценка. Разумный подход — разбить проект на MVP и последующие итерации, где MVP включает только Must have из приоритизации. Это позволяет запуститься быстрее и проверить систему в бою, не дожидаясь всей функциональности.

Этап	Результат	Ориентировочно
Аналитика и ТЗ	Согласованное ТЗ, модель данных, оценка	2–4 недели
Дизайн и прототип	UX-схемы, макеты ключевых экранов	2–3 недели
Разработка MVP	Ядро: сущности, сделки, роли, критичные функции	2–4 месяца
Интеграции	Телефония, почта, 1С, API и вебхуки	3–6 недель
Тестирование и приёмка	Тест-кейсы, приёмочное тестирование, правки	2–4 недели
Развитие (итерации)	Should have и Could have из бэклога	по плану

Цифры в таблице — ориентир: реальные сроки зависят от сложности процессов и числа интеграций. Но сама структура «аналитика → MVP → итерации» универсальна и делает проект управляемым.

Критерии приёмки и тестирование

Критерии приёмки — это заранее описанные условия, при которых функция считается выполненной, и без них приёмка превращается в спор «работает / не работает». Для каждого значимого требования сформулируйте acceptance criteria в проверяемой форме: «при создании сделки без обязательного поля "Сумма" система показывает ошибку и не сохраняет запись». Такой критерий однозначно проверяется тест-кейсом.

В разделе про тестирование опишите: какие виды тестирования применяются (функциональное, интеграционное, нагрузочное), кто и как проводит приёмочное тестирование на стороне заказчика, как фиксируются и классифицируются дефекты (критичный / существенный / незначительный) и какие сроки их устранения. Отдельно пропишите гарантийный период — в течение которого подрядчик исправляет дефекты бесплатно. Всё это должно быть в ТЗ до старта, а не обсуждаться постфактум на приёмке.

Типичные ошибки при составлении ТЗ на CRM

Большинство проблем с ТЗ на CRM сводится к нескольким повторяющимся ошибкам, и почти все они — про размытость и неполноту:

• Расплывчатые формулировки вместо измеримых. Требование, которое нельзя проверить, — это не требование, а пожелание.
• Отсутствие приоритизации. Когда «всё важно», невозможно выделить MVP и дать реалистичный срок.
• Смешение «что» и «как». ТЗ описывает, что система делает; технические решения о том, как это реализовать, — зона архитектора, если только это не ваше осознанное ограничение.
• Забытые нефункциональные требования. Нагрузка, безопасность и 152-ФЗ всплывают на приёмке и стоят дорого.
• Отсутствие модели данных. Функции описаны, а на чём они работают — нет; это выясняется уже в коде.

Наглядный пример, как одна и та же мысль звучит как пожелание и как требование:

Плохо (не проверить)	Хорошо (проверяемо)
Система должна быстро открывать сделки	Карточка сделки открывается не дольше 1,5 секунды при 100 000 записей в базе
Нужен удобный поиск клиентов	Поиск по имени, телефону и email возвращает результат за ≤1 сек, поддерживает частичное совпадение и опечатки
Менеджер не должен видеть чужие сделки	Менеджер видит только сделки, где он ответственный; попытка открыть чужую возвращает ошибку 403

Чек-лист готового ТЗ на разработку CRM

Перед тем как отдавать ТЗ в разработку и оценку, пройдитесь по короткому чек-листу — он ловит большинство пробелов:

1. Сформулированы бизнес-цели и измеримые метрики успеха.
2. Описаны процессы as-is и to-be, ключевые сценарии проиллюстрированы схемами.
3. Явно заданы границы проекта: scope и out-of-scope.
4. Функциональные требования проверяемы и приоритизированы по MoSCoW.
5. Есть модель данных: сущности, поля, типы, связи, история изменений.
6. Прописаны нефункциональные требования: нагрузка, безопасность, 152-ФЗ, отказоустойчивость.
7. Описаны все интеграции и требования к API и вебхукам.
8. Заданы матрица ролей и права доступа, включая нестандартные правила.
9. Зафиксированы требования к архитектуре, средам и качеству кода.
10. Определены этапы, MVP и подход к оценке сроков.
11. Для ключевых требований описаны критерии приёмки и порядок тестирования.
12. Указаны классификация дефектов и гарантийный период.

Частые вопросы (FAQ)

Чем ТЗ на разработку CRM отличается от ТЗ на внедрение готовой?

ТЗ на внедрение описывает, как настроить и адаптировать под бизнес готовую коробку (Битрикс24, amoCRM): роли, поля, воронки, интеграции, обучение. ТЗ на заказную разработку дополнительно фиксирует всё, что при коробке уже сделано за вас: модель данных, архитектуру и стек, требования к API, нефункциональные требования и критерии приёмки кода. Это принципиально более объёмный документ.

Кто должен писать ТЗ — заказчик или подрядчик?

Оптимально — совместно. Заказчик отвечает за бизнес-цели, процессы, роли и приоритеты, подрядчик — за техническую часть: модель данных, архитектуру, оценку трудозатрат, критерии приёмки. На практике итоговый документ чаще собирает системный аналитик подрядчика на основе интервью с заказчиком, а заказчик его согласует.

Нужно ли указывать в ТЗ конкретный язык и СУБД?

Не всегда. Если у вас нет своей команды поддержки и жёстких ограничений, лучше зафиксировать требования к результату (нагрузка, безопасность, размещение данных в РФ по 152-ФЗ, необходимость API), а выбор стека оставить подрядчику. Конкретный язык и СУБД указывают, когда систему будет сопровождать ваша команда или есть корпоративные стандарты.

Сколько времени занимает подготовка ТЗ?

Для CRM среднего размера — обычно от одной до трёх-четырёх недель: интервью с будущими пользователями, описание процессов as-is и to-be, проектирование модели данных и согласование приоритетов. Экономить на этом этапе невыгодно: неполное ТЗ оборачивается переделками, которые стоят дороже, чем сама аналитика.

Можно ли начать разработку по MVP-ТЗ и дополнять его?

Да, это здоровая практика. Достаточно детально описать ядро системы (сущности, ключевые процессы, роли, критичные к запуску функции), запустить MVP, а остальное вынести в бэклог следующих итераций. Главное — чтобы модель данных и архитектура закладывались с учётом планируемого развития, иначе доработки упрутся в переписывание ядра.

Как ТЗ влияет на стоимость разработки CRM?

Напрямую. Подробное ТЗ позволяет декомпозировать работу и дать точную фиксированную оценку, а не диапазон «плюс-минус два раза». Размытые формулировки заставляют подрядчика закладывать риск в цену или работать по time&material без потолка. Хорошее ТЗ снижает и стоимость, и вероятность конфликтов при приёмке.