Как применял нотации?
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Применение нотаций в аналитической работе
Нотации — это язык визуальной коммуникации. За 10+ лет я использовал разные нотации для разных целей, в зависимости от аудитории и сложности задачи. Вот мой практический опыт:
1. UML Use Case Diagram
Когда использую: на ранних стадиях анализа, когда нужно показать взаимодействие разных actors (пользователи, системы, внешние сервисы) с нашей системой.
Пример: e-commerce платформа
Actors:
- Customer (клиент)
- Admin (администратор)
- Payment System (Yandex.Kassa)
- Email Service (SendGrid)
Use Cases:
- Customer: Browse Products, Add to Cart, Checkout, Track Order
- Admin: Manage Inventory, Manage Users, Generate Reports
- Payment System: Process Payment, Confirm Payment
Relationships:
- Customer --(Browse Products)--> System
- Customer --(Checkout)--> System
- System --(includes)--> Payment Processing
Преимущества:
- Легко видеть весь scope системы
- Все stakeholders поймут основные actors
Минусы:
- Не показывает внутреннюю логику
- На больших системах становится кашей
2. User Story Mapping (Story Board)
Когда использую: когда нужно понять journey пользователя и как user stories связаны между собой.
Структура:
User Goal: User wants to complete a purchase
Tasks:
1. Browse & Search
- Search by category
- Filter by price
- Read reviews
2. Add to Cart
- Select quantity
- Choose size/color
- Save for later
3. Checkout
- Enter shipping address
- Select delivery method
- Enter payment details
- Review order summary
4. Payment
- Process payment
- Get confirmation
5. Post-purchase
- Send order confirmation email
- Allow order tracking
- Support returns
Потом каждый task раскладываю на User Stories и Acceptance Criteria.
Преимущества:
- Видна последовательность
- Понимаю, что первой версии, что потом
3. BPMN (Business Process Model and Notation)
Когда использую: когда процесс сложный, есть много ветвлений, параллельные процессы, wait states.
Пример: процесс обработки заказа
Ноталась BPMN с элементами:
- Start/End — начало и конец
- Task — человеческое действие
- Service Task — автоматизированное действие
- Gateway — логическое ветвление (если/иначе)
- Event — происходит что-то (payment confirmed, email sent)
Start
↓
Customer places order
↓
Validate inventory
↓
(Diamond) Is stock available?
├─ No → Send "Out of stock" email → End
└─ Yes → Reserve inventory
↓
Process payment
↓
(Diamond) Payment successful?
├─ No → Release inventory → Send error email → End
└─ Yes → Send confirmation email
↓
Ship order
↓
End
Преимущества:
- Ясно видны все исключительные случаи
- Разработчики понимают, что нужно закодировать
- Можно проверить логику со stakeholders
Минусы:
- Сложно для простых процессов
- Требует обучения для чтения
4. Entity-Relationship Diagram (ERD)
Когда использую: когда нужно показать, как связаны данные в системе. Важно для всех, кто работает с БД.
Пример: e-shop
Customers
├─ id (PK)
├─ name
├─ email
└─ created_at
|
1:N
|
Orders
├─ id (PK)
├─ customer_id (FK)
├─ total_amount
├─ status
└─ created_at
|
1:N
|
Order Items
├─ id (PK)
├─ order_id (FK)
├─ product_id (FK)
├─ quantity
└─ price
|
Products
├─ id (PK)
├─ name
├─ price
└─ inventory
Преимущества:
- БД архитектор видит, нужны ли нормализация
- Разработчики знают, какие joins писать
5. Sequence Diagram (для интеграций)
Когда использую: когда много систем взаимодействуют в определённом порядке, важна последовательность и timing.
Пример: оплата через Yandex.Kassa
Customer Our App Yandex.Kassa Bank
| | | |
|--Checkout---->| | |
| |--Create Payment->| |
| |<--Payment ID-----| |
|<--Redirect to YK--| | |
|--Enter card----->| | |
| |--Verify card----| |
| |<--OK from Bank--| |
|<--Confirm--------| | |
| |--Check Status->| |
| |<--Confirmed----| |
Это помогает найти race conditions и timing issues.
6. Data Flow Diagram (DFD)
Когда использую: когда нужно показать, как данные движутся через систему.
Уровни:
- Level 0 (Context) — вся система как один ящик
- Level 1 — основные процессы
- Level 2 — детальные процессы
Пример:
(Context DFD)
Customer → [E-commerce System] → Inventory DB
↓ ↓
Orders DB Payment Gateway
Level 1 Details:
- Customer sends order → Process Order → Update Inventory
- Process Order → Process Payment → Payment Gateway
- Update Inventory → Save to DB
7. Mind Maps (для брейнштормов)
Когда использую: когда нужно собрать все идеи, требования, вопросы перед формализацией.
Пример центральной идеи: "New Customer Onboarding"
├─ Signup
│ ├─ Email verification
│ ├─ Phone verification (optional)
│ └─ Terms & Conditions
├─ Profile Setup
│ ├─ Personal info
│ ├─ Address
│ └─ Payment method
├─ First Purchase
│ ├─ Product recommendations
│ ├─ Discount code
│ └─ Free shipping
└─ Support
├─ Help center
├─ Live chat
└─ FAQ
8. Impact Mapping (для приоритизации)
Когда использую: когда нужно понять, что реально даст impact на бизнес метрику.
Структура:
Goal: Increase conversion rate from 2% to 3%
├─ Who: Customers
│ ├─ Behavior: Faster checkout
│ │ ├─ Capability: Remove extra steps
│ │ ├─ Capability: Save payment method
│ │ └─ Capability: Express checkout
│ ├─ Behavior: Trust the system
│ │ ├─ Capability: Show security badges
│ │ ├─ Capability: Customer reviews
│ │ └─ Capability: Money-back guarantee
Это помогает не делать фичи "для красоты", а фокусироваться на том, что реально поднимает метрики.
9. Wireframes & Mockups
Когда использую: всегда, когда проектирую UI.
Уровни деталей:
- Low-fidelity — черновик с блоками (быстро согласовать layout)
- Mid-fidelity — с текстом, иконками (показать информационную иерархию)
- High-fidelity — полный дизайн (готово к разработке)
Практическое применение: как я выбираю нотацию?
Вопросы, которые я себе задаю:
- Кто будет это читать? (Бизнес, разработчики, PM?)
- Какой уровень абстракции нужен? (overview или детали?)
- Что главное показать? (actors, процесс, данные, UI?)
- Сколько времени на создание? (быстрый sketch или formal diagram?)
- Нужна ли интерактивность? (статическая диаграмма или prototype?)
Примеры выбора:
- Потребитель просит новую фичу → User Story Map (быстро согласовать scope)
- Нужно спроектировать интеграцию с платёжной системой → Sequence Diagram + BPMN
- Нужно понять, как пользователь будет взаимодействовать → Wireframes → Prototypes
- Нужно найти все edge cases в процессе → BPMN с gatewaysами
- Нужно показать сложность системы CTO → ERD + DFD
Мой походу
Не люблю:
- Создавать диаграммы "для галочки"
- Использовать сложные нотации без необходимости
- Забывать обновлять диаграммы (они устаревают быстро)
Люблю:
- Живые, обновляемые документы в Notion/Figma
- Коллаборативное уточнение требований (заказчик смотрит, как я рисую)
- Простые диаграммы, которые легко объяснить словами
Нотации — это средство, не цель. Главное — чтобы люди поняли требования и согласились с ними.