Введение

ГОСТ Р 54869–2011 даёт проекту следующее определение: «комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений» [1]. Формулировка эта сложилась в отраслях, где результат осязаем, будь то здание, станок или внедрённая учётная система; его предъявляют заказчику, подписывают акт и ставят на баланс. Попробуем приложить ту же мерку к новой функции мобильного приложения с аудиторией в десятки миллионов человек, и сразу возникнет вопрос, что считать её завершением. Через неделю после выпуска функцию могут переделать, через месяц убрать вовсе, если ею никто не пользуется.

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

Не стоит упускать из виду и размеры бизнеса. В пресс-релизе компании указано, что «выручка VK за 2024 год увеличилась на 23 % по сравнению с 2023 годом до 147,6 млрд руб». [10]. Из этой суммы 96,1 млрд руб. дала онлайн-реклама (около 65 %), сегмент «Социальные платформы и медиаконтент» принёс 104,3 млрд руб. [10]. Дневная аудитория сервисов в среднем достигала 77 млн человек, которые вместе проводили в них порядка 4,4 млрд минут в сутки [10]. Разделив одно на другое, получаем около 57 минут на активного пользователя в день. Понятно, что при таких величинах неудачное продуктовое решение почти сразу отражается на количестве рекламных показов, а через него и на выручке.

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

Чем проект развития продукта отличается от классического

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

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

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

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

Продуктовая команда и распределение ролей

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

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

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

Иной стала и роль аналитика. Если раньше он готовил отчёты по запросу руководства, то в продуктовой команде участвует в выработке решений: строит воронки, выделяет сегменты аудитории, проектирует эксперименты и зачастую первым замечает падение удержания после очередного релиза. Д. А. Отрешко связывает повышение эффективности командной разработки в том числе с применением аналитических и интеллектуальных инструментов [6]. Практический вывод из этого достаточно прост: подключать аналитика имеет смысл на этапе формулировки гипотезы, пока исправление ошибки стоит дёшево.

Планирование и измерение результатов

Методологической опорой продуктовых команд служат гибкие подходы. В манифесте гибкой разработки этот принцип выражен формулой «Готовность к изменениям важнее следования первоначальному плану» [9]. И. А. Зайцева, У. Ш. Эбата и Н. А. Ковбаса, изучив практику российских компаний, приходят к выводу, что «методология Agile и входящий в нее фреймворк Scrum позволяют более продуктивно управлять ИТ-проектами» [4, с. 62].

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

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

Продуктовую инициативу удобно описывать через цель, метрику и гипотезу. Цель объясняет, зачем нужна работа, метрика задаёт показатель для оценки результата, гипотеза фиксирует ожидаемую величину изменения и срок. Например, сокращение регистрации с трёх шагов до одного за квартал увеличит на 2–3 процентных пункта долю новых пользователей, вернувшихся в сервис на седьмой день.

Набор базовых метрик в социальных сервисах сложился давно. Масштаб оценивают дневной (DAU) и месячной (MAU) аудиторией, отношение DAU к MAU характеризует регулярность использования. Удержание показывает, какая доля новичков возвращается через день, неделю, месяц. Вовлечённость измеряют временем в продукте и глубиной просмотра, средний доход на пользователя (ARPU) связывает эти величины с выручкой. При этом каждую метрику легко истолковать неверно. Время в продукте, к примеру, растёт и тогда, когда пользователь просто дольше ищет нужную кнопку.

Другая распространённая проблема — избыток показателей. На панели с несколькими десятками графиков почти всегда что-то растёт, а что-то падает, и выбрать по ней направление работы затруднительно. А. Г. Шаврей подчёркивает, что «метрики должны интерпретироваться в контексте рынка» [8]. Мы бы дополнили это требование учётом сезонности и сопоставлением с аналогичными сегментами: без них абсолютное значение показателя мало о чём говорит.

Проверяют гипотезы обычно в A/B-тестах. Функцию включают случайно отобранной части аудитории, затем сравнивают тестовую и контрольную группы и оценивают статистическую значимость различий. Процедура в литературе описана подробно, трудности возникают с её соблюдением. Тест, рассчитанный на две недели, останавливают на четвёртый день, потому что график пошёл вверх; целевую метрику выбирают задним числом; неудобный итог списывают на «шум». В таких случаях эксперимент лишь оформляет решение, принятое заранее.

Не лучше обстоит дело с оценкой трудоёмкости. Разработчики систематически называют сроки меньше фактических, особенно если задача затрагивает код соседней команды. Повысить точность помогают сравнение с похожими задачами прошлых итераций, резерв времени на интеграцию, дробление задачи на части длительностью до недели. Давление сверху, наоборот, приучает команду называть те сроки, которые хочет услышать руководитель.

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

Портфель инициатив и риски экосистемы

Экосистемная специфика тесно связана с платформенной природой бизнеса. По наблюдению Е. В. Васильевой, при переходе от дизайна отдельного продукта к проектированию платформы меняется сама постановка задачи, поскольку ценность рождается во взаимодействии участников среды [3, с. 78]. Применительно к ВКонтакте речь идёт о том, что единая учётная запись, мини-приложения, рекламный кабинет и платёжные механизмы вместе дают эффект больший, нежели каждый по отдельности. Но за связанность приходится платить. Стоит поменять механизм входа, и изменения коснутся всех сервисов, которые им пользуются; работы по совместимости и переносу данных поэтому закладываются в план заранее, ведь обнаруженные посреди проекта, они неминуемо отодвигают сроки.

Траекторию, общую для отечественных цифровых экосистем, описывают М. А. Мамедов и Т. Ф. Мамедов: технологическая либо телекоммуникационная компания обрастает вокруг основного сервиса смежными направлениями, стараясь удержать пользователя у себя [5]. Отсюда для руководителя проекта следует, что регулирование становится такой же частью проектной среды, как и технологии.

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

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

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

