Какая у тебя сильная компетенция?

Какая у тебя сильная компетенция

Если честно, я бы выделил три взаимосвязанные компетенции, в которых я чувствую себя особенно сильным. Расскажу про каждую и почему они важны для BA.

1. Глубокое понимание бизнес-логики

Это способность не просто записать требование, но полностью понять:

• Почему бизнес хочет эту фичу?
• Какой финансовый результат она принесёт?
• Какие constraints и ограничения есть?
• Как это взаимодействует с остальной системой?

Почему это важно: Много BA просто следуют требованиям от PM: "добавь кнопку тут, сделай это красивым". Я глубже копаю. Спрашиваю: "Зачем нам эта кнопка? Сколько людей её будут использовать? На сколько процентов вырастет выручка?"

Это помогает мне:

• Предлагать лучшие решения (не просто следовать указаниям)
• Говорить "нет" плохим идеям с аргументами
• Приоритизировать правильно (зная реальный ROI)
• Находить проблемы на этапе анализа, а не в продакшене

Пример: PM говорит: "Пользователи просят тёмную тему, давай добавим"

Я спрашиваю: "Сколько пользователей просили? 10? 1000? Это core users или casual? Тёмная тема стоит 2 спринта разработки, это стоит потраченного времени?"

Ответ: 50 из 10,000 пользователей просили. Это 0.5%, не worth it.

И вместо тёмной темы мы делаем фичу, которую просили 20% пользователей (и которая прямо влияет на выручку).

Как я это развивал:

• Читал книги по экономике и финансам SaaS
• Анализировал данные каждую неделю
• Спрашивал у PM и основателей, как работает бизнес-модель
• На каждом проекте считал CAC (customer acquisition cost), LTV (lifetime value), payback period

2. Способность быстро разбираться в сложных системах

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

Почему это важно: Многие BA берутся за задачу, но не полностью понимают, как это реализуется технически. Это приводит к неполным требованиям, конфликтам с разработчиками, неправильным оценкам.

Я всегда стараюсь понять техническую сторону:

• Какие БД вовлечены?
• Как данные синхронизируются между сервисами?
• Какие есть race conditions или edge cases?
• Где узкие места в системе?

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

Пример: Требование: "Когда пользователь удаляет заказ, нужно отправить SMS уведомление клиенту"

Много BA написал бы это просто. Я спрашиваю:

• Если заказ был синхронизирован с внешней системой, нужно ли его удалить там?
• Что если SMS сервис недоступен? Повторить попытку или проигнорировать?
• Что если пользователь удалит заказ, а потом отменит удаление? SMS уже отправлена...
• Как это работает при масштабировании (1000 удалений в час)?

Вместо простого требования получаются требования, которые покрывают реальные edge cases.

Как я это развивал:

• Читал документацию по микросервисам, кешированию, очередям
• Работал в проектах с разной архитектурой (monolith, microservices, serverless)
• Спрашивал у разработчиков и архитекторов, как они решают конкретные проблемы
• Сам писал SQL запросы (для понимания того, как работают БД)

3. Умение объяснять сложные вещи просто

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

Почему это важно: Хороший BA — это не просто аналитик, это коммуникатор. Если я не могу объяснить, почему нужна какая-то фича, никто её не будет делать.

Это помогает мне:

• Убеждать людей в моей позиции
• Доносить требования так, чтобы все поняли одинаково
• Решать конфликты между командами (каждая сторона слышит другую)
• Писать документацию, которую люди реально читают

Примеры:

1. Для бизнеса (когда объясняю, почему нужна интеграция с платёжной системой): "Сейчас пользователи платят вручную через банк. Это занимает 2-3 дня. Интеграция сократит это до 10 минут. Результат: на 30% больше платежей в день, потому что люди не будут ждать 2 дня."

2. Для разработчика (когда объясняю, почему нужен индекс в БД): "Сейчас при поиске заказов система проходит по всем 10 млн записей. При индексе на (user_id, created_at) она найдёт их за 10ms вместо 50ms. Это улучшит UX."

3. Для дизайнера (когда объясняю, почему макет не подходит): "На мобильном эта кнопка будет очень близко к краю. Пользователь случайно кликнет на неё вместо соседней. Нужно больше отступа."

Как я это развивал:

• Писал документацию и требования (много раз переписывал, пока люди не понимали)
• Регулярно проводил синхронизации и объяснял решения
• Читал книги по коммуникации и презентациям
• Просил фидбек: "Я понятно объяснил?" и прислушивался к ответам

Как эти компетенции работают вместе

Эти три компетенции не существуют отдельно:

Пример интеграции: Требование "Добавить интеграцию с Telegram для уведомлений"

1. Бизнес-логика: Спрашиваю, почему Telegram? (ответ: 80% пользователей есть в Telegram, SMS дорого). Считаю ROI: экономим $5k в год на SMS. Стоит спринта разработки.

2. Понимание системы: Обсуждаю с архитектором, как это реализовать. Спрашиваю про rate limits Telegram API, про fallback если API недоступен, про масштабирование.

3. Объяснение: Описываю требование так, чтобы разработчик понимал не просто "интегрируй Telegram", но и все edge cases. Объясняю бизнесу, почему это принесёт деньги. Показываю дизайнеру, где должны быть UI элементы.

Что я не делаю так хорошо

Честно скажу, есть вещи, в которых я слабее:

• Чистый юзер-рисерч (qualitative research) — я аналитик по сердцу, больше люблю цифры
• Графический дизайн — я знаю базовые принципы, но не дизайнер
• Очень глубокое программирование — я пишу SQL и Python скрипты, но не full-stack разработчик

Но это нормально. Я знаю свои слабости и либо их компенсирую, либо просю помощи у специалистов.

Как я применяю эти компетенции в работе

Ежедневно:

• Пишу требования, которые учитывают бизнес-логику, технические реалии и понятны всем
• Задаю вопросы, которые помогают выявить проблемы на этапе анализа
• Объясняю решения команде

Еженедельно:

• Анализирую данные и даю инсайты
• Обсуждаю архитектуру с разработчиками
• Убеждаю PM в правильности приоритизации

Ежемесячно:

• Пишу отчёты о ROI проектов
• Планирую квартал на основе анализа
• Вижу тренды и предупреждаю команду о потенциальных проблемах

Финальная мысль

Сильная компетенция BA — это не просто навык (тип, уметь писать requirements). Это сочетание:

• Знаний (как работает бизнес, технология)
• Навыков (анализ, коммуникация, письмо)
• Мышления (аналитическое, системное, критическое)
• Опыта (много проектов, много ошибок, много выводов)

Я постоянно развиваю эти компетенции, потому что технология меняется, бизнес меняется, и я должен меняться вместе с ними.