Project Requirements Platform

Обзор и контекст продукта

Project Requirements Platform — enterprise-система для управления требованиями, проектной документацией, оценкой решений и проектным governance.

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

В рамках проектной работы нужно было превратить сложную предметную область в понятную интерфейсную систему: workspace, проекты, репозиторий требований, detail-сценарии, scoring, каталог решений, организации, коммуникации и mobile-представления.

Главная задача была не в том, чтобы спроектировать ещё одну таблицу требований, а в том, чтобы сделать требования рабочим инструментом принятия решений.

Почему продукт сложный

Требование в такой системе — это не статичная текстовая строка. У него есть источник, тип, категория, описание, статус, ответственный, связь с проектом, связь с продуктом или решением, комментарии, история изменений, оценка покрытия и итоговое влияние на выбор решения.

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

Поэтому интерфейс должен был поддерживать несколько рабочих режимов:

• быстрый обзор требований в таблице;
• группировку и фильтрацию;
• детальный просмотр требования;
• редактирование и уточнение формулировок;
• оценку покрытия требования продуктом или решением;
• комментарии и обсуждения;
• связь с проектами, поставщиками и организациями;
• mobile-сценарии для просмотра и оценки.

Зона ответственности и объём работ

Работа была сфокусирована на UX-структуре продукта, интерфейсной архитектуре и подготовке материалов, которые можно было обсуждать с командой и передавать дальше в разработку.

В работу входили:

• анализ предметной области и ключевых сущностей платформы;
• проектирование структуры продукта: workspace, проекты, требования, каталог решений, организации, команда, события;
• проектирование dashboard и проектных рабочих поверхностей;
• UX-логика репозитория требований, групп требований и детального просмотра;
• сценарии создания, редактирования, фильтрации и категоризации требований;
• сценарии оценки соответствия решений требованиям;
• таблицы, карточки, side panels, модальные окна, empty states и mobile-представления;
• комментарии, обсуждения и activity-сценарии вокруг требований;
• concept-layer для AI-assisted работы с формулировками требований;
• подготовка интерфейсных материалов для дальнейшей реализации.

Screen Families

Интерфейс был разложен на несколько связанных screen families. Это помогло не проектировать продукт как набор отдельных страниц и удержать общую систему.

Workspace Family

Workspace работает как стартовая область пользователя. Он помогает быстро вернуться к работе: открыть проекты, репозиторий требований, каталог решений, события, недавно просмотренные материалы, дедлайны или закладки.

Это не маркетинговая home page, а рабочий hub. Его задача — снизить время возвращения в контекст.

Project Family

Проект — центральный контейнер работы. Внутри него собираются требования, команда, заказчики, потенциальные поставщики, встречи, события, бизнес-цели и прогресс.

Для этой family были важны список проектов, карточный и табличный вид, создание проекта, empty states, project dashboard и summary-блоки.

Requirements Family

Requirements repository — ядро продукта. Здесь пользователь работает с требованиями: ищет, фильтрует, группирует, добавляет, редактирует, импортирует и открывает детали.

Важен баланс между плотностью и читаемостью. Аналитик может работать не с одним требованием, а с десятками или сотнями, поэтому таблица, фильтры, группы и быстрые действия должны работать вместе.

Evaluation / Scoring Family

Этот слой превращает требования в инструмент выбора решений. Пользователь оценивает, насколько продукт, поставщик или вариант реализации покрывает каждое требование.

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

Organization / Counterparties Family

Требования и решения в enterprise-проектах связаны с реальными организациями. Поэтому в продукте нужен слой компаний, подразделений, сотрудников, контактов, поставщиков и продуктов / технологий.

Этот слой не должен превращаться в отдельную CRM, оторванную от требований. Его задача — поддерживать проектную работу: кто участвует, кто отвечает, кто поставщик, какие решения связаны с организацией.

Communication / Activity Family