Риски экосистемных проектов мы предлагаем объединить в четыре группы. Первая группа — каннибализация трафика. Новая функция собирает пользователей, пришедших из соседнего сервиса той же компании, показатели продукта растут, а общий итог остаётся прежним. Вторая группа — зависимость от рекомендательной выдачи; одна-единственная правка алгоритма способна за считанные дни перечеркнуть прирост, на который у команды ушли месяцы.

Третья группа касается персональных данных, под которыми закон понимает «любую информацию, относящуюся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных)» [2, ст. 3]. Социальный сервис так или иначе оперирует именно такой информацией, от списка друзей до истории просмотров, и неаккуратное обращение с ней грозит как юридическими, так и репутационными последствиями. В. В. Филатов с соавторами, анализируя корпоративное управление ООО «ВКонтакте», указывают, что проблемы компании неоднократно возникали как раз вокруг авторских прав, защиты данных и устойчивости работы сервиса [7].

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

Пример: развитие «VK Видео» в 2024 году

Обратимся к практике на примере видеоплатформы компании, которая официально называется «VK Видео». Из отчётности видно, что в 2024 году сервис двигался сразу в нескольких направлениях: дорабатывались рекомендации, на платформу привлекали авторов, производился собственный контент, появились приложения для телевизоров. Новых авторов за год пришло более 42 тыс., установок приложения набралось более 60 млн [10]. Ещё быстрее рос формат коротких видео, где среднесуточные просмотры VK Клипов прибавили 144 % и вышли на уровень 3 млрд [10].

Связующим показателем для всех направлений было время просмотра. По сообщению компании, к концу 2024 года совокупное время, проводимое зрителями в «VK Видео» за сутки, выросло в 4,5 раза к тому же периоду 2023 года, а время во всех сервисах VK увеличилось в среднем на 29,4 % [10]. Акта приёмки, который подвёл бы черту под работой, у такого проекта не существовало: каждое направление продолжало развиваться.

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

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

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

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

Координация десятков команд требует общей инструментальной среды, которая включает систему учёта задач, базу знаний, автоматическую сборку кода и график дежурств. Д. А. Отрешко отмечает, что интеллектуальные технологии всё шире используются для прогнозирования сроков, выявления рисков, частичной автоматизации тестирования [6]. Алгоритм способен предупредить о вероятной задержке, однако решать, что с ней делать (сокращать объём, просить людей у соседей или переносить срок), по-прежнему приходится руководителю. Заметную долю ресурсов поглощают и коммуникации. Их удешевляют письменная фиксация договорённостей, один ответственный за каждое решение, короткие еженедельные встречи вместо длинных совещаний и журнал принятых решений, который особенно выручает при смене состава команды.

Заключение

По результатам анализа руководителям проектов развития цифровых продуктов в экосистеме можно рекомендовать следующее. Проект стоит начинать с цели и показателя, по которому будет видно, достигнута ли она; если измеримой формулировки найти не удаётся, разумно задуматься, нужен ли проект в принципе. Команду имеет смысл собирать под результат, с обязательным участием владельца продукта и аналитика. Процесс подбирается под характер работ: гипотезы проверяют итерациями, поддержку ведут отдельной очередью, под технический долг выделяют фиксированную долю ресурсов. На квартал хватает одной основной метрики и двух-трёх вспомогательных. Зависимости от смежных команд выясняют до старта, ведь месяц в чужой очереди обходится дороже любых предварительных переговоров. Экосистемные риски (каннибализация, изменения выдачи, обработка персональных данных) вносят в реестр рисков проекта с самого начала.

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

Литература:

1. ГОСТ Р 54869–2011. Проектный менеджмент. Требования к управлению проектом. — Москва: Стандартинформ, 2012.
2. О персональных данных: Федеральный закон от 27.07.2006 № 152-ФЗ (последняя редакция) // КонсультантПлюс: справочная правовая система. — URL: https://www.consultant.ru/document/cons_doc_LAW_61801/ (дата обращения: 10.10.2026).
3. Васильева Е. В. Методологии проектирования стратегии бизнеса: от дизайна продукта к проектированию платформ // Управление. — 2021. — Т. 9, № 2. — С. 76–89.
4. Зайцева И. А., Эбата У. Ш., Ковбаса Н. А. Практика применения методологий Agile, Scrum в ИТ-проектах // Индустриальная экономика. — 2021. — № 1. — С. 62–67.
5. Мамедов М. А., Мамедов Т. Ф. Становление и развитие цифровых экосистем на базе технологических и телекоммуникационных компаний в России // Финансы и управление. — 2022. — № 3. — С. 1–19.
6. Отрешко Д. А. Интеллектуальные технологии в оптимизации процессов командной разработки цифровых продуктов // Вестник науки. — 2025.
7. Филатов В. В., Полянская О. А., Аленина Е. Э., Зюлина В. В. Современные проблемы корпоративного управления ООО «ВКонтакте» // Журнал прикладных исследований. — 2022. — № 6.
8. Шаврей А. Г. Метрики успеха в продакт-менеджменте: как измерять ценность продукта // Вестник науки. — 2025.
9. Манифест гибкой разработки программного обеспечения [Электронный ресурс]. — URL: https://agilemanifesto.org/iso/ru/manifesto.html (дата обращения: 10.10.2026).
10. МКПАО «ВК». Пресс-релиз по результатам за 4 кв. и 12 мес. 2024 года [Электронный ресурс]. — URL: https://vk.company/ru/press/releases/11976/ (дата обращения: 10.10.2026).