Написать ТЗ на модуль уведомлений

ТЗ: Модуль уведомлений для корпоративного портала

1. Цели в бизнес-показателях

Основная цель: Повысить вовлечённость пользователей и своевременность реагирования на задачи.

KPI:

• User Engagement: увеличить активность на 30% (метрика: daily active users)
• Task Resolution Time: сократить время выполнения на 20% (с 5 дней → 4 дня)
• Deadline Compliance: повысить соблюдение дедлайнов на 25% (с 75% → 100%)
• Communication Efficiency: уменьшить письма по задачам на 40% (за счёт уведомлений)
• Notification Opt-in Rate: 80% пользователей активируют уведомления
• Email Open Rate: > 45% (industry standard 20-25%)
• Push Click-Through Rate: > 15%

2. Ролевая модель

Администратор портала:

• Настраивать глобальные параметры уведомлений
• Отключать/включать уведомления для отдельных пользователей
• Просмотр статистики
• Управление шаблонами уведомлений

Руководитель (Manager):

• Создавать задачи и выбирать получателей уведомлений
• Видеть статистику по своей команде
• Настраивать уведомления для своей команды (если разрешено)

Исполнитель (Employee):

• Получать уведомления о задачах
• Настраивать личные каналы уведомлений
• Отключать/включать определённые типы уведомлений
• Изменять частоту уведомлений (real-time, daily digest, weekly)

Система (System):

• Автоматически генерировать уведомления по правилам
• Отправлять уведомления в указанные каналы

3. Функциональные требования

FR 1: Типы уведомлений

1.1 Новая задача

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

1.2 Приближающийся дедлайн

• Срабатывает за 1 день до дедлайна
• Дополнительно срабатывает в день дедлайна (утром)
• Показывает: название, оставшееся время, статус выполнения

1.3 Новый комментарий

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

1.4 Изменение статуса задачи

• Срабатывает когда задача изменила статус
• Показывает: старый статус → новый статус
• Включает ссылку на задачу

1.5 Переназначение задачи

• Срабатывает если задача переназначена на пользователя
• Показывает: от кого переназначена, причина (если указана)

FR 2: Каналы доставки

2.1 Email

• Доставка уведомления на email пользователя
• Поддержка HTML и Text версий
• Шаблонизация
• Unsubscribe link

2.2 Push-уведомление (в портал)

• Всплывающее уведомление в веб-приложении
• Звуковой сигнал (опционально)
• Хранение в центре уведомлений (история за 30 дней)

2.3 SMS

• Отправка по номеру телефона (если указан)
• Короткий формат (макс 160 символов)
• Синтаксис: [Задача] Срок на дне: задача X

FR 3: Настройка уведомлений

3.1 Личные предпочтения пользователя

• Для каждого типа уведомления (новая задача, дедлайн, комментарий):
  • Включить/отключить
  • Выбрать каналы (email, push, SMS)
  • Выбрать частоту (real-time, daily digest, weekly digest, never)
  • Выбрать время отправки

3.2 Часовой пояс

• Уведомления должны отправляться в соответствии с часовым поясом пользователя
• Не отправлять между 22:00 и 08:00 (unless urgent)

3.3 Отключение на период

• "Do Not Disturb" режим (временное отключение на X часов)
• Отпуск (автоматическое отключение на выбранный период)

3.4 Правила фильтрации

• Отправлять уведомления только если приоритет >= Medium
• Отправлять только от конкретных проектов (whitelist)
• Отправлять только от конкретных людей (whitelist)

FR 4: Управление уведомлениями

4.1 Просмотр истории

• Центр уведомлений с историей всех уведомлений
• Фильтр по типам, датам, статусу (прочитано/не прочитано)
• Поиск

4.2 Отметить как прочитанное

• Отдельное уведомление
• Все уведомления
• Маркировка как важное

4.3 Удаление

• Удалить отдельное уведомление
• Удалить все старые уведомления (> 30 дней)

FR 5: Admin функции

5.1 Шаблоны уведомлений

