Платформа управления задачами
Заказная разработка ПО
Настраиваемые рабочие пространства в корпоративном SaaS-продукте.
~2~Обзор проекта ~p~Разработчик ПО создавал платформу для команд с разными требованиями к задачам и процессам. Вместо единой схемы задач для всех подразделений продукт должен был поддерживать разные типы объектов, связи и права доступа. Инженеры присоединились к команде заказчика для развития этих базовых возможностей. ~2~Задача ~p~Настраиваемая система процессов сложнее фиксированной доски задач. Администратор должен определять назначение записи, набор полей и связей, доступные пространства и права пользователей. Продукту также требовались согласованные интерфейсы и API для этих настроек.
~2~Решение и реализация ~3~Гибкие рабочие пространства и сущности ~p~Команда создала средства настройки рабочих пространств и переиспользуемых типов записей, позволяющие элементам, похожим на задачи, представлять разные операционные сущности. ~3~Определение рабочих процессов ~p~Выбранные правила пространств и сущностей описываются конфигурационными файлами, поэтому процессы можно менять без полной переработки. ~3~Связи и права доступа ~p~Инженерные работы охватывали связи между записями, роли, настройки досок и доступ к типам сущностей в конкретных рабочих пространствах. ~3~Модернизация интерфейса продукта ~p~Фронтенд адаптировали под дизайн-систему заказчика, реализовали новые представления, фильтры и API-методы для функций продукта. ~2~Технические особенности ~3~Рабочие пространства и типы записей как настройки ~p~Ключевая абстракция разделяет рабочее пространство и доступные в нём типы записей. Запись может означать задачу, дефект, тест-кейс или другой бизнес-объект. Инженеры создали механизмы обновления конфигураций, импорта правил из файлов и управления доступностью типов в конкретном пространстве. Это гибче приложения с жёстко заданной схемой задач. ~3~Связи, роли и расширяемость ~p~Работы включали связи записей, права доступа, доски, фильтры и управление участниками. Для каждой новой возможности разрабатывались соответствующие API-методы и поведение интерфейса. Изменения вносились в действующий продукт на Java/Spring Boot и React/TypeScript, а не в отдельный прототип. ~3~Соответствие дизайн-системе заказчика ~p~Интерфейс переносился с Ant Design на собственные компоненты заказчика. Это затронуло формы, фильтры и экраны настройки при сохранении связей между записями. Разработка продолжается как часть продуктового проекта: инженерная команда создаёт модули в рамках общей дорожной карты заказчика. ~3~Особенности реализации ~p~Основные сущности продукта — рабочие пространства и настраиваемые записи: задачи, дефекты, тест-кейсы и другие объекты. Настройки можно передавать файлами конфигурации. ~p~В разработке использовались Java 17, Spring Boot, PostgreSQL, React и TypeScript. Интерфейс переводили со стандартной библиотеки компонентов на дизайн-систему заказчика.
~2~Результат ~p~Развиваемый продукт управления задачами получил настраиваемые пространства, типы записей, связи, роли и процессы. Команды могут адаптировать структуру работы, а не подгонять всё под один формат задачи. Заказчик продолжает развитие платформы с подключёнными инженерами фронтенда и бэкенда; кейс описывает реализованные компоненты, а не объявленный общерыночный запуск.