Системный аналитик (Senior System Analyst) (удаленная работа)

Вакансия: Системный аналитик (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 вместо устных постановок.

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

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

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