Создание ИТ-продуктов с нуля — всегда вызов. В отличие от доработки существующего решения или выполнения заказной разработки, здесь компании приходится строить все с чистого листа: архитектуру, процессы, команду и даже подход к управлению. Такой путь требует не только инженерных компетенций, но и исследовательской дисциплины, а также готовности принимать рискованные решения. О роли R&D в процессе создания ИТ-продуктов – Светлана Лазарева, директор исследовательского центра компании «Аэродиск».
Исследовательская работа часто воспринимается как нечто оторванное от реалий бизнеса. Люди тестируют в лабораториях алгоритмы и прототипы, которые никогда не попадут в продакшн, читают статьи, спорят на семинарах. В университетской среде, где важна научная новизна, а не конечный продукт, на фундаментальные исследования могут уходить десятилетия.
Однако в бизнесе продуктовой ИТ-компании, такой роскоши нет. Ей нужна не «новая гипотеза ради публикации», а решение, которое будет работать уже завтра и приносить деньги послезавтра. Это и порождает ключевые отличия R&D-процесса в бизнесе: следование срокам, соответствие разработок рыночным реалиям, ориентация на стабильность работы и масштабируемость нового продукта.
Индустриальное R&D-направление существует в парадигме быстрых прототипов, четких метрик и демо-версий. Раз в квартал или хотя бы раз в несколько недель команда обязана показать результат. Это держит исследователей в тонусе, не позволяя уходить в теоретические дебри.
Первая развилка: исследовать или переписать
В любой ИТ-компании, которая решается на разработку нового продукта, первым шагом становится честный аудит того, что уже есть на рынке. Это обязательная процедура, которая позволяет избежать главной ловушки любой продуктовой R&D-инициативы: «изобретения велосипеда».
Обычно команда начинает с обзора существующих решений: opensource-платформ, собственных предыдущих версий и доступных коммерческих аналогов. И вот тут возникает первая ключевая развилка — стоит брать что-то за основу и дорабатывать то, что есть, под свои задачи, или проще все переписать с нуля?
Второй вариант несет риски: вложения растут, сроки удлиняются, но выгода очевидна. Новый фундамент позволяет встроить все то, что раньше невозможно было «прикрутить»: гибкость модулей, современную архитектуру, поддержку масштабируемости и производительности.
Чтобы решение было рациональным, вводятся метрики. Они становятся своеобразной системой координат, в которой сравниваются все варианты. Такими метриками могут быть: производительность, надежность, стоимость поддержки, требования к инфраструктуре. Они-то и позволяют ответить на главный вопрос: «Стоит ли латать старое или дешевле построить новое?».
Опытные исследователи тратят на эту фазу больше времени, чем на сами эксперименты. Потому что одно неверное решение здесь может обнулить годы работы.
Лаборатория гипотез: не влюбляйтесь в прототип
Далее наступает самый захватывающий и одновременно самый рискованный этап: прототипирование. Это своеобразная «лаборатория ошибок», где ценность имеет не столько количество удачных решений, сколько скорость проверки гипотез.
В бизнесе гипотеза ценна лишь постольку, поскольку ее можно быстро проверить на практике, т.е. собрать минимальную версию продукта и запустить на тестовой базе. Это черновик, набросок архитектуры, на котором проверяется жизнеспособность идеи.
Самая большая ошибка команд на этом этапе — «влюбиться в прототип». Нужно помнить: он не создан для того, чтобы «прожить долгую жизнь». Его миссия — подтвердить или опровергнуть гипотезу. Иногда десятки строк кода пишутся лишь затем, чтобы через неделю их выкинули. Это нормально: ценность не в самом коде, а в понимании, какое направление развития жизнеспособно.
Именно здесь проявляется культура итераций. «Гипотеза → прототип → тест → вывод»: этот цикл повторяется раз за разом, пока команда не выходит на оптимальное решение, которое работает лучше старого и укладывается в заданные метрики. Ускорение цикла — важнейшее конкурентное преимущество. Кто умеет проверять гипотезы быстрее, тот быстрее приходит к рынку с рабочим продуктом.
Однако есть и обратная сторона. При передаче прототипа в полноценную разработку легко потерять ту самую новизну, ради которой все затевалось. На уровне алгоритма все может выглядеть блестяще. Но если разработка реализует его так, что половина преимуществ исчезает, продукт сразу потеряет ценность.
Поэтому компании стараются удерживать исследователей ближе к разработке: чтобы лучше контролировать трансфер идей и участвовать в реализации вместе с программистами.
Сценарии разработки: от знакомого к неизведанному
Не существует единого сценария создания нового ИТ-продукта. Каждый проект развивается по своей траектории, и многое зависит от того, насколько команде знакома задача, каков ее профиль и т.д. По сути, можно выделить три типичных сценария.
Первый сценарий — «знакомая территория». Это ситуации, когда команда уже работала над подобным продуктом или задачей и имеет готовый «скелет» решений. Пример — разработка нового типа RAID-массива в системах хранения данных. Для компании это может быть совершенно новый проект, но для инженеров, которые уже создавали разные виды RAID в прошлом, — повторение пройденного.
Здесь ценность в накопленном опыте: команда знает типичные подводные камни, умеет прогнозировать сроки и понимает, какие архитектурные решения будут устойчивыми. Такие проекты чаще идут по линейному циклу: «спланировали → реализовали → протестировали → показали результат». Риски ниже, скорость выше, но инновационность обычно ограничена.
Второй сценарий — «глубокое исследование». Он возникает, когда команда пытается улучшить алгоритм или придумать принципиально новый способ решения задачи там, где конкуренты уже сильны. Например, создание более эффективного алгоритма дедупликации данных. Здесь невозможно обойтись только инженерными методами. Подключаются математики, аспиранты, научные консультанты. Процесс идет по циклу гипотез и итераций, о которых говорилось выше.
Каждую идею проверяют на тестовой базе, отбрасывают неудачные и накапливают опыт. Проекты такого рода редко движутся линейно: они похожи на движение по концентрическим кругам, когда команда постепенно приближается к рабочему решению. Это долгий путь, но именно он чаще всего приводит к настоящим технологическим прорывам.
Третий сценарий — terra incognita, полностью новая задача, в которой нет опыта ни у команды, ни у рынка. Такие проекты особенно сложны, потому что здесь нет даже условного «скелета», на который можно опереться. Например, компания впервые берется за разработку компонента, который до этого никто не делал. В этом случае критически важно тесное взаимодействие с продуктовыми менеджерами, заказчиками и технической поддержкой.
Команда должна постоянно сверяться с будущим пользователем: действительно ли создаваемое решение отвечает его ожиданиям, не упускаются ли ключевые сценарии эксплуатации.
Внутри одной компании могут одновременно сосуществовать все три сценария. Один отдел пишет хорошо знакомый функционал, второй экспериментирует с алгоритмами, третий пробует силы в области, где нет накопленного опыта. Такой «портфельный» подход позволяет снижать риски. Для руководителя R&D важно уметь различать сценарии и задавать адекватный режим работы. Ошибка — пытаться управлять фундаментальным исследованием так же, как внедрением давно знакомой технологии.
R&D-команда: почему конфликты неизбежны
R&D-отдел в ИТ-компании — живой организм, состоящий из людей с очень разными навыками, характерами и научными бэкграундами. И именно эта пестрота делает его сильным, но одновременно порождает массу сложностей.
Когда компания только запускает исследовательскую группу, чаще всего в нее приходят молодые специалисты с исследовательскими навыком и опытом: умение читать научные статьи, работать с гипотезами, видеть нестандартные решения. Но одного исследовательского склада недостаточно: без практических программистов, которые могут воплотить идею в коде, и тестировщиков, способных прогнать ее через реальные сценарии, R&D рискует застрять на уровне красивых теорий.
Поэтому сильная команда формируется по принципу мозаики. В ней есть математики, программисты, тестировщики, иногда даже специалисты из смежных областей — физики, химики, инженеры. Каждый закрывает свою зону, но при этом важно, чтобы мозаика складывалась в цельную картину. В реальности это означает не только подбор компетенций, но и подбор психотипов.
R&D редко работает в режиме «одиночных гениев». Здесь нужны люди, которые умеют спорить, слушать критику и при этом отстаивать свои идеи. Мозговые штурмы в исследовательских группах зачастую проходят бурно: обсуждения бывают жесткими, эмоции — на грани. Но без этого невозможно двигаться вперед. Если все соглашаются друг с другом, скорее всего, команда движется по проторенному пути и вряд ли создаст что-то принципиально новое.
Однако именно на стыке характеров рождаются главные сложности. Конфликты в R&D — неизбежны. Опытные инженеры иногда «застревают» в уверенности, что их решение единственно правильное. Молодые сотрудники могут настаивать на
гипотезах, которые не подтверждаются практикой, но они верят в них до конца.
Руководителю приходится тратить ресурсы на управление людьми: убедить, собрать аргументы «за» или «против», а иногда даже позволить проверить заведомо проигрышный вариант, чтобы команда наглядно увидела его несостоятельность.
Скорость против качества: где граница
В ИТ-разработке соблазн всегда один — сделать быстрее. Бизнес требует релиз к определенной дате, рынок давит, инвесторам нужен результат. Но любая попытка выиграть время ценой качества почти неизбежно приводит к техническому долгу: продукт работает сегодня, но завтра ломается под нагрузкой или требует переписывания.
Опытные R&D-команды решают эту дилемму архитектурно. Они закладывают в продукт «скелет» — модульную структуру, которую можно наращивать функциональностью без полной переделки. Тогда компромисс выглядит разумно: выпускается минимально жизнеспособная версия (MVP), а дальше продукт развивается итерациями. Такой подход позволяет и показать результат в срок, и сохранить задел на будущее.
Главная ошибка — обещать невозможное. Слишком короткие сроки на исследование приводят к хаосу: метрики не проверены, прототипы непродуманы, архитектура хрупкая. Наоборот, если в начале проекта заложить дополнительное время на исследование и планирование, то на дистанции это экономит месяцы и даже годы.
Вывод прост: скорость важна, но выигрывает тот, кто умеет балансировать ее с качеством. Успех — в точке равновесия, которую каждая команда должна найти сама, исходя из своей экспертизы и амбиций.