Переносить знания, проверять экономику решения
Начало карьеры Фёдора связано с МИФИ и стажировкой в CBOSS. После задачи на разбор формул он занялся интеграцией биллинговых систем, а затем поехал внедрять решение у зарубежных операторов. Командировка в Индонезию превратила абстрактный код в работающий бизнес: рядом были операторы кол-центра, серверная и финансисты, которым нужны отчёты. Стало видно, кому именно помогает программа. Следующий урок оказался управленческим: создавая технический центр во Вьетнаме, Фёдор нанимал людей и передавал им продукты на поддержку. Его представление о мотивации не совпало с предпочтениями команды: за круглосуточную доступность сотрудники уверенно выбирали прибавку к зарплате, хотя он ожидал интереса к дополнительному отпуску. Уже внутри телекома перенос опыта требовал понимать людей и условия работы. Позднее этот принцип повторялся при каждом переходе: полезен накопленный способ разбираться в задаче, но знакомая среда не даёт готового ответа за другую компанию.
В Orange он пришёл в 2010 году и столкнулся с маленькой командой и большим потоком пожеланий внутренних заказчиков. Собрав их в общий список, показал руководству сроки при текущем составе и варианты с дополнительными разработчиками; компания согласовала две ставки. Следующей проблемой стал биллинг, который мешал запускать новые продукты. Первым порывом было купить знакомое решение, но расчёт стоимости изменил выбор: команда перестроила собственную систему. Одновременно появились контроль версий, Jira и ограничения на прямую работу разработчиков в производственной среде. Проект занял около девяти месяцев и открыл путь новым предложениям бизнеса. Здесь переносилась экспертиза в расчётных системах и организации разработки, а масштаб решения определяла экономика заказчика. Следующий опыт в OTC.ru добавил рост: от двух разработчиков, двух тестировщиков и внешней команды до собственного технического подразделения более чем из пятидесяти человек.
Готовность автомобиля зависит от совместной работы систем
В Arrival Фёдор пришёл на позицию Head of Solutions: архитекторы с автомобильным опытом, команда управляющего ПО и интеграционные тестировщики. Часть инженеров прежде занималась турбинами, авиацией или другими физическими системами; модели в MATLAB Simulink становились прошивками для собственного оборудования компании. Температура, вибрация и электромагнитные помехи здесь влияли на результат напрямую. Задача руководителя состояла в том, чтобы связать специалистов и обеспечить согласованную работу автомобиля. Единицей планирования сделали функцию продукта, обычно затрагивающую несколько систем. Для неё предусмотрели уровни готовности: альфа давала работающий прототип и знания о взаимодействии с оборудованием; на бете подключали тестирование с ещё достаточно мягкими ограничениями по дефектам; гамма означала готовность к эксплуатации с более строгими требованиями к качеству. Так интеграция происходила уже в ранней итерации, а затем команда повышала качество. Прототип не объявлялся готовым продуктом, но позволял проверить совместную работу раньше, чем все участники закончат собственные части.
Требования связали в четыре уровня: бизнес, функция, система, компонент. Входом служили и коммерческие пожелания, и регуляторные ограничения; понять последние помогали описания приёмочных испытаний. Для групп функций появились ответственные руководители, координирующие работу разных специалистов. С ростом технического подразделения более чем до 650 человек возможностей Confluence с плагином стало недостаточно, и команда внедрила Polarion. Фёдор особенно выделяет пометки связей после изменения требования: они показывают, где нужно заново проверить тесты, нижележащие требования или соответствие исходному ограничению. Общий план релизов открыли смежным командам в Jira. Если поставщик задерживал компонент, зависимую функцию переносили, а освободившихся людей переключали на другую задачу с понятным всем изменением плана. Когда приоритет смещался с автобуса на фургон, помогало разделение драйверов конкретного оборудования и общей управляющей логики. Однако инженерная согласованность не обеспечила бизнесу выживание: по рассказу Фёдора, Arrival не хватило финансирования до выхода в производство, а смены приоритетов распыляли ресурсы.
В страховании сначала договориться, что считать продуктом
В QIC Digital Hub Фёдор работал Head of Technology с апреля 2025-го по июль 2026-го. Страхование принесло новые предметные знания, но знакомую сложность интеграций и регуляторных требований. Подход к их разбору сохранили, сократив иерархию до трёх уровней: отдельный уровень компонентов здесь не понадобился. Более трудной оказалась договорённость о продуктах и ответственности. Под одним словом команды понимали систему наблюдения за сервисами, переезд в Google Cloud и мобильное приложение. Вместе с руководителем аналитики Фёдор несколько месяцев уточнял определения и раскладывал объекты по уровням. Общие критерии понадобились для решений о создании и объединении продуктов, а также для назначения владельцев систем. При разборе обнаружились старые разработки без ответственной команды: безопасность указывала на уязвимости, но устранять их было некому. Работа со словарём тем самым решала вполне операционную задачу — делала видимыми обязанности, которые потерялись во время роста.
Главный технический проект касался зависимости от старого монолита, который развивала другая компания внутри группы. Изменения приходилось ждать дольше, чем позволяли задачи продаж. Поэтому часто меняющуюся часть страхового ядра — расчёт стоимости полиса, формирование документа и проверки — решили выделить в собственные сервисы на Go, сохранив необходимую интеграцию. Фёдор подчёркивает, что выбор микросервисов был оправдан этой ситуацией; универсального рецепта он из неё не делает. Параллельно шёл переход в Google Cloud, включая коммерческие переговоры. Разговор возвращается и к назначению привычных практик: проверка кода может искать ошибки, передавать знания или поддерживать единообразие, поэтому сначала нужно назвать её цель. Завершение работы в QIC также напоминает о внешних ограничениях: Фёдор связывает сокращение бюджета и остановку части проектов с ухудшением бизнес-ситуации. Даже осмысленная техническая трансформация остаётся зависимой от рынка и решений компании.
Что стоит унести с собой
- 01Экспертиза помогает выбирать, а не копировать прошлое решение. В Orange знание биллинга привело к перестройке собственной системы после сравнения затрат на покупку и разработку.
- 02Планировать сложный продукт полезно через функции, объединяющие несколько систем. Ранний совместный прототип выявляет проблемы интеграции, а явные уровни готовности отделяют эксперимент от результата для эксплуатации.
- 03Связи между бизнес-требованиями, реализацией и тестами нужны особенно при изменениях. Инструмент может подсветить затронутые зависимости, но проверить согласованность должны ответственные специалисты.
- 04Перенос процесса требует менять его глубину и договариваться о терминах. В QIC хватило трёх уровней требований, а определение продукта помогло найти системы без владельцев.
Источники
- Субтитры записи
- Запись выпуска