Профессия:
Глубинное интервью — Метод качественного исследования
Глубинное интервью (in-depth interview) — это качественный метод исследования, при котором интервьюер проводит длительный, неструктурированный или полуструктурированный разговор с одним респондентом для изучения его мотивов, поведения, ценностей и отношения к продукту или услуге.
Характеристики глубинного интервью
Особенности:
Отличие от фокус-групп
Фокус-группа проводится с 5-12 участниками одновременно, что создаёт синергию и групповую динамику. Глубинное интервью — это один-на-один беседа, позволяющая углубиться в личный опыт и избежать влияния группового мнения.
Как проводить глубинное интервью
Что должно быть перед каждым Sprint
Это один из ключевых вопросов в agile процессе. Хороший sprint начинается до того, как он начинается. Вот что я делаю:
1. Проработанный Backlog
User Stories с высокой четкостью — каждая story, которая попадет в sprint, должна быть четко описана:
Я НЕ даю в sprint story, которая звучит как "Fix the thing". Stories должны быть конкретны.
Acceptance Criteria — это must have. Разработчик должен точно знать, когда story готова. Примеры хороших AC:
Given пользователь на странице профиля
When он нажимает кнопку "Изменить пароль"
Then открывается форма изменения пароля с полями "Старый пароль" и "Новый пароль"
And кнопка "Сохранить" неактивна до заполнения обоих полей
And система показывает ошибку если пароли не совпадают в требуемых критериях
Когда использовать BPMN диаграмму
BPMN (Business Process Model and Notation) — это стандартная нотация для моделирования бизнес-процессов. Это мощный инструмент, но он не всегда уместен. Важно понимать, когда BPMN действительно добавляет ценность, а когда проще использовать другие подходы.
Когда BPMN идеально подходит
1. Сложные многошаговые процессы
Когда процесс имеет много шагов, условных переходов и параллельных потоков, BPMN отлично показывает эту сложность:
Пример: Процесс ипотечного кредитования
2. Процессы с ролевыми ответственностями
Протоколы для внутренней интеграции
Внутренняя интеграция (internal integration) — это обмен данными и коммуникация между компонентами, сервисами и системами внутри организации. Рассмотрю основные протоколы и подходы, используемые в различных архитектурах.
1. REST (Representational State Transfer)
Описание: Основано на HTTP протоколе, использует стандартные методы (GET, POST, PUT, DELETE) и JSON для передачи данных.
Когда используется:
Плюсы:
Минусы:
Пример:
GET /api/v1/users/123
POST /api/v1/orders
Content-Type: application/json
{"user_id": 123, "items": [...]}
Что такое нормализация базы данных?
Нормализация БД для Business Analyst
Нормализация — это процесс организации данных в БД так, чтобы минимизировать дублирование и обеспечить консистентность. Хотя это технический вопрос, понимание нормализации помогает мне писать лучшие требования.
Зачем нужна нормализация
Проблема без нормализации:
Табл Users_Orders (BAD):
┌────┬────────┬──────────────────┬──────────┬─────────────────┐
│id │name │email │order_id │products │
├────┼────────┼──────────────────┼──────────┼─────────────────┤
│1 │John │john@example.com │101 │Phone, Laptop │
│1 │John │john@example.com │102 │Monitor, Mouse │
│2 │Jane │jane@example.com │103 │Keyboard │
└────┴────────┴──────────────────┴──────────┴─────────────────┘
Какие знаешь подтипы Agile?
Разновидности Agile методологии
Agile — это не одна методология, а семейство методологий. Все они следуют Agile Manifesto, но имеют разные практики и фокусы. Я работал с разными и расскажу про каждую.
1. Scrum — САМЫЙ ПОПУЛЯРНЫЙ (70% использования)
Что это: Структурированная методология с ролями, событиями и артефактами.
Ключевые элементы:
Роли:
- Product Owner (что делать)
- Scrum Master (как работать)
- Development Team (пишет код)
События:
- Sprint Planning (планирование 2-недельного спринта)
- Daily Standup (ежедневные 15-минутные синхро)
- Sprint Review (демо для stakeholders)
- Sprint Retrospective (команда анализирует улучшения)
Артефакты:
- Product Backlog (все требования)
- Sprint Backlog (требования на спринт)
- Increment (готовый продукт в конце спринта)
Мой опыт с Scrum:
Это мой основной инструмент в 70% проектов. Преимущества:
Чем я занимаюсь на текущем проекте
На моём текущем проекте я работаю в роли Senior Business Analyst в команде digital-трансформации компании в секторе электронной коммерции. Проект направлен на миграцию legacy-системы на современный микросервисный стек.
Основные задачи и ответственность
1. Анализ и оптимизация бизнес-процессов
Current State Analysis:
To-Be Process Design:
Какие занимал роли на прошлых проектах?
Эволюция ролей в карьере
Я не просто Business Analyst — я прошел через несколько ролей и в разных сферах. Это было очень полезно для моего развития. Расскажу о пути, который я прошел.
Роли, которые я занимал
2010-2012: Junior Business Analyst
Проект: Система управления продажами для розничной сети Компания: IT консультационная фирма
Что я делал:
Чему я научился:
Трудности:
2012-2014: Senior BA (Waterfall projects)
Виды документации на IT-проекте
Документация на проекте — это его нервная система. Плохая документация приводит к потере знаний, дублированию работы и конфликтам между командой. Business Analyst должен знать, какие виды документации существуют и когда какая нужна.
1. Требования и Аналитика
Business Requirements Document (BRD)
Описывает что нужно построить и зачем (бизнес-целей).
Пример:
Кто пишет: Product Manager, Business Analyst Для кого: Стратегические решения, инвестиции, финансирование
Functional Requirements Specification (FRS)
Описывает как система будет работать с функциональной точки зрения.
MVP и как определить его границы
MVP (Minimum Viable Product) — это минимально жизнеспособный продукт, который содержит только самые критичные функции для решения основной проблемы пользователя. Это не неполный продукт, а полнофункциональный продукт, но без лишних фич.
Определение MVP
MVP должен:
MVP НЕ должен:
Примеры MVP
Airbnb (начало):
Создатель просто размещал фото своей квартиры на доске объявлений
МВП: Сайт с фото, описанием и способом связи
НЕ в МВП: Система бронирования, платежи, отзывы
Это позволило валидировать идею за неделю
Самые интересные проекты за карьеру
За 10+ лет я работал с разными масштабами проектов. Расскажу о трёх наиболее интересных, которые оставили глубокий след в моем развитии как аналитика.
1. Реимплементация платёжной системы (FinTech, 2019-2021)
Контекст:
Компания с экосистемой платёжных услуг (переводы, микрокредиты, платежи по счётам) обслуживала 2.5 млн пользователей. Система становилась узким местом: запросы обрабатывались 3-4 секунды, была 15% потеря данных из-за race conditions.
Моя роль:
Требования в контексте разработки проекта
Требования — это описание того, что должно быть реализовано в системе, продукте или услуге. Это технический перевод потребностей пользователей и целей бизнеса в чёткие, измеримые, реализуемые пункты, которые разработчики могут воплотить в жизнь.
Что такое требования простыми словами
Представьте, что вы заказываете разработку сайта для кофейни. Требование — это не просто сделайте сайт, а конкретные описания:
Без чётких требований разработчик может понять задачу неправильно, потратить время впустую, и результат не совпадёт с ожиданиями. С чёткими требованиями все понимают, что нужно делать.
Типы требований
Product Backlog: Определение, структура и составление
Product Backlog (Бэклог продукта) — это приоритизированный список всего, что нужно сделать для продукта. Это живой документ, который постоянно обновляется по мере развития понимания рынка, технологии и требований клиентов.
Определение
Product Backlog — это упорядоченный по приоритету список:
Каждый item содержит:
Структура типичного Product Backlog item'а
ID: PBI-42
Title: Как клиент, я хочу сохранять избранные товары в список wishlist
Критерии приемки: Определение и значение
Критерии приемки (Acceptance Criteria, AC) — это четкие, измеримые условия, которые должны быть выполнены для того, чтобы требование или задача считались завершёнными. Это контрольный список, который определяет, когда разработка закончена и продукт готов к использованию.
Почему критерии приемки критически важны
Предотвращение разногласий:
Основа для тестирования:
Объективная оценка завершения:
Характеристики хороших критериев приемки
Проекты, в которых я участвовал
В течение своей карьеры я работал над разнообразными проектами, охватывающими различные отрасли и масштабы. Расскажу о самых значимых из них.
1. Финтех платформа для B2B операций
Компания: Средний финтех-стартап (50+人) Период: 2 года (основной проект) Роль: Senior BA, отвечал за требования и аналитику
Контекст: Платформа позволяла корпоративным клиентам управлять расчётами и платежами между контрагентами. Типичный сценарий: сеть магазинов розницы, которая должна рассчитаться с поставщиком.
Основные достижения:
Scope Creep и как его избежать
Scope Creep (расширение границ проекта) — это явление, когда требования к проекту постоянно растут и расширяются во время разработки, часто без согласования сроков, бюджета и ресурсов. Это одна из главных причин задержек проектов и превышения бюджета.
Почему это происходит
1. Нечёткое определение требований
2. Слабое управление изменениями
3. Психологические факторы
4. Отсутствие контроля
Примеры scope creep
Являются ли конкуренты стейкхолдерами?
Ответ на этот вопрос неоднозначен и зависит от определения термина "стейкхолдер" и контекста анализа. Давайте разберёмся подробнее.
Определение стейкхолдера
Стейкхолдер (Stakeholder) — это лицо или организация, которая имеет интерес, влияние или на которую влияет проект, продукт или инициатива. Ключевые характеристики:
Анализ: конкуренты как стейкхолдеры
Аргументы "ДА" — конкуренты могут быть косвенными стейкхолдерами:
UAT (User Acceptance Testing) — что это и почему это критично
UAT — это User Acceptance Testing, последний этап тестирования перед запуском продукта в production. На этом этапе реальные пользователи или представители бизнеса проверяют, соответствует ли система их требованиям и ожиданиям.
Ключевые характеристики UAT
Кто участвует:
На что проверяют:
Отличие UAT от других уровней тестирования
SWOT анализ
SWOT анализ — это стратегический инструмент, используемый для оценки текущего состояния бизнеса, проекта или организации путём анализа четырёх ключевых факторов.
Четыре компоненты SWOT
Strengths (Сильные стороны)
Weaknesses (Слабые стороны)
Opportunities (Возможности)
Threats (Угрозы)
Что такое NFR (Non-Functional Requirements)?
NFR — это нефункциональные требования, которые описывают не то, что должна делать система, а как она должна это делать. В отличие от функциональных требований, которые определяют конкретные функции (например, «авторизация пользователя»), NFR фокусируются на качественных характеристиках и ограничениях системы.
Основные категории NFR
Производительность (Performance)
Надежность и доступность (Reliability & Availability)
Should Do: Разрыв между текущим и желаемым состоянием
Should Do ("Что нужно делать") — это одна из ключевых концепций в бизнес-анализе. Она описывает разрыв между тем, как процесс работает сейчас (As Is), и тем, как он должен работать (To Be). Это фундамент для определения требований к системе.
Определение Should Do
Should Do — это набор правил, процедур и механизмов, которые необходимо внедрить для достижения целей организации и устранения текущих проблем.
Это НЕ "в идеальном мире", а вполне реалистичное, достижимое состояние с учетом:
Как выглядит процесс анализа As Is → Should Do
Шаг 1: Документирование текущего состояния (As Is)
Что нужно понять:
Работа с неопределенными критериями приемки
Невозможность четко определить критерии приемки — это один из самых сложных и распространенных вызовов в бизнес-аналитике. Такая ситуация часто возникает с инновационными проектами, размытыми требованиями или амбициозными stakeholders. Однако это решаемая проблема.
Почему это происходит
Несформированные требования:
Субъективность критериев:
Динамичность бизнеса:
Мой подход к решению этой проблемы
Шаг 1: Вовлечение stakeholders в процесс дефинирования
Мой опыт участия в процессе UAT
UAT — это мой责任 как BA. Я не просто должен быть присутствующим, я должен actively facilitate и ensure что все требования validated. Расскажу как я это делал.
Структура UAT которую я устанавливал
Шаг 1: Подготовка (за 2 недели)
Я:
Пример тест сценария:
Scenario: Freelancer finds and applies для project
Preconditions:
- Freelancer logged in
- 5 projects visible
Steps:
1. Open projects page
2. Filter by "web development"
3. Expected: only web projects shown
4. Click на first project
5. Expected: project details open
6. Click "Apply" button
7. Enter cover letter
8. Click "Submit"
9. Expected: success message
Достижения, которыми я горжусь
Я отмеряю успех не только в завершённых проектах, но и в impact'е, который я создавал. Вот несколько достижений, которыми я действительно горжусь.
Достижение 1: Спасил проект с $2M бюджета от срыва
Контекст: Проект уже был на пути к провалу: 6 месяцев развития, ничего не работает, бюджет половина истрачена, team демотивирована, stakeholders давят.
Проблема, которую я выявил: Приехал и понял: requirements были собраны 6 месяцев назад и уже устарели. Business требовал одно, техи разрабатывали другое. Никакого alignment.
Что я сделал:
Что такое база данных?
Определение для Business Analyst
Хотя это базовый вопрос, я объясню его так, как я объясняю коллегам и stakeholders. База данных — это организованное хранилище информации, которое позволяет быстро искать, добавлять, изменять и удалять данные.
Простое объяснение
Аналогия: Если Excel файл — это один список, то база данных — это несколько связанных списков с быстрым поиском и правилами.
Excel:
Один лист с 10,000 строк товаров
Поиск: Ctrl+F (медленно)
Лимит: ~1 млн строк
Опасность: легко перепутать данные
База данных:
Несколько таблиц (товары, категории, цены)
Поиск: индексы (быстро, даже на 1 млн строк)
Лимит: миллиарды строк
Безопасность: ограничения и проверки
Как я работаю с базами данных как BA
1. Понимание структуры (Data Model)
Я не пишу SQL, но я должен понимать:
Как часто использую User Story
Отвечу прямолинейно: ВСЕГДА. User Story — это основной инструмент моей работы как BA. Буквально каждый день я пишу, уточняю или переписываю user stories.
Зачем использовать User Story?
User Story — это не просто документирование. Это:
Стандартный формат User Story
As a [type of user]
I want [action]
So that [value/benefit]
Реальные примеры из моей практики
As a customer
I want to save my payment method
So that I don't have to enter it every time
Как часто используешь Use Case?
Место Use Case в современной разработке
Это хороший вопрос, потому что он показывает эволюцию методик в BI. Я использую Use Cases, но не так часто, как 10-15 лет назад. Объясню почему и в каких ситуациях они все еще критичны.
Историческая перспектива
В 2000х: Use Cases были главным инструментом
Сейчас (2025): Use Cases используются выборочно
Когда я использую Use Cases
1. Сложные бизнес-процессы (80% моих Use Cases)
Пример: "Система управления заказами в e-commerce"
Use Case: "Оформить заказ"
Актеры:
- Customer (основной)
- Payment System (вспомогательный)
- Inventory System (вспомогательный)
Предусловия:
- Customer залогинен
- Товары в корзине
Как я решаю сложные задачи
С 10+ летним опытом я столкнулся с множеством нетривиальных проблем. Сложность в аналитике может быть технической, организационной или концептуальной. Расскажу о своем методе.
1. Определи точную природу проблемы
Первый шаг — не бежать в решение, а понять что именно непонятно.
Делаю следующее:
Пример из практики:
Проблема казалась технической: "API медленный"
Но когда я углубился, оказалось:
Проблема была организационная — документирование и мониторинг.
2. Соберу информацию
Второй шаг — data-driven approach. Даже если это кажется очевидным, нужны данные.
Источники требований для Business Analyst
Один из главных вопросов в работе BA — "от кого получать требования?" Неправильный выбор источников приводит к пустой трате времени, конфликтам и неверным приоритетам. За 10+ лет я выделил четких категории стейкхолдеров и их роли в формировании требований.
Ключевые источники требований
1. Product Manager (PM) — PRIMARY SOURCE
ПМ — это главный источник требований. Его работа — понимать рынок и пользователей, синтезировать это в требования.
Где получать требования:
Как работать:
PM: "Нам нужна функция X"
Ты: "Понял. Какой бизнес результат добавит функция X?"
PM: "Увеличит retention на 5%"
Ты: "Сколько людей это коснётся? Как ты мерить успех?"
PM: "Тестируем на 10% пользователей, метрика — сколько вернулись через неделю"
Как аргументировать идеи руководителю: стратегия убеждения
Умение отстоять свою идею перед руководством — это критический навык для Business Analyst. Это не о том, чтобы спорить, а о том, чтобы презентовать информацию так, чтобы принятие решения было очевидным. За 10+ лет я выработал действенный подход.
Фундамент: Никогда не приходи с идеей — приди с проблемой
Ошибка
"Я думаю, нам нужна новая система рекомендаций."
Руководитель подумает: "Откуда это взялось? Это очень затратно. Почему именно сейчас?"
Правильно
"Текущая система рекомендаций дает 2% конверсии. При нашем трафике 100K/мес это 2K пользователей, которые не покупают из-за плохих рекомендаций. Если улучшить до индустриального стандарта 5%, это +3K покупок/мес = +150K в месяц."
Теперь говоришь на языке руководителя: проблема (потеря денег) и возможность (прибыль).
Структура аргументации: ВАШЕ УРАВНЕНИЕ
В (Видимость проблемы)
Открой глаза руководителю на проблему данными.
Виды требований: полная классификация
Business Analyst работает с разными видами требований. Понимание их различий критично для правильного анализа.
Основная классификация
Функциональные требования (FR) — описывают, ЧТО система должна делать Нефункциональные требования (NFR) — описывают, КАК система должна это делать
1. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Определение: Описание функций, действий, которые система должна выполнять.
Примеры:
Характеристики:
Виды функциональных требований:
a) Основная функциональность
b) Интеграции
Роль бизнес-аналитика в тестировании
Да, бизнес-аналитик должен активно участвовать в тестировании. Это критически важная часть его деятельности, так как он является связующим звеном между требованиями и реализацией.
Почему BA должен участвовать в тестировании
1. Верификация требований
2. Бизнес-перспектива
3. Качество продукта
Что мне нравится в работе Business Analyst
Работая в роли бизнес-аналитика, я обнаружил множество аспектов, которые делают эту профессию особенно привлекательной и мотивирующей.
1. Мост между бизнесом и технологиями
Мне нравится быть переводчиком между непрограммистами и разработчиками. Это позволяет:
Так я вношу вклад в успех проекта с самого начала, а не просто передаю информацию.
2. Решение сложных проблем
Текущий проект: Платформа подготовки к собеседованиям
Я работаю над проектом PrepBro — это платформа, помогающая кандидатам подготовиться к собеседованиям через интерактивные вопросы и ответы.
Общее описание
Проект представляет собой веб-приложение, которое предоставляет:
Ключевые компоненты системы
Backend:
Когда использовать Use Case: практическое применение
Определение Use Case
Use Case — это детальное описание взаимодействия актёра (пользователя, системы или другого участника) с системой для достижения конкретной цели. Это методология, активно применяемая в Business Analysis для документирования требований.
Основные ситуации для применения Use Case
Use Case идеален для описания многошаговых процессов с разветвлениями. Например:
Когда в процессе участвуют разные пользователи с разными правами и целями:
Как я предлагаю идеи в своей работе
Предложение идей и инноваций — это интегральная часть моей работы как аналитика. Но это не просто спонтанное «я знаю, как сделать лучше». Это структурированный процесс.
Частота и контекст
Регулярность
Я предлагаю идеи постоянно, но в правильное время:
Примерно 2-3 идеи в неделю, которые стоят доводить до обсуждения. Остальное — заметки в Confluence.
Структура предложения идеи
Шаг 1: Проблема (Problem Statement)
Не говорю "давайте добавим X". Сначала описываю проблему:
Плохо:
Опыт работы с требованиями
Обладая более чем 10 годами опыта в бизнес-анализе, я разработал системный подход к сбору, документированию и управлению требованиями, который позволяет минимизировать риски и обеспечивать успешную реализацию проектов.
Методология и подходы
В своей практике я использую комплексный процесс работы с требованиями:
Выявление и сбор требований — применяю различные методики в зависимости от контекста: структурированные интервью со stakeholder'ами, фокус-группы, анализ существующих процессов и конкурентов, мастер-сессии. Критически важно слушать не только то, что говорят, но и понимать underlying потребности и боли бизнеса.
Классификация и структурирование — разделяю требования на функциональные и нефункциональные, бизнес-требования, пользовательские сценарии и технические ограничения. Использую иерархическое структурирование и трейсируемость требований для обеспечения полноты.
Отличия REST от SOAP
Это два принципиально разных подхода к проектированию веб-сервисов, каждый со своими преимуществами и областями применения.
Архитектурный подход
REST (Representational State Transfer) — это архитектурный стиль, основанный на принципах HTTP и стандартных методах (GET, POST, PUT, DELETE). REST работает с ресурсами, каждый из которых имеет свой URL. Это простой, масштабируемый подход.
SOAP (Simple Object Access Protocol) — это протокол на основе XML, который определяет строгую структуру сообщений. SOAP используется для вызова удалённых процедур через HTTP, но может работать и с другими протоколами.
Ключевые различия
1. Формат данных
Техники выявления требований — инструменты Business Analyst
Выявление требований — это один из ключевых навыков Business Analyst. Существует множество техник, каждая из которых полезна в разных ситуациях. Выбор правильной техники зависит от контекста, бюджета, временных рамок и типа проекта.
1. Интервью (Interviews)
Когда применяю:
Преимущества:
Недостатки:
Тип: One-on-one или focus group
2. Опросы (Surveys / Questionnaires)
Когда применяю:
Преимущества:
Управление сложными стейкхолдерами: Стратегия и методы
Работу со сложными стейкхолдерами, постоянно меняющими требования, нужно строить на основе структурированного подхода, взаимного уважения и четких границ. Вот как я бы это делал:
1. Понимание корневых причин изменений
Диагностика
Анализ паттернов
2. Установление четких процессов и границ
Мощность теста — способность выявлять дефекты
Мощность теста (Test Coverage / Test Strength) — это характеристика, которая показывает, насколько хорошо тест способен обнаружить дефекты и ошибки в системе. Это мера эффективности, полноты и качества тестирования.
Что измеряет мощность теста
Мощность отвечает на вопрос:
Типы мощности тестов
1. Code Coverage (Покрытие кода)
2. Statement Coverage — выполнено ли каждое утверждение 3. Branch Coverage — проверены ли все ветки if/else 4. Path Coverage — пройдены ли все возможные пути выполнения
Бизнес-анализ: Определение и Суть
Бизнес-анализ — это систематический процесс изучения бизнеса, выявления потребностей организации и разработки решений для улучшения её деятельности и достижения поставленных целей. Это мост между технологией и бизнесом, который трансформирует требования stakeholders в конкретные действия.
Основные компоненты бизнес-анализа
Исследование и понимание
Выявление требований
Проектирование решений
Что хочу изменить с переходом на новый проект
Переход на новый проект — это не просто смена задач, а возможность применить уроки из прошлого и улучшить свой подход. Вот конкретные области, над которыми хочу работать.
1. Раньше включать Data & Analytics в планирование
Что было раньше:
Что хочу изменить:
Мой опыт на последнем месте работы
На последнем месте работы я был Senior Business Analyst в финтех-компании, занимающейся инвестиционными технологиями. Это был увлекательный и требовательный опыт, где я носил несколько шляп.
Основные обязанности
Сбор и анализ требований — это была основная часть моей работы. Я проводил интервью с клиентами, stakeholder'ами и командой продакта для понимания бизнес-проблем и необходимых решений. Затем трансформировал качественную информацию в формальные требования и спецификации.
Моделирование бизнес-процессов — создавал BPMN диаграммы для существующих процессов и предложенных улучшений. Это помогало выявить неэффективность и точки автоматизации. Например, я описал полный цикл обработки и верификации документов инвестора, что привело к снижению времени обработки на 40%.
REST API интеграция: мой опыт проектирования
REST API интеграции с внешними системами — это одна из самых common задач BA. Это critical потому что API это interface между вашей системой и чужими. Расскажу мой опыт.
Первая интеграция (наивный подход)
В fintech проекте нужна была интеграция с платежной системой (Stripe). Я просто взял их документацию и написал требования как она описана.
Результат: Разработчик кодил, интеграция работала... иногда. Иногда платежи зависали, иногда возвращались неправильные статусы.
Проблемы:
Урок: Просто copy-paste API documentation это плохо.
Правильный подход (marketplace интеграция)
Позже я спроектировал интеграцию с правильным способом.
Unit экономика: что это и почему это важно для BA
Unit экономика — это анализ прибыльности одной единицы продукта или услуги. Это fundamental для понимания как бизнес масштабируется. Расскажу с примерами.
Основная идея
Marginal profit на одного customer или одну order:
Unit economics = Revenue per unit - Cost per unit
Если это positive — каждый customer приносит прибыль. Если negative — losing money на каждом customer.
Пример 1: Marketplace (freelancer platform)
Scenario: Freelancer находит job, выполняет его, платит commission.
Unit economics per order:
Order value (средний): 500 долларов
Commission (10%): 50 долларов (revenue для platform)
Costs per order:
- Payment processing fee (2.5%): 12.50 долларов
- Fraud detection: 1 доллар
- Customer support (средний): 3 доллара
- Total costs: 16.50 долларов
Unit profit = 50 - 16.50 = 33.50 долларов per order
Profit margin = 33.50 / 50 = 67%
NoSQL базы данных: плюсы и минусы
NoSQL (Not Only SQL) — это нереляционные базы данных, которые предлагают альтернативу традиционным SQL базам. Они подходят для специфичных сценариев использования.
Плюсы NoSQL
Масштабируемость
Гибкость схемы данных
Производительность
Адаптивность к данным
UML нотации
UML (Unified Modeling Language) — универсальный язык моделирования, который я активно использую при описании требований и архитектурных решений. Расскажу о самых важных нотациях, которые применяются в работе Business Analyst.
Диаграмма вариантов использования (Use Case Diagram)
Это первая диаграмма, которую я рисую при анализе новой функциональности. Она показывает взаимодействие пользователей (актёров) с системой. На диаграмме обозначаются:
Это особенно полезно при сборе требований, так как помогает договориться со стейкхолдерами о границах системы.
Диаграммы классов (Class Diagram)
Диаграмма классов показывает структуру данных и связи между сущностями. Я использую её для:
Когда лучше использовать User Story?
Практический подход к выбору инструмента
User Stories — это не универсальное решение. Я использую их в Agile проектах, но есть ситуации, когда лучше использовать другие форматы требований. Расскажу, как я выбираю.
Краткое сравнение форматов
| Формат | Когда | Для кого | Объем |
|---|---|---|---|
| User Story | Agile, MVP,快速 delivery | Разработчики, QA | 1-2 страницы |
| Use Case | Waterfall, сложные процессы | Аналитики, архитекторы | 2-5 страниц |
| SRS Document | Enterprise, регуляторные требования | Все stakeholders | 50-300 страниц |
| Requirements List | Simple projects, быстрые изменения | Разработчики | 1 лист |
| BDD (Given-When-Then) | TDD процессы, автоматизированные тесты | Разработчики, QA, BAs | 1 страница |
Когда я использую User Story
✅ ПРАВИЛЬНО ИСПОЛЬЗОВАТЬ User Story в этих случаях:
1. Agile / Scrum проекты (ГЛАВНЫЙ СЛУЧАЙ)
Когда лучше применять Agile
Основные критерии применимости
Agile методология наиболее эффективна в проектах с высокой неопределённостью требований и необходимостью быстрого получения результатов. Вот ключевые сценарии:
1. Условия, благоприятствующие Agile
Характеристики проектов:
Примеры из практики: