РОСХИМ · Портал КУ
Шаг 2 · аналитик · по ТЗ v2.0 от 17.09.2026

Состав Этапа 1 и разбор 12 открытых вопросов

Два самостоятельных результата на этой странице: (1) точный состав 10 экранов приоритета Must — какие поля и кнопки должны быть на каждом, взято дословно из Приложения Г технического задания; (2) таблица по всем 12 открытым вопросам ТЗ — по каждому указано, блокирует ли он работу над Этапом 1 или закрыт допущением. Экраны Should и этапы 2–6 — отдельным разделом в конце, это следующие шаги, не эта работа.

1. Экраны Must Этапа 1 — состав полей и действий

Все 10 экранов карты (Приложение Г.1 ТЗ) отнесены командой к приоритету Must — в ТЗ у карты экранов нет отдельной колонки приоритета, деление сделано по функциональным требованиям, которые закрывает каждый экран (подробное обоснование — на странице плана реализации). Ниже — состав каждого экрана: блок действия (кнопки) и таблица полей «поле / источник / обязательность / режим», дословно из Приложения Г.2–Г.11 ТЗ, ничего не добавлено и не изменено по смыслу.

UI-01 Рабочий стол Must

Роль: член органа или секретарь · Контекст: после входа · Результат: пользователь видит ближайшие действия и доступные заседания

Блоки экрана: «Мои ближайшие действия» (проголосовать до срока, ознакомиться с обновлёнными материалами, согласовать проект уведомления или протокола); «Ближайшие заседания» (компания — орган — дата — статус, индикаторы комплектности/ознакомления/голосования/протокола); «Просроченные поручения» (поручение — исполнитель — срок — статус).

Открыть заседаниеВсе задачиКалендарь
Поле / элементИсточникОбяз.Режим
Юридическое лицоПрава пользователя и справочникДаФильтр
Орган управленияСоставы и полномочияНетФильтр
Карточка действияЗаседание, документ или поручениеДаТолько чтение
Срок и статусСвязанный объектДаТолько чтение

UI-02 Юридические лица и органы Must

Роль: корпоративный секретарь или администратор · Контекст: настройка структуры · Результат: создана структура группы и состав органа

Блоки экрана: «Структура группы» (Компания 1 — Компания 5, модель до 26 юрлиц); «Органы выбранной компании» (совет директоров, комитеты, аппарат корпоративного секретаря); «Состав органа» (ФИО — роль — начало/окончание полномочий, документ-основание и контакты).

Добавить обществоДобавить органИзменить составСохранить
Поле / элементИсточникОбяз.Режим
Краткое и полное наименованиеСправочник юридических лицДаРедактирование
Тип и наименование органаКарточка органаДаРедактирование
Председатель и секретарьСостав органаДаВыбор пользователя
Период полномочийРешение о назначенииДаДата
Документ-основаниеФайловое хранилищеНетЗагрузка

UI-03 Реестр заседаний Must

Роль: секретарь или участник · Контекст: список доступных заседаний · Результат: найдено заседание и открыт нужный контекст

Блоки экрана: «Фильтры» (юрлицо, орган, период, форма, статус, ответственный); «Результаты» (дата, компания, орган, форма, статус); «Представление» (таблица или календарь, сортировка по дате/статусу/компании).

Создать заседаниеОткрытьЭкспорт
Поле / элементИсточникОбяз.Режим
Компания и органКарточка заседанияДаФильтр и колонка
Дата и формаКарточка заседанияДаФильтр и колонка
СтатусСтатусная модельДаФильтр и колонка
ГотовностьМатериалы, рассылка, голосаНетИндикатор

UI-04 Карточка заседания Must

Роль: корпоративный секретарь · Контекст: черновик или подготовка · Результат: заполнены реквизиты, участники и статус

Блоки экрана: «Основные реквизиты» (компания*, орган*, наименование*, форма* очная/заочная, дата и время начала*, дата окончания, место или ссылка, председательствующий*, секретарь*); «Участники» (члены органа из действующего состава, приглашённые по отдельным вопросам, признаки присутствия и письменного мнения); «Процесс» — статусная модель черновик → подготовка → доступно → голосование → подготовка протокола → состоялось → архив, с историей статусов, авторов и времени.

