Дисклеймер: статья написана на основе интервью с героиней, которая пожелала остаться анонимной.
Мне 43 года, я бизнес-аналитик из Москвы.
В бизнес-анализе я с 2015 года. В первую компанию пришла без опыта. Сказала: «Я согласна брать ниже рынка, пожалуйста, возьмите меня, я очень хочу быть аналитиком».
Полгода описывала и рисовала бизнес-процессы, перечитывая федеральный закон по ЖКХ. Плюс прочитала кучу книжек типа Вигерса про то, как писать требования.
Устроилась на 65 000 ₽ на руки.
Два с половиной года проработала — зарплату не подняли. Пришлось искать другую компанию, чтобы вырасти в зарплате — перешла на 125 тысяч.
После этого в 2017 был ВТБ — там уже 150 на руки. Там мне немного подняли зарплату, но до 300 000 ₽ я доросла только к 2025 году, когда ушла из последнего банка.
Нашла работу очень быстро, за 5 недель, мне очень повезло. Сделала 85 откликов, было 8 собеседований с HR. В трёх компаниях я дошла почти до самого конца и 1 раз получила оффер.
Как изменился рынок найма
Ожидания от бизнес-аналитика сейчас сильно выросли и расширяются в две стороны.
Первое направление — продуктовые компетенции:
Ожидается, что бизнес-аналитик будет помогать бизнесу зарабатывать деньги и вносить предложения такого характера. Ещё нужно давать аналитику текущей ситуации, объяснять почему именно так, а не иначе. По сути, совмещать бизнес-анализ и BI-анализ (анализ данных).
Смотришь на данные и предполагаешь, какое развитие системы будет наиболее выгодно для компании. Строишь гипотезы, потом их проверяешь.
Раньше этого от бизнес-аналитика никогда не требовали. Если этим кто-то занимался, то продакт-оунер.
Второе направление — системный анализ:
Хотят fullstack-аналитика, который занимается и бизнес-, и системным анализом. Причем глубоко — так, чтобы мог написать JSON самостоятельно, спроектировать сервисы.
Если в команде нет архитектора, нужно очень хорошее знание архитектуры. Если архитектор есть — попроще будет.
Третье направление — управление проектом:
Ожидают, что аналитик будет ещё руководителем проекта: отвечать за бюджет, презентации руководству, контроль сроков и выполнения задач всеми членами команды. Правда, так было и раньше — это не новое требование.
Как писала резюме
Резюме писала сама. Когда-то коллега дала мне наводки — она старше меня, мы тогда дружили.
Главный совет касался блока «О себе».
Коллега сказала: «У тебя есть определенный взгляд на то, что такое хорошее место работы, что такое хорошо организованный проект. Есть какие-то наработки — вот об этом надо писать».
Последовала совету.
Каждое место работы структурировала одинаково: сначала достижения, потом обязанности, потом инструментарий и причина увольнения. В итоге получилось 5 листов. Недавно выгрузила резюме в Word и обнаружила это — думаю, как меня вообще пригласили, непонятно.
Если продолжу откликаться дальше, буду резюме сокращать.
Собеседования
В большинстве компаний наём проходит в 3-4 этапа. Первый этап — созвон с HR.
Рекрутер проверяет базовое соответствие вакансии и обсуждает условия.
Что спрашивают:
Опыт работы по каждому месту.
Инструментарий, которым пользуешься.
Организационные моменты: готовность ехать в офис, ожидания по зарплате.
Причины увольнения с предыдущих мест.
По инструментарию есть два блока вопросов:
Первый — в каких программах работаешь: Microsoft Office, Excel, PowerPoint, Visio, специализированные программы типа Camunda, Iris.
Второй — какие нотации и способы представления данных используешь. Есть разные типы диаграмм, и ты называешь типы диаграмм или нотации описания бизнес-процессов.
Если эти аббревиатуры совпадают с тем, что используют в компании — все довольны. Если не совпадают — с тобой почти всегда прощаются. Например, если в компании описывают бизнес-процессы в BPMN, а ты его не знаешь — значит, твоё описание будет непонятно и неудобно коллегам.
Сейчас на рынке ищут специалистов именно в нужной области. Если внедряют ЭДО, то возьмут человека, который знает об ЭДО всё и внедрял его пару раз. Это минимум, к которому прилагаются все остальные ожидания — продуктовые компетенции, системный анализ, управление проектом. Снижать планку в этом плане не готовы.
Дальше идёт техническое собеседование, на нём проверяют профессиональные знания. Обычно собеседует руководитель отдела или старший аналитик.
Потом — собеседование с руководителем проекта. Ещё могут быть собеседования с командой или ещё одно техническое интервью.
Расскажу о собеседованиях в крупные компании, которые у меня были.
Дом.РФ
Этап 1: Созвон с HR
Всё стандартно. HR спрашивал про мой опыт, инструментарий и организационные моменты — устроит ли, если придется ехать в офис.
По инструментарию все совпало — у них в компании используется BPMN, это сейчас очень распространено. UML тоже спрашивали, я его знаю.
Этап 2: Техническое собеседование с руководителем бизнес-анализа
Меня собеседовали два человека, ещё HR подключался-отключался. У девушки-руководителя был прямо длинный план, мы только-только в час уложились.
Что спрашивали:
Что такое бизнес-требования
Что такое нефункциональные требования
Структура требований
На что обращать внимание при создании презентаций
Что включать в документы, а что не стоит писать
Какие диаграммы и схемы в каких случаях использовать
Мэппинг полей
Проектирование сервисов и интеграций
ER-связи: Проверяли, чтобы я хорошо плавала среди связей и не путала объекты. Спрашивали про связи "один ко многим", "один к одному", необязательные связи. Важно было понимать связи между ними, чтобы не путать объекты в системе.
Ещё давали кейсовые вопросы и аналитическую задачку. Их уже не помню.
Этап 3: Собеседование с продакт-оунерами
Здесь я посыпалась. Было два продакт-оунера, и они спрашивали про эмоциональный интеллект при работе с заказчиками.
Вопросы были такие:
А если заказчики против ваших предложений?
А если они настаивают на своем?
А если есть два заказчика, у которых стычки между собой — что будете делать?
Они задавали примерно одни и те же вопросы с разных углов. Я рассказывала подход, который применяла на прошлом месте работы.
У нас там было два подразделения на одном уровне, которые между собой конкурировали и друг друга терпеть не могли. Любой аналитик, который попадал на проекты с этими подразделениями, сталкивался с этой проблемой.
Всегда есть ведущие или ведомые подразделения, ключевые и неключевые. Я сначала всё согласовывала с ключевыми подразделениями, потом — с системными аналитиками, после этого прихожу к остальным и рассказываю только тот минимум, который им надо знать, не погружаясь в детали.
Когда отвечала на вопросы продакт-оунеров, придерживалась этого подхода.
Видимо, это их не удовлетворило. Возможно, у них есть своя специфика или они хотели от меня чего-то «инновационного».
После этого этапа со мной не связались. Обратной связи не было — я поняла, что это их не устраивает, но где именно и что конкретно, не знаю.
Совкомбанк
Когда я откликалась на вакансию в Совкомбанке, нужно было прислать видеорезюме.
Тебе дают ссылку, там вопросы, и тебе нужно записать ответы на них прям через камеру. Было 6 или 7 вопросов
Один из вопросов запомнился: "Почему вы выбрали бизнес-анализ? Чем он вам нравится?"
После этого этапа было собеседование с HR, но дальше я не прошла.
Крупный IT-интегратор (моё текущее место работы)
Здесь было рекордное количество этапов — 4. Компания вышла на меня сама.
Стандартное интервью с HR, потом — интервью с руководителем бизнес-аналитиков. Для него была важна многозадачность:
— Сколько ты можешь одновременно задач вести?
— Три-четыре хорошо, больше пяти уже плохо.
— Ну, это ни о чем.
Но он все равно назначил встречу с моей будущей коллегой. Третье собеседование было с ней.
Дальше был четвертый этап — техническое собеседование. После него — ещё собеседование. И уже после этого получила оффер.
Оффер
Больше всего бизнес-аналитикам платят в банках и IT-интеграторах. Могут платить и 400 000 ₽. Но сейчас вакансий немного.
В небанковском секторе 300 000 ₽ — это абсолютный потолок.
Ещё есть бизнес-аналитики, которые разбираются в ценных бумагах — они получают 500-600 000 ₽. Просто за счет того, что погружены в эту область.
Здесь нужно знать производные финансовые инструменты. Это очень сложно, я так и не смогла разобраться.
Зарплату, на которые устроилась героиня, можно посмотреть в канале «Кухня известной IT-компании».
Работаю 4-й месяц. На прошлой неделе мне сказали, что я прошла испытательный срок, но «по границе» — дали второй шанс до нового года, чтобы исправить недочеты.
Когда только устроилась сюда, было ощущение, что мне надо отсюда уходить. Поэтому параллельно смотрела, что есть на рынке, откликалась, ходила на собеседования. Сделала 137 откликов, получила всего 1 приглашение на собеседование. За 4 месяца так ничего и не нашла.
Посмотрела, как на меня реагируют на рынке и поняла, что остаюсь здесь. Если меня попросят, это другой вопрос, но сама вряд ли уйду.
Дисклеймер: статья написана для блога «Кухня известной IT-компании», героиня пожелала остаться анонимной.
Поиск работы – это всегда стресс, и было бы здорово получить доступ к опыту тех, кто недавно этим занимался.
Поэтому мы решили следить за ситуацией на рынке IT в 2024-2025 гг.
Мы берём интервью у айтишников, которые искали работу в этот период. Они рассказывают нам о том, что изменилось в найме IT, что теперь спрашивают на собеседованиях, как проходит отбор, какую зарплату предлагают.
Если вам понравилась эта история, вы можете прочитать и другие истории на телеграм-канале:
Комментарии (0)
Johninator
23.09.2025 15:52"дали второй шанс до нового года"
Наглость работодателей уже не знает границ. Вы им напомните, что после испытательного срока так угрожать не стоит, и уволить быстро сотрудника не получится.
sloww
23.09.2025 15:52Это не угроза, с чего вы вообще взяли?
Скорее всего это обычный отклик на ревью. И да, если человек не справляется, и ему это говорят после ревью - это наоборот хорошо. Потому что в 90% компаниях до момента увольнения наоборот делают вид, что все прекрасно и вы очень ценный сотрудник.
А тут ясно дали понять, что человек не вывозит. Далее могут быть уже вопросы к метрикам и адекватности уровня задач, но это лирика для автора.
Kwisatz
23.09.2025 15:52До окончания испытательного срока тоже на самом деле. Там нужно довольно серьезное обоснование.
MyraJKee
23.09.2025 15:52Бизнес аналитика, системная, немного архитектор и РП. Как в том анекдоте:
- Танцуешь?
- Танцую, пою, стихи читаю, кошек люблю...
- Ты че плетешь?
- Плету, вышиваю, спицами вяжу...
Q3_Results
23.09.2025 15:52Где смеяться?
LeVoN_CCCP
23.09.2025 15:52Да чего въезжать в эту лажу. Терминатор... Терминатор - машина, он из металла, так? Но почему ребёнок - марионетка, а?
LeVoN_CCCP
23.09.2025 15:52Ох забыл сарказм поставить, ну и ладно. В этих ваших интернетах не поймёшь кто прикалывается, а кто реально дебил.
AndronNSK
23.09.2025 15:52Из статьи у меня сложилось впечатление, что героиня ищет позицию какой-то несуществующей в реальности единицы. Когда были жирные времена, держали человека ради модного названия должности на 5тысяч зелени на руки.
Trivial_manager
23.09.2025 15:52Да собственно, это и есть существующая реальность. Аналитик, хоть бизнес, хоть системный - это низкоквалифицированных труд за большие деньги.
Вот эти вопросы, что перечислены в статье - это и есть актуальный максимум знаний, который надо иметь. Иногда к ним примешивается предметная область. Ну и сравните, какой уровень знаний вам нужен, чтобы ответить на вопрос "что такое бизнес требования?" и какой при ответе на вопрос "как работает garbage collector в .net/java/go?". Чтобы разобраться во всех используемых аббревиатурах типа BPMN, UML и их аналогах вам понадобится пара дней, чтобы разобраться в основных протоколах стека TCP/IP у некоторых уходят годы.
По факту, 90% всех аналитиков пишут не особо понятные "требования" за продуктами или другими бизнесологами, или "проектируют" api и таблички в БД, которые разработчики потом переделывают. В лучшем случае, заполняют проектную документацию.
Естественно, бывают исключения, но это как иголка в стороне сена.
Kyrych
23.09.2025 15:52TCP/IP - годы? Да, даже если заголовки все наизусть выучить захочется больше года - перебор.
Trivial_manager
23.09.2025 15:52Ну, если прям этим заняться то и год перебор, но это, обычно второстепенный вопрос, поэтому его все откладывают. Тут может не очень корректное сравнение привел
Mimimi
23.09.2025 15:52Так тут очевидное "вот мы действительно работаем, а они ничего не делают". Данное заблуждение свойственно чуть ли не всем в айти. И девопсы за всеми переделывают а разрабы код не умеют писать, и разрабы CI пишут лучше любого "yaml-разработчика", безопасникам всегда нужно всех учить делать правильно, аналитики работают по 15 часов и пишут идеальные требования для макак, а разрабы не понимают в какой цвет красить кнопку если написано "красный".
Поэтому кто-то годами учит как garbage collector работает и это нормально, а годами учить UML это моветонTrivial_manager
23.09.2025 15:52"вот мы действительно работаем, а они ничего не делают" тут начисто отсутствует. У аналитиков есть своя зона ответственности и ее надо закрывать. Я говорю лишь о том, что порог вхождения, требования к аналитиками и уровень сложности их задач - одни из самых низких в индустрии, но при этом, оплачиваются аналитики +- как разрабы или девопсы, которым для работы требуется гораздо больше вложений в свои навыки.
Я не знаю, хорошо это или плохо, это просто факт. Таков сегодняшний рынок труда.
То, что бывают разработчики, которые в принципе не могут базовые вещи освоить и аналитики, которые прекрасно разбираются в современных технологиях я тоже не отрицаю. Но это скорее исключения из правил.
NightBlade74
23.09.2025 15:52порог вхождения, требования к аналитиками и уровень сложности их задач
Как человек, поработавший и аналитиком, и разработчиком, и руководителем таковых, могу сказать, что это полная чушь.
Trivial_manager
23.09.2025 15:52Как человек, поработавший и аналитиком, и разработчиком, и руководителем таковых, могу сказать, что это реальность. И вот вам целую статью ещё человек написал для подтверждения.
skovoroad
23.09.2025 15:52Вы немножко мерилом работы считаете усталость.
Представляется, что дело не в том, насколько трудно освоить профессию БА (срежем углы и примем гипотезу, что это действительно просто). Ассенизатором тоже, предположу, несложно стать. Проблема в соотношении спроса и квалифицированного предложения. Белые воротнички, имеющие достаточно софтов и абстрактного мышления - зачем они, собственно, пойдут на низкооплачиваемую должность? В мире есть миллион стезей для таких людей: мелкий бизнес, менеджмент, финансовый гешефт, значительная часть преподавания очевидных умений, в конце концов - мошенники той или иной степени легальности.
Ну и сколько остаётся достаточно способных людей на такую странную должность, как БА? Вот именно отношение их количества к количеству позиций и даёт в итоге и зарплаты для топовых специалистов, и средний уровень остальных. Из порога вхождения тут надо вычитать порог вхождения в другие отрасли деятельности.
А вот для программистов тут дело хуже - умение упаковывать килобайты, сочинять апи и проектировать микросервисы востребовано только здесь, его в театре, вузе или на площади не монетизируешь. Короче, прямое сравнение трудозатрат на обучение и востребованности тут не работает.
Trivial_manager
23.09.2025 15:52Конечно же, условия диктует рынок труда и да, он такой, как вы описали. Поэтому товарищи аналитики столько и стоят.
Собственно, я с этим и не спорю. Просто вы говорите о причине, я говорю о следствии.
По большому счету, вся ветка началась потому что человек удивился простоте представленных вопросов на собеседовании)
NightBlade74
23.09.2025 15:52Статья на самом деле очень противоречивая. Но то, что я там вижу - человек отработал 10 лет БА, чтобы подняться с 65 до 300. Я бы сказал, что в принципе и для разработчика, поднявшегося со стажера до сеньора - вполне себе нормальный прогресс. Чем 10 лет опыта БА (здесь пока не трогаем СА) хуже? БА надо очень хорошо понимать бизнес, знать нотации, т.к. в крупных компаниях типа банков это обязательно, ну и плюс все скиллы аналитика: коммуникабельность, написание грамотной документации (иногда, кстати, тоже по ГОСТу или другим стандартам). Мало того, БА в большинстве случаев предполагает не посредничество между бизнесом и ИТ, а работа с бизнесом в принципе, такая как финансовая и производственная аналитика, оптимизация процессов и тому подобное, что предполагает навыки в куче различных областей знания.
Что же касается СА, то самые лучшие аналитики получаются из разработчиков, которые обладают скиллами общения с людьми, а не только с железками, как это умеют делать разработчики. И вот таких людей немного, в противовес того, что я знаю очень многих разработчиков, которых к людям подпускать недопустимо, ибо результат будет крайне печальным для всех участников и для конечного результата. И тут уже аналитик стоит на голову выше разработчика, т.к. он может все, что может разработчик, ибо сам является таковым, плюс еще много чего, чего у других разработчиков нет.
Естественно, существуют должности, где к аналитику не предъявляют каких-то прям специальных требований, только типа "башка на месте, говорить-читать-писать умеешь и этого достаточно", но это редкость, а судя по той же статье, уже и совсем себя изжило.
ris58h
23.09.2025 15:52порог вхождения, требования к аналитиками и уровень сложности их задач - одни из самых низких в индустрии, но при этом, оплачиваются аналитики +- как разрабы или девопсы
Интересное утверждение. И каким образом возникла такая аномалия противоречащая законам рынка?
jonikjonikovich
23.09.2025 15:52QA потом смотрит на ТЗ от аналитика, на реализацию от разработчиков и плюется. "Что там описывать, там и так все понятно" или "это не баг - это фича".
sepulkary
23.09.2025 15:52Поэтому «волчистые» вкатуны обычно и метят в аналитики или тестировщики. В разрабы — редко-редко.
Okeu
23.09.2025 15:52Данное заблуждение свойственно чуть ли не всем в айти
Во-первых не всегда оно беспочвенно, а во-вторых выше немного не о том ведь.
Вот с чем лично я регулярно сталкиваюсь:
Мне регулярно приходится изучать пользовательскую документацию за скрам-мастера, продакт овнера, и проджект менеджера, разбираться в функционале и методологиях, например чтобы построить правильные отчеты.
А вот им за меня скрипты писать как-то не приходится, или изучать документацию администратора или еще что-нибудь в этом роде. И большая часть просьб о помощи от подобного персонала означает "сделай за нас". "Одмин" курит мануалы и раскатывает для них требуемый инструмент, а они еще и пользоваться им не хотят, "тыжодмин", "помоги" нам))
А то, о чем вы выше упоминаете - это вообще выходит за рамки ИТ, и является обычными человеческими взаимоотношениями - вызываешь сантехника - он смотрит на трубы и спрашивает "КТОЖ ВАМ НАВОРОТИЛ ТАКОГО УЖАСА" - и так по кругу, этоколесо сансарыкруговорот рукожопов)
R3B3LL10N
23.09.2025 15:52Да не только в айти. Чем меньше что-то понимаешь, тем проще оно кажется. Распространённый феномен.
uuger
23.09.2025 15:52"что такое бизнес требования?"
что такое бизнес-требования - это простой вопрос. а вот "как вынуть из заказчика реальные бизнес-требования, которые потом могут превратиться в реальный проект со сроками и стоимостью" - это уже настоящий вопрос для собеседования кандидата с опытом. по сути, нанимая опытного аналитика, компания платит за количество "граблей", по которым он прошёл за счёт других компаний
i86com
23.09.2025 15:52"как вынуть из заказчика реальные бизнес-требования, которые потом могут превратиться в реальный проект со сроками и стоимостью"
Так на такой вопрос единственный способ ответить - взять какое-то направление с потолка и придерживаться его, в надежде что у интервьюера в методичке что-то похожее написано.
Потому что ответов может быть целый спектр, от "быть мягким" до "быть жестким", от "самому написать и попросить кивнуть" до "не нужны бизнес-требования, просто сказать разрабам сделать стандартный прототип, а там уже заказчик сам пальцем ткнёт, что не так".
uuger
23.09.2025 15:52в надежде что у интервьюера в методичке что-то похожее написано
Опытный сотрудник не будет собеседоваться не у нанимающего менеджера. А если потенциальный руководитель интервьюирует по методичке - штош, удачи тому отчаянному, кто решится работать в таких условиях.
northrop
23.09.2025 15:52Опытный сотрудник не будет собеседоваться не у нанимающего менеджера.
Угу-угу, и еще не будет подаваться в транснациональные корпорации с числом работников минимум в пяток дивизий...Там нанимающий менеджер, если забыли - далеко не первый шаг во всем воркфлоу.
ManulVRN
23.09.2025 15:52Причем все ответы могут быть правильными в соответствующей ситуации))
Dmitry_604
23.09.2025 15:52Почему-то вспомнился старый анекдот про "почему без шапки/почему в шапке". :)
Вообще как технарь, слабо представляю себе собеседование по пободным софт-скильным проблемам, аж интересно стало как такое проходит.
vadimr
23.09.2025 15:52Это задача скорее для руководителя проекта, чем для аналитика.
uuger
23.09.2025 15:52это, как раз, эталонная (хоть в палату мер и весов клади) задача для аналитика, задача РП сделать то, что перечислено в моём комментарии после слова "потом":
превратиться в реальный проект со сроками и стоимостью
а после этого - управлять всеми сопутствующими процессами
vadimr
23.09.2025 15:52Я бы на месте РП побоялся нести ответственность за сроки и стоимость проекта, полученные на основании умозаключений одного подчинённого.
Вы предлагаете РП делегировать самую важную свою работу. Имея правильные сроки и стоимость, остальное сделает и дурак, а вот наоборот – проблематично.
uuger
23.09.2025 15:52Я бы на месте РП побоялся нести ответственность за сроки и стоимость проекта, полученные на основании умозаключений одного подчинённого.
где я такое предлагал? я предлагал собрать требования в пригодном для всех дальшнейших процедур формате.
имя
Ибрагимrequirements management plan вам о чём-нибудь говорит?Вы предлагаете РП делегировать самую важную свою работу
сбор и формализация требований и управление ими - это задачи для разных ролей в проекте
LinkToOS
23.09.2025 15:52Я бы на месте РП побоялся нести ответственность за сроки и стоимость проекта, полученные на основании умозаключений одного подчинённого.
Тем более если подчиненный не имеет полной информации об отношениях с заказчиком. Например о размере отката. А посвящать BA во все тонкости ведения бизнеса, только увеличивать количество свидетелей в судебном процессе.
mayorovp
23.09.2025 15:52Я бы на месте РП побоялся нести ответственность за сроки и стоимость проекта, полученные на основании умозаключений одного подчинённого.
Так пусть пытают заказчика несколько подчинённых.
И вообще, мне бы на месте РП было куда страшнее нести ответственность за сроки и стоимость проекта, полученные на основании некорректно сформулированных слов заказчика.
vadimr
23.09.2025 15:52Так пусть пытают заказчика несколько подчинённых.
Это не решает проблему принципиальным образом.
И вообще, мне бы на месте РП было куда страшнее нести ответственность за сроки и стоимость проекта, полученные на основании некорректно сформулированных слов заказчика.
Ну так, как вы верно заметили, в этом и фишка – правильно пытать.
Helson
23.09.2025 15:52Довольно поверхностное суждение=) Аналитик и разработчик ~ как инженер и токарь/фрезеровщик. Может ли производство работать без инженеров? Выпуская примитивные изделия - может, а если что то сложнее болта с гайкой (хоть и там есть куча нюансов) очень вряд ли. БА при проектировании системы собирает требования, отсеивает откровенный бред и тд, а затем оформляет их в виде схем разного рода нотаций. Далее, как правило именно БА с помощью СА пишет всякие доки для закрытия проекта - чтз, пз, пми и т.д. Это отдельные компетенции - написать доки так, чтобы всем было хорошо: одновременно не подставить команду излишне подробным чтз и при этом угодить заказчику=) У БА на первом месте софт скилы и личные навыки, а не хард - хард скилов от БА действительно не сильно много требуют.
Про СА это вообще отдельный разговор - это именно тот, кто проектирует по сути какой то функционал - перекладывает бизнес требования на "язык" пермишенов, бд и математики. На этапе проектирования это СА вместе с архитектором проектируют модель данных. Если нужно взаимодействие между системами - это опять же, описывает СА. Именно он читает документацию, вычленяет от туда нужное, общается со второй командой для уточнения неясных моментов, недокументированных особенностей и тд. И в результате его работы и получается "краткое" изложение требований на язык разработчиков - постановка. На этапе разработки именно СА описывает поведение системы при взаимодействии пользователя с ней: какие проверки и ошибки должны отображаться, какими пермишенами закрыто, какой сценарий основной, а какой нет. Опять же, это именно он ведет все эти документы-постановки - когда понадобится произвести какую то доработку к системе, вместо выдергивания разработчика можно посмотреть в постановку и понять логику работу какой либо функции. Да, она скорее всего на 100% не будет соответствовать тому, что реализовано, но как правило на 90-95% соответствует - этого достаточно, чтобы разобраться и вспомнить как функционирует та или иная часть системы. Тестирование - опять же, это тестировщики месте с СА пишут тест-кейсы и тестировщик пойдет именно к СА спрашивать, что ожидается от того или иного взаимодействия (или в идеале - почитает постановку)=)
Я видел команды (и работал с ними), которые работают без аналитиков - с ними крайней тяжело взаимодействовать, потому что разработчики часто забывают сообщать о каких либо изменениях, крайне неохотно общаются в принципе и скажем так, не очень умеют общаться и излагать мысли - хоть ртом, хоть текстом. Также разработчики чаще всего не умеют собирать требования и видеть несостыковки на этапе сбора требований - это довольно сильно усложняет разработку. Когда в команде есть нормальные аналитики, разработка ведется заметно легче, быстрее и комфортнее для всех участников=)
Trivial_manager
23.09.2025 15:52Да уж, очень поверхностно.
Ведь, на самом деле, разработчики у нас не умеют фильтровать откровенный бред, читать документацию с api и проектировать системы, они вообще не понимают, что они делают, они просто пишут этот ваш код так, как им сказано. А вот БА и СА с их упорами на "софт скилы" проектируют такие замечательные интеграции, никогда не приносят полный бред в требованиях и ещё и могут заполнять документацию. Вот только код и не умеют писать, а так вообще были бы золотые люди.
Вы сравниваете фрезеровщиков с программистами, а инженеров с аналитиками, но если уходить в вашу аналогию, то фрезеровщик или токарь - это джуны программисты, а инженер - это опытный и обученный программист или архитектор. Не может человек, который не понимает для чего нужны все станки быть инженером. Зато может инвентаризацию проводить.
В целом, вы говорите о не очень хороших программистах и тех самых иголках в стоге сена аналитиках. Но ситуация на рынке такая, что аналитиков, которые вообще не понимают как ИТ системы работают и непонятно зачем вообще они нужны - 99% всех кандидатов. А программистов, которые могут только код писать по указке и не знают ничего про брокеры, базы данных и паттерны проектирования гораздо меньше.
Helson
23.09.2025 15:52Нет, по моей аналогии - инженер это человек, который может не знать тонкостей обработки деталей, работы станка, режимов резания и т.д., но владеет более общей картиной по изделию, может пояснить за допуски, шероховатости и материалы, как СА например понимает почему именно такие атрибуты, почему именно такие кейсы описаны и нужны именно определенные проверки на фронте/бэке. Разработчик, как и фрезеровщик, может не знать/не понимать каких то тонкостей по, например, эксплуатации изделии (зачем такие допуски, зачем такие шероховатости, почему именно такой материал и тд), в то же время инженер может не знать, какие именно режимы резания у нержавейки и углеродистой стали. Ему, инженеру, в целом достаточно знать, что они разные.
Могут ли разработчики читать документацию к апи? Могут, конечно же. Только чтение документации без наложения на это дело требований - бесполезно. СА как раз тот человек, который читает документацию и доводит до менеджмента/заказчика невозможность и/или сложность реализаций каких то функций из-за каких-то ограничений. Может ли разработчик прочитать доки к апи и потом написать на понятном менеджеру языке, почему это нельзя/долго реализовывать? Могут, но не все. И займет это времени скорее всего дольше, чем у СА + вместо написания кода, разработчик будет заниматься согласованием функций, сроков их и т.д.
Макеты, кстати, сюда же. СА - это первичный фильтр между заказчиком и разрабами и как правило именно он первично говорит "Так не будет работать". Или вообще СА, что чаще, рисует первичные технические макеты с учетом бд/требований. Тоже отдать разработчику?:) Конечно, при разработке тоже может выясниться, что какой то момент упустили, но одно дело - пара полей на фронте, а другое - макет в целом.
Вопрос не в том, что БА/СА лучше чем разработчик или разработчик лучше чем БА/СА - это все люди, у которых своя зона ответственности и разные требования к выполняем ими функциям.
Trivial_manager
23.09.2025 15:52Вы очень сильно недооцениваете степень понимания разработчиками общей картины. Если у вас разработчик не может перед тем как начать читать документацию к api понять, что конкретно ему надо сделать, чтобы разобраться, сможет ли он это сделать с помощью этого api, и не может объяснить, почему этого сделать нельзя, то это не очень хороший разработчик. А аналитик, который видит картину целиком и может ещё и пояснить за шероховатости при разработке, потому что понимает концепции распределенных систем, особенности работы разных баз данных, или, хотя бы, принципы, которых вы придерживаетесь при разработке вашей системы - это та самая иголка в стоге сена.
Помимо этого, вы не улавливаете основную мысль.
Я не говорю, что аналитики не нужны. У них есть свои задачи, которые тоже надо выполнять. Я говорю, что в своем большинстве, это низкоквалифицированный труд за большие деньги.
monco83
23.09.2025 15:52Плюс много. От быдлокодера в любом случае мало толку. И часто разоработка понимает больше, потому что _вынуждена_ понимать. Это выше по стеку могут сказать: я дал вам стратегию, тактику сами выбирайте. А разработчик всегда тот Вася, которому лопатой махать.
monco83
23.09.2025 15:52Человек, который не попилил рестухи в кровавом энтерпрайзе пяток лет бесполезен для проектирования API и других подобных интерфейсов. Он может книжку какую-то найти и почитать, но сам по этим граблям не ходил, для него вся эта "идемпотентность" с "транзакционностью" - закрытая книга. Он не понимает почему и где это важно. Если аналитик взялся проектировать БД, то дай бог он not null правильно в колонках расставит. Ограничения уникальности, check constraint, понимания, что какие-то данные можно засунуть в jsonb - этого нет почти ни у кого. И таких людей без подходящего технического бэкграунда среди аналитиков большинство. Редко из разработки уходят в аналитику.
BadNickname
23.09.2025 15:52Да, не умеют.
И да, программами, написаными программистами, могут пользоваться только программисты.
monco83
23.09.2025 15:52Идеальный мир описан, а в реальном мире "БА с помощью СА" регулярно рожают галиматью, а "откровенный бред" отсеивает тимлид, если ему ещё не стало всё тут фиолетово. Если и тимлид решил переселиться в "идеальный мир", то бред аналитиков будет обрушиваться прямо на головы разработчиков и команда из релиза в релиз будет заниматься откапыванием и закапыванием стюардессы. Доска полна багами, зато разработчики не "простаивают", команда превозмогает и все при деле - радостная картина, которую не трудно продать менеджменту.
DMGarikk
23.09.2025 15:52а "откровенный бред" отсеивает тимлид, если ему ещё не стало всё тут фиолетово
далеко не все тимлиды хотят и вникают в то что там бизнес хочет
то как вы описываете, это тимлид начинает исполнять обязанности аналитика, причем зачастую не получая за это ничего взамен
мне приходилось восстанавливать заваленные проекты где на тимлиды работали без аналитиков и где аналитики вообще не понимали что делают и писали то что им скажет тимлид и проект превращался в пользовательский ад написанный программистами с зубодробительными процессами в стиле "ввод данных в систему осуществляется через эксель файл который надо по почте отправить на определенный адрес....эксель файл на 50 страниц с перекрестными ссылками" - почему так? а нафига им сложный интерфейс делать! в файле же всё понятно!
monco83
23.09.2025 15:52"Не хотят вникать" - это человеческий фактор. Он может встретиться на всех уровнях. Но у разработки есть сдерживающий фактор, которого нет у других - им всё это самим делать. Вот я недавно отбрил прилетевшую сверху идею интеграции двух систем на основе парсинга писем, доставляемых пользователю. В 2025 году. Тебе же только в копию адрес системы поставить, а парсить другой отдел будет. Не разработчики такое придумали, к разработчикам овнеры с этим пришли, а аналитики промолчали.
DMGarikk
23.09.2025 15:52им всё это самим делать
а вы не сталкивались с тем что "нам сказали - мы сделали, хз как вы с этим работать будете, это не наша ответственность" (с) ?
Это вот во многих проектах сквозит, где явно видно что сами разработчики нифига не пользуются тем что делают
monco83
23.09.2025 15:52Да сколько угодно такого, но такое отношение как раз и не защищает от аналитического скама. Если б мы жили в идеальном мире, где по цепочке бизнес-продукт-аналитик до разработки доходят только выверенные решения, то и проблем бы не было. Бери табличку из спецификации и переводи её в SQL. Но в том то и дело, что эта цепочка никогда не работает даже близко к идеальному варианту. И если ещё и разработка пофигисты (мы так сделали, потому что нам так сказали), то это будет комбо.
mayorovp
23.09.2025 15:52"ввод данных в систему осуществляется через эксель файл который надо по почте отправить на определенный адрес....эксель файл на 50 страниц с перекрестными ссылками" - почему так? а нафига им сложный интерфейс делать! в файле же всё понятно!
Я чаще наблюдаю обратную ситуацию: сделали UI, в котором можно всё настроить - но первой же фичей, которую запросили пользователи, является импорт из Excel для миграции старых данных. После появления этого импорта он навсегда становится основным механизмом внесения данных в систему, даже для единичных записей.
DMGarikk
23.09.2025 15:52(задумчиво) а это вы не видели еще таких экселей которые у меня в системе были... там руками внести те данные было задачей паре человек на неделю, а в интерфейсе за 2 часа с перекурами наткыать
вот тут и нужен адекватный аналитик и тот кто систему внедрять будет, а не выдать юзерам нечто и ничего не объясняя бросить с ней, очевидно что они начнут всякой чертовщиной там заниматься в обход того как она проектировалась.
sloww
23.09.2025 15:52Я когда это прочитал
так, чтобы мог написать JSON самостоятельно
Даже сначала и не понял. Ну то есть умение написать JSON приходит в момент написания самого первого JSON. Кавычки, запятая, перенос строки, отступы. Примерно как в школе заставляли по клеточками писать... Если это продают как скилл, то у меня в целом вопросов больше нет...
BTRchik
23.09.2025 15:52Так у этого автора все истории какие то такие…. С техническими нестыковками, когда специалист претендует на высокую позицию и при этом у него спрашивают какие то азы, которые этот специалист еще и не знает.
Vedomir
23.09.2025 15:52Аналитики которых я видел и которые выполняли очень важную и нужную роль прежде все ограждают разработчиков от общения с заказчиком, начальством, смежными отделами, от корпоративной бюрократии. Они знают предметную область и могут транслировать невнятные и противоречивые хотелки заказчика в четкую и логичную постановку по которой уже можно собственно разрабатывать - проектировать техническое решение и писать код. В крупных компаниях также избавляют от возни с бумажной и бюрократической волокитой. По большому счету это софт скиллы, знание предметной области и технические знания достаточные, чтобы не давать разрабам что-то странное и противоречивое. В мелких командах часто выполняют функции тестировщика, рп и частично архитектора.
И разработчик в теории может этим заниматься, только, во первых, у него времени уйдет столько же если не больше и, как правило, разработчики, это не любят.
Считать это низкоквалифицированным трудом несколько наивно - менеджмент это тоже по сути дела софт-скиллы, как и ведение своего бизнеса, и платят за них намного больше чем разработчикам.
Ivan22
23.09.2025 15:52так-то конечно разработчик может быть и Аналитиком и Тестировщиком и Менеджером и ДевОпсом и дизайнером и принтеры заправлять.
Но это всё только от бедности
Vedomir
23.09.2025 15:52В мелкой команде или стартапе на ранней стадии, я не удивлюсь, если разработчик будет одновременно и бэком и фронтом и девопсом. А вот аналитика, дизайн и менеджмент все-таки несколько другие сферы деятельности.
Хотя если разработчик например игру в одиночку делает, то он запросто будет всем вышеперечисленным и еще и композитором например.
NightBlade74
23.09.2025 15:52Разобраться в аббревиатурах BPMN и UML недолго, а вот выучить нотации и научиться их правильно применять, причем не просто текст в них переводить, а выстраивать процессы и архитектуру - это вот долго и непросто. Вы же не считаете, что для понимания IP-стека выучить аббревиатуры типа TCP и UDP и получить базовое понимание, чем они отличаются?
Ivan22
23.09.2025 15:52Разобраться в аббревиатурах BPMN Это ничто по сравнению с тем чтобы разобраться кто ...ять в корпорации из 100000 человек таки знает что за данные лежат вот в той системе и как они получаются.
NightBlade74
23.09.2025 15:52И это тоже, это прям альфа и омега для любого аналитика, найти иголку в стоге сена. Но тут человек как бы намекает, что достаточно аббревиатуры выучить.
monco83
23.09.2025 15:52>90% всех аналитиков пишут не особо понятные "требования" за продуктами или другими бизнесологами, или "проектируют" api и таблички в БД, которые разработчики потом переделывают
Ну, это если продукт им попадётся толковый, а то тоже протиратели штанов бывают.
А так то многое верно: и в части ясности и чёткости требований регулярный булшит, и таблички в БД зачем то "проектируют". При этом польза от аналитиков в наших краях всё-таки есть: легаси могут хорошо расковырять, требования с горем пополам доводятся до уровня, что по ним тестировщики могут написать test-case'ы... Ну продуктовую постановку вместо продукта сделать.
atues
Это Вы еще в Москве. В провинции "гроб с покойничком летает над крестами. А вдоль дороги мертвые с косами стоят. И тишина" (C)
NightBlade74
Если смотреть в Москве, то там все тоже не радужно. Мобильное приложение HH показывает количество откликов на вакансию (сайт почему-то не показывает). На ИТ-вакансии количество откликов 100+ обычное дело. На некоторые вакансии 300-400, бывает, что на некоторые количества откликов исчисляются тысячами. Какова вероятность, что вас хотя бы пригласят на собеседование? Она отличается от нуля, только если ваше резюме близко к идеальному с точки зрения данного HR и на 100% соответствуют требованиям вакансии. В остальных случает отказ или игнор. Так что если на желаемые вакансии количество откликов 100, тогда надо и 100 раз минимум резюме отправить, чтобы хоть на собес попасть, чисто статистически.
Ну и пышным цветом цветут вещи типа эйджизма. Если вам 40+, то вероятность еще более снижается: в наш молодой и дружный коллектив нужен такой же молодой и дружный специалист. Если вам 50+, то добро пожаловать на работу в "Пятерочку" или в такси.
ahdenchik
Это, кстати, очень интересный момент, который при обсуждениях hh как-то обходят или не считают важным упомянуть
nooknv
Если у компании сильно больше половины трафика с мобилок, то не удивлен, что и все фичи основные именно там. Это объяснимо. Но с другой стороны на беке фича уже сделана, и в таком случае прикрутить её на веб, не долго, если форнтэндеры не имеют беклог на год вперед)
Я это к тому, что всё можно объяснить) но как там в реальности не знаю)
NightBlade74
Вряд ли HH получает большее количество трафика с мобилок. Там еще можно посмотреть оперативно отзывы или поднять резюме в выдаче, но вот что-то серьезное, типа поиска подходящих вакансий, а тем более заполнения резюме там делать крайне неудобно - это дело для десктопа.
Надо заметить, что фича с показом количества отзывов появилась уже очень давно.
sobeskiller
Не долго, но стоит денег. Сейчас такое ощущение что всем стало пофиг на эти айтишные свистоперделки, не хочет никто больше вкладываться. Ну т.е. на минималках вроде что-то работает, но вот так вот запилить приятную фичу уже нафиг никому не сдалось.
Anyuta1166
Сразу скажу - я не HR, я простой IT-специалист, но по просьбе руководства участвовала в процессе найма новых людей в команду IT-отдела. Так вот, проблема в том, что по факту из этих 100 откликов будет только 5-10 более-менее релевантных, из которых только пару человек пройдет первичное тестирование и дойдет хотя бы до собеседования. Люди просто спамят своими резюме куда попало, зачастую не имея ни опыта, ни знаний.
ahdenchik
Они это делают потому что ваше "первичное тестирование" это тыканье пальцем в небо
Slavik2025
Приём на работу через сложное тестирование - это технология. Чем больше работы у принимающего рекрутера - тем больше времени он занят выбором кандидатов. Составление резюме, собеседования - отборы кандидатов нужны потому, что колличество работы меньше колличества соискателей. Если соискателей меньше, чем работы - то при наличии такого усложнённого механизма приёма на работу большая часть времени соискателей и рекрутеров тратится на непроизводительный труд и это означает наличие потенциального барьера в таких фирмах, например в виде следования культуры приёма работников. Поэтому если работников нехватает - то это означает, что идёт блокирование на входе.
MTyrz
Проблема в том, что по факту смотреть эти 100 откликов не будет никто. И никогда.
include a recipe for flan in your message to me
В первичные фильтры, которые и дадут вам на выходе "5-10 более-менее релевантных", как правило оказываются включены и возраст, и неуказание любой из двух десятков запрошенных технологий, и слишком малый стаж, и слишком большой стаж, желаемый знак зодиака, рандомный тест на неудачника и еще сорок восемь параметров. Поэтому со стороны соискателя, пусть трижды адекватного, задача проще отнюдь не становится.
urvanov
Приносит начальник отдела кадров генеральному пачку резюме тот берет половину рвет и в корзину. Она - что вы делаете там же есть и хорошие? Он- неудачники нам не нужны!!!
MTyrz
Да, вы совершенно верно поняли мою отсылку :)
ITDiver77
Количество откликов не показатель. Вот сейчас нужен тестировщик джун, но по скольку железо делаем, нужны навыки пайки. В вакансии про это ключевое требование написано в самом начале. 100500 откликов от мяса после всяких курсов, которые даже не читают описание вакансии и откликаются везде и всегда.
qbzerodp
Я умею паять. Что за компания? Как с вами/HR связаться?
Mirzapch
Могу паять паяльником, феном, и на ИК-станции.
Ссылка на вакансию будет?
Alexey_Volchanskiy
А мне скоро 61, я в найм даже не дергаюсь, поезд ушел. Надежда только на свой проект, вижу цель — верю в себя.
alexeypj
Ситуация странная. Неужели тишина? Вообще чтоль никто не нужен?
atues
Ну, не сказать, что полная тишина. Какие-то невнятные звуки доносятся. Вроде спецы нужны. Но сейчас мы не готовы. Знаете, как в магазине: и нравится, и хочется, да сомнения берут и жаба душит. В каком-то ожидании. Мутное времечко, скажем так