Системный аналитик (Senior System Analyst)

О роли

Twinby — один из крупнейших российских дейтинг-сервисов с миллионами пользователей: реалтайм (лента, матчи, чаты), деньги (подписки, покупки), антифрод и модерация. Мы перестраиваем разработку Twinby CIS и собираем продуктовые команды практически с нуля. Ищем сильного системного аналитика — это кросс-командная функция и мост между продуктом, бэкендом и аналитикой.

Это инженерная роль, а не «оформление хотелок в тикеты». Ты владеешь требованиями и контрактами целиком: достраиваешь то, что недодали в постановке, проектируешь, как сервисы договариваются друг с другом, и держишь спеку, по которой команда уверенно пишет код, тесты и приёмку. У нас спека — закон и единый источник правды: код, тесты и приёмка идут именно по ней.

Чем предстоит заниматься

• Достраивать требования там, где их недодали: ловить пробелы, противоречия и edge-cases до того, как они доедут до прода — это и есть основная ценность роли.

• Проектировать API-контракты (REST/OpenAPI, gRPC) и интеграции между сервисами: поля, коды ошибок, идемпотентность, лимиты, обратная совместимость со старыми клиентами.

• Строить модель домена и жизненные циклы сущностей (матч, лайк, подписка, платёж): состояния, инварианты, запрещённые переходы — чтобы система не оказывалась в невозможном состоянии.

• Держать спеку-закон в Confluence: оформлять требования и сценарии так, чтобы бэкенд, QE и аналитика читали один и тот же источник истины, а спека была пригодна для DoR/DoD.

• Работать с моделью данных (PostgreSQL): читать и проектировать схемы, видеть, где контракт расходится с данными, проверять гипотезы SQL — а не на словах.

• Спорить по существу с бэкендом и продуктом: отстаивать решение по контракту и модели, а не фиксировать чужое.

Что мы ждём

• Умеешь проектировать контракт, а не только описывать фичу: торгуешься про требования (что обязательно, что при повторе, какие коды ошибок — 200 vs 409 vs 4xx), мыслишь идемпотентностью, лимитами и версионированием.

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

• Читаешь чужую схему и контракт как родной текст: OpenAPI/Swagger, DDL, модель данных — замечаешь nullable, который сломает джойн, и поле в ответе, которого нет в модели.

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

• Различаешь «требование бизнеса» и «как мы это технически реализуем», и аргументируешь решения по модели, а не оформляешь их по диктовку.

• Опыт в домене со сложными интеграциями, где ошибка в контракте стоит дорого, — финтех, биллинг, госинтеграции, сложный e-com.

Будет плюсом

• Опыт проектирования событийных и асинхронных интеграций (очереди, outbox/saga), а не только синхронных вызовов.

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

• Знакомство с дейтингом или другим реалтайм-продуктом с деньгами — приятный бонус, но не обязателен.

Чего НЕ требуем

Знания нотаций наизусть (BPMN/UML/IDEF) и «правильности» диаграмм, заученных шаблонов ТЗ и методологий, идеального оформления именно в нашем инструменте, знания именно домена дейтинга. Нам важнее системное мышление и инстинкт на контракты и противоречия — стек и предметную область добираешь по ходу.

Окружение и инструменты

Требования и спеки, контракты REST/OpenAPI и gRPC, интеграции между сервисами, модели данных в PostgreSQL. Документация и спека-закон — в Confluence, задачи — в Jira; диаграммы (UML, sequence) — как инструмент, а не самоцель; SQL — чтобы проверять гипотезы по данным. Бэкенд, с которым работаешь, — монолит на Django и Go-сервисы; инфраструктура — российское облако (Yandex Cloud).

Что предлагаем

• Владение моделью домена и контрактами — ты проектируешь, как устроены интеграции, а не переписываешь чужие постановки в тикеты.

• Настоящая инженерная система, а не лозунги: спека-закон как единый источник правды, OpenAPI как контракт, замкнутый цикл доставки и DoR/DoD вместо устных постановок.

• Влияние с нуля: команды собираются заново, контракты и модель домена ещё не застыли — ты задаёшь, как они будут устроены.

• Прямой контакт с бэкендом, продуктом и аналитикой; масштаб и реалтайм, где цена ошибки в контракте высока.

• Формат: удалёнка, РФ.