01 / ПРОЦЕССЫ И ОТВЕТСТВЕННОСТЬ
ДУПиК — управление ответственностью и согласованиями
Платформа связывает процессы, ответственных, задачи и согласования. Передача ответственности фиксирует состав обязанностей и решения участников; изменение состава требует нового согласия.
Мой вклад. Предложил интерактивную платформу, отвечал за её логику, интерфейс и реализацию. Участвовал в формировании и совместном описании процессной модели.
Ключевое решение. Привязать согласие преемника к конкретному составу обязанностей: изменение состава требует нового решения.
Результат. Решение связало процессы, владельцев, участников, задачи и согласования. После исправлений платформа прошла итоговую приёмку и была передана ответственным в сентябре 2026 года.
Принят и переданСентябрь 2026 · подтверждено автором
С чего началась задача
При передаче дел важно согласовать конкретный набор обязанностей. Если он меняется после согласия преемника, прежнее решение уже не относится к актуальной передаче.
Мой вклад
- Продуктовая логика, интерфейс, реализация платформы и поэтапное разделение монолита.
- Уточнение ролей и передачи ответственности по встречам и замечаниям участников.
- Совместное описание процессов, сценарии проверки и сопровождение приёмки.
Команда и моя зона ответственности
- Я — продуктовая логика, визуальная модель, реализация платформы и участие в описании процессов.
- Коллега — совместное тестирование, логическая проверка и курирование описаний.
- Руководитель — HR-предметный эксперт, бизнес-контекст и проверка продуктовых решений.
Реализацией платформы с ИИ руководил я: задавал требования, интерфейс, архитектурные решения и проверял результат.
Решения и их причины
- Привязать согласие преемника к конкретному составу обязанностей: изменение состава требует нового решения.
- Разделить текущую ответственность и авторство прошлых действий; проверять права на сервере.
- Развить HTML-карту в платформу с ролями и рабочими действиями, а не ограничиваться показом модели.
- Выносить части монолита в модули постепенно, сохраняя HTML-сборку и совместимость рабочих сценариев.
Устройство решения
Браузер → шлюз с разрешёнными маршрутами → Node ESM → репозитории → PostgreSQL → планировщики.
HTML собирается из шаблона и модулей стилей, клиентского кода, логики приложения и предметной области. Серверная часть хранится отдельно.
Разделение монолита идёт поэтапно: совместимый runtime сохраняется. Это не полная замена прежней архитектуры.
Порядок работы
- HTML-карта
- Интерактивная платформа
- Роли и рабочие сценарии
- Поэтапное разделение монолита
- Приёмка и передача
Условный пример · передача дел
Согласие относится к конкретным обязанностям
Сотрудник передаёт процесс одному преемнику, а текущие задачи — другому. Каждый должен понимать, за что он принимает ответственность.
Если после согласия преемника состав передачи изменился, его решение нужно получить заново.
Как проходит сценарий
- Собрать действующие обязанности и назначить преемника для каждой из них.
- Показать каждому преемнику его состав передачи и получить согласие.
- При изменении состава запросить новое согласие на обновлённый набор.
- Перенести текущую ответственность, сохранив авторов прежних комментариев и решений.
Критерии приёмки этого сценария
- Преемник принял процесс; до завершения передачи ему добавили задачу. Ожидается новое согласие.
- После передачи автором старого комментария остаётся прежний сотрудник.
- Согласие одного преемника не заменяет согласие другого на его обязанности.
Система меняет операционную ответственность и сохраняет историю решений.
Сценарий иллюстрирует правило; это не протокол испытаний рабочей системы.
Что получилось
Результат работы
В платформе определены роли, задачи, согласования, передача дел, зависимости процессов и правила внесения изменений.
Использование и передача
Решение связало процессы, владельцев, участников, задачи и согласования. После исправлений платформа прошла итоговую приёмку и была передана ответственным в сентябре 2026 года.
Показатели зафиксированной версии
Исторический срез, август 2026: 16 верхнеуровневых + 145 процессов в матрице = 161 процесс. Отдельная техническая метрика того выпуска: 16 развёрнутых миграций. Это масштаб модели и проверки исторического выпуска.
- 16
- верхнеуровневых процессовОтдельные процессы верхнего уровня; не развёрнутые миграции.
- 145
- отдельных процессов в матрицеСамостоятельные процессы матрицы; не утверждение об автоматизации или полном описании.
161 процесс в общей модели. Отдельная техническая метрика: 16 развёрнутых миграций
Материалы и проверка
Проверка и границы решения
В сентябре 2026 года исправленная платформа принята и передана. Проверки передачи ответственности описаны в сценарии выше; исторические проверки выпуска — в показателях версии.
Что проверялось
- После изменения состава передачи запрашивается новое согласие преемника. Решения разных преемников проверяются независимо.
- Переход текущих обязанностей не меняет авторов старых комментариев и решений. Замечания устранены при итоговой приёмке.
- Исторический выпуск августа 2026 года: резервная копия, миграции, восстановление, работоспособность и контроль доступа.
Границы результата
- 161 — масштаб процессной модели августа 2026 года. Степень описания и автоматизации процессов учитывается отдельно.