• Управление шаблонами текстов для каждого типа
• Переменные: {task_name}, {deadline}, {assignee}, {priority}
• Версии на разные языки

5.2 Статистика

• Количество отправленных уведомлений
• Процент открытых уведомлений
• Количество отказавшихся
• Самые часто игнорируемые типы

5.3 Тестирование

• Отправить тестовое уведомление конкретному пользователю
• Просмотр логов доставки

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

NFR 1: Производительность

• Latency: уведомление должно быть отправлено в течение 5 минут
• Throughput: система должна обрабатывать 10K уведомлений в минуту
• Response time: страница настроек загружается за < 2 сек

NFR 2: Надёжность

• Delivery guarantee: at-least-once (если отправка не удалась, повторить до 3 раз)
• Availability: 99.9% uptime
• Data backup: все данные уведомлений хранятся в резервной копии

NFR 3: Безопасность

• Authentication: все запросы требуют аутентификации
• Authorization: пользователь видит только свои уведомления
• Encryption: email и SMS содержат только неконфиденциальную информацию
• GDPR compliance: право на удаление данных уведомлений
• PII: не хранить в логах личные данные

NFR 4: Масштабируемость

• Horizontal scaling: система должна масштабироваться на 100K+ пользователей
• Database: должна работать с 10 млн. уведомлений в месяц
• Concurrency: поддержка 1K одновременных запросов

NFR 5: Maintainability

• Code quality: code review обязателен
• Monitoring: все метрики логируются в Prometheus
• Alerting: критические ошибки отправляют Slack алерт
• Documentation: API документирована в Swagger
• Testing: > 80% code coverage

NFR 6: Usability

• UI/UX: интерфейс настройки простой (max 3 клика до нужной настройки)
• Mobile: адаптивный дизайн для мобильных
• Accessibility: поддержка screen readers (WCAG 2.1 AA)

5. Ограничения и зависимости

Ограничения

1. SMS стоимость

   • SMS стоят деньги (3-5 руб за SMS)
   • Ограничить отправку до 1 SMS в день на пользователя
   • Только для приоритетных уведомлений

2. Email deliverability

   • Некоторые email могут уходить в spam
   • Нужно настроить SPF, DKIM, DMARC
   • Максимум 1000 уведомлений в час от одного сервера

3. Частота уведомлений

   • Не отправлять больше 10 уведомлений в день на пользователя
   • Батчить в daily digest если много

4. История

   • Хранить историю уведомлений 90 дней
   • Старые удалять автоматически

Зависимости

1. Внешние системы

   • Email сервис (SendGrid, AWS SES)
   • SMS сервис (Twilio)
   • Push сервис (Firebase Cloud Messaging)

2. Система управления задачами

   • Зависит от API системы задач для получения информации о задачах
   • Требует real-time событий (Task Created, Task Updated, Comment Added)

3. Система аутентификации

   • Использует существующую аутентификацию портала
   • Зависит от User Service для получения email, phone

4. Message Queue

   • Требует очереди сообщений (RabbitMQ, Kafka) для асинхронной обработки

6. Сценарии использования

Сценарий 1: Руководитель создаёт срочную задачу

• Новая задача → сотрудник получает push (real-time)
• Если не открыл за 2 часа → email
• Если не прочитал за 24 часа → SMS (если priority = critical)

Сценарий 2: Дедлайн приближается

• За 1 день → первое уведомление
• В день дедлайна (09:00) → второе уведомление
• Если не выполнил → напоминание от руководителя

Сценарий 3: Сотрудник в отпуске

• Отпуск 17-31 августа → все уведомления отключены
• После возврата → summary of missed notifications

7. Критерии готовности

• Все FR реализованы и протестированы
• NFR производительности проверены load-тестированием
• Security-аудит пройден
• Документация написана
• Обучение пользователей проведено
• Monitoring и alerting настроены
• Rollback план готов

8. Timeline

• Design & Architecture: 1 неделя
• Development: 3 недели
• Testing (QA): 1.5 недели
• Staging & UAT: 1 неделя
• Production: готово к релизу

Итого: 6.5 недель