Думал ли расти как бизнес аналитик

Карьерный путь: от разработчика к бизнес-аналитику

Это интересный вопрос про карьерное развитие. Я рассмотрю оба направления честно.

Мой подход к карьере

За 10+ лет разработки я видел разные пути развития. Лично я сосредоточился на углублении в Backend архитектуру и системном проектировании, а не на миграции в BA роль. Вот почему:

Почему я выбрал путь архитектора, а не BA

Преимущества специализации в разработке:

• Углубленное понимание того, как работает система "снизу вверх"
• Возможность влиять на технические решения напрямую
• Лучший контроль над качеством и производительностью
• Более высокий потолок заработков (Senior/Lead engineer)

Преимущества перехода в BA:

• Ближе к бизнесу и клиентам
• Можно переломать в более управленческую роль
• Проще переживать выгорание от кода
• Часто меньше "боевых дежурств"

Что нужно для перехода в BA

Если разработчик хочет стать BA, то нужно:

1. Развить мягкие навыки:

   • Навык коммуникации с неподготовленными людьми
   • Умение слушать и задавать правильные вопросы
   • Способность синтезировать информацию

2. Изучить методологии:

   • User Stories и Use Cases
   • Event Storming
   • User Research методы
   • A/B testing и метрики

3. Инструменты BA:

   • Diagramming (Miro, Figma)
   • Prototyping (Figma, Axure)
   • SQL для анализа данных
   • Excel/Google Sheets

Гибридный путь — мой рекомендуемый вариант

На практике я вижу самых эффективных людей, которые совмещают обе роли:

Technical Product Manager = Backend-разработчик + BA навыки
↓
Может разговаривать с:
- Разработчиками (они же)
- Продуктом и аналитиками
- Клиентами и операциями

Это роль более редкая и ценная, чем чистый BA.

Пример из моей карьеры

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

1. Проанализировать требования компании (как BA)
2. Спроектировать архитектуру (как архитектор)
3. Реализовать критические части (как разработчик)
4. Оптимизировать процесс (как системный инженер)

Этот "полный цикл" знаний дал мне намного больше, чем узкая специализация.

Практический пример: требование к платежам

Задача от продукта: "Мы теряем платежи, нужна система восстановления"

Как BA я бы:

• Спросил: сколько платежей теряется? в какие моменты?
• Составил requirements doc
• Согласовал со всеми stakeholders

Как разработчик + BA я бы:

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

Второй подход экономит месяцы и дорогостоящие ошибки.

Когда переходить в BA имеет смысл

• Ты перегорел от кода, но любишь понимать проблемы
• Тебе интересны люди больше чем технология
• Ты плохо разбираешься в коде, но хорошо в общении
• Хочешь работать в стартапе, где BA = со-founder

Когда оставаться в разработке

• Ты любишь решать технические задачи
• Нравится видеть результат своего кода
• Интересует системный дизайн
• Готов расти как Senior/Lead/Principal engineer

Мой совет молодым разработчикам

Не торопись выбирать. Сначала:

1. Стань очень хорошим разработчиком (3-5 лет)
2. Поговори с BA из своей компании
3. Попроси помочь в требованиях одного проекта
4. Через 1-2 года поймешь, подходит ли тебе

Гибридный путь:

Years 1-3: Junior Dev → фокус на коде
Years 3-5: Middle Dev → начни участвовать в design
Years 5-8: Senior Dev → лидируй в архитектуре + требованиях
Years 8+: Выбирай: чистый архитектор или lead + BA

Практические навыки для B&A успеха

# SQL для анализа
SELECT customer_id, COUNT(*) as transactions
FROM orders
WHERE created_at > NOW() - INTERVAL '30 days'
GROUP BY customer_id
HAVING COUNT(*) > 5;

# Понимание метрик
ARPU = Total Revenue / Active Users
Churn Rate = Lost Customers / Starting Customers

Заключение

Я не перешел в BA потому что вижу больше возможностей в разработке + системном дизайне. Но я приобрел BA навыки, чтобы быть более эффективным:

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

Это сделало меня более ценным специалистом, чем узкий разработчик.

Мой рекомендуемый путь для вас: Становись хорошим разработчиком, постепенно добавляй BA навыки, и через несколько лет выбирай, что интереснее. Не спешить с выбором — спешка приводит к неправильным решениям.