Initial commit: add project files and documentation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Наталия
@@ -0,0 +1,479 @@
|
||||
# ВКУС: C4 Context, клиентский flow и связь с capabilities
|
||||
|
||||
Версия: `v0.1`
|
||||
Назначение: companion-документ к PDF `ВКУС_C4_context_flow_capabilities_v0.1.pdf` для самостоятельного изучения командой.
|
||||
|
||||
Документ показывает, как связать:
|
||||
|
||||
```text
|
||||
клиентский путь
|
||||
→ capabilities
|
||||
→ архитектурные компоненты
|
||||
→ метрики
|
||||
```
|
||||
|
||||
Ключевая идея: диаграммы не должны быть «красивой картинкой отдельно от требований». Они должны помогать проследить, **какая capability нужна на каком шаге клиентского пути и какими архитектурными элементами она реализуется**.
|
||||
|
||||
---
|
||||
|
||||
## 1. Общая логика комплекта диаграмм
|
||||
|
||||
Для обсуждения целевой витрины сервисного входа лучше использовать не одну перегруженную схему, а набор связанных представлений:
|
||||
|
||||
| Артефакт | Что показывает | Зачем нужен |
|
||||
|---|---|---|
|
||||
| C4 Context Diagram | Границы целевой системы, акторов и внешние системы | Понять архитектурный контекст решения |
|
||||
| Customer Journey Flow | Путь пользователя и включение capabilities | Понять, как меняется клиентский опыт |
|
||||
| Service Blueprint Light | Пользователь / Frontstage / Backstage / Системы | Связать UX, capabilities и архитектуру |
|
||||
| Traceability Matrix | Шаг CJM → capability → компонент → метрика | Сделать связь формальной и проверяемой |
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
Одна супер-диаграмма со всеми системами, шагами, capabilities, roadmap и стрелками.
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
1. Context — кто и с какими системами взаимодействует.
|
||||
2. Flow — как пользователь проходит путь.
|
||||
3. Blueprint — какие capabilities и системы включаются на каждом шаге.
|
||||
4. Matrix — формальная трассировка CJM → capabilities → architecture.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. Capability-легенда
|
||||
|
||||
Чтобы диаграммы можно было читать и сопоставлять между собой, вводятся постоянные ID capabilities.
|
||||
|
||||
| ID | Capability | Краткий смысл |
|
||||
|---|---|---|
|
||||
| CAP-01 | Единый сервисный вход | Пользователь идет в один понятный вход во ВКУС |
|
||||
| CAP-02 | Понимание намерения пользователя | Система понимает задачу в пользовательском языке |
|
||||
| CAP-03 | Помощь до создания обращения | Витрина пытается помочь до создания заявки |
|
||||
| CAP-04 | Предзаполнение обращения | Система подставляет известные данные и контекст |
|
||||
| CAP-05 | Автомаршрутизация и корректное создание обращения | Обращение уходит в правильный процесс / группу |
|
||||
| CAP-06 | Прозрачный статус обращения | Пользователь понимает, что происходит |
|
||||
| CAP-07 | Уведомления и управление ожиданиями | Пользователь видит next best action и не пропускает уточнения |
|
||||
| CAP-08 | Аналитика клиентского пути | События, тексты и логи превращаются в метрики |
|
||||
| CAP-09 | Управление знаниями и инструкциями | Инструкции актуальны, понятны и используются в self-service |
|
||||
| CAP-10 | Контур постоянного улучшения | Обратная связь попадает в backlog улучшений |
|
||||
|
||||
---
|
||||
|
||||
## 3. C4 Context Diagram v0.1
|
||||
|
||||
### 3.1. Назначение
|
||||
|
||||
C4 Context Diagram отвечает на вопрос:
|
||||
|
||||
> Какие люди и внешние системы взаимодействуют с целевой системой «Витрина сервисного входа ВКУС»?
|
||||
|
||||
На этом уровне не детализируем внутренние микросервисы. Показываем границу целевой системы и внешние зависимости.
|
||||
|
||||
### 3.2. Mermaid-код
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
|
||||
%% Actors
|
||||
User["Сотрудник компании<br/>пользователь поддержки"]
|
||||
Support["Сотрудник техподдержки"]
|
||||
KnowledgeOwner["Владелец знаний / инструкций"]
|
||||
ServiceOwner["Владелец сервиса / аналитик CX"]
|
||||
|
||||
%% Target system
|
||||
subgraph Target["Целевая система: Витрина сервисного входа ВКУС"]
|
||||
VKUS["ВКУС<br/>единый сервисный вход<br/>CAP-01"]
|
||||
end
|
||||
|
||||
%% External systems
|
||||
ITSM["ITSM / Creatio BPM<br/>обращения, SLA, статусы<br/>CAP-05 CAP-06"]
|
||||
ServiceCatalog["Каталог услуг<br/>услуги, карточки, маршруты<br/>CAP-02 CAP-05"]
|
||||
KnowledgeBase["База знаний / инструкции<br/>Confluence, SharePoint, файлы<br/>CAP-03 CAP-09"]
|
||||
SearchRAG["Search / RAG / LLM layer<br/>поиск, классификация, ответы<br/>CAP-02 CAP-03"]
|
||||
IAM["IAM / AD<br/>пользователь, роли, доступы<br/>CAP-04"]
|
||||
HR["HR / оргструктура<br/>подразделение, руководитель<br/>CAP-04"]
|
||||
CMDB["CMDB / Inventory<br/>системы, сервисы, зависимости<br/>CAP-04 CAP-05"]
|
||||
Notify["Каналы уведомлений<br/>почта, Teams, push<br/>CAP-07"]
|
||||
Analytics["CX Analytics / Data Mart / BI<br/>метрики, тексты, логи<br/>CAP-08 CAP-10"]
|
||||
|
||||
%% User interactions
|
||||
User -->|"Описывает задачу,<br/>получает ответ / заявку / статус"| VKUS
|
||||
VKUS -->|"Показывает статус,<br/>запрашивает уточнения"| User
|
||||
|
||||
%% Support and owners
|
||||
Support -->|"Исполняет обращения"| ITSM
|
||||
KnowledgeOwner -->|"Актуализирует инструкции"| KnowledgeBase
|
||||
ServiceOwner -->|"Анализирует путь,<br/>формирует backlog улучшений"| Analytics
|
||||
|
||||
%% System interactions
|
||||
VKUS <-->|"Создание обращения,<br/>комментарии, статусы"| ITSM
|
||||
VKUS <-->|"Поиск услуги,<br/>карточки, маршруты"| ServiceCatalog
|
||||
VKUS <-->|"Поиск ответа,<br/>источники знаний"| KnowledgeBase
|
||||
VKUS <-->|"Классификация намерения,<br/>поиск, краткий ответ"| SearchRAG
|
||||
VKUS <-->|"Данные пользователя,<br/>роли, доступы"| IAM
|
||||
VKUS <-->|"Оргданные"| HR
|
||||
VKUS <-->|"Контекст систем и сервисов"| CMDB
|
||||
VKUS -->|"Уведомления,<br/>next best action"| Notify
|
||||
VKUS -->|"События клиентского пути,<br/>логи, оценки"| Analytics
|
||||
|
||||
ITSM -->|"Статусы, сроки,<br/>маршрутизация"| Analytics
|
||||
KnowledgeBase -->|"Качество знаний,<br/>knowledge gaps"| Analytics
|
||||
ServiceCatalog -->|"Проблемные карточки,<br/>ошибки выбора"| Analytics
|
||||
```
|
||||
|
||||
### 3.3. Как читать диаграмму
|
||||
|
||||
**ВКУС** — это не просто портал и не отдельный экран. В этой модели он выступает как **граница целевой системы**: витрина сервисного входа.
|
||||
|
||||
**Search / RAG / LLM layer** — не центр архитектуры, а один из supporting layers, который помогает реализовать CAP-02 и CAP-03.
|
||||
|
||||
**Analytics / Data Mart / BI** — обязательная часть контекста, потому что без нее невозможны MVP 0 / Data Discovery, метрики и контур улучшений.
|
||||
|
||||
### 3.4. Вопросы для уточнения границ
|
||||
|
||||
| Вопрос | Почему важен |
|
||||
|---|---|
|
||||
| ВКУС — это вся целевая система или только frontstage? | Определяет границу C4 Context |
|
||||
| Search/RAG/LLM layer — внутренний компонент или внешний сервис? | Влияет на следующий C4 Container уровень |
|
||||
| Каталог услуг — часть решения или внешняя мастер-система? | Влияет на ответственность и governance |
|
||||
| Analytics/Data Mart — отдельный компонент проекта или корпоративная платформа? | Влияет на архитектуру MVP 0 |
|
||||
| Notification service — существующие каналы или новый компонент? | Влияет на MVP 4 |
|
||||
|
||||
---
|
||||
|
||||
## 4. Customer Journey Flow + Capabilities v0.1
|
||||
|
||||
### 4.1. Назначение
|
||||
|
||||
Диаграмма отвечает на вопрос:
|
||||
|
||||
> Как пользователь проходит путь, какие capabilities включаются на каждом шаге и какие архитектурные слои участвуют?
|
||||
|
||||
### 4.2. Mermaid-код
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
|
||||
%% Journey steps
|
||||
S1["1. Возникла проблема<br/>Пользователь не может выполнить работу"]
|
||||
S2["2. Вход во ВКУС<br/>CAP-01"]
|
||||
S3["3. Описание задачи<br/>своими словами<br/>CAP-02"]
|
||||
S4{"4. Можно помочь<br/>без обращения?<br/>CAP-03 CAP-09"}
|
||||
S5["5A. Быстрый ответ /<br/>инструкция / next best action<br/>CAP-03 CAP-09"]
|
||||
S6{"Ответ помог?"}
|
||||
S7["5B. Создание обращения<br/>с контекстом<br/>CAP-04 CAP-05"]
|
||||
S8["6. Исполнение в ITSM<br/>маршрутизация, SLA<br/>CAP-05"]
|
||||
S9["7. Понятный статус<br/>и уведомления<br/>CAP-06 CAP-07"]
|
||||
S10["8. Получение результата<br/>что сделано / что проверить"]
|
||||
S11["9. Оценка результата<br/>CAP-08 CAP-10"]
|
||||
S12["10. Контур улучшения<br/>карточки, знания, маршрутизация<br/>CAP-08 CAP-09 CAP-10"]
|
||||
|
||||
%% Main flow
|
||||
S1 --> S2 --> S3 --> S4
|
||||
S4 -->|Да| S5 --> S6
|
||||
S6 -->|Да| S11
|
||||
S6 -->|Нет| S7
|
||||
S4 -->|Нет| S7
|
||||
S7 --> S8 --> S9 --> S10 --> S11 --> S12
|
||||
|
||||
%% Architecture side notes
|
||||
A1["ВКУС Frontstage<br/>задачная главная, поиск, карточка"]
|
||||
A2["Scenario & Intent Layer<br/>классификация, сценарии, уточнения"]
|
||||
A3["Knowledge Layer<br/>база знаний, RAG/search, источники"]
|
||||
A4["Form & Prefill Layer<br/>предзаполнение, валидация, context package"]
|
||||
A5["ITSM Execution Layer<br/>Creatio, маршрутизация, SLA"]
|
||||
A6["Status & Notification Layer<br/>статусы, уведомления, next best action"]
|
||||
A7["Analytics & Improvement Layer<br/>логи, тексты, BI, backlog"]
|
||||
|
||||
S2 -.-> A1
|
||||
S3 -.-> A2
|
||||
S4 -.-> A2
|
||||
S5 -.-> A3
|
||||
S7 -.-> A4
|
||||
S8 -.-> A5
|
||||
S9 -.-> A6
|
||||
S11 -.-> A7
|
||||
S12 -.-> A7
|
||||
```
|
||||
|
||||
### 4.3. Ключевой сдвиг
|
||||
|
||||
#### Не так
|
||||
|
||||
```text
|
||||
Пользователь → форма → заявка → ожидание
|
||||
```
|
||||
|
||||
#### А вот так
|
||||
|
||||
```text
|
||||
Пользователь → описание задачи → быстрый ответ или предзаполненная заявка → понятный статус → оценка → улучшение сервиса
|
||||
```
|
||||
|
||||
Важный принцип: обращение создается **не всегда**. Сначала витрина пытается помочь без создания заявки.
|
||||
|
||||
---
|
||||
|
||||
## 5. Service Blueprint Light v0.1
|
||||
|
||||
### 5.1. Назначение
|
||||
|
||||
Blueprint-вариант лучше всего показывает связь:
|
||||
|
||||
```text
|
||||
путь пользователя
|
||||
→ frontstage ВКУС
|
||||
→ backstage capabilities
|
||||
→ системы
|
||||
```
|
||||
|
||||
Он полезен для совместного обсуждения UX, бизнес-аналитиками и архитекторами.
|
||||
|
||||
### 5.2. Mermaid-код
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
|
||||
subgraph U["Пользователь"]
|
||||
U1["Возникла проблема"]
|
||||
U2["Открывает ВКУС"]
|
||||
U3["Описывает задачу"]
|
||||
U4["Получает ответ<br/>или создает обращение"]
|
||||
U5["Следит за статусом"]
|
||||
U6["Получает результат"]
|
||||
U7["Оценивает"]
|
||||
end
|
||||
|
||||
subgraph F["Frontstage: ВКУС"]
|
||||
F1["Задачная главная<br/>CAP-01"]
|
||||
F2["Поле описания / сценарии<br/>CAP-02"]
|
||||
F3["Короткий ответ<br/>или карточка обращения<br/>CAP-03 CAP-04"]
|
||||
F4["Статус и next best action<br/>CAP-06 CAP-07"]
|
||||
F5["Оценка результата<br/>CAP-08 CAP-10"]
|
||||
end
|
||||
|
||||
subgraph B["Backstage capabilities"]
|
||||
B1["Понимание намерения<br/>CAP-02"]
|
||||
B2["Поиск знаний<br/>CAP-03 CAP-09"]
|
||||
B3["Предзаполнение<br/>CAP-04"]
|
||||
B4["Маршрутизация<br/>CAP-05"]
|
||||
B5["Аналитика пути<br/>CAP-08"]
|
||||
B6["Feedback loop<br/>CAP-10"]
|
||||
end
|
||||
|
||||
subgraph S["Системы"]
|
||||
S1["Каталог услуг"]
|
||||
S2["База знаний"]
|
||||
S3["Search / RAG / LLM"]
|
||||
S4["IAM / HR / CMDB"]
|
||||
S5["ITSM / Creatio"]
|
||||
S6["Notifications"]
|
||||
S7["Data Mart / BI"]
|
||||
end
|
||||
|
||||
U1 --> U2 --> U3 --> U4 --> U5 --> U6 --> U7
|
||||
|
||||
U2 --> F1
|
||||
U3 --> F2
|
||||
U4 --> F3
|
||||
U5 --> F4
|
||||
U7 --> F5
|
||||
|
||||
F2 --> B1
|
||||
F3 --> B2
|
||||
F3 --> B3
|
||||
F3 --> B4
|
||||
F4 --> B4
|
||||
F5 --> B5
|
||||
B5 --> B6
|
||||
|
||||
B1 --> S1
|
||||
B1 --> S3
|
||||
B2 --> S2
|
||||
B2 --> S3
|
||||
B3 --> S4
|
||||
B4 --> S5
|
||||
F4 --> S5
|
||||
F4 --> S6
|
||||
B5 --> S7
|
||||
B6 --> S2
|
||||
B6 --> S1
|
||||
```
|
||||
|
||||
### 5.3. Как читать blueprint
|
||||
|
||||
| Дорожка | Что показывает |
|
||||
|---|---|
|
||||
| Пользователь | Линейный путь пользователя от проблемы до оценки результата |
|
||||
| Frontstage: ВКУС | Что пользователь видит в витрине |
|
||||
| Backstage capabilities | Какие способности срабатывают под капотом |
|
||||
| Системы | Какие архитектурные элементы обеспечивают capabilities |
|
||||
|
||||
### 5.4. Почему blueprint особенно полезен
|
||||
|
||||
Он помогает избежать ошибки, когда команда проектирует только UI. На blueprint видно, что любой видимый шаг во ВКУС требует backstage capabilities и системной поддержки.
|
||||
|
||||
Например:
|
||||
|
||||
| Видимый элемент | Что нужно под капотом |
|
||||
|---|---|
|
||||
| Поле описания задачи | Intent classification, словарь намерений, связь с каталогом услуг |
|
||||
| Короткий ответ | База знаний, RAG/search, качество источников |
|
||||
| Предзаполненная карточка | IAM, HR, CMDB, prefill service, validation rules |
|
||||
| Понятный статус | ITSM status normalization, notification service, user status dictionary |
|
||||
| Оценка результата | Event tracking, analytics, feedback backlog |
|
||||
|
||||
---
|
||||
|
||||
## 6. Мини-матрица трассировки diagram-to-architecture
|
||||
|
||||
Эта таблица нужна рядом с диаграммами. Она делает связь формальной.
|
||||
|
||||
| Шаг клиентского пути | Capability | Что делает витрина | Архитектурные компоненты | Метрика |
|
||||
|---|---|---|---|---|
|
||||
| Вход во ВКУС | CAP-01 | Дает единый сервисный вход | ВКУС, задачная главная, SSO | Доля входов через ВКУС |
|
||||
| Описание задачи | CAP-02 | Понимает намерение пользователя | Intent service, Search/LLM layer, каталог услуг | Intent accuracy, reclass rate |
|
||||
| Быстрая помощь | CAP-03, CAP-09 | Предлагает ответ или инструкцию | База знаний, RAG/search, knowledge governance | Deflection rate, helpfulness |
|
||||
| Создание обращения | CAP-04, CAP-05 | Предзаполняет форму и передает контекст | Prefill service, IAM, HR, CMDB, ITSM | Time to submit, clarification rate |
|
||||
| Исполнение | CAP-05 | Передает обращение в правильную группу | ITSM / Creatio, routing rules, service catalog | Reassignment rate |
|
||||
| Ожидание | CAP-06, CAP-07 | Показывает понятный статус и следующий шаг | Status/event service, ITSM, notifications | CSAT по ожиданию |
|
||||
| Получение результата | CAP-06 | Показывает результат в понятном виде | ITSM, ВКУС, шаблоны результата | FCR, reopen rate |
|
||||
| Оценка | CAP-08, CAP-10 | Собирает обратную связь и события пути | Data Mart, BI, feedback backlog | CSAT, feedback-to-backlog |
|
||||
| Улучшение | CAP-08, CAP-09, CAP-10 | Выявляет, что улучшать | Text analytics, knowledge governance, service catalog | Доля улучшенных карточек/инструкций |
|
||||
|
||||
---
|
||||
|
||||
## 7. Как использовать этот комплект в работе команды
|
||||
|
||||
### 7.1. Для обсуждения с бизнесом / владельцем сервиса
|
||||
|
||||
Показывать прежде всего:
|
||||
|
||||
1. Capability-легенду.
|
||||
2. Customer Journey Flow.
|
||||
3. Таблицу трассировки.
|
||||
|
||||
Главный тезис:
|
||||
|
||||
```text
|
||||
Мы проектируем не новый канал общения, а витрину сервисного входа, которая меняет путь пользователя.
|
||||
```
|
||||
|
||||
### 7.2. Для обсуждения с архитекторами
|
||||
|
||||
Показывать:
|
||||
|
||||
1. C4 Context.
|
||||
2. Blueprint.
|
||||
3. Вопросы по границам целевой системы.
|
||||
|
||||
Главный тезис:
|
||||
|
||||
```text
|
||||
Нужно определить границы целевой системы и решить, какие слои являются частью ВКУС, а какие — внешними сервисами.
|
||||
```
|
||||
|
||||
### 7.3. Для обсуждения с UX / CX
|
||||
|
||||
Показывать:
|
||||
|
||||
1. Customer Journey Flow.
|
||||
2. Blueprint.
|
||||
3. Метрики на каждом шаге.
|
||||
|
||||
Главный тезис:
|
||||
|
||||
```text
|
||||
Видимый интерфейс должен снижать усилия пользователя, а не переносить анкетирование в новую форму.
|
||||
```
|
||||
|
||||
### 7.4. Для обсуждения с командой данных
|
||||
|
||||
Показывать:
|
||||
|
||||
1. CAP-08 и CAP-10.
|
||||
2. Analytics / Data Mart / BI в C4 Context.
|
||||
3. MVP 0 / Data Discovery.
|
||||
|
||||
Главный тезис:
|
||||
|
||||
```text
|
||||
Без анализа текстов обращений, ответов поддержки и логов действий невозможно доказательно выбрать пилот и управлять улучшением пути.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. Вопросы для следующей итерации
|
||||
|
||||
Перед переходом к C4 Container Diagram нужно согласовать несколько решений.
|
||||
|
||||
| № | Вопрос | Возможные варианты | Почему важно |
|
||||
|---:|---|---|---|
|
||||
| 1 | Где граница целевой системы? | Только ВКУС frontstage / ВКУС + backend capabilities / отдельная платформа сервисного входа | Определяет C4 Context и Container |
|
||||
| 2 | Search/RAG/LLM layer — часть решения или внешний сервис? | Внутренний компонент / корпоративная AI-платформа / внешний сервис | Влияет на ответственность, безопасность и интеграции |
|
||||
| 3 | Каталог услуг — внешний источник или часть capability layer? | ITSM-каталог / отдельный каталог ВКУС / общий service catalog | Влияет на mapping intent → service |
|
||||
| 4 | Где живет prefill service? | ВКУС / интеграционный слой / отдельный сервис | Влияет на интеграции с IAM, HR, CMDB |
|
||||
| 5 | Кто владеет статусной моделью? | ITSM / ВКУС / совместная модель | Влияет на CAP-06 и CAP-07 |
|
||||
| 6 | Analytics/Data Mart — часть решения или корпоративный слой? | Локальный data mart / корпоративная платформа / BI над выгрузками | Влияет на MVP 0 и CAP-08 |
|
||||
| 7 | Как фиксируем feedback loop? | Backlog улучшений / ITSM-задачи / отдельный governance-процесс | Влияет на CAP-10 |
|
||||
|
||||
---
|
||||
|
||||
## 9. Что не стоит делать на этом этапе
|
||||
|
||||
### Не стоит сразу делать C4 Container
|
||||
|
||||
Container-уровень полезен только после согласования:
|
||||
|
||||
- границ целевой системы;
|
||||
- состава capabilities;
|
||||
- роли ВКУС;
|
||||
- роли Search/RAG/LLM;
|
||||
- роли ITSM;
|
||||
- роли Data Mart / BI.
|
||||
|
||||
### Не стоит превращать flow в техническую sequence diagram
|
||||
|
||||
Пока важно сохранить читаемость для команды. Детальные последовательности вызовов API появятся позже.
|
||||
|
||||
### Не стоит перегружать C4 Context capabilities
|
||||
|
||||
На C4 Context достаточно указывать CAP-теги возле ключевых систем. Подробная связь должна жить в traceability matrix.
|
||||
|
||||
---
|
||||
|
||||
## 10. Рекомендуемый следующий шаг
|
||||
|
||||
Следующая итерация должна дать два результата:
|
||||
|
||||
1. **Согласованную границу целевой системы.**
|
||||
Что входит в «Витрину сервисного входа ВКУС», а что считается внешними системами.
|
||||
|
||||
2. **Первую C4 Container Diagram.**
|
||||
Уже не только контекст, а внутренние контейнеры целевой системы:
|
||||
- Frontend / ВКУС UI;
|
||||
- Scenario & Intent Service;
|
||||
- Knowledge/Search Service;
|
||||
- Form & Prefill Service;
|
||||
- Integration/API Gateway;
|
||||
- Status/Event Service;
|
||||
- Analytics/Event Tracking;
|
||||
- Feedback/Improvement Backlog.
|
||||
|
||||
---
|
||||
|
||||
## 11. Итоговая формулировка
|
||||
|
||||
Комплект диаграмм должен помогать команде видеть не только архитектуру, но и смысл архитектуры.
|
||||
|
||||
```text
|
||||
Каждый шаг клиентского пути должен быть связан с capability.
|
||||
Каждая capability должна быть связана с архитектурным компонентом.
|
||||
Каждый компонент должен иметь метрику эффекта.
|
||||
```
|
||||
|
||||
Это позволяет перейти от обсуждения интерфейса к управляемому проектированию витрины сервисного входа.
|
||||
Reference in New Issue
Block a user