Для решения этих проблем запущена программа повышения надёжности биллинга. Она включает выделение единого API, постепенный переход к микросервисной архитектуре, разделение транзакционной и аналитической нагрузки, развитие событийной модели и повышение качества выпуска изменений.

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

Главная задача роли

Обеспечить управляемую техническую модернизацию биллинга без потери устойчивости текущих бизнес-процессов.

Необходимо соединить в единый план архитектуру, разработку, базы данных, инфраструктуру, тестирование и потребности бизнеса:

определить приоритетные проблемы → сформировать технический план → распределить ответственность между командами → управлять зависимостями и рисками → обеспечить поставку изменений → подтвердить эффект через технические и бизнес-показатели.

Это не роль администратора задач и не классическое сопровождение готового плана. Technical Delivery Manager будет участвовать в формировании программы, влиять на порядок архитектурных изменений и отвечать за достижение результата несколькими командами.

Основные направления программы

Единый API биллинга

• Создание единой управляемой точки доступа к функциям биллинга.
• Перевод внутренних потребителей с прямого обращения к базе данных на API.
• Внедрение ограничения частоты запросов и управления нагрузкой.
• Применение механизмов защиты от каскадных сбоев.
• Централизация авторизации, аудита и мониторинга запросов.
• Повышение прозрачности нагрузки в разрезе каждого потребителя.

Выделение сервисов и доменных границ

• Постепенный вынос бизнес-логики из монолитной базы данных.
• Выделение сервисов для клиентских данных, продуктов, тарификации, выставления счетов и аналитики.
• Снижение связанности приложений и команд.
• Создание возможности независимой разработки, тестирования и выпуска изменений.
• Формирование понятных контрактов между сервисами.

Разделение транзакционной и аналитической нагрузки

• Вынос тяжёлой отчётности и аналитических запросов из основной транзакционной базы.
• Формирование отдельного контура для отчётов, статистики и работы с CDR.
• Использование CDC и событийной передачи данных.
• Переход к публикации изменений через Kafka или аналогичные механизмы.
• Снижение риска влияния аналитических операций на горячий биллинг.

Повышение надёжности релизов

• Создание предпроизводственной среды, сопоставимой с промышленной.
• Развитие нагрузочного и интеграционного тестирования.
• Организация независимых выпусков выделенных сервисов.
• Развитие CI/CD.
• Постепенное внедрение функциональных переключателей и поэтапных выпусков.
• Снижение риска распространения ошибки сразу на всех клиентов.

Производительность и масштабируемость

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

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

Управлять технической программой

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

Обеспечивать поставку результата

• Организовывать работу нескольких технических команд.
• Согласовывать планы архитекторов, разработчиков, аналитиков, специалистов по базам данных, тестированию и инфраструктуре.
• Следить за готовностью задач к разработке.
• Контролировать прохождение работ от архитектурного решения до промышленного запуска.
• Управлять блокирующими зависимостями.
• Своевременно поднимать проблемы, по которым требуется управленческое решение.
• Добиваться завершения этапов, а не только движения отдельных задач.

Работать с архитектурой и техническими рисками

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

Повышать предсказуемость разработки

• Настроить прозрачный процесс планирования и контроля исполнения.
• Формировать общий список задач программы и планы отдельных команд.
• Отслеживать сроки, прогресс, риски и зависимости.
• Выстраивать регулярный цикл технических и управленческих обзоров.
• Контролировать качество декомпозиции и готовность задач.
• Анализировать причины отклонений и устранять системные проблемы в процессе разработки.
• Работать с Jira, YouTrack или аналогичными системами.

Управлять релизами и изменениями

• Координировать выпуск изменений в критической системе.
• Обеспечивать готовность тестовых и предпроизводственных сред.
• Контролировать наличие планов переключения и возврата.
• Согласовывать порядок миграции потребителей на новые API и сервисы.
• Организовывать поэтапное развертывание изменений.
• Учитывать влияние релизов на крупных клиентов и критические бизнес-операции.
• Обеспечивать разбор технических проблем после выпуска и включение выводов в дальнейший план.

Подтверждать эффект

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

Technical Delivery Manager отвечает за то, чтобы техническая программа давала измеримый результат, а не ограничивалась созданием новых компонентов.

Кого мы ищем

• Опыт работы в роли Technical Project Manager, Technical Program Manager или Delivery Manager от шести лет.
• Опыт управления сложными техническими программами с участием нескольких команд.
• Понимание микросервисной архитектуры и принципов разделения монолитных систем.
• Знание процессов CI/CD.
• Понимание контейнеризации и оркестрации: Docker, Kubernetes.
• Опыт работы с Jira, YouTrack или аналогичными системами.
• Умение строить дорожные карты, планы реализации и управлять межкомандными зависимостями.
• Опыт управления рисками в критических или высоконагруженных системах.
• Способность разбираться в технической проблеме глуже уровня статуса задачи.
• Умение говорить на одном языке с архитекторами, разработчиками, специалистами по базам данных и инфраструктуре.
• Навык переводить архитектурные решения в последовательный и реалистичный план реализации.
• Умение работать в условиях, когда модернизация идёт параллельно с развитием и эксплуатацией действующей системы.
• Самостоятельность, настойчивость и ориентация на завершение результата.

Будет плюсом

• Опыт миграции бизнес-логики и хранимых процедур из базы данных в отдельные сервисы.
• Опыт декомпозиции монолитных систем.
• Понимание особенностей OLTP- и OLAP-нагрузки.
• Опыт работы с CDC, Debezium или аналогичными технологиями.
• Понимание очередей сообщений: Kafka, RabbitMQ.
• Понимание событийной архитектуры.
• Знание принципов транзакций в распределённых системах.
• Понимание согласованности данных, идемпотентности и повторной обработки событий.
• Опыт организации нагрузочного тестирования.
• Опыт создания предпроизводственных сред.
• Опыт поэтапных или канареечных выпусков и функциональных переключателей.
• Опыт работы с API Gateway, ограничением частоты запросов и защитой от каскадных сбоев.
• Опыт в биллинге, телекоме, финтехе или других критических системах с высокой транзакционной нагрузкой.
• Опыт разработки, системной инженерии или технической архитектуры в прошлом.

Формат работы

• Полная занятость.
• Формат работы обсуждается индивидуально.

Этапы отбора

1. Отклик и короткое сопроводительное письмо.
2. Первичное интервью.
3. Встреча с руководителем направления.
4. Техническая встреча с архитекторами и представителями разработки.
5. Разбор практического примера управления сложной технической программой.
6. Финальная встреча.
7. Предложение о работе.

Ждем откликов в tg @AlinaKharchenkoHR