Компания «Мобиус Технологии» изначально специализировалась на сервисной поддержке, технологическом консалтинге и системной интеграции. Следуя стратегии диверсификации бизнеса, компания успешно запустила собственное R&D-направление. О том, как за шесть месяцев пройти путь от идеи до успешного старта, рассказывают генеральный директор «Мобиус Технологии» Сергей Широков и заместитель генерального директора по созданию продуктов и развитию производства Александр Тригуба.
Как заложить успех на старте
Чтобы компания могла расти и сохранять конкурентоспособность, необходима внутренняя трансформация. «В определенный момент мы приняли решение о создании собственного R&D-направления с фокусом на разработку и запуск цифровых продуктов. В итоге за полгода команде удалось не только выстроить новое подразделение, но и выпустить первую версию продукта для управления проектами и производственными процессами», — сообщил Сергей Широков. По данным эксперта, успеху способствовали четко сформулированные цели:
- Диверсификация бизнеса. В компании понимали риски нестабильного проектного рынка и хотели создать собственный продукт, способный их снизить, а также генерировать регулярную новую выручку.
- Усиление экспертизы. Собственная разработка позволяет глубже погрузиться в технологии и привлекать самых сильных специалистов, которым интересно создавать, а не только поддерживать.
- Рост устойчивости и стоимости компании в долгосрочной перспективе. Наличие собственного продукта повышает инвестиционную привлекательность, укрепляет рыночные позиции и создает фундамент для масштабирования.
От принятия решения до выпуска первого рабочего прототипа прошло 6 месяцев. Широков уточняет, что такая скорость реализации стала возможной благодаря трем ключевым факторам:
- Четкий фокус. Команда не пыталась захватить весь рынок или создать универсальный инструмент. На старте мы выбрали одну острую тему в области ленточных систем хранения данных и сосредоточили усилия только на ней.
- Компетентная команда. Проект не начинался с нуля: внутри уже существовала инженерная группа с нужной экспертизой и высокой мотивацией.
- Автономия и гибкость. Команда получила полную свободу в выборе технологий, архитектурных решений и подходов к реализации.
Этапы и сроки
Александр Тригуба уточнил, что в их случае переход от концепции до релиза занял шесть месяцев, каждый из которых имел четкое содержание, цели и конкретные точки контроля. Весь путь эксперты разделили на следующие ключевые этапы:
- Месяц 1 — формулировка гипотезы продукта, анализ рынка, предварительный выбор технологического стека. На этом этапе составили основную продуктовую гипотезу: какую задачу решает будущее решение, для кого оно предназначено, чем будет отличаться от уже существующих аналогов. Параллельно велась аналитическая работа.
- Месяц 2 — сбор ядерной команды, выделение их из операционных задач, прототипирование ключевого функционала. В течение второго месяца приняли одно из принципиальных решений: выделить ключевых инженеров из текущей операционной нагрузки и собрать ядро проектной команды, сфокусированной на разработке.
- Месяцы 3–4 — интенсивная работа над MVP. Третий и четвертый месяцы стали ключевыми для всего процесса. Именно в этот период шла активная разработка MVP-версии, в которой реализован ключевой функционал, достаточный для начала тестирования.
- Месяц 5 — альфа-тестирование в контролируемой среде. В пятый месяц созданная версия продукта была передана ограниченному кругу пользователей — как внутри компании, так и среди партнеров, согласившихся выступить в роли пилотных команд.
- Месяц 6 — первый релиз и сбор первой обратной связи. Заключительный месяц этапа — это первый официальный релиз MVP. Продукт стал доступен внешним пользователям, при этом команда сопровождала внедрение и продолжала мониторинг. В этот период начался сбор обратной связи от пользователей.
Каждый из этих шести месяцев решал свою задачу и дал результаты, без которых движение вперед было бы невозможно. Поэтапный подход помог избежать перегрузки команды, задать темп и поддерживать четкий фокус на поставленных целях.
Финансовая модель запуска
Стартовый бюджет компании составил 20 млн рублей на шесть месяцев — и этого оказалось достаточно, чтобы сформировать команду, разработать MVP и провести тестирование.
«Минимальный бюджет может варьироваться, но принцип остается общим: львиная доля затрат — это фонд оплаты труда. Если ориентироваться на команду из 5–7 ключевых специалистов (разработчики, дизайнер, продукт-менеджер), именно на них уйдет основная часть средств».
Сергей Широков, генеральный директор «Мобиус Технологии»
Бюджет был распределен так:
- 70% — фонд оплаты труда. Это базовая статья расходов, включающая зарплаты всех членов команды;
- 15% — инфраструктура. Сюда входят аренда серверов, лицензии на ПО, инструменты для разработки и тестирования;
- 10% — маркетинг и PR. На старте достаточно базовых промо-материалов, присутствия на целевых мероприятиях и каналах. Основная задача — донести ценность MVP до первых пользователей;
- 5% — резерв на непредвиденные расходы.
«Главное, как показывает наш опыт, — инвестировать на старте сначала в команду, а уже потом в инфраструктуру. Многие ошибки связаны с тем, что на старте вкладываются в дорогостоящее оборудование, сложные решения и дизайн без проработанного ядра. Однако при ограниченном бюджете выиграет тот, кто сконцентрируется на скорости разработки, гибкости и эффективности внутренних процессов», — дополнил эксперт.
Оргвопросы и их решение
Команда
При ограниченных ресурсах невозможно сформировать полноценный департамент разработки с отделами, иерархиями и т. п. «На старте необходимо собрать команду из универсальных специалистов, способных закрывать сразу несколько направлений», — сообщил Тригуба. В базовый состав проекта вошли:
- техлид/Архитектор — человек, который видит целостную картину и принимает ключевые технологические решения;
- fullstack‑разработчики (2–3 человека) — специалисты, способные работать как с бэкендом, так и с фронтендом;
- продуктовый дизайнер (UX/UI) — понимает логику пользователя и способен создать удобный, понятный интерфейс;
- менеджер проекта;
- продуктовый менеджер — формулирует гипотезы, расставляет приоритеты, является «голосом клиента» внутри команды.
На старте эту роль продуктового менеджера может взять на себя идейный вдохновитель, в случае компании им стал Александр Тригуба.
Структура управления
Классическая структура с несколькими уровнями управления, типичная для сервисных организаций, неприменима в условиях запуска R&D. «В нашем случае была выбрана модель независимой продуктовой ячейки — кроссфункциональной команды, подчиненной напрямую генеральному директору и руководителю проекта. Команда работала автономно: самостоятельно принимала технические и продуктовые решения, не проходя через цепочку внутренних согласований. Это резко сократило цикл обратной связи и повысило ответственность участников», — пояснил эксперт.
Поиск специалистов
Первых участников команды искали по следующим критериям: гибкость ума и любознательность, проактивность и предпринимательский склад характера.
В первую очередь кандидатов искали внутри самой компании — это упростило запуск: сотрудники уже знали корпоративную культуру, процессы и специфику задач. Команда была собрана из тех, кто действительно «болел» идеей и видел в ней возможность профессионального роста. Для усиления использовали профессиональные сообщества, точечный хантинг и реферальные рекомендации.
Взаимодействие с другими отделами
Эксперты не стали глубоко интегрировать R&D с текущими отделами, чтобы не замедлять их, но наладили два ключевых канала взаимодействия:
- Обратная связь от коллег. Первыми тестировщиками стали сотрудники технической поддержки и эксплуатации.
- Регулярные демо-дни. Каждые две недели команда R&D проводила внутренние демонстрации прогресса — показывала всей компании, что было сделано, какие решения приняты и какие гипотезы проверяются.
«Организационные решения, принятые на старте, в значительной степени определили успех проекта. Отказ от иерархических структур, ставка на универсальных специалистов, автономия команды и продуманные каналы связи с остальной частью компании — все это позволило запустить R&D‑направление всего за 6 месяцев».
Александр Тригуба, заместитель генерального директора по созданию продуктов и развитию производства «Мобиус Технологии»
Построение технологической платформы
Основу технологической платформы составили уже имеющиеся ресурсы компании. Благодаря накопленной инженерной базе удалось избежать затрат на аренду или покупку серверов, а также обойтись без длительного цикла развертывания технической среды.
Для управления проектом на первом этапе использовалась облачная система Smart Sheet, позволявшая быстро организовать задачи, координацию и трекинг прогресса. Позже команда перешла на «Яндекс.Трекер» — инструмент, который лучше соответствовал внутренним требованиям по кастомизации и интеграции с другими сервисами.
При организации рабочих процессов с самого начала был выбран Agile-подход, но не в догматичном, а в адаптивном исполнении. Команда использовала гибрид Scrum и Kanban — с одной стороны, регулярные двухнедельные спринты и планирование, с другой — возможность оперативно менять приоритеты, не нарушая общую структуру разработки.
Регулярные рабочие встречи были обязательными — в режиме коротких рабочих встреч без лишней формализации. Их задачей было не столько контролировать, сколько синхронизировать команду, помогать фокусироваться и выявлять блокировки. Параллельно практиковались ретроспективы: команда не просто подводила итоги спринта, но обсуждала, что можно улучшить в процессе, и внедряла корректировки на ходу.
«Мы также привлекли к тестированию MVP несколько наших давних клиентов-партнеров, которые работают в смежных областях. Их мнение помогло нам «заточить» продукт под реальные нужды рынка. Они также участвовали в отраслевых митапах, чтобы «прощупать» аудиторию», — сообщил Тригуба.
Метрики успеха: как измерять прогресс
На ранней стадии классические метрики разработки (строки кода, количество задач, процент покрытия тестами) мало что говорят о реальном прогрессе. Главное — появление работающего прототипа, способного решать реальную задачу.
Первый KPI — готовый MVP за ограниченное время. Если через 3–4 месяца команда показывает прототип, который можно демонстрировать или тестировать — это правильная траектория.
Второй KPI — частота итераций. Команда должна быть способна выпускать обновления, пусть даже незначительные, каждые 1–2 недели. Это говорит о выстроенном процессе, фокусе и жизнеспособности проекта.
Вызовы и открытия
Самым серьезным вызовом в ходе реализации проекта стал поиск баланса в кадровых вопросах. «Мы использовали гибридную команду разработки, где основной костяк состоял из выделенных сотрудников. Кроме того, часть сотрудников мы подключали к работе периодически – очень важно было найти для них правильный баланс между основной деятельностью и разработкой в RnD», — пояснил Сергей Широков.
«Мы для себя определили, что оптимальным решением станет введение системы дополнительной мотивации. Сопротивления как такового не было, просто каждый решение для себя принимал сам, интересна ли ему тема R&D или нет, поэтому нам удалось сформировать некоторый костяк энтузиастов и единомышленников, который и двигает разработку вперед».
Сергей Широков, генеральный директор «Мобиус Технологии»
Благодаря созданной творческой атмосфере недостатка в идеях эксперты не испытывали, но когда пропускали их через исследования рынка, многие приходилось откладывать. Причинами были сложность реализации MVP, возврат инвестиций и потенциал рынка. «Возможно, к некоторым идеям мы еще вернемся, немного переосмыслив их или накопив необходимые для реализации ресурсы», — сообщил эксперт.
«Проект R&D зарождался в компании достаточно давно, было много разных лабораторий внутри технических подразделений, каждая из которых решала, как правило, свою узкоспециализированную задачу — создание единой структуры вызвало абсолютную поддержку. Теперь каждый может лидировать свой собственный проект в рамках единой структуры R&D и получать поддержку смежных команд», — продолжает Широков.
Что касается каналов взаимодействия, то по-прежнему с точки зрения генерации идей самым эффективным в компании остается обычный брейнсторм в очном формате. Но когда речь идет о реализации, то злоупотреблять этим форматом не стоит, чтобы не превратить его в череду неэффективных совещаний. Лучше использовать работу малых рабочих групп в удобном для них формате.
«И, пожалуй, самое важное открытие ждало нас не в технологиях или методологиях, а в людях. В условиях новых задач многие из наших коллег начали раскрываться с совершенно новых сторон. Оказалось, что все они не только эксперты в своей области, но и обладают широким кругозором в смежных сферах. Эти незамеченные ранее таланты и их искренняя увлеченность и желание узнавать новое и стали главным драйвером для достижения общей цели», — подытоживает генеральный директор «Мобиус Технологии».