Технические требовния на систему управления задачами

Цели создания системы

Основной целью создания системы является систематизация управленческих и рабочих задач в рамках существующих процессов и реализующихся проектов компании. Сопутствующей целью создания системы - является прослеживаемость выполняемых задач сотрудниками компании для оптимизации трудовых ресурсов.

Вводимые термины и определения

В рамках настоящей технической спецификации вводятся основные термины и определения:

• Процесс — Решаемая глобальная задача имеющая одну или несколько целей, несколько исполнителей, характеризующаяся отсутствием конечного срока и набора подзадач. Подзадачи процесса формируются по мере поступления информации от участников такого процесса или явлсются следствием выполнения других (связанных) подзадач. Каждая подзадача процесса всегда направлена на достижение конкретной цели и имеет свой приоритет выполнения. Может затрагивать проекты и формировать дополнительные промежуточные цели проектов.
• Проект — Любое разрабатываемое решение, такое как: программное обеспечение, аппаратный комплекс, инженерное сооружение, законодательный акт или иной субьект права собственности, являющийся конечным продуктом проекта. Проект всегда завершается созданием артефакта в форме нематериального актива или основного средства. Проект может быть заранее подергнут процессу декомпозиции на промежуточные цели, задачи, подзадачи, проектные команды. В рамках проекта формируются и закреплаются артефакты, такие как техничекие спецификации, технические задания, архитектурные планы, дизайн-макеты и иные сопутствуюшие документы необходимые для целей реализации проекта.
• Промежуточная цель — Этап Процесса или разработки Проекта имеющий собственное описание, точные или оценочные сроки выполнения цели и набор вводных и результирующих документов (артефактов) цели.
• Задача — Сформулированное конечное требование для одного или нескольких исполнителей. Задача имеет следующий набор атрибутов:
  • Наименование задачи
  • Описание задачи
  • Вложенные документы
  • Дата постановки задачи
  • Дедлайн задачи
  • Состояние задачи
  • Приоритет задачи
  • Проект/Процесс задачи
  • Промежуточная цель задачи
  • Автор задачи
  • Ответственный по задаче
  • Исполнители задачи
  • Родительская задача

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