СохранитьПроверить комплектностьПодготовить уведомлениеОпубликовать
Поле / элементИсточникОбяз.Режим
Компания и органСправочникиДаВыбор до публикации
Название и формаВвод секретаряДаРедактирование
Начало и окончаниеВвод секретаряДаДата и время
Место или ссылкаВвод секретаряПо формеРедактирование
ПредседательствующийСостав органаДаВыбор пользователя
УчастникиСостав органаДаВыбор и исключение

UI-05 Повестка и материалы Must

Роль: секретарь или участник · Контекст: подготовка или доступно · Результат: сформирована версия повестки и комплект материалов

Блоки экрана: «Версия повестки» (номер, дата и время, автор; изменения после публикации создают новую версию и уведомление); карточки вопросов повестки (докладчик, время, проект решения, материалы — файл/версия/конфиденциальность/скачать, приглашённые по вопросу); перетаскивание вопросов и материалов меняет порядок до публикации; помощник комплектности показывает отсутствующие документы.

Добавить вопросЗагрузить материалыСформировать комплектОпубликовать версию
Поле / элементИсточникОбяз.Режим
Номер и название вопросаВвод секретаряДаРедактирование
Проект решенияВвод или файлДаРедактирование
Докладчик и приглашённыеПользователиНетВыбор
Материал и версияФайловое хранилищеПо чек-листуЗагрузка
Уровень доступаВвод секретаряДаВыбор

UI-06 Голосование участника Must

Роль: член совета директоров или комитета · Контекст: голосование открыто до срока · Результат: голос и особое мнение зафиксированы

Блоки экрана: вопрос (номер и наименование, проект решения, материалы — открыть/версия/ознакомление подтверждено); «Позиция участника» (За / Против / Воздержался, особое мнение — многострочное поле, приложить подписанный файл); «Подтверждение» — перед отправкой показываются выбранная позиция и версия материалов, после отправки — время и регистрационный идентификатор.

НазадСохранить черновикОтправить голос
Поле / элементИсточникОбяз.Режим
Вариант голосаВыбор участникаДаОдин вариант
Особое мнениеВвод участникаНетРедактирование до отправки
ПриложениеФайловое хранилищеНетЗагрузка
Версия материаловОпубликованный комплектДаТолько чтение
Время и идентификаторСерверДаПосле отправки

UI-07 Итоги и протокол Must

Роль: корпоративный секретарь · Контекст: подготовка протокола · Результат: зафиксированы итог и проект протокола

Блоки экрана: «Итоги по вопросу» (за/против/воздержался/не голосовал — числа, участники с письменным или особым мнением, ссылки на записи голосования по правам); «Юридический итог MVP» (кворум* — имеется/не имеется/не определён, результат* — решение принято/не принято, комментарий секретаря и основание*); «Проект протокола» (номер, дата составления, председатель, секретарь, предпросмотр документа и список приложений, версии и маршрут согласования).

Сохранить итогСформировать протоколНа согласованиеОпубликовать
Поле / элементИсточникОбяз.Режим
Количество голосовЗаписи голосованияДаАвтоматически
КворумРешение секретаря в MVPДаВыбор
РезультатРешение секретаря в MVPДаВыбор
Комментарий и основаниеВвод секретаряДаМногострочное поле
Номер и дата протоколаВвод секретаряДаРедактирование

UI-08 Поручения Must

Роль: секретарь, контролёр или исполнитель · Контекст: после фиксации решения · Результат: решение превращено в контролируемое поручение

Блоки экрана: «Источник» (компания, орган, заседание, вопрос, пункт принятого решения); «Поручение» (содержание*, ответственный*, соисполнители, срок*, контролёр*, приоритет, статус, отчёт исполнителя и подтверждающие файлы); «История» — создание, изменение срока, напоминания, отчёты, возврат на доработку и закрытие.

Создать из решенияНапомнитьОтправить отчётЗакрыть
Поле / элементИсточникОбяз.Режим
Источник решенияПротокол и вопросДаАвтоматически
СодержаниеПункт решения или вводДаРедактирование
Ответственный и контролёрПользователиДаВыбор
СрокВвод секретаряДаДата
Отчёт и файлыВвод исполнителяПри закрытииРедактирование

UI-09 Архив и поиск Must

Роль: пользователь в пределах полномочий · Контекст: поиск по разрешённым объектам · Результат: найден и открыт разрешённый объект

