Умение программировать в бизнес‑анализе — это как скрытый тату на корпоративной спине: ...
Умение программировать в бизнес‑анализе — это как скрытый тату на корпоративной спине: официально «необязательно, но желательно», а по факту половина требований к вакансиям выглядит как «аналитик, который ещё и чуть‑чуть разработчик, и немножко дата‑сайентист, и иногда DevOps, если не сложно». Классика объявлений: «Ищем бизнес‑аналитика. Обязанности: интервью, требования, диаграммы. Будет плюсом: • умение писать SQL любой сложности, • опыт скриптов на Python, • знание REST, очередей, Kafka, Git, CI/CD и желательно фронт на React. Мы не ищем разработчика!» То есть как бы не ищем. Но если ты вдруг умеешь — мы это обязательно превратим в твою бесплатную опцию по умолчанию. В теории программистский скилл аналитику нужен, чтобы: • самому быстро проверить гипотезу в данных; • не верить чужим словам «там всё сложно»; • говорить с разработчиками на одном языке, а не через шаманский танец вокруг UML. В практике же происходит так: — Слушай, ты же «чуть‑чуть код пишешь», можешь сам выгрузку сделать? — А можешь сразу предобработать? — А можешь скрипт оставить, а то вдруг пригодится… Через полгода у аналитика три питоновских утилиты в проде и ощущение, что его тихо переквалифицировали в подпольного инженера. Мой любимый жанр — аналитик, который однажды признался: «Да, SQL знаю плохо, но что‑то могу». С этого дня он «наш главный по SQL». Всё: никакой путь назад уже не предусмотрен. Любой новый отчёт идёт через него, потому что «ему быстрее, чем просить разработчиков». И да, при этом на курсах по бизнес‑анализу тема «умение программировать» обычно подаётся в стиле: «это поможет вам лучше понимать техническую часть». Звучит мило. В реальной жизни это часто значит: «это поможет компании сэкономить на одном разработчике и повесить ещё пару тасок на того, кто не успел вовремя промолчать на собеседовании».