← Все статьи

Михаил Поляков

Нужен ли стартапу системный аналитик: что делает эта работа и когда нанимать отдельного человека

Уровень: ПростойВремя чтения: 12 мин

Темы: Системный анализ, Малый бизнес

Светящийся ноутбук на тёмном фоне, от него линии к карточке оплаты, коробке доставки и стопке карточек клиентов; над ноутбуком прозрачная схема со стрелками и развилкой, на развилке жёлтый треугольник предупреждения

Короткий ответ: сама работа системного аналитика нужна стартапу с первой строчки кода, а отдельный человек под неё нужен не сразу. Кто-то в команде должен решить, какие данные хранит продукт, с какими сервисами он обменивается, что происходит при сбое и как понять, что функция готова. На старте это делают основатель и ведущий разработчик по простому шаблону. Нанимать аналитика имеет смысл, когда потери, которые он реально снимет, по деньгам больше его полной стоимости для компании. В маленькой команде к часам разработчиков стоит прибавить то, что ими не измерить: ошибки в деньгах клиентов, требования партнёров, риски с персональными данными. Ниже разберу, как это проверить на своей команде и посчитать.

Я больше 13 лет в ИТ, с 2020 года в финансовом секторе, сейчас главный системный аналитик. Штатным аналитиком в стартапе я не работал, поэтому здесь нет историй из стартапов. Здесь подход, который я применяю к новым системам, которые делают с нуля. Состав работы в вашем продукте может отличаться.

Что такое системная аналитика простыми словами

Основатель говорит: «хочу, чтобы клиент мог оплатить подписку картой». Системный аналитик превращает эту фразу в план для разработчиков: какие экраны, какие данные, какой платёжный сервис, что делать, если деньги списались, а подписка не включилась.

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

  • что функция должна делать и при каких условиях;
  • какие данные она хранит и откуда их берёт;
  • с какими внешними сервисами обменивается: оплата, доставка, CRM (программа для учёта клиентов и сделок), маркетплейс;
  • что происходит, если что-то пошло не так: сервис оплаты не ответил, клиент нажал кнопку дважды, данные пришли неполные;
  • как понять, что функция готова (критерии приёмки).

Рядом есть две похожие роли. Бизнес-аналитик отвечает на вопрос «что нужно и зачем». Продуктовый аналитик смотрит на поведение пользователей и цифры продукта. Системный аналитик отвечает на вопрос «как это устроить в наших программах». В небольшой команде всё это может делать один человек, и это нормально.

Зачем это стартапу

У стартапа главный ограниченный ресурс это деньги до следующего раунда или до окупаемости. В марте 2026 года аналитическая компания CB Insights изучила 431 стартап с венчурными инвестициями, которые закрылись с 2023 года. Источники: публичные разборы, интервью основателей и объявления о закрытии. У 70% среди причин названа нехватка денег, у 43% продукт, который не совпал с потребностями рынка. У одного стартапа могло быть несколько причин, поэтому проценты в сумме больше ста. И это не статистика по всем стартапам: в выборку попали только компании с венчурными инвестициями, о закрытии которых есть публичные материалы. Авторы отчёта прямо пишут, что нехватка денег почти всегда финал истории, а корень в других причинах.

Системный аналитик спрос на продукт не найдёт, это работа основателя и тех, кто говорит с клиентами. Его работа влияет на другое: сколько денег уходит на то, чтобы сделать функцию и потом переделать её. Каждая неделя разработчиков, потраченная на переделку из-за неучтённого сценария, оплачивается из того же бюджета, что и поиск спроса.

Вторая причина: персональные данные. Если продукт хранит имена, телефоны или почты клиентов, закон о персональных данных (152-ФЗ, статья 22) требует до начала обработки уведомить Роскомнадзор. Исключения узкие, например обработка без компьютера. За неподачу уведомления организации грозит штраф от 100 до 300 тысяч рублей. За утечку данных от 1 до 10 тысяч человек при первом нарушении штраф организации от 3 до 5 миллионов рублей (статья 13.11 КоАП, части 10 и 12). Решение «какие данные собирать, где их хранить и кому показывать» как раз системная аналитика. Чем меньше лишних данных, тем меньше риск. Это ориентир, а не юридическая консультация: что именно нужно вашему продукту, проверьте с юристом.