Блоки экрана: «Поисковая строка» (название вопроса, решение, документ, поручение или ФИО); «Фильтры» (компания, орган, период, тип объекта, статус, конфиденциальность); «Результаты» (тип, название, компания и орган, дата, совпавший фрагмент; недоступные объекты и фрагменты не отображаются; архивный объект открывается только для чтения).

НайтиСбросить фильтрыОткрытьЭкспорт по правам
Поле / элементИсточникОбяз.Режим
Поисковый запросВвод пользователяНетПолнотекстовый поиск
ФильтрыСправочники и праваНетМножественный выбор
Фрагмент результатаПоисковый индексДаТолько чтение
Архивный статусЖизненный циклДаТолько чтение

UI-10 Уведомления Must

Роль: корпоративный секретарь · Контекст: подготовка и публикация заседания · Результат: создано и отправлено адресное уведомление

Блоки экрана: «Шаблон» (уведомление о заседании, изменение повестки, открытие голосования, готовность протокола); «Адресаты и каналы» (члены органа, приглашённые по вопросам, отдельные пользователи; портал, e-mail, иные подключённые каналы); «Сообщение» (тема*, текст*, ссылка на заседание, переменные подстановки, предпросмотр по каждому каналу); «Доставка» (отправлено / доставлено / ошибка / открыто, если канал подтверждает).

ПредпросмотрСохранить шаблонОтправитьПовторить ошибочные
Поле / элементИсточникОбяз.Режим
Тип уведомленияСправочник шаблоновДаВыбор
АдресатыУчастники и приглашённыеДаМножественный выбор
КаналНастройки интеграцийДаМножественный выбор
Тема и текстШаблон и переменныеДаРедактирование
Статус доставкиШлюз каналаДаТолько чтение

Источник всего раздела: Приложение Г.2–Г.11 технического задания «Портал корпоративного управления Росхим», версия 2.0. Звёздочка (*) у поля в тексте блоков — обязательность реквизита по ТЗ.

2. Двенадцать открытых вопросов — блокер или допущение

Раздел 13 ТЗ содержит 12 вопросов, от ответа на которые зависит объём решения. По каждому — что говорит сам ТЗ (дословно, столбец «Почему влияет на объём»), и итоговый статус для Этапа 1: блокер — работа над этим вопросом стоит без ответа заказчика, здесь же — кому адресован; допущение — решение принято командой, чтобы не останавливать работу, с формулировкой допущения.

Адресат в тексте ТЗ ни для одного вопроса не указан отдельно — вопросы обращены к Группе Росхим в целом, без разбивки по конкретному сотруднику.

КодРешение (дословно из ТЗ)СтатусАдресат / формулировка допущения
Q-01 Реальные наименования, реквизиты и состав органов 26 юридических лиц отвечено Заказчик ответил на вопрос «пример реальных данных или справочников по экранам Этапа 1»: используем моковые данные. Поэтому в Этапе 1 остаются демо-общества Компания 1 — Компания 5 с придуманными реквизитами; реальные наименования и состав органов 26 юридических лиц подключаются на этапе тиража (этап 4), когда заказчик решит их передать.
Q-02 Формулы кворума, долей, неравных голосов и кумулятивного голосования допущение Сам ТЗ относит это к «промышленной очереди»: в MVP итог голосования (кворум и результат) вводит и фиксирует секретарь вручную, выбором из списка, без автоматического расчёта по формулам.
Q-03 Типы электронной подписи, провайдер и перечень документов допущение В Этапе 1 нет реальных интеграций (см. допущения ТЗ проекта). Поле «приложить подписанный файл» на экране голосования — просто загрузка файла, без проверки подписи и без подключения к провайдеру. Выбор провайдера ЭП — решение для следующих этапов.
Q-04 SSO, каталог, MFA и аварийный доступ допущение Уже зафиксировано в согласованном задании: вход в портал упрощённый, учётные записи заводит команда сама, без подключения к корпоративному входу, SSO и MFA.
Q-05 СЭД, архив, почта, календарь, SMS и push первой очереди допущение Реальных интеграций с внешними системами в Этапе 1 нет. Экран «Уведомления» показывает шаблон, адресатов, каналы и статус доставки как рабочий интерфейс, без фактической отправки во внешние СЭД/почту/SMS.
Q-06 Размещение: контур заказчика, on-prem или иной вариант; dev, test, prod, DR допущение Этап 1 разворачивается в контуре платформы СРЕДА как один демонстрационный контур. Выбор варианта размещения и состава dev/test/prod/DR — вопрос этапов «Проектирование» и «Тираж» (2 и 4 по плану), на состав экранов Этапа 1 не влияет.
Q-07 Классификация данных и допустимые LLM допущение Ни один из 10 Must-экранов по составу полей (раздел 1 этой страницы) не обращается к LLM для обработки пользовательских данных. Вопрос актуален для AI-сценариев следующих этапов — см. Q-11.
Q-08 Сроки хранения документов, голосов, логов и AI-трасс допущение На демонстрационных данных Этапа 1 срок хранения не ограничивается. Политику хранения нужно закрепить до пилота (этап 3) и тем более до тиража (этап 4).
Q-09 Целевая одновременная нагрузка, SLA, RPO и RTO допущение Этап 1 — демонстрационный контур не под промышленную нагрузку. Показатели нагрузки и SLA/RPO/RTO нужны при проектировании инфраструктуры пилота и тиража, не для этой работы.
Q-10 Объём и качество исторических данных допущение Миграция в Этап 1 не входит — используются заново введённые демо-данные Компания 1 — Компания 5. Оценка архивов прежних систем — задача этапа проектирования миграции перед тиражом.
Q-11 Обязательные AI-сценарии пилота допущение В составе полей и действий 10 Must-экранов (раздел 1) нет ни одного обязательного AI-сценария. Состав AI-сценариев для пилота — отдельное решение к этапу 3, в Этап 1 не входит.
Q-12 Необходимость английской версии и требования к брендингу допущение Интерфейс Этапа 1 делается на русском языке, с рабочей (не финальной) палитрой без официального брендбука Росхима — см. раздел «Дизайн-система» на странице плана реализации. Английская версия и фирменный стиль — решение дизайна на этапе «Проектирование» или позже.

