Как создать сильную команду разработки: опыт CDO Sergek Group Ивана Божитова

Иван Божитов, город — Астана, CDO Sergek Group, Linkedin

О компании и роли

В компании Sergek Group выстроена функционально-матричная структура по модели Spotify. Технический блок разделен одновременно в двух плоскостях: вертикальная плоскость — продуктовые команды разработки, каждая из которых вовлечена в разработку конкретного продукта или домена в портфеле компании. Таких команд шесть. Горизонтальная плоскость — чаптеры, объединяющие специалистов по функциональным направлениям и областям компетенций. Среди них DevOps Chapter, Backend Chapter, Frontend Chapter, QA Chapter, System Analysis Chapter, Data Analysis Chapter, CV Chapter и Transport Analysis Chapter.

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

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

Сегодня Sergek Group фокусируется на технологиях, которые делают продукты умнее и удобнее для пользователей. Наши решения учатся, предсказывают и помогают, используя современные методы анализа данных и AI. DevOps обеспечивает стабильность и предсказуемость процессов, а R&D позволяет исследовать, оптимизировать и создавать новые аппаратные и программные системы, делая обработку данных быстрее, точнее и ценнее для пользователей. Все это помогает нам превращать технологии в ощутимую ценность.

О вызовах и инновациях

Сейчас наш главный вызов — постоянно растущая сложность, которая проявляется на нескольких уровнях. Первый уровень — данные: их объем растет, они поступают из разных источников, в разных форматах и в реальном времени. Задача Sergek Group — не просто собирать эти данные, а быстро интерпретировать, очищать и использовать для построения точных и эффективных моделей.

Сегодня наш главный вызов — постоянно растущая сложность, которая проявляется на нескольких уровнях. Сначала — данные: их объем растет, они поступают из разных источников, в разных форматах и при этом, как правило, в реальном времени. Задача команды разработки Sergek — не только собирать эти данные, но и быстро их интерпретировать, очищать, обогащать их и использовать для построения точных и устойчивых моделей.

Далее — сценарии. Они становятся все более многослойными: от дорожной и общественной безопасности до эко-метеодатчиков, дронов и Big Data. Модели и подходы должны работать стабильно в любых условиях, при этом улучшение точности моделей требует постоянной работы команд над оптимизацией и внедрении новых решений.

Третий уровень — инфраструктура. Система должна выдерживать нагрузку, сохранять стабильность и при этом позволять быстро внедрять новые решения, несмотря на распределенность систем и их масштаб.

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

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

Когда появляется продуктовая гипотеза, например новый сценарий в компьютерном зрении, мы сначала проверяем ее с готовой open-source моделью. Такие модели удобны для быстрого теста, но редко подходят напрямую: они зачастую создаются лишь отдаленно схожих задач, других типов данных или принципиально иных условий эксплуатации. Использование таких моделей помогает понять, стоит ли дальше развивать гипотезу.

Если идея подтверждается — для решения поставленной задачи мы создаем отдельный функционал, но уже на базе нашей собственной инфраструктуры. Иными словами — сначала мы оцениваем целесообразность, только затем — формируем технологическую основу и внедряем решение. 

Если же речь идет о продуктовых гипотезах в других областях, например о создании принципиально нового раздела в продукте — на первый план выходят кликабельные макеты в Figma, классические кастдевы и поэтапное внедрение нового функционала. Такой подход позволяет проверять идеи быстро и минимизировать риски при расширении продукта.

В ближайшие три-пять лет рынок будут определять несколько ключевых трендов. Во-первых, развитие AI и машинного обучения, особенно в обработке потоковых данных и компьютерном зрении.

Во-вторых, распространение интеллектуальных и автономных систем в городской инфраструктуре — создание «умных городов» с интеграцией всевозможных сенсоров и аналитикой в реальном времени.

В-третьих, команды все активнее вовлекаются в R&D. Это уже не отдельная лаборатория, а часть ежедневной работы: инженеры и продуктовые команды тестируют новые решения, превращают эксперименты в улучшения и быстро проверяют гипотезы. Особенно важно это при работе с аппаратными системами и сложной инфраструктурой, где каждая инновация напрямую влияет на точность и эффективность продуктов. Такой подход помогает накапливать экспертизу и интегрировать новые идеи прямо в продуктовые решения.

О команде и культуре

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

Мы ценим сотрудников, которые делятся знаниями, предлагают улучшения и постоянно учатся. Чтобы облегчить обмен опытом, мы используем принципы модели Spotify.

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

Собрать сильную команду гораздо сложнее, чем построить технологию. Найти людей, которые мыслят системно, работают вместе и постоянно улучшают процессы, гораздо труднее, чем реализовать технологическое решение. Мы гордимся нашей командой разработчиков, инженеров DevOps, QA, специалистов по CV и ML, аналитиков и R&D инженеров.

О пути и лидерстве

Я пришел в профессию из интереса к сложным системам и механизмам в целом. До Sergek Group занимался проектной разработкой, а в компанию пришел project-менеджером с техническим бэкграундом, но без опыта в продуктовой разработке.

Со временем направления в компании разделили на delivery, project- и product-менеджмент. Я стал delivery-менеджером, отвечая за процессы и координацию одной из команд разработки.

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

Наибольшую пользу мне дал опыт работы в команде разработки и погружения в процессы других продуктовых команд. Когда компания решила внедрить модель Spotify и распространить практику delivery management на другие продуктовые команды, у меня уже был необходимый контекст, чтобы занять позицию Head of Delivery и помочь выстроить матричную схему как единую систему.

Я поддерживал команды, участвовал в формировании структуры и стремился видеть систему целиком, а не только свою зону ответственности. Широкий взгляд, инициативность и понимание процессов разных команд позволили мне сначала стать руководителем, а затем — CDO.

Также работая на позициях delivery-менеджера и Head of Delivery, я осознал специфику компании, ее локальные и глобальные цели. Благодаря этому мог принимать и предлагать решения, которые помогали развивать процессы, закрывать пробелы, повышать эффективность и упрощать работу там, где это было возможно. Пожалуй, именно этот опыт и стал основой для перехода на позицию CDO.

Совет молодым специалистам: не бойтесь изменений и ответственности. Беритесь за задачи, которые кажутся «не по плечу». Ошибки не страшны — более того, они неизбежны: ошибается только тот, кто ничего не делает. Опыт, полученный в сложных задачах, ценнее того, который дает рутина. Пробуя разные подходы и находя решения, мы действительно растем профессионально.

О будущем и видении

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

Но главное для CDO — быть менеджером, который объединяет команды и создает условия, чтобы новые решения работали и приносили результат, который можно измерить по внутренним метрикам.

Сильная технологическая компания это не только продукт и технологии, но и команда, которая мыслит системно, адаптируется к новым задачам и вместе находит лучшие решения. Сильная технологическая компания объединяет экспертизу из разных областей: от AI и инфраструктуры до внутренних процессов, и делает это качественно. За технологиями всегда стоят люди — те, кто их создает, и те, для кого они создаются.