• Календарь — Датированное представление задач в разрезе сохраненного фильтра, имеющий ссылку для доступа по протоколу CalDAV для чтения расписания и управления задачами. Цели обозначаются выделенной датой на календаре специальной рамкой и цветом.
• KanBan Доска — Постолбцовое представление задач в разрезе сохраненного фильтра. Столбец определяется условием группировки задач, может быть одним из атрибутов задачи (Состояние, Приоритет, Проект/Процесс, Цель, Автор, Ответственный, Дата постановки, Дедлайн), при этом для дат используется округление до недели, месяца или квартала по выбору пользователя. Задачи могут быть отсортированы по дате постановки, дедлайну, состоянию, приоритету, автору или ответственному. Цель выводится как одно из полей задачи.
• Диаграмма Ганта — Линейное представление задач в разрезе сохраненного фильтра. Данная диаграмма имеет вид хронологического горизонтального представления календаря, разделенного на Годы, Кварталы, Месяцы, Недели, Дни недели, где задачи представлены в виде плашек, распространяющихся от даты постановки задачи до её дедлайна или назначенной промежуточной цели. Порядок пересекающихся задач, приходящихся на один период времени может быть отсортирован по дате постановки, состоянию, приоритету, автору или ответственному. Цели отображаются в виде сплошных вертикальных плашек, затрагивающих дату завершения промежуточной цели.
• Список задач — Представление задач в виде таблицы с указанием наименования задачи, автора, ответственного, исполнителей, цели, приоритета и сроков выполнения задачи. Задачи выстраиваются в рамках иерархии подзадач. Сортировка может осуществляться по любому столбцу с учетом иерархии задач. Задачи могут быть сгруппированы аналогично KanBan доске.
• Дашборд — Специальное представление, задач, имеющее набор настроек внешнего вида: Гант, Доска, Календарь, Список; а так же набора фильтров по статусу, сотрудникам, датам, целям, проектам/процессам, приоритету, состоянию. Набор фильтров и внешний вид дашборда может быть сохранен как публичное или приватное представление, а так же иметь публичную ссылку в режиме "Только для чтения". Публичное представление может быть назначено на группу пользователей. При переключении настройк внешнего вида параметры фильтра и группировки сохраняются и применяются к выбранному внешнему виду.
• Группа пользователей — Выделенная группа пользователей, имеющих одинаковые настройки интерфейса, перечень доступных проектов и процессов, представлений и набор привилегий. Привилегии назначенные для разных групп пользователей суммируются для каждого конкретного пользователя, в случае их пересечения. Группа пользователей может иметь фильтр автодобавления, при котором все новые пользователи, соответствующие критериям фильтра автоматически будут добавлены в группу (автопополняемая группа).
• Пользователь — Сотрудник организации или внешний контрагент прошедший процедуру аутентификации и входящий в одну или несколько групп пользователей. Если пользователь не имеет ни одной назначенной группы, такой пользователь относится к служебной группе "Гости" и может просматривать только публичные представления.
• Отчет — Формируемый по расписанию срез задач, согласно заданному фильтру задач, содержит ссылку на интерактивный дашборд с применением указанного фильтра, в котором можно изменять внешний вид задач: Список, Календарь, Гант, Доска. Отчет может быть направлен по любому каналу уведомлений.
• Уведомления — Системное сообщение отправляемое по одному или нескольким каналам связи: Мгновенное сообщение (Telegram), Электронная почта, Push уведомление и т.п. Уведомления вызываются по триггеру события. Типы получаемых уведомлений настраиваются для каждого пользователя индивидуально. Уведомления по событиям могут аккумулироваться для пользователя, и отправляться одним сообщением, если для данного типа уведомлений указан период группировки сообщений и время отправки уведомления.
• Журнал — Системный журнал событий, включающий в себя действия пользователя, от момента аутентификации, до момента получения уведомления. Все операции изменения задачи пользователем попадают в журнал и могут быть отслежены как в отдельной задаче, так и формировать уведомление пользователя или группы по условию. По каждой задаче ведется контроль наличия изменений, относительно последней даты доступа пользователя к задаче и отображается пользователю путем цветового выделения задачи более ярким цветом или рамкой.
• Чат — Внутренняя система обмена мгновенными сообщениями. Чат является самостоятельным представлением, но может быть открыт в качестве виджета или отображаться в рамках задачи, к которой он относится. У каждой задачи может быть свой чат, который становится доступен всем участникам задачи (Автор, Ответственный, Исполнители) при отправке первого сообщения. Чаты группируются по проекту и задаче к которой они относятся. Для выполненных (завершенных) задач чат скрывается из общего списка чатов, список чатов включает в себя только активные/действующие задачи пользователя, связанного с такой задачей. Количество новых сообщений отображается в виде цифры в круглом блоке поверх соответствующещй задачи, в заголовке страницы и в окне чата для каждого чата сответственно.

Технические требования к реализации системы

Система управления задачами должна обладать набором слудующих обязательных характеристик:

• Аутентификация
  • Доменная
  • OAuth2
• Реактивность (Интерфейс зависит от поступаемых данных и отрисовывается на стороне клиента)
• Интерактивность (Все изменения задач в системе отражаются в виде событий и доставляются активным сессиям пользователей)
• Адаптивность (Возможность взаимодействия с основными функциями интерфейса как на мобильных устройствах, так и на ПК)
• Масштабируемость (Возможность запуска множества экземпляров Backend и Frontend серверов с общим центральным хранилищем, например с использованеим брокера RabbitMQ Stream)
• Поддерживаемость (Наличие сборочного сценария и документации на систему разработки и сборки проекта)
• Переносимость (Возможность развертывания в виде OnPermisse или облачного решения на стороне конечного заказчика)