Бриф финального проекта

Название проекта

Разработка внутренней системы управления задачами и загрузкой команды (TeamTask Hub) — платформа для постановки, отслеживания и анализа задач сотрудников компании «SoftSolutions».

Контекст: компания «SoftSolutions»

SoftSolutions — российский аутсорсер-разработчик со штатом 120 человек (80 разработчиков, 15 аналитиков, 10 тестировщиков, 10 менеджеров, 5 HR). Компания работает по модели выделенных команд (dedicated teams) для 12 зарубежных и российских заказчиков.

Текущее состояние (As-Is)

Управление задачами в компании полностью хаотично:

Канал	Что происходит	Кто использует
Telegram (10 рабочих чатов)	Задачи ставятся текстом: «Иван, сделай CI/CD до пятницы». Нет статуса, нет приоритета, нет дедлайна.	Team Leads, разработчики
Email	Письма с задачами от заказчиков пересылаются внутри. Теряются в цепочках.	Менеджеры, заказчики
Jira (бесплатная, 10 пользователей)	Формально задачи ведутся, но лицензии хватает только на тимлидов. Разработчики не видят задач.	Team Leads
Excel-таблицы	Еженедельные отчёты о загрузке. Заполняются вручную, всегда устаревшие.	HR, руководители
Личные заметки	Каждый разработчик ведёт свой список дел. Никто не знает, кто чем занят.	Разработчики

Измеримые бизнес-проблемы

Проблема 1: Срыв SLA по заказчикам

Цифры:

• Среднее время выполнения задачи: 14 дней (при плановых 5)
• 30% задач просрочены более чем на неделю
• 2 заказчика расторгли контракты за последние полгода (потеря $240 000 годовой выручки)
• Штрафы за срыв SLA: $12 000 за последний квартал

Почему:

• Задачи «забываются» в чатах — нет единого бэклога
• Нет приоритетов — срочная задача заказчика тонет в текучке
• Нет прозрачности: менеджер не знает, занят ли разработчик или простаивает

Проблема 2: Хаос в мессенджерах

Цифры:

• 10 рабочих чатов Telegram, в среднем 250 сообщений в день
• 40% сообщений — вопросы о статусе задач («Коля, ты сделал?», «А когда будет?», «Я просил вчера!»)
• 3 часа в день тимлид тратит на ответы на статус-запросы вместо управления командой
• 15% задач теряются — сообщение ушло в историю, никто не прочитал

Последствие: Выгорание Team Leads. Текучесть среди тимлидов — 40% в год (2 из 5 уволились за последний год, замена — $15 000 на каждого).

Проблема 3: Выгорание HR из-за ручного сбора аналитики

Цифры:

• 2 полных рабочих дня в неделю HR-менеджер тратит на сбор данных о загрузке сотрудников
• HR обходит 10 тимлидов лично или в чатах, собирая статусы
• Данные всегда устаревшие на 2–3 дня — решение о найме/аутплейсменте принимается по неактуальным данным
• 70% отчётов по загрузке содержат ошибки (человеческий фактор)

Пример:

В апреле HR увидела, что «Команда А загружена на 40%» (по собранным данным). Приняла решение отдать разработчика на другой проект. Через неделю выяснилось, что данные были старые — команда А работала на 110% (переработки). Разработчик уволился. Замена стоила $18 000.

Проблема 4: Отсутствие метрик эффективности

Цифры:

• Нет данных: какая команда перегружена? Кто простаивает?
• Нет истории: сколько задач сделала команда за месяц? Растёт или падает производительность?
• Невозможно оценить: стоит ли нанимать ещё разработчиков или хватит текущих?

Последствие:

• В прошлом году наняли 10 разработчиков (затраты $300 000 на first-year salary)
• Через 3 месяца оказалось, что 4 из них не нужны — простой
• Уволить нельзя (имидж компании), затраты не окупились

Скрытые бизнес-требования HR-отдела

Важно: Эти требования явно не высказаны заказчиком, но являются ключевыми для успеха проекта. Хороший аналитик найдёт их сам.

Требование	Почему это нужно	Что будет, если не реализовать
Автоматический сбор статистики загрузки без участия сотрудников	HR тратит 2 дня в неделю на ручной сбор. Данные должны собираться из факта выполнения задач, а не из опроса.	HR продолжит выгорать, данные будут недостоверными
Дашборд загрузки в реальном времени	Решения о релокации ресурсов принимаются по устаревшим данным	Ошибки в распределении людей → потери $18k+ на замену
История производительности по каждому сотруднику	Невозможно оценить рост/падение эффективности	Невозможно кого-то повысить или уволить объективно
Экспорт отчётов для заказчиков (по требованию)	Заказчики просят отчёты: «сколько задач сделано за месяц?»	Менеджеры тратят часы на ручную подготовку отчётов
Интеграция с корпоративным календарём (дедлайны)	Дедлайны задач должны синхронизироваться с Google Calendar / Outlook	Задачи забываются, дедлайны срываются
Автоматическое уведомление о просрочках	Тимлид не может уследить за 15 задачами в голове	Просрочка становится сюрпризом для всех
Ролевая модель: Администратор / Team Lead / Разработчик / HR	Разные роли видят разную информацию	HR не должен видеть задачи конкурентов, разработчик — чужие KPI
API для внешних систем (Jira импорт)	Команды хотят перенести текущие задачи из Jira в новую систему	Повторный ввод 500+ задач вручную

