Как составить техническое задание на разработку CRM-системы: полное руководство

Когда компания решает заказать разработку собственной CRM-системы вместо покупки готовой коробочной версии, первый и главный камень преткновения — это техническое задание (ТЗ). Написали документ «на коленке» с общими фразами? Ждите бесконечных правок, раздутого бюджета и софта, который в итоге делает совсем не то, что нужно вашему отделу продаж.

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

Зачем вообще нужно ТЗ и почему без него не обойтись?

ТЗ — это не просто формальная бумажка для галочки, а юридический и технический фундамент проекта:

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

Если ТЗ составлено правильно, у вас не возникнет споров о том, почему «эта кнопка должна быть в другом углу» или «почему лиды не падают автоматически из формы на сайте».

Кто должен писать ТЗ: сами, подрядчик или сторонний эксперт?

Это вечный спор, от которого зависит половина успеха проекта. Вариантов обычно три:

1. Пишем сами внутри компании. Плюс — вы отлично знаете свои бизнес-процессы. Минус — сотрудники часто упускают технические нюансы, архитектуру баз данных и особенности интеграций, из-за чего программисты потом все равно переписывают документ.
2. Отдаем студии-разработчику. Плюс — они профессионально упаковывают ваши пожелания в технический язык. Минус — недобросовестные подрядчики могут заложить в ТЗ удобные для себя (но не для вас) архитектурные решения или намеренно раздуть смету.
3. Нанимаем независимого бизнес-аналитика. Идеальный, но более дорогой вариант. Специалист аудирует ваши продажи, описывает процессы на нейтральном языке и пишет исчерпывающее ТЗ, с которым можно идти к любым программистам.

Классическое ТЗ vs Agile: какой формат выбрать?

Раньше все жили по ГОСТам: пишется огромный документ на 100 страниц, утверждается, и через полгода вам выкатывают готовую систему. В реальности бизнес меняется быстрее, чем идет разработка.

Поэтому сегодня для кастомных CRM чаще используют гибридный подход или гибкий бэклог (Agile): фиксируются глобальные цели, архитектура и базовый каркас системы (MVP), а мелкие фичи, интерфейсные доработки и новые отчеты добавляются итерациями уже в процессе работы.

Главные разделы правильного технического задания

Хорошее ТЗ на CRM не должно состоять из трех строчек в ворде. В нем обязательно должны быть прописаны следующие блоки:

1. Общие сведения и цели проекта. Зачем мы пишем эту CRM? Какую боль бизнеса она закрывает (например: «менеджеры теряют заявки из мессенджеров, а руководство видит отчеты по продажам с опозданием в неделю»). Здесь же фиксируются термины (лид, сделка, воронка, контрагент), чтобы все участники говорили на одном языке.
2. Анализ и описание бизнес-процессов. Прежде чем кодировать, нужно описать, как устроен реальный отдел продаж: от первого контакта до повторной продажи. Какие этапы проходит сделка? Кто за что отвечает на каждом шаге?
3. Функциональные требования (модули системы):
   • Управление контрагентами и базой клиентов: карточки компаний, контакты, история взаимодействий (звонки, переписки, встречи).
   • Воронка продаж и сделки: этапы движения клиента, автоматическое переключение статусов, задачи для менеджеров.
   • Интеграции: подключение телефонии, почты, мессенджеров (Telegram, WhatsApp), сайта и 1С/складских систем.
   • Права доступа: разграничение ролей (менеджер видит только свои сделки, РОП — свой отдел, директор — всю аналитику).
4. Интерфейс и UX/UI. Требования к внешнему виду, адаптивности (чтобы CRM нормально открывалась на планшетах или в мобильном браузере), логике меню и дашбордов.
5. Технические требования (стек и инфраструктура): на каких языках и фреймворках пишется проект (например, PHP/Python + PostgreSQL), требования к серверу, масштабируемости, безопасности и регулярным бэкапам.
6. Этапы разработки и критерии приемки. Разделение проекта на итерации (запуск MVP, затем подключение отчетов), а также порядок тестирования и сдачи работ.