Что должно быть в техническом задании на личный кабинет

Техническое задание на личный кабинет не должно начинаться со списка страниц «Главная, профиль, документы». Экран — только представление данных и действий. Если не описаны пользователи, права, статусы, источники информации и исключения, одинаковый макет можно реализовать десятками несовместимых способов.

Сформулируйте цель кабинета

Сначала зафиксируйте, какую ручную работу должен убрать портал. Например: клиент самостоятельно видит статус заявок, загружает документы и получает закрывающие материалы; партнер оформляет заказы; сотрудник выполняет задачи на объекте.

Цель должна быть проверяемой. Формулировка «повысить удобство» слишком общая. Формулировка «сократить ручные запросы статуса и дать клиенту единое место для документов» задает конкретные сценарии.

Опишите пользователей и роли

В одном кабинете могут работать разные люди:

• клиент-физлицо;
• представитель компании;
• администратор компании клиента;
• сотрудник исполнителя;
• руководитель;
• партнер;
• внешний исполнитель.

Для каждой роли укажите, какие объекты она видит, что может создавать, редактировать, подтверждать и удалять. Важно описать не только обычный доступ, но и границы между компаниями: пользователь одной организации не должен получить данные другой из-за изменения URL или идентификатора запроса.

Зафиксируйте ключевые сценарии

Сценарий пишется как последовательность с результатом:

1. 1Пользователь авторизуется.
2. 2Выбирает объект обслуживания.
3. 3Создает заявку и прикладывает файл.
4. 4Получает номер и статус.
5. 5Сотрудник принимает заявку.
6. 6Клиент видит изменение и уведомление.
7. 7После завершения доступны результат и документы.

Отдельно описываются отмена, возврат на уточнение, потеря доступа, просрочка и ошибка интеграции. Именно исключения чаще всего определяют реальный объем разработки.

Постройте модель данных

Перечислите основные сущности и связи: пользователь, компания, объект, заявка, задача, сообщение, файл, счет, документ, заказ. Для каждой сущности нужны обязательные поля, статусы, правила изменения и срок хранения.

Не следует копировать все поля из внутренней CRM. Клиенту показывают только понятные и полезные данные. Если информация приходит из нескольких систем, заранее определяют источник истины и правила обновления.

Для обмена с внешними системами пригодятся принципы из статьи о проектировании интеграции сайта с CRM.

Опишите статусы понятным языком

Внутренний статус «ожидает L2» ничего не говорит клиенту. В ТЗ полезно разделить технические статусы и видимое пользователю состояние.

Для каждого статуса укажите:

• кто может его установить;
• из каких статусов возможен переход;
• какие поля обязательны;
• какое уведомление отправляется;
• что видит клиент;
• можно ли вернуть процесс назад.

Так диаграмма статусов становится частью приемки, а не внутренней договоренностью разработчиков.

Документы и файлы

ТЗ должно отвечать на вопросы о форматах, размере, версиях, доступе и удалении. Нужны ли электронные подписи? Кто видит исходный файл? Можно ли заменить документ после согласования? Как долго хранится ссылка на скачивание?

Для чувствительных документов нельзя использовать постоянные публичные URL. Доступ проверяется сервером при каждом запросе, а журнал фиксирует загрузку и скачивание.

Уведомления и сообщения

Опишите событие, канал и получателя. «Отправлять уведомления» недостаточно.

Пример:

• новая заявка — сотруднику в рабочем интерфейсе;
• смена статуса — клиенту в кабинете и по почте;
• запрос уточнения — клиенту с прямой ссылкой на заявку;
• приближение срока — ответственному сотруднику;
• ошибка доставки — в технический журнал.

Пользователь должен управлять необязательными уведомлениями, но критичные события безопасности отключать нельзя.

Интеграции и ответственность за данные

Для каждой интеграции укажите направление обмена, поля, частоту, авторизацию, действия при ошибке и способ повторной отправки. Нужен журнал операций, позволяющий найти конкретную заявку без просмотра секретных данных.

Если внешняя система недоступна, кабинет не должен молча терять действие. Пользователь получает понятный статус, а операция сохраняется для повторной обработки.

Безопасность и авторизация

В ТЗ фиксируют:

• способ регистрации и приглашения;
• восстановление доступа;
• двухфакторную защиту при необходимости;
• срок сессии;
• требования к журналу действий;
• ограничения загрузки файлов;
• защиту API;
• порядок блокировки сотрудника;
• резервное копирование.

Фраза «сделать безопасно» не является требованием. Нужны конкретные угрозы и проверяемые меры.

Критерии приемки

Каждый ключевой сценарий превращается в проверку. Не «раздел работает», а «администратор компании приглашает сотрудника, сотрудник входит, видит только объекты своей компании и не может открыть чужой объект по прямой ссылке».

Критерии включают обычный путь, ошибочные данные, недостаточные права, повторное действие и недоступность внешнего сервиса.

Определите первый рабочий контур

Не все идеи должны войти в первый релиз. В старт обычно включают авторизацию, роли, основной объект, один полный сценарий, файлы, сообщения и критичную интеграцию. Отчеты, дополнительные модули и редкие исключения добавляются после проверки на реальных пользователях.

Этапы более широкого проекта разобраны в статье о разработке веб-приложения от процессов до запуска. Профильная страница разработки личных кабинетов показывает типовые функциональные блоки без привязки к конкретной отрасли.

Частые вопросы

Нужен ли готовый дизайн до технического задания?

Нет. Сначала определяют сценарии и данные, затем строят прототип и визуальную систему. Дизайн без модели ролей часто приходится переделывать после начала разработки.

Можно ли описать кабинет таблицей функций?

Таблица полезна как реестр, но не заменяет сценарии, права и переходы статусов. Она не показывает, что происходит при ошибке или кто отвечает за действие.

Кто должен писать ТЗ?

Лучший результат дает совместная работа владельца процесса, будущих пользователей и технической команды. Бизнес описывает фактическую работу и ограничения, команда превращает их в модель данных и проверяемые требования.

Как не раздувать первый релиз?

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