Проблемы продукта

Основная проблема CorePlay видится в том, что он выстроен как сервисный бизнес (модель, ориентированная на услуги). Переход к модели потоков создания ценности (product-value-stream) и реформирование из независимой структуры в более интегрированную с операционной деятельностью модель представляется решением организационных и управленческих проблем.

Симптомы

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

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

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

Организационные модели

Сервисная модель

На данный момент компания работает в парадигме сервисной модели. Это подразумевает иерархическое структурирование команд: мы группируем людей по навыкам (бэкенд, фронтенд, бизнес-аналитики, верстка).

Ключевая метрика каждой команды: насколько качественно и быстро мы выполнили свою конкретную задачу?

Постановка задачи: тикет в системе учета на конкретного человека.

Проблема: каждый отдел отработал на «отлично», но продукт в целом не работает или выходит за рамки всех возможных эстимейтов. Это происходит потому, что задачи "застревают" между командами, и ни один отдел не видит общую картину дальше своего участка (хотя свой участок и выполняется качественно).

Потоки создания ценности (Product-value-stream)

Альтернативная форма организации работы, которая могла бы решить текущие проблемы. В такой модели мы формируем небольшие кросс-функциональные команды. Например: бизнес-аналитик + бэкенд + портал + QA; продакт-менеджер + верстальщик + портал + QA и т. д.

Ключевая метрика каждой команды: как быстро мы реализовали готовую функциональность (фичу).

Постановка задачи: пользовательская история (user story) с уточнениями в процессе работы.

Риски: может страдать качество и архитектура, поэтому необходимы роли-предохранители (архитекторы, тимлиды).

Важное уточнение: например, DevOps-инженеры все равно останутся в рамках сервисной модели, но будут переключаться между командами, которые поставляют (деливерят) фичи.

Контекст и стратегия

В целом, сейчас мы строим структуру по типу SoftSwiss — сервисную компанию (у которой почти нет собственного оперирования) со всеми сопутствующими проблемами сервисного бизнеса: стабильно дорого, долго, но зато стабильно. В то время как на самом деле у нас собственный бизнес по оперированию.

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

Выделим основные потоки ценности в продукте:

• Регистрация и KYC;
• Платежный шлюз (HubbleGate);
• Игровой контент (игры, поиск, рекомендации, интеграция с провайдерами);
• Бонусы и лояльность (CRM, Bonus Engine, Smartico);
• Риски, антифрод и комплаенс (Self-exclusion);
• Платформа (DevOps, архитекторы и другие общие ресурсы).

В результате мы пересобираем команды под потоки ценностей. Эти команды объединены не по типу специализации разработчиков (фронтенд, бэкенд), а по ценности, которую они создают. Например, в «Игровом контенте» это и бэкенд-разработчик, который делает интеграции с провайдерами, и фулстек-разработчик, который реализует поиск на сайте.

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