Источник вопросов: раздел 13 технического задания «Решения, требующие подтверждения». Итог: все 12 вопросов закрыты — 1 (Q-01) ответом заказчика, 11 допущениями команды; блокеров для Этапа 1 не осталось.

3. Следующие шаги (в эту работу не входят)

Should-элементы внутри Must-экранов

Формального деления самих экранов на Must/Should в ТЗ нет — приоритеты расставлены по 73 функциональным требованиям, а не по экранам (подробности — в разделе 1 плана реализации). Внутри уже перечисленных 10 Must-экранов в ТЗ отмечены Should/Could-частности, которые в Этап 1 не входят:

Печатные формы (Приложение Г.12–Г.17 ТЗ)

Шесть печатных форм — уведомление, повестка, опросный лист и письменное мнение, протокол, выписка из протокола, и общие правила реализации форм (Г.17) — в ТЗ описаны отдельно от 10 экранов Приложения Г.1 и не входят в состав веб-экранов Этапа 1. Кнопки вида «Сформировать протокол» или «Экспорт» на экранах Must в Этапе 1 остаются действиями интерфейса; формирование итоговых DOCX/PDF документов по этим формам — задача следующего этапа разработки.

Экраны Should

Отдельного списка «экраны Should» в материалах проекта нет: все 10 экранов карты (Приложение Г.1) командой отнесены к Must, потому что закрывают хотя бы одно Must-требование (обоснование — раздел «Карта экранов MVP» плана реализации). Если заказчику нужно формальное деление части экранов на Should, это отдельный вопрос для согласования, не входящий в 12 вопросов раздела 13 ТЗ.

Этапы 2–6 плана (раздел 12 ТЗ)

ЭтапСодержаниеРезультат и критерий завершения
2. РазработкаЮридическое ядро, прикладные сервисы, интерфейсы, агенты и интеграцииФункции развёрнуты в test, автоматические тесты проходят
3. ПилотНастройка пяти условных обществ, обучение, сценарии, исправления и опытная эксплуатацияПодписан протокол приёмочных испытаний
4. ТиражПодключение остальных обществ, данных и пользователейСогласованный охват группы работает в prod
5. СопровождениеSLA, мониторинг, инциденты, обновления, evals и развитиеЕжемесячная отчётность и управляемый backlog

Этап 0 «Уточнение MVP» и этап 1 «Проектирование» из раздела 12 ТЗ по смыслу совпадают с текущей работой (сбор фактов, макеты, разбор вопросов) и каркасом портала — здесь не повторяются как «следующий шаг». В ТЗ нет длительности (недель/дат) ни для одного из 6 этапов — оценки сроков на странице плана реализации сделаны командой, а не взяты из документа.