Кто делает эту работу на разных стадиях

Стадия Кто делает Чего достаточно
Идея и прототип, 1-2 разработчика Основатель вместе с разработчиком Одна страница на функцию по шаблону ниже
Первые платящие клиенты, подключены оплата и 2-3 внешних сервиса Ведущий разработчик или аналитик на часть ставки по договору Шаблон плюс схема обмена с каждым внешним сервисом
Несколько команд, крупные клиенты требуют документацию, деньги и персональные данные клиентов Отдельный системный аналитик Требования, описание обмена данными, модель данных, сценарии сбоев

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

Признаки, что пора нанимать, и чем их проверить

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

  1. Разработчики много времени тратят на уточнения. Чем проверить: попросите команду неделю отмечать в трекере задач (программа, где ведутся задачи) время на созвоны и переписку «а как должно работать». Получившиеся часы понадобятся для расчёта окупаемости ниже.
  2. Готовые функции возвращаются на переделку. Чем проверить: заведите в трекере метку «переделка: не учли сценарий» и посчитайте такие задачи за месяц. Если такие задачи появляются каждый месяц, разберите две-три из них: какой сценарий не учли и можно ли было описать его до начала работы. Если причина в том, что сценарий никто не описал до начала работы, это та часть работы аналитика, которая у вас выпадает. Если причина другая, например поменялись требования клиента, к найму аналитика этот признак не относится.
  3. Внешних сервисов стало много. Оплата, доставка, CRM, маркетплейс, сервис рассылок. Чем проверить: нарисуйте на одном листе, какие сервисы с чем обмениваются данными. Если ни один человек в команде не может нарисовать эту схему без ошибок, её пора описать.
  4. Ошибки в деньгах и статусах. Оплата прошла, а заказ не создался, или клиенту списали дважды. Чем проверить: сверьте за месяц число успешных оплат в личном кабинете платёжного сервиса с числом оплаченных заказов в вашей базе. Любое расхождение стоит разобрать: оно может означать сбой в обмене данными между сервисами.
  5. Крупный клиент или партнёр просит документацию. Описание программного интерфейса (API, то есть правил, по которым ваша система обменивается данными с чужой), список хранимых данных, ответы на вопросы безопасности. Если команда отвечает на такой запрос неделями, проверьте, есть ли у кого-то время и навык готовить эти документы. Это одна из задач системного аналитика.
  6. Новый разработчик долго входит в работу. Если новичку нужен месяц расспросов, чтобы понять, как устроен продукт, это может значить, что устройство продукта нигде не описано.

Один признак ещё не повод нанимать. Два-три сразу, особенно четвёртый, хороший повод хотя бы посчитать.

Сколько это стоит и как посчитать окупаемость

По данным Хабр Карьеры за первое полугодие 2026 года, медианная зарплата системного аналитика 222 тысячи рублей в месяц: младшего 109 тысяч, среднего 200, старшего 303. Медианная зарплата бэкенд-разработчика (того, кто пишет серверную часть: логику, работу с базой данных, обмен с другими сервисами) 251 тысяча рублей. Обе цифры из исследований одной площадки и по всем отраслям. Реальные расходы компании выше на налоги и страховые взносы, ставка зависит от статуса компании, точную сумму даст бухгалтер.

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

Условный пример на медианных зарплатах, доля потерь здесь допущение, подставьте свою из проверки выше:

  • 3 бэкенд-разработчика, потери 15% времени. 3 × 251 тысяча × 0,15 ≈ 113 тысяч рублей в месяц. Это меньше зарплаты аналитика среднего уровня. По часам разработчиков штатный аналитик здесь не окупится, разумнее шаблон ниже или аналитик на часть ставки по договору.
  • 6 бэкенд-разработчиков, те же 15%. 6 × 251 тысяча × 0,15 ≈ 226 тысяч рублей в месяц. Но это все потери, а аналитик снимет только часть. Если он снимет половину, польза ≈ 113 тысяч, и это снова меньше его зарплаты, даже без налогов и взносов.

