Project Requirements Platform

Контекст продукта

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

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

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

Связи и рабочие режимы

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

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

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

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

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

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

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

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

Семейства экранов

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

Рабочая область

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

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

Проекты

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

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

Репозиторий требований

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

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

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

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

Оценка соответствия

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

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

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

• Покрытие — полностью, частично или не покрывает требование.
• Реализация — стандартная, с настройкой, расширением, разработкой, сторонним решением или со статусом «не реализуется».

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

Организации и участники

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

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

Обсуждения и события

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

AI-assisted слой

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

Он может помогать в нескольких рабочих задачах:

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

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

Адаптация для mobile

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

Широкие desktop-поверхности переводились в более компактные mobile-сценарии:

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

Mobile-представление сохраняло смысл сценария и переводило desktop-механику в последовательность, удобную для небольшого экрана.

Интерфейсная система

Интерфейсная система удерживает повторяемые enterprise-паттерны для репозитория требований, detail-сценариев, scoring, activity-слоя и mobile-представлений.

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

• плотные таблицы;
• cards;
• side panels;
• модальные окна;
• filters;
• empty states;
• status markers;
• карточки комментариев;
• activity feed;
• mobile requirement cards;
• evaluation chips;
• action menus.

Зафиксированные паттерны задавали повторяемые правила для таблиц, карточек, side panels, модальных окон, комментариев, статусов и мобильных сценариев.

Публичная версия

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

Публичная версия показывает продуктовую логику, UX-архитектуру, decision-support сценарии, семейства экранов и обновлённый визуальный слой. Static concept используется как форма презентации и не подменяет исходные проектные материалы.

Результат работы

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