Системный аналитик (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 вместо устных постановок. Влияние с нуля: команды собираются заново, контракты и модель домена ещё не застыли — ты задаёшь, как они будут устроены. Прямой контакт с бэкендом, продуктом и аналитикой; масштаб и реалтайм, где цена ошибки в контракте высока. Формат: удалёнка, РФ.