КСУП - внутренняя корпоративная система управления проектами

Задача

КСУП - внутренняя платформа управления проектами на базе SharePoint для крупного государственного клиента. К моменту подключения команды система значительно разрослась без единых инженерных стандартов: сильно связанный код фронтенда и бэкенда, отсутствие переиспользуемых компонентных паттернов, медленный цикл сборки и деплоя. Новые функции обходились дорого во внедрении и ещё дороже в сопровождении.

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

Исследование

Каждый модуль выявлял свой класс проблем:

• Пользователи переключались между пятью отдельными списками, чтобы найти сущности - сквозного поиска не было.
• Финансовым директорам приходилось вручную сводить финансовые планы из операционных планов, пресейлов, договоров и продаж - всё в разных списках.
• Поля формы были видны всем независимо от роли - не было системы прав на уровне полей.
• Обновление операционных планов шло полностью автоматически, не давая пользователям возможности просмотреть или выбрать кандидатов перед фиксацией изменений.
• Данные по платежам из внешней системы AX должны были отражаться в продажах и договорах, но механизма синхронизации не было.

Рассмотренные варианты

1. Делать каждый модуль изолированно без общих паттернов - отклонено. Это повторило бы те же проблемы связанности и упустило бы возможность поднять всю кодовую базу.
2. Полный рефакторинг до новых функций - отклонено. Нереально в бизнес-сроки; месяцами не дало бы никакого результата.
3. Постепенное улучшение - внедрение стандартов модуль за модулем - выбрано. Каждый новый модуль следует чистому разделению фронтенда и бэкенда; существующий код улучшается попутно, по мере обращения к нему.

Решение

Стандартизировали на React/TypeScript/Redux с redux-saga для сайд-эффектов и reselect для производного состояния. Каждый модуль получает свой Redux-слайс, типизированные контракты API, спроектированные совместно с бэкенд-разработчиком, и покрытие юнит-тестами. Общая конфигурация (например, схемы фильтров) хранится в библиотеках документов SharePoint, чтобы поведение можно было менять без пересборки.

Реализация

Главная страница портала

Главная страница портала с быстрыми ссылками на два основных модуля управления проектами.

Единый поиск по базе знаний

Создана единая страница поиска по всем сущностям системы. Адаптивная боковая панель фильтров перестраивается в зависимости от выбранного типа контента; каждый тип фильтра (список, term store, enum-поле, диапазон дат, диапазон чисел) описывается JSON-конфигом, хранящимся в SharePoint - перенастраивается без деплоя кода. Загрузка вариантов фильтра ленивая и постраничная через watcher'ы redux-saga. Внёс улучшения в open-source библиотеку react-widgets - несколько PR приняты в официальный репозиторий.

Модуль финансовых планов

Внедрён рабочий процесс для финансового директора, который автоматически формирует годовые финансовые планы, агрегируя данные из операционных планов, пресейлов, договоров и продаж. Собственный jQuery-плагин (DataTables + Mustache) отображает JSON-поле отчёта как интерактивную финансовую таблицу прямо на странице элемента списка SharePoint. Бэкенд-сервис на C# отвечает за формирование плана, валидацию на уровне директора и обработчики событий SharePoint - полностью покрыт интеграционными тестами NUnit.

Редактирование проекта

Редактирование одного из проектов в системе. Сам проект - это тоже глубоко доработанная библиотека документов SharePoint, как и планы, которые на ней стоят.

Редактирование продаж по проекту

Редактирование продаж по одному из проектов. Система управления проектами вела активности по каждому проекту, управляла итерациями оплат и считала на их основе финансовые планы.

Внесение суммы поступлений

Добавление суммы поступлений по одному из проектов - та самая точка ввода, из которой потом считаются прогнозы и отчёты.

Проекты → Планы

Модуль «Планы» в разделе «Проекты», построенный на библиотеке документов SharePoint с кастомными полями и кастомными представлениями. В проект вносятся плановые и фактические поступления, а из них модуль строит предсказания по оплатам и отчёты.

Видимость полей по правам

Разработан UserControl с PeoplePicker, позволяющий администраторам назначать правила видимости полей отдельным пользователям или группам безопасности - без изменения кода. JSON-конфигурация сохраняется через WCF-сервис; слой на C# рекурсивно разрешает членство в группах на этапе рендеринга. Модуль поставляется с полным покрытием тестами.

Интерактивное обновление операционных планов

Существующий процесс обновления ОП автоматически сравнивал старые и новые продажи/договоры и фиксировал изменения без участия пользователя. Переработал его так, чтобы показывать модальное окно с двумя таблицами сравнения - новые позиции и изменённые позиции - позволяя пользователям выборочно включать нужное. Ключевая техническая сложность: существующая логика была сильно завязана на SPListItem. Вместо её переписывания ввёл обёртку VirtualSpListItem на C# - идентичный API, но работает исключительно в памяти, не создавая элементы списка SharePoint, что позволяет выбирать кандидатов до фиксации любых данных.

Создание оперативного плана дирекции

Интерфейс создания нового оперативного плана дирекции. Основа та же: библиотека документов SharePoint с кастомными представлениями плюс фоновые процессы, которые запускаются по сабмиту формы.

Отладка сломанного представления

Типичный момент работы с платформой SharePoint: представление сломалось. Открываем ULS Logs Viewer и разбираемся, в чём дело. Здесь - модуль оперативных планов.

Интеграция платёжных данных AX

Создан SharePoint TimerJob, который синхронизирует данные по платежам из внешней финансовой системы AX в сущности продаж и договоров. Поддерживает как полный, так и инкрементальный режимы синхронизации. Каждый запуск валидирует обязательные поля, сопоставляет сущности по коду проекта и сериализует графики платежей в JSON для хранения. Подробное логирование с контрольными точками обеспечивает возможность аудита каждой синхронизации. Покрыто интеграционными тестами на реальных данных AX.

Практически вся работа шла на удалённых Windows-серверах. Клиент удалённого рабочего стола стал почти родным: любая задача начиналась с подключения к удалённому серверу.

Результат

Пять рабочих модулей выпущено на платформе, где раньше каждая функция требовала индивидуальной интеграционной работы. Внедрение чистого разделения фронтенда и бэкенда и общих Redux-паттернов сократило время выпуска новых функций примерно на 30%. Подход с конфигурацией фильтров устранил целые категории деплоев - менеджеры продукта теперь могут перенастраивать поведение поиска без привлечения инженеров.