Вокруг требований возникают обсуждения, события, комментарии, изменения и уведомления. Этот слой помогает не терять контекст: кто изменил требование, что обсуждалось, какие вопросы остались открытыми и какие события связаны с проектом.

Requirements Repository

Репозиторий требований должен был поддерживать массовую работу с данными: таблицы, категории, типы требований, фильтры, добавление, редактирование, импорт, empty states и переход к детальному просмотру.

Side panel использовался для добавления и редактирования требований без потери контекста списка. Это важно для enterprise-интерфейса: пользователь остаётся в рабочей поверхности, видит таблицу и может быстро закрыть или сохранить действие.

Таблицы использовались там, где нужна плотность и сравнение. Карточки — там, где важен быстрый обзор или dashboard-подача. Эти режимы не являются просто разными визуальными вариантами: они поддерживают разные способы работы.

Requirement Detail и scoring

Детальный экран требования должен был быть фокусной рабочей единицей. На этом уровне пользователь видит описание, пояснение, атрибуты, категорию, статус, связанные решения, комментарии и варианты оценки покрытия.

Scoring-сценарий помогает зафиксировать экспертную оценку:

• полностью покрывает требование;
• частично покрывает;
• не покрывает;
• реализуется стандартно;
• требует настройки;
• требует расширения;
• требует разработки;
• требует стороннего решения;
• не реализуется.

Если решение не покрывает требование или покрывает его частично, интерфейс должен помочь зафиксировать причину. Это превращает субъективную экспертную оценку в структуру, которую можно анализировать и использовать при выборе решения.

AI-assisted слой

В concept-layer предусмотрен AI-помощник для работы с требованиями. Его роль не в том, чтобы принимать решения за команду, а в том, чтобы ускорять подготовку и чистку текста.

Возможные задачи:

• проверить формулировку на неоднозначность;
• предложить черновик;
• найти дубли;
• декомпозировать перегруженное требование;
• помочь структурировать выделенный фрагмент текста.

Финальное решение, оценка покрытия и принятие требований остаются за человеком и проектной командой. AI здесь работает как вспомогательный слой, а не как автоматический decision-maker.

Mobile adaptation

Основная рабочая плотность продукта — desktop. Но часть сценариев должна была работать и на mobile: просмотр проектов, открытие требования, выбор варианта оценки, навигация по группам и быстрые действия.

Мобильную версию нельзя было строить как уменьшенную таблицу. Поэтому широкие desktop-поверхности переводились в более компактные сценарии:

• карточки вместо широких строк;
• chips для вариантов оценки;
• отдельный экран требования;
• compact progress;
• action menu вместо полного toolbar;
• пошаговая навигация по группам требований.

Так mobile сохраняет смысл сценария, но не пытается повторить desktop-механику один к одному.

Interface system

В кейсе важна не только структура страниц, но и повторяемые enterprise-паттерны.

В систему входили:

• high-density tables;
• cards;
• side panels;
• modal windows;
• filters;
• empty states;
• status markers;
• comment cards;
• activity feed;
• mobile requirement cards;
• evaluation chips;
• action menus.

Эти паттерны помогают удерживать продукт от хаоса. Когда появляются новые экраны, они не должны каждый раз решать базовые задачи заново: где таблица, где карточка, где side panel, где modal, где empty state, где comment и где status.

Public-safe presentation

Текущая версия кейса оформлена как static public-safe concept. В ней не раскрываются закрытые документы, коммерческий контекст, реальные имена участников и внутренняя документация.

Публичная версия показывает продуктовую логику, UX-архитектуру, decision-support сценарии, screen families и обновлённый визуальный слой. Это не Live Demo и не production claim, а статический кейс, который объясняет подход к проектированию сложной enterprise-системы.

Что показывает этот кейс

Project Requirements Platform показывает опыт работы с enterprise-продуктом, где интерфейс должен поддерживать не только ввод и хранение данных, но и принятие решений.

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