Сколько нужно разработчиков при тех же допущениях (потери 15%, аналитик снимает половину): польза с одного разработчика 251 тысяча × 0,15 × 0,5 ≈ 19 тысяч рублей в месяц. Чтобы перекрыть хотя бы зарплату среднего аналитика в 200 тысяч, без налогов и взносов, нужно от 11 разработчиков.

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

Как понять, что вложение работает: через два-три месяца после найма повторите обе проверки из предыдущего раздела, время на уточнения и число переделок. Снижение не докажет, что дело именно в аналитике, но если цифры не снизились совсем, разберитесь, читает ли команда то, что пишет аналитик, и успевает ли он описать задачу до того, как её начали делать. Если и после этого ничего не меняется, найм стоит пересмотреть.

Как начать без отдельного аналитика

Перед тем как разработчик берёт новую функцию, основатель и ведущий разработчик заполняют одну страницу из пяти пунктов.

  1. Зачем. Кто пользуется функцией и какую задачу она решает, одной-двумя фразами.
  2. Данные. Что функция хранит и откуда берёт. Есть ли среди этого персональные данные, и можно ли без них обойтись.
  3. Обмен. С какими внешними сервисами функция обменивается данными и что именно передаёт. Принцип: не передавать в чужой сервис поле, без которого он обходится.
  4. Сбои. Что будет, если внешний сервис не ответил; если клиент нажал кнопку дважды; если оплата прошла, а наша система упала. Для каждого случая: что видит клиент и кто в команде узнаёт о проблеме.
  5. Готовность. Три-пять проверок, после которых функцию можно выпускать. Например: «при повторном нажатии второй заказ не создаётся».

Чем проверить, что шаблон работает: сравните за месяц два числа. Первое: сколько часов команда тратит на заполнение страниц. Второе: сколько часов ушло на задачи с меткой «переделка: не учли сценарий» до начала работы с шаблоном и после. Если часы на переделки сократились больше, чем ушло на шаблон, это довод его оставить, но не доказательство. На число переделок влияет и другое, например новый человек в команде или крупный выпуск, а час ведущего разработчика стоит дороже часа младшего, поэтому для точности переведите часы в деньги по ставке каждого и смотрите на два-три месяца. Если разницы нет, упростите шаблон или откажитесь от него.

Черновик такой страницы можно попросить у нейросети: опишите функцию и попросите перечислить, что может пойти не так. Нейросеть может пропустить важное или придумать лишнее, поэтому решение по каждому пункту принимает человек из команды. Персональные данные клиентов и закрытые договорённости в общедоступный чат-бот не вставляйте.

Как проверить кандидата и когда аналитик не поможет

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

Если нужен человек на часть ставки, договаривайтесь о результате, а не о часах: например, описание обмена с платёжным сервисом и сценарии сбоев к определённой дате.

Когда аналитик не поможет:

  • спроса на продукт ещё нет. Аналитик опишет устройство продукта, который никому не нужен, а это лишние расходы из того же бюджета;
  • в команде один-два разработчика, основатель каждый день рядом и может ответить на любой вопрос за пять минут. Здесь хватит шаблона;
  • аналитика нанимают, чтобы он «написал документацию», а команда продолжает решать всё в созвонах. Документы, которые никто не читает, потери не снижают.

Итог

Системная аналитика в стартапе начинается с ответа на четыре вопроса по каждой функции: какие данные, с кем обмен, что при сбое и как понять, что готово. На старте на них отвечают основатель и ведущий разработчик по одной странице на функцию. Отдельный аналитик имеет смысл, когда потери, которые он снимет, по деньгам больше его полной стоимости для компании. По медианным зарплатам и допущениям из примера одни часы разработчиков перекрывают зарплату среднего аналитика только от 11 разработчиков. Поэтому в маленькой команде доводом за найм становятся деньги клиентов, требования партнёров и персональные данные, и их стоит посчитать по своим цифрам. Начните с двух проверок в трекере, они помогут понять, где вы сейчас.

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

Я занимаюсь системной аналитикой, ИИ-агентами и автоматизацией. Если хотите посмотреть мои проекты или обсудить свою задачу, загляните в портфолио.

Источники