Я работаю системным и бизнес-аналитиком, но периодически вижу обсуждения, что аналитики не нужны, либо не нужны были изначально, потому что DDD и вот это всё, либо не нужны становятся сейчас из-за развития нейросетей и трансформации разработки. Однако на своем опыте я вывел несколько причин, почему аналитики всё таки нужны:
Разделение труда - системный и бизне-аналитик это результат разделения труда и специализации. Естественный процесс в любой деятельности, где работает больше трех человек.
Дешевая замена - аналитики в рамках выделения своей ролевой специфики часто выступают для сокращения затрат на разработчиков.
Тушитель пожаров - аналитики на проектах часто выступают в роли затыкателя дыр, выполняя все возможные временные функции от тестировщика до техписа.
Собиратели конструкторов - аналитики заменяют разработку в проектах с лоу-код и ноу-код конструкторами.
Вайб-кодеры - в настоящее время за ��чет нейросетей аналитик может самостоятельно тестировать идеи в коде и прототипах вообще без разработчиков. Далее рассмотрим подробнее.
1. Разделение труда - основа эффективности
Разработка ПО — уже давно не ремесло одного мастера, а командная работа множества специалистов. Разделение труда здесь не прихоть менеджмента, а необходимое условие масштабирования. Разработчик фокусируется на архитектуре и коде, тестировщик — на качестве, дизайнер — на опыте пользователя. А кто же будет отвечать за смысл?
Именно аналитик переводит запросы бизнеса в технические требования. Он задаёт ключевые вопросы:
— Какую проблему мы решаем?
— Кто наш пользователь?
— Как мы поймём, что решение работает?
Аналитик создаёт общее понимание между заказчиком, который говорит «хочу одну кнопку», и разработчиком, который спрашивает: «А что именно делать?».
Это ведь не просто «бумажная работа» по записи требований. Это управление сложностью. И чем масштабнее проект, тем выше цена недопонимания. Ошибка в требованиях на раннем этапе может стоить десяток переделок в дальнейшем, поэтому работе аналитика следует уделять внимание.
2. Дешёвая замена - страховка от некомпететености
К целом аналитик на рынке стоит дешевле, чем программист. Конечно аналитик не замещает программистов, но позволяет им сконцентрироваться на написании кода, сократив время на созвоны с заказчиком и переведя эту работу на себя. К тому же, аналитики могут на ранних этапах предусмотреть какие-то проблемы в реализации требований, найти противоречия, а значит сократят время на споры и переделки. В этом случае, аналитик экономит не за счет зарплаты, а за счет повышения эффективности работы команды.
Более того, в продуктовых компаниях и на синьорном уровне разрыв в зарплатах уже сокращается. Потому что зрелый аналитик влияет на разработку не меньше программиста, и также приносит значительную ценность.
3. Тушитель пожаров и «универсальная затычка»
В идеальном мире каждая роль выполняет свои функции. В реальности — аналитик часто закрывает пробелы за других.
Руководитель проекта перегружен и не успевает расставить приоритеты? Аналитик делает это сам.
Тестировщики не понимают бизнес-логику? Аналитик пишет сценарии и проверяет функции ПО.
Технического писателя нет? Аналитик создаёт документацию, инструкции, да ещё и обучает пользователей.
Разработчик не хочет вникать в нюансы? Аналитик «додумывает» логику и исправляет требования постфактум.
На проекте нет специалистов технической поддержки? Аналитики будет принимать заявки от пользователей, консультировать их, либо передавать выявленные баги разработке.
Конечно это не совсем здоровые ситуации, но реальность такова. Сейчас во многих проектах программисты пишут код, а аналитики и с заказчиком общаются, и документы пишут и доработки тестируют.
4. Собиратели конструкторов - аналитик становится разработчиком
С приходом платформ вроде Bubble, Airtable, Power Apps, ELMA, Первая форма аналитик получил суперсилу: он может сам создавать рабочие решения без единой строчки кода.
Теперь он не просто описывает форму для приложения — он может с��брать её сам и она сразу будет работать, при это не требуется писать код. Я знаю, что на Хабре мало поклонников ноу-код, но тем не менее такие платформы используются, работают и выполняют свои функции. Если в компании внедряют какую-то лоу-код платформу, то ей нужны аналитики, которые будут там настраивать и править, сразу реализуя то, что нужно пользователям. Программисты в этом случае конечно тоже нужны, но только для написания плагинов, коннекторов, каких-то базовых функций и т.д. Здесь вот про это подробно описано https://habr.com/p/977318/
Это превращает аналитика в продуктового инженера одного лица: от идеи до MVP — за день. Но есть и риски. No-code — не панацея. Такие решения часто не масштабируются, сложны в поддержке и могут стать «цифровым мусором», если не продумана архитектура. Аналитик должен понимать границы возможностей платформ и вовремя передавать зрелые продукты в руки программистов то, что требует классической разработки через код.
5. Вайб-кодинг и ИИ: от ТЗ к архитектуре намерений
Самый мощный тренд 2024–2025 годов — вайб-кодинг (vibe coding): когда достаточно описать желаемое поведение на естественном языке, чтобы ИИ (GitHub Copilot, Cursor, V0, Lovable) сгенерировал рабочий интерфейс или даже full-stack приложение.
Это не отменяет аналитика — наоборот, делает его роль критичной. Теперь его главная задача — не писать многостраничные спецификации, а формулировать точные, структурированные промпты, которые ИИ поймёт без искажений.
Аналитик становится валидатором намерений: он проверяет, правильно ли ИИ интерпретировал логику, учтены ли крайние случаи, не нарушена ли связность системы.
Ещё важнее — фокус на гипотезах и метриках. Если реализация занимает минуты, то главный вопрос — не «как сделать», а «зачем и как измерить эффект». Аналитик переходит от описания функций к управлению бизнес-ценностью. То самое "сделать хорошо".
Выводы
Аналитик это необходимая во многих случаях роль (и должность) на проектах связанных с разработкой и внедрением ПО. Сейчас, в ряде случаев, это может быть единственная роль технического специалиста в команде. И эта роль будет долго существовать в том или ином смысле.
