1. Общие сведения
Наименование проекта:
CRM-система для автоматизации отдела продаж и клиентской поддержки
Инициатор разработки:
ООО «Пример», отдел коммерции
Разработчик:
Компания «Глаголия» — разработка программного обеспечения под ключ
Цель разработки:
Создание единой системы управления взаимодействием с клиентами, включающей хранение истории контактов, управление воронкой продаж, постановку задач, аналитику и интеграции с внешними сервисами (почта, телефония, мессенджеры).
Основание для начала работ:
- Внутренний приказ №12 от 14.04.2025
- План цифровой трансформации компании
- Устные обращения сотрудников отдела продаж о неэффективности текущего инструментария
Сфера применения:
Внутреннее использование сотрудниками отдела продаж, маркетинга и клиентской поддержки. Предполагается доступ к системе через веб-интерфейс как из локальной сети офиса, так и удалённо (через защищённое интернет-соединение).
Юридическая основа и соответствие стандартам:
Разработка осуществляется в соответствии с внутренним регламентом и положениями ФЗ-152 «О персональных данных»
В рамках проектной документации используется техническое задание на разработку по образцу, адаптированное к требованиям заказчика
Структура документа совместима с положениями ГОСТ 34.602–2020 для соблюдения формальных критериев при необходимости включения ТЗ в договор
2. Цели и задачи проекта
Цель проекта:
Разработать надёжную и масштабируемую CRM-систему, которая позволит централизовать взаимодействие с клиентами, оптимизировать работу отдела продаж и службы поддержки, а также обеспечить прозрачность процессов на всех этапах коммуникации с клиентами.
Система должна стать единой точкой входа для всех сотрудников, участвующих в работе с клиентами, минимизировать человеческий фактор, автоматизировать рутинные действия и обеспечить быстрый доступ к ключевой информации.
Ключевые задачи проекта:
Цифровизация клиентской базы.
Отказ от хранения данных о клиентах в таблицах Excel и почте. Создание централизованного и структурированного реестра клиентов с историей взаимодействий.
Управление воронкой продаж.
Реализация гибкой многоступенчатой системы управления лидами и сделками, позволяющей отслеживать текущее состояние каждой сделки и проводить аналитику по эффективности.
Автоматизация коммуникаций.
Интеграция с почтовыми сервисами, IP-телефонией и мессенджерами (в перспективе) для фиксации всех входящих и исходящих контактов.
Планирование и контроль задач.
Возможность постановки задач, установки дедлайнов, отслеживания исполнения в рамках сделок и коммуникаций.
Аналитика и отчётность.
Внедрение системы сбора и визуализации статистики по сделкам, менеджерам, каналам продаж, воронке. Формирование отчётов в PDF и CSV.
Доступ и безопасность.
Разграничение прав доступа, надёжное хранение персональных данных, соответствие ФЗ-152 и другим нормам в области ИБ.
Интеграция с другими системами.
Предусмотреть возможность подключения к 1С, внешним базам, формам захвата с сайта и другим источникам данных через API.
Проект реализуется с учётом рекомендаций по разработке технического задания на выполнение ПО, а также включает отдельные элементы из практики составления технического задания на разработку проекта ПО по ГОСТ, адаптированные к коммерческой задаче.
3. Область применения
Разрабатываемая CRM-система предназначена для автоматизации процессов взаимодействия с клиентами, управления сделками и задачами, ведения аналитики и улучшения внутренней коммуникации в отделах продаж и клиентской поддержки.
Система будет применяться внутри компании ООО «Пример» и рассчитана на использование сотрудниками с различными ролями: менеджерами по продажам, специалистами поддержки, руководителями подразделений и системным администратором.
Ключевые бизнес-процессы, в которых будет использоваться система:
- Ведение клиентской базы (B2B и B2C)
- Управление входящими лидами и текущими сделками
- Постановка и контроль задач по клиентам
- Планирование коммуникаций и взаимодействий
- Проведение анализа продаж, эффективности сотрудников и каналов
Среда эксплуатации:
- Веб-интерфейс, работающий в браузерах Chrome, Edge, Firefox
- Доступ к системе должен быть возможен как из офиса (через локальную сеть), так и удалённо — по защищённому интернет-соединению (HTTPS)
Технические особенности среды:
- Операционные системы пользователей: Windows 10+, macOS
- Минимальное разрешение экрана: 1280×720
- Наличие подключения к интернету со скоростью от 5 Мбит/с
- Поддержка мобильных устройств на этапе 2 (не включается в текущее ТЗ)
Интеграционные ограничения и особенности:
- Используемая система не должна требовать установки клиентской части
- Все данные должны храниться в единой базе (PostgreSQL / совместимый аналог)
- Предусмотрена разработка технического задания на создание ПО, совместимого с текущими внутренними стандартами хранения и защиты персональных данных
Учитывая возможность масштабирования и подключения новых подразделений, система должна быть построена с заделом на расширение числа пользователей, доработку отдельных блоков и последующую интеграцию с внутренними сервисами компании.
Документ составлен в формате технического задания на разработку ПО по шаблону, рекомендованному компанией «Глаголия», и может быть дополнительно адаптирован под требования ГОСТ по запросу заказчика.
4. Аудитория системы
CRM-система разрабатывается с учётом специфики внутренних процессов компании и ориентирована на несколько категорий пользователей. При разработке технического задания на выполнение ПО важно точно определить, кто будет взаимодействовать с системой и в каком объёме. Это влияет как на функциональную архитектуру, так и на интерфейсные решения, уровень прав доступа и технические ограничения.
Ниже приведены основные типы пользователей (роли), на которых рассчитана система:
1. Менеджеры по продажам
- Работа с клиентской базой (создание, редактирование, фильтрация, поиск)
- Ведение сделок и перемещение по этапам воронки
- Постановка задач, ведение комментариев, добавление файлов
- Работа с календарём напоминаний
- Подготовка отчётов по своим клиентам и сделкам
Особенности интерфейса:
Простой, интуитивно понятный, с упором на скорость работы и минимум отвлекающих элементов. Возможность быстро переключаться между клиентами, задачами и стадиями сделок.
2. Специалисты клиентской поддержки
- Ведение истории обращений и жалоб
- Привязка тикетов к карточкам клиентов
- Обновление статусов, фиксация ответов
- Поддержка SLA и контроль сроков обработки
Особенности:
Интерфейс в виде ленты тикетов и автоматических уведомлений. Чёткая привязка к CRM-базе.
3. Руководитель отдела продаж
- Мониторинг эффективности менеджеров
- Просмотр сделок в разных статусах
- Формирование отчётности (по источникам, по сотрудникам, по итогам месяца)
- Доступ ко всем клиентам
- Управление правами пользователей (в рамках подразделения)
Интерфейс:
Дашборды, аналитика, фильтрация по ключевым KPI, экспорт отчётов.
4. Системный администратор / IT-отдел
- Управление пользователями, ролями и доступами
- Настройка справочников
- Мониторинг состояния системы
- Контроль резервного копирования
- Интеграция с другими сервисами (API, почта, телефония и пр.)
Интерфейс:
Админ-панель с расширенным функционалом, доступной только авторизованным пользователям с правами администратора.
Описание целевой аудитории и её ролей позволяет обеспечить точную разработку технического задания на разработку проекта ПО, соответствующую реальной логике работы в компании. Такой подход минимизирует количество переделок и улучшает пользовательский опыт.
Также в будущем может быть предусмотрена роль аудитора — с доступом только на чтение, для проведения внутренних проверок.
5. Функциональные требования
Разрабатываемая CRM-система должна обеспечивать полный цикл управления клиентскими взаимодействиями: от первого контакта до заключения сделки и постпродажного сопровождения. Данный раздел определяет основные функции, которые будут реализованы в рамках проекта.
Функциональные требования сгруппированы по ключевым модулям и составлены на основании типового технического задания на разработку ПО, адаптированного под задачи отдела продаж и клиентской поддержки.
5.1. Работа с клиентской базой
- Создание, редактирование, удаление карточек клиентов
- Гибкая фильтрация и поиск по атрибутам (имя, ИНН, менеджер, тег)
- Привязка к сделкам, задачам, обращениям, истории коммуникаций
- Возможность добавления вложений (документов, сканов, файлов)
- Хранение всей истории взаимодействий (звонки, письма, встречи)
5.2. Управление воронкой продаж
- Настройка этапов воронки и логики переходов
- Перемещение сделок по этапам drag-and-drop
- Подсветка просроченных и «застрявших» сделок
- Автоматическая смена статусов по событиям
- Назначение ответственных, комментирование, фиксация результатов
5.3. Календарь и задачи
- Постановка задач по клиенту или сделке
- Визуальный календарь задач на неделю и месяц
- Напоминания, дедлайны, статусы исполнения
- Возможность делегирования задач другому пользователю
- Повторяющиеся задачи и шаблоны действий
5.4. Интеграция с коммуникациями
- Привязка входящих и исходящих писем к карточке клиента
- Сохранение истории переписки
- Возможность подключения IP-телефонии (через API)
- Фиксация результатов звонка вручную или автоматически
- Поддержка интеграции с Telegram и WhatsApp (на следующем этапе)
5.5. Отчёты и аналитика
- Генерация отчётов по менеджерам, сделкам, клиентам
- Графики воронки, KPI по отделу, эффективность каналов
- Выгрузка данных в формате PDF и CSV
- Возможность настроить пользовательские отчёты
- Виджеты на главном экране (dashboard)
5.6. Уведомления
- Система уведомлений по задачам, просрочкам, новым обращениям
- Настраиваемая частота и формат (email, всплывающее, push)
- Уведомления при смене стадии сделки и новых комментариях
Функциональные блоки могут быть доработаны или расширены в процессе итеративной разработки по согласованию с заказчиком. Каждая функция будет протестирована на соответствие требованиям, в том числе по критерию «проверяемости», как того требует разработка технического задания на выполнение ПО в соответствии с ГОСТ и международными стандартами.
Данный раздел может быть детализирован в рамках прототипирования или согласования интерфейсных решений.
6. Нефункциональные требования
Наряду с функциональностью, техническое задание на разработку ПО должно чётко описывать нефункциональные характеристики будущей системы. Эти требования не зависят от того, какие именно задачи решает CRM, но напрямую влияют на её надёжность, удобство, масштабируемость и безопасность.
В рамках данного проекта заказчик предъявляет следующие нефункциональные требования:
6.1. Производительность
- Время отклика системы на действия пользователя (переход по вкладкам, открытие карточек) не должно превышать 1 секунды при стандартной нагрузке.
- Поддержка не менее 100 одновременных активных пользователей без деградации быстродействия.
- Возможность обработки до 1000 клиентов и 5000 сделок без ухудшения скорости поиска и навигации.
6.2. Масштабируемость
- Архитектура должна предусматривать горизонтальное масштабирование backend-сервисов.
- Система должна поддерживать добавление новых модулей без полной остановки работы.
- Возможность интеграции с внешними API без переписывания основной логики.
6.3. Надёжность и отказоустойчивость
- Доступность системы — не менее 99,5% в месяц.
- Резервное копирование данных должно осуществляться ежедневно, с возможностью восстановления за 24 часа.
- Ошибки системы должны фиксироваться в логах и сопровождаться кодом ошибки и кратким описанием.
6.4. Безопасность
- Соответствие требованиям Федерального закона №152-ФЗ «О персональных данных».
- Хранение персональных данных на серверах, физически расположенных на территории РФ (или Timeweb Cloud с аккредитацией).
- Обязательное шифрование паролей (хэширование с солью).
- Ограничение доступа по ролям (RBAC), ведение логов действий пользователей.
- Поддержка HTTPS, CSRF- и XSS-защита.
6.5. Удобство использования (Usability)
- Система должна быть доступна через современные браузеры: Chrome, Firefox, Edge (последние 3 версии).
- Интерфейс должен быть адаптирован под мониторы с шириной от 1280 px.
- Реализация адаптивного дизайна под планшеты — по запросу, не входит в первую версию.
- Поддержка переключения между светлой и тёмной темой.
6.6. Совместимость
- Совместимость с 1С, IP-телефонией и корпоративной почтой.
- Возможность экспорта и импорта данных в форматах CSV, XLSX и PDF.
- Работа системы в рамках существующей IT-инфраструктуры заказчика или на хостинге Timeweb Cloud.
Данные требования соответствуют методике разработки технического задания на создание ПО, описанной в статье компании «Глаголия», и позволяют добиться стабильной, масштабируемой и юридически корректной реализации продукта. В случае изменения регуляторных требований или масштабов проекта данные параметры могут быть скорректированы.
7. Технические требования
Данный раздел определяет требования к архитектуре, стеку технологий, среде выполнения и совместимости разрабатываемой CRM-системы. При разработке технического задания на выполнение ПО, особенно в проектах с перспективой масштабирования, крайне важно зафиксировать технический фундамент, чтобы избежать дополнительных рисков и сложных изменений в будущем.
7.1. Архитектура
- Система должна быть реализована как веб-приложение по архитектуре SPA (Single Page Application).
- Backend и frontend разделены по слоям.
- Вся логика взаимодействия клиентского интерфейса с сервером осуществляется через REST API.
7.2. Технологический стек
Backend:
- Язык: Python (FastAPI) или Node.js (по согласованию с заказчиком)
- База данных: PostgreSQL (версия 13 и выше)
- ORM: SQLAlchemy / Prisma
- Аутентификация: JWT, OAuth 2.0 (в перспективе)
Frontend:
- Язык: JavaScript / TypeScript
- Фреймворк: React (с использованием Redux или аналогичного состояния управления)
- Стилизация: TailwindCSS / MUI / кастомная адаптивная тема
DevOps и инфраструктура:
- Контейнеризация: Docker
- CI/CD: GitLab CI или GitHub Actions
- Хостинг: Timeweb Cloud, VDS-сервер или локально (по требованию заказчика)
- Мониторинг: Prometheus + Grafana / Sentry (опционально)
7.3. API-интерфейсы
- Открытое REST API с возможностью подключения сторонних сервисов
- Документация по API: в формате OpenAPI (Swagger UI)
- Обязательная авторизация по токену (JWT)
- Возможность подключения внешней телефонии и сервисов email-рассылки
7.4. Требования к базе данных
- База данных должна быть оптимизирована под работу с большим количеством записей (от 100 000 и выше)
- Обязательная поддержка транзакций и связей между таблицами (реляционная модель)
- Создание резервных копий ежедневно, хранение до 30 дней
- Ведение логов действий пользователей (минимум: авторизация, изменения, удаление данных)
7.5. Совместимость и интеграция
- Поддержка интеграции с 1С через API или универсальный коннектор
- Совместимость с корпоративной почтой заказчика (IMAP, SMTP)
- Возможность последующей интеграции с Telegram, WhatsApp, Viber (через официальные API)
7.6. Безопасность на уровне системы
- Все соединения должны осуществляться по HTTPS
- Поддержка CSRF-токенов, фильтрация XSS-угроз
- Контроль доступа на уровне ролей (менеджер, руководитель, админ)
- Ведение системного журнала безопасности (аудит активности пользователей)
Настоящий раздел составлен в рамках технического задания на разработку по шаблону, адаптированного под сложные корпоративные CRM-системы. При необходимости может быть дополнен параметрами производительности, высоконагруженности и кластеризации по согласованию с заказчиком.
8. Интеграции
Один из ключевых факторов эффективности CRM-системы — это её способность к интеграции с внешними и внутренними информационными системами компании. При разработке технического задания на создание ПО, предназначенного для отдела продаж и клиентской поддержки, необходимо предусмотреть как обязательные, так и перспективные каналы интеграции.
Система должна быть построена таким образом, чтобы расширение списка подключаемых сервисов происходило без полной переработки архитектуры. Все интеграции осуществляются через модуль API и сервис-шину взаимодействия.
8.1. Интеграция с корпоративной почтой
- Протоколы: IMAP/SMTP
- Поддержка отправки и приёма писем прямо из карточки клиента
- Автоматическая привязка писем к соответствующей сделке/контакту
- Поддержка подписи, вложений, шаблонов писем
- Отображение истории переписки в ленте активности
8.2. Интеграция с IP-телефонией
- Обязательная поддержка Asterisk, МТС, Mango Office и других популярных провайдеров
- Входящие и исходящие звонки отображаются в истории клиента
- Фиксация даты, времени, длительности, менеджера
- Возможность записи звонков и их прослушивания (по настройке)
- API для уведомлений о звонках в режиме реального времени
8.3. Интеграция с 1С и бухгалтерскими системами
- Двусторонняя синхронизация справочников (клиенты, сделки, счета)
- Передача данных по выставленным счетам и оплатам
- Поддержка универсального обмена через XML или REST
- Возможность настройки расписания синхронизации
8.4. Интеграции с сайтами и формами захвата
- Интеграция с формами на корпоративном сайте (заявки, запросы, обратный звонок)
- Автоматическое создание лида в CRM при заполнении формы
- Webhook-интеграции с конструкторами (Tilda, LPgenerator, WordPress)
- Настраиваемая карта полей и фильтрация спама
- Возможность антибот-защиты через внешние сервисы (капча, SaaS API)
8.5. Перспективные интеграции
- Мессенджеры: Telegram, WhatsApp, Viber — через официальные API
- Slack, Microsoft Teams — для корпоративных уведомлений
- BI-системы (Power BI, Metabase) — для расширенной визуализации отчётов
- Сервисы SMS-рассылок и пуш-уведомлений
- ERP-системы и внутренние базы данных заказчика
Все интеграции должны быть реализованы по REST API, с возможностью масштабирования. Документация по каждому внешнему подключению должна быть оформлена и включена в раздел «Системная документация».
Раздел составлен в логике технического задания на разработку по ГОСТ, но с упором на гибкость и расширяемость, присущую современным SaaS- и B2B-решениям.
Интеграции являются частью функциональности Must Have — они включены в первую фазу внедрения.
9. Ограничения
Ограничения — важная часть технического задания на разработку проекта ПО, поскольку они задают реальные рамки реализации и помогают заранее избежать конфликтов между ожиданиями и возможностями системы. В рамках разработки CRM для компании «ООО Пример» необходимо учитывать как технические, так и юридические, инфраструктурные и организационные ограничения.
9.1. Инфраструктурные ограничения
- Размещение сервера: Использование облачной инфраструктуры Timeweb Cloud с сертификацией в РФ, либо локальный сервер внутри корпоративной сети заказчика.
- Резервирование: Система не должна зависеть от внешнего облака в случае отключения интернета (при установке локальной версии).
- Мобильная версия: В рамках текущего этапа разработки не предусмотрена реализация нативных мобильных приложений. Возможен доступ через адаптированную веб-версию.
9.2. Юридические и регуляторные ограничения
- Соблюдение законодательства: Обязательное соответствие Федеральному закону №152-ФЗ «О персональных данных».
- Обработка данных: Все данные пользователей, клиентов и сделок должны храниться на серверах, физически расположенных в РФ.
- Доступ к данным: Доступ к персональным данным регулируется системой ролей и обязан быть логируемым.
- Соответствие требованиям ГОСТ: Структура и порядок описания требований должны быть совместимы с техническим заданием на разработку по ГОСТ 34.602–2020 при необходимости включения ТЗ в договор.
9.3. Технические ограничения
- Минимальные системные требования клиента:
- Разрешение экрана: не менее 1280×720 px
- Поддерживаемые браузеры: последние 3 версии Chrome, Firefox, Edge
- Необходима поддержка JavaScript, cookies, WebSockets
- Форматы экспорта: CRM должна поддерживать экспорт данных только в форматах PDF, CSV и XLSX. Выгрузка в DOCX или ODS — не входит в ТЗ.
- Интерфейс: Только на русском языке. Мультиязычность — в перспективе.
9.4. Организационные ограничения
- Количество пользователей на первом этапе: не более 50 одновременных пользователей
- Роль IT-отдела заказчика: Поддержка работы системы со стороны заказчика осуществляется силами собственного IT-отдела, в том числе обеспечение доступа, установка локальных компонентов (при необходимости)
Данные ограничения включены в состав шаблона технического задания на разработку ПО, применяемого компанией «Глаголия». При изменении внешних условий (изменение законодательства, расширение инфраструктуры и пр.) возможна адаптация данного раздела с дополнительным согласованием.
10. Требования к пользовательскому интерфейсу
Интерфейс CRM-системы должен быть интуитивно понятным, минималистичным и функциональным. Его задача — обеспечить быструю навигацию, визуальную ясность и снижение порога входа для новых пользователей. В компании «Глаголия» мы придерживаемся принципов разработки технического задания на создание ПО, в котором UI — это не просто «обложка», а важная часть архитектуры взаимодействия с системой.
10.1. Общие принципы UI
- Простота. Интерфейс должен быть лаконичным, без перегруженности элементами.
- Единый стиль. Использование единой дизайн-системы на всех страницах.
- Скорость. Интерфейс должен загружаться быстро даже при медленном интернете.
- Информативность. Чёткое отображение статусов, действий и уведомлений.
- Доступность. Учитывать пользователей с нарушениями зрения (контрастность, шрифт).
10.2. Цветовая схема и темы
- По умолчанию — светлая тема (белый фон, синие и серые акценты).
- Поддержка переключения в тёмную тему (по профилю пользователя).
- Цвета интерфейса не должны мешать восприятию данных (особенно на дашбордах).
10.3. Навигация
- Меню слева (sidebar), фиксированное, сворачивающееся.
- Быстрый доступ к разделам: Клиенты, Сделки, Задачи, Календарь, Отчёты, Настройки.
- Breadcrumbs в верхней панели для быстрого понимания вложенности.
10.4. Формы и карточки
- Использование многошаговых форм для сложных операций (например, создание сделки).
- Автосохранение введённых данных при переключении между вкладками.
- Возможность добавления комментариев, файлов, ссылок.
- Упрощённое редактирование по двойному клику (in-place editing).
10.5. Дашборды и визуализация
- Отображение ключевых метрик: воронка, выручка, активные сделки, задачи.
- Визуальные элементы: графики, диаграммы, таблицы.
- Виджеты настраиваются индивидуально под пользователя.
10.6. Адаптивность
- Интерфейс адаптирован под экраны шириной от 1280 px и выше.
- Поддержка планшетов (iPad, Android) в горизонтальном режиме.
- Смартфоны — не входят в минимальный состав ТЗ, реализация мобильного приложения — в перспективе.
10.7. Микроанимации и обратная связь
- Обратная связь на действия пользователя (загрузка, сохранение, ошибки)
- Анимации: появление модальных окон, подсветка новых элементов
- Использование CSS-анимаций и лёгких JS-библиотек
10.8. Язык интерфейса
- Интерфейс — полностью на русском языке.
- Поддержка мультиязычности не входит в текущую версию, но архитектура должна предусматривать возможность локализации в будущем (i18n).
Требования к интерфейсу соответствуют практике разработки технического задания на разработку ПО по шаблону, с учётом адаптивного дизайна и доступности для разных ролей. Все элементы будут проверяться по критерию «проверяемости» — наличие логики, стилей, доступности и технической реализуемости.
11. Приоритеты (проранжированность)
При разработке технического задания на выполнение ПО крайне важно определить, какие функции и модули являются критически необходимыми, а какие можно реализовать на последующих этапах проекта. Это позволяет чётко структурировать спринты, избежать размытости объёма задач и сосредоточиться на действительно важных элементах системы.
Мы применяем приоритезацию по методу MoSCoW, разделяя требования на 4 категории:
- Must Have — функциональность, без которой система теряет смысл
- Should Have — важные функции, которые желательно реализовать в MVP
- Could Have — полезные, но необязательные функции
- Won’t Have — исключены из текущей версии, но могут быть возвращены в будущем
11.1. Must Have (обязательные требования)
- Ведение клиентской базы с историей взаимодействий
- Многоступенчатая воронка продаж с визуальным управлением
- Постановка задач и календарь с напоминаниями
- Отчёты по сделкам и эффективности сотрудников
- Интеграция с корпоративной почтой и IP-телефонией
- Ролевая модель доступа (менеджер, руководитель, админ)
- Соответствие ФЗ-152 по защите персональных данных
- Возможность резервного копирования и восстановления данных
- Работа в браузере без установки ПО на клиентскую машину
11.2. Should Have (желательные функции)
- Виджеты и аналитические дашборды на главной странице
- Экспорт данных в PDF/CSV/XLSX
- Поддержка напоминаний и уведомлений
- Отчёты по источникам лидов
- Возможность делегирования задач
- Визуальная настройка этапов воронки
11.3. Could Have (возможные дополнения)
- Интеграция с мессенджерами (Telegram, WhatsApp)
- Поддержка тёмной темы интерфейса
- Быстрая фильтрация по тегам, статусам, категориям клиентов
- Возможность настройки цветовых тем интерфейса под бренд
- Механизм массового обновления клиентских данных
- Подключение BI-систем для расширенной визуализации
11.4. Won’t Have (исключено из текущего этапа)
- Мобильное приложение для iOS и Android
- Поддержка голосовых помощников или чат-ботов
- Генерация договоров в PDF по шаблону
- Интеграция с системами документооборота (например, Диадок)
- Расширенные права на уровне подразделений и филиалов
Приоритезация фиксируется в рамках текущего ТЗ и может быть изменена только по согласованию обеих сторон. Все требования категории Must Have проверяются в первую очередь, их невыполнение означает неприёмку проекта.
Такой подход полностью соответствует практике технического задания на разработку проекта ПО по шаблону Глаголия, с привязкой к целям и задачам заказчика. Он позволяет управлять ожиданиями, ресурсами и качеством реализации без потерь в логике или бизнес-эффективности.
12. Требования к документированию
Полноценная документация является неотъемлемой частью программного продукта и напрямую влияет на его внедрение, сопровождение и развитие. В рамках данного проекта необходимо обеспечить подготовку как пользовательской, так и технической документации.
Документация должна быть создана в процессе реализации проекта, актуализироваться при каждом релизе и передаваться заказчику вместе с исходным кодом. Раздел оформлен в соответствии с практиками разработки технического задания на разработку ПО по ГОСТ, а также с учётом гибких методологий разработки, где документация поддерживается итеративно.
12.1. Пользовательская документация
Формат: PDF + встроенные справочные модули в интерфейсе системы
Целевая аудитория: конечные пользователи (менеджеры, руководители)
Обязательные разделы:
- Обзор системы и структуры интерфейса
- Авторизация и начальная настройка
- Работа с клиентской базой и сделками
- Постановка задач и взаимодействие с календарём
- Формирование и экспорт отчётов
- Частые вопросы (FAQ)
Документация должна быть написана на русском языке, с примерами экранов и поясняющими скриншотами. Желательно наличие интерактивной справки внутри интерфейса, либо интеграции с базой знаний.
12.2. Административная документация
Формат: PDF + Markdown-документы в Git-репозитории
Целевая аудитория: системные администраторы, сотрудники ИТ-отдела
Обязательные разделы:
- Установка и развёртывание системы
- Обновление и миграция данных
- Настройка пользователей, ролей, прав доступа
- Работа с журналами событий и логами
- Резервное копирование и восстановление
Должны быть приведены примеры команд, параметры запуска контейнеров, пути к файлам конфигурации. При использовании Docker — отдельный docker-compose.yaml и README по установке.
12.3. Техническая документация по API
Формат: OpenAPI (Swagger)
Целевая аудитория: сторонние разработчики, интеграторы, ИТ-отдел заказчика
Обязательные разделы:
- Авторизация и структура запросов
- Эндпоинты (описание, параметры, примеры)
- Коды ответов и ошибки
- Ограничения и лимиты
- Webhook-описания (для внешних систем)
Документация должна быть сгенерирована автоматически на основе контрактов и включена в развёрнутую систему (например, по адресу: /docs).
12.4. Журнал изменений и актуальности
- Каждая версия документации должна содержать лог изменений
- Документы подлежат актуализации после каждой доработки, связанной с функциональностью
- Ответственность за ведение документации несёт аналитик проекта
Подобный набор документации позволяет обеспечить управляемость проекта в долгосрочной перспективе. Он соответствует практике типового технического задания на разработку ПО, принятой в компании «Глаголия», и необходим для приёмки продукта, его поддержки и развития.
13. Порядок приёмки
Для успешного завершения проекта необходимо формализовать и согласовать процедуру приёмки программного продукта. В данном разделе описан порядок действий, который обеспечивает объективную проверку соответствия реализованной CRM-системы требованиям, зафиксированным в настоящем техническом задании на разработку ПО.
Приёмка осуществляется в несколько этапов и предполагает участие как команды исполнителя, так и представителей заказчика. Вся процедура сопровождается документацией и завершается оформлением акта приёмки-передачи.
13.1. Предварительное тестирование
Исполнитель проводит внутреннюю проверку (Unit-тесты, ручное тестирование, smoke-тесты), чтобы убедиться, что:
- реализация всех функций категории Must Have завершена;
- интерфейс доступен и соответствует утверждённым макетам;
- критических ошибок не обнаружено;
- все функциональные и нефункциональные требования из ТЗ учтены.
13.2. Подготовка демонстрационной версии
Исполнитель развёртывает систему на тестовом сервере и предоставляет заказчику:
- доступ к CRM с двумя тестовыми ролями: Менеджер и Администратор;
- инструкцию по работе с системой;
- чек-лист для приёмки (ссылка на требования и критерии проверки);
- ссылку на актуальную документацию.
13.3. Приёмочное тестирование (UAT)
Заказчик в течение 5 рабочих дней проводит самостоятельную проверку:
- тестирует ключевые функции;
- проверяет обработку данных;
- оценивает полноту реализации интерфейса;
- сверяет отчёты, задачи, фильтры и работу ролей;
- по желанию — тестирует нагрузку.
Если замечаний не выявлено — подписывается акт. В случае обнаружения отклонений составляется перечень несоответствий с указанием:
- конкретного требования из ТЗ;
- отклонения от ожидаемого поведения;
- приоритета исправления (блокирующее / критичное / второстепенное).
13.4. Устранение замечаний
Исполнитель в течение согласованного срока (не более 10 рабочих дней) устраняет замечания, после чего система вновь предоставляется на проверку.
Количество итераций устранения не ограничено, но не должно выходить за рамки разработки технического задания на выполнение ПО, т.е. затрагивать только то, что уже описано в ТЗ.
13.5. Финальная приёмка
После успешного завершения UAT заказчик и исполнитель подписывают следующие документы:
- Акт приёмки-передачи работ
- Отчёт по тестированию
- Подтверждение получения исходных кодов и документации
Дополнительно может быть оформлен протокол приёмки по шаблону технического задания на разработку ПО, если это требуется для внутреннего аудита или тендера.
13.6. Гарантийный период
Исполнитель предоставляет гарантию на систему сроком 90 календарных дней с момента приёмки. В течение этого периода устранение всех ошибок, не выявленных ранее, осуществляется бесплатно.
Чёткая структура приёмки соответствует требованиям ГОСТ, а также практике разработки технического задания на создание ПО, принятой в компании «Глаголия». Это защищает интересы обеих сторон и обеспечивает контроль качества реализации на всех этапах.
14. Приложения
Данный раздел содержит перечень материалов, которые дополняют основное содержание технического задания на разработку ПО и обеспечивают более полное понимание требований, интерфейсов и логики работы системы. Приложения являются неотъемлемой частью ТЗ и должны передаваться заказчику вместе с основным документом.
14.1. Прототипы пользовательского интерфейса (UI-макеты)
- Карточка клиента
- Страница воронки сделок
- Список задач и календарь
- Дашборд руководителя
- Экран настроек
Прототипы подготовлены в Figma, имеют комментарии и номера версий. Все макеты сопровождаются ссылкой на живой просмотр и экспортированы в PDF для офлайн-использования.
Интерфейсы разработаны в соответствии с требованиями из раздела 10, а также учитывают адаптивность под разные разрешения.
14.2. Карта ролей и прав доступа
- Таблица соответствия ролей (Менеджер, Руководитель, Администратор)
- Доступ к разделам системы, действиям и данным
- Механизмы ограничения и скрытия полей
- Особенности разграничения в API
Карта прав необходима для тестирования безопасности и соответствия технического задания на разработку по ГОСТ, если требуется приёмка для внутреннего аудита или формализация проекта.
14.3. Бизнес-процессы и логика работы
- Диаграммы в BPMN (Business Process Model and Notation):
- Обработка лида
- Работа с повторными клиентами
- Эскалация обращений
- Таблицы состояний сделок, переходов, автоматических действий
- Логика взаимодействия задач с воронкой и календарём
Эти схемы необходимы для валидации функциональных требований и настройки бизнес-логики в системе без привязки к коду.
14.4. Таблицы данных и справочники
- Примеры справочников (статусы сделок, типы задач, источники лидов)
- Структура клиентской карточки (поля, типы, валидации)
- Шаблоны экспорта отчётов в CSV, PDF
Эти таблицы являются частью типового технического задания на разработку ПО и важны для дальнейшей настройки системы силами внутреннего ИТ-отдела заказчика.
14.5. Документация по API (черновик)
- Swagger-описание основных эндпоинтов
- Примеры POST/GET-запросов
- Справочник ошибок
- Требования к авторизации и лимитам запросов
Документация может быть дополнена в процессе реализации, но должна быть включена в состав приёмочной версии системы.
Приложения формируют визуальный и технический контекст, позволяющий максимально точно интерпретировать положения ТЗ, особенно в случае передачи проекта другой команде или интеграции с внешними решениями.
Таким образом, структура документа завершена в соответствии с лучшими практиками разработки технического задания на создание ПО, принятыми в компании «Глаголия».
Хотите получить техническое задание на CRM под ваш проект?
Оставьте заявку на сайте или напишите нашему Telegram-боту — и мы:
✅ пришлём вам готовый пример ТЗ, который можно адаптировать под вашу задачу
✅ или бесплатно составим техническое задание с учётом ваших требований и целей бизнеса
📩 Оставить заявку на сайте
🤖 Написать в Telegram-бот
Глаголия — превращаем идеи в работающие цифровые решения.