Цели проекта (To-Be)

Бизнес-цели (измеримые)

Цель	Метрика	Текущее значение	Целевое значение	Срок
Снизить время выполнения задачи	Среднее время от создания до Done	14 дней	≤ 5 дней	6 мес
Устранить потерю задач	% задач, потерянных в чатах	15%	< 1%	3 мес
Снизить время HR на сбор аналитики	Часов в неделю	16 часов	≤ 1 час	1 мес
Повысить точность отчётов по загрузке	% ошибок в отчётах	70%	< 5%	1 мес
Снизить текучесть тимлидов	% уволившихся за год	40%	< 10%	12 мес
Устранить штрафы за срыв SLA	$ в квартал	$12 000	$0	3 мес

Функциональные цели

1. Создать единое пространство для постановки и отслеживания задач (замена Telegram + Excel)
2. Обеспечить прозрачность загрузки сотрудников в реальном времени (для HR и Team Leads)
3. Автоматизировать уведомления о смене статуса, дедлайнах и просрочках
4. Предоставить дашборды с аналитикой по командам и проектам
5. Интегрироваться с корпоративным календарём (Google Calendar / Outlook)

Заказчик и стейкхолдеры

Роль	Представитель	Интерес	Боли
Внутренний заказчик	HR-директор (Мария)	Автоматизация сбора аналитики, снижение ручного труда	2 дня ручного сбора в неделю, устаревшие данные
Team Lead	Старший разработчик (Антон)	Прозрачность загрузки команды, устранение хаоса в чатах	3 часа в день на статус-запросы, потерянные задачи
Разработчик	Middle разработчик (Иван)	Чёткий бэклог, понятные приоритеты, не дёргают в чатах	14 дней на задачу, забытые дедлайны
Менеджер проектов	PM (Елена)	Отчётность для заказчиков, контроль SLA	Ручная подготовка отчётов, срывы сроков
Технический директор	CTO (Дмитрий)	Метрики эффективности, data-driven решения	Невозможность оценить, кого нанимать

Ключевые функции (обязательные для MVP)

• Управление задачами: создание, редактирование, удаление, назначение исполнителя, дедлайн, приоритет (Critical / High / Medium / Low)
• Статусная модель: To Do → In Progress → Testing → Done + Blocked (с возможностью вернуть в работу)
• Комментарии к задачам: обсуждение внутри задачи (вместо Telegram)
• Уведомления: по email и/или Telegram-bot о смене статуса, назначении, приближении дедлайна, просрочке
• Дашборд загрузки сотрудников: для HR и Team Leads (количество задач, статусы, загрузка в %)
• Фильтрация и поиск: по статусу, приоритету, исполнителю, проекту, дате
• Ролевая модель: Администратор / Team Lead / Разработчик / HR (разные права доступа)
• API (REST): для интеграции с внешними системами и потенциального импорта из Jira

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

ID	Категория	Требование
NFR-01	Производительность	Время загрузки дашборда — не более 2 секунд (P95) при 5000 задач
NFR-02	Доступность	Uptime 99.5% (допустимо ~3.5 часа простоя в месяц)
NFR-03	Безопасность	Аутентификация через JWT. Пароли — bcrypt. Ролевой доступ
NFR-04	Совместимость	Chrome, Firefox, Safari (2 последние версии)
NFR-05	Масштабируемость	Система должна поддерживать 120+ одновременных пользователей
NFR-06	Интеграция	REST API для внешних систем. Webhook при создании задачи
NFR-07	Аудит	Логирование всех действий (кто, когда, что изменил)
NFR-08	Usability	Новая задача создаётся не более чем за 3 клика

Технический стек (предполагаемый)

Компонент	Технология	Обоснование
Backend	Java (Spring Boot) / C# (.NET Core)	Стандарт в enterprise-разработке
Frontend	React / Vue 3	SPA, высокая скорость разработки
Database	PostgreSQL	Надёжность, JSONB для гибких полей
API	REST (OpenAPI 3.0)	Универсальность
Аутентификация	JWT + bcrypt	Безопасность, stateless
Очереди	RabbitMQ / Kafka (для уведомлений)	Асинхронная отправка уведомлений
Кэш	Redis (для дашбордов)	Скорость загрузки дашбордов

Ожидаемый результат (deliverables)

См. документ 09-02-deliverables.md — полный перечень артефактов финального проекта.

Дополнительная информация

Бюджет проекта: Внутренняя разработка (6 месяцев, команда 4 человека: 2 backend, 1 frontend, 1 аналитик/PM). Плановый ROI: $78 000 экономии в год (устранение штрафов SLA $48k + сокращение времени HR $12k + снижение текучести $18k).

Ключевые риски

Риск	Вероятность	Влияние	Mitigation
Сопротивление команды («ещё одна CRM»)	Высокая	Среднее	Показать выгоду: меньше вопросов в чатах
Заказчики не хотят отказываться от Jira	Средняя	Высокое	Сделать импорт из Jira, дать параллельный период
Неточные метрики загрузки	Средняя	Высокое	Использовать объективные данные (факт задач), а не субъективные (self-report)
Перегрузка дашборда данными (information overload)	Высокая	Среднее	Три уровня детализации: общий → по команде → по сотруднику