Недавно я попал на встречу сообщества «Тимлид не кодит», где собрались ребята из Kaspi, Sterdyev, Bereke Bank и нескольких AI-стартапов. Обсуждали одну простую вещь – что такое R&D в казахстанском IT. Казалось бы, вопрос на пять минут. Но кто же знал, что мы там застрянем на два часа.
Итак, поехали.
Три команды, три «R&D»
Команда в Kaspi переводит маркетплейс на WebView, гоняет серию A/B-тестов, сталкивается с кучей неизвестных. Другая команда в Sterdyev учит нейросеть определять протёршиеся шины по фотографии и распознавать автомобили по звуку мотора ночью. Третья – полностью пересобирает LLM-токенизатор, чтобы одно казахское слово занимало один токен вместо пяти.
Все три примера попадут в годовой отчёт под вывеской «R&D».
Но все ли они – исследование? Спойлер: нет.
Пять типов, и различия принципиальны
Международная классификация (да, есть такая штука) выделяет пять типов R&D. Давайте коротко:
– Фундаментальное исследование – работа ради нового знания, без конкретного применения. В коммерческом IT Казахстана практически не встречается. Это про университеты и государственные лаборатории.
– Прикладное исследование – исследование с конкретной целью, но без гарантии результата. Для наших компаний – редкость. И это нормально.
– Экспериментальная разработка – создание новых продуктов на основе уже известных знаний. Вот тут начинается территория, которую IT-компании обычно называют R&D.
– Продуктовая R&D – улучшение существующего продукта. Самый распространённый тип в казахстанском IT.
– Процессная R&D – оптимизация бизнес-процессов через контролируемые эксперименты. Тут нужен масштаб: несколько одинаковых подразделений для контрольных групп.
А теперь честно. Большинство казахстанских IT-компаний занимаются четвёртым типом. Продуктовой разработкой. Внедряют и улучшают существующие бизнес-практики. Это полезная, важная, квалифицированная работа.
Но называть её «исследованием» – значит, размывать термин до бессмыслицы.
R или D? Главный спор
На встрече народ быстро разделился на два лагеря. Это, в целом, отражает вопрос, с которым сталкивается каждый тимлид, когда пишет квартальный отчёт.
Первая позиция, строгая. Если технологию знают и практикуют тысячи компаний в мире, то ваша работа с ней – Development. Точка. Неважно, насколько это было сложно конкретно для вас. Перевод маркетплейса на WebView? Инженерная задача. Оптимизация карточек через OpenCV? Инженерная задача. Тысячи компаний делали это до вас.
Вторая позиция, широкая. Любой проект с существенной неопределённостью – это R&D. Когда ребята из Kaspi бралась за WebView-миграцию, количество неизвестных было колоссальным. Результат не гарантирован. Ресурсы тратились без уверенности в отдаче.
Казалось бы, оба подхода имеют право на жизнь.
Но на практике разница между ними определяет, как компания бюджетирует IT, какие ожидания ставит команде и какие решения принимает о найме. Тоесть это не теоретический спор, это про деньги.
Есть один простой фильтр, который помогает определиться: сколько компаний в мире обладают экспертизой для решения вашей задачи? Если тысячи – это D. Если единицы – ближе к R.
Критерии Фраскати: красиво, но ломается
ОЭСР в руководстве Фраскати предлагает формализованный подход. Пять критериев для определения R&D:
– Новизна – нацеленность на принципиально новые результаты. Проблема: «новое для компании» – это не «новое для мира».
– Творчество – оригинальные, неочевидные концепции. Проблема: без базовых знаний «творчество» превращается в переизобретение велосипеда.
– Неопределённость – непредсказуемость результатов и затрат. Проблема: любой сложный проект имеет неопределённость. Это не делает его исследованием.
– Систематичность – запланированный и задокументированный процесс. Проблема: хаотичные эксперименты – не R&D, даже если дают результат.
– Воспроизводимость – результаты можно передать или воспроизвести. Проблема: если знание «умерло» с уходом разработчика – оно не было зафиксировано.
На первый взгляд – стройная система. Но участники встречи быстренько нашли уязвимости. «Творчество» без фундамента – это не инновация, а незнание предшественников. «Неопределённость» есть в любом проекте сложнее лендинга. А «систематичность» отсекает подавляющее большинство того, что компании неформально называют R&D.
Даже международные критерии не дают однозначного ответа. Они полезны как ориентир, но уязвимы для интерпретации. Наверное, это нормально для области, которая по определению работает с неизвестным.
Два кейса, которые прошли фильтр
Sterdyev. Определение изношенных шин по фотографии и идентификация автомобилей по звуку мотора в ночное время. Мало кто в мире обладает такой экспертизой. Задача не решается стандартными подходами – нужно собирать собственные датасеты, разрабатывать уникальные модели, работать с ограничениями, которых нет в учебниках.
Даже скептики на встрече согласились: это ближе к настоящему R&D.
Казахский LLM-токенизатор. Стандартные токенизаторы крупных языковых моделей разбивают казахские слова на 3–5 субтокенов. Это снижает качество генерации и увеличивает стоимость инференса. Команда полностью пересобрала токенизатор, чтобы одно казахское слово – один токен.
Для слаборесурсных языков это явная инновация. Решение требовало исследования морфологии казахского языка, экспериментов с корпусами и нестандартных архитектурных решений. Мировая экспертиза в этой области минимальна.
Что объединяет оба примера? Малое количество мировой экспертизы в конкретной задаче. Именно это, наверное, самый надёжный маркер того, что вы занимаетесь R, а не D.
А стартапы-то могут?
На встрече прозвучал провокационный тезис: стартап не может заниматься R&D, потому что исследование – это систематический процесс, а систематичность требует ресурсов.
Один эксперимент – не R&D. Один эксперимент – это один эксперимент.
Возражение прилетело тут же: основатель AI-стартапа потратил два года на исследования, прежде чем выйти на рынок. «Больше 10% всей жизни», заметил он. Зашибись аргумент, конечно.
Истина, наверное, в том, что стартап может делать R, но не может позволить себе его потерять. Отсюда практический вывод: если исследование не задокументировано и не опубликовано, оно не существует. Патентование, публикации, внутренние отчёты – без фиксации результатов ваш R&D «умирает» вместе с компанией или уходом ключевого разработчика.
В Казахстане эта проблема особенно острая. Локальные патенты часто оформляются «для тендера», а не для защиты реальных разработок. Настоящие результаты исследований остаются в головах и уходят вместе с людьми.
Обещание «мы потом опубликуем» – это не результат.
Как измерить то, что по определению неизвестно
Участники встречи не пришли к консенсусу. И наверное это единственный честный результат.
Патенты – самая распространённая метрика, но легко становится целью вместо средства. Когда KPI привязан к количеству патентов, люди начинают патентовать тривиальные решения. Знакомо, да?
Экономические параметры – стоимость прототипирования, время от идеи до деплоя, количество дефектов в экспериментальном коде. Полезно для D, но плохо ловит R.
Модель DARPA – ротация программных менеджеров каждые несколько лет, чтобы убрать предвзятость. Интересный подход, но требует масштаба, который в Казахстане есть у единичных компаний.
Подход Маска – KPI за количество идей, а не качество. Работает только при жёстком отборе людей, которые хотят менять статус-кво. В среднестатистической компании превратится в генерацию шума.
Отсутствие универсальной метрики – это не баг, а фича. R&D по определению работает с неизвестным. Метрика для неизвестного – парадокс.
Как проверить себя
Прежде чем написать в отчёте «R&D», честно ответьте на пять вопросов:
– Сколько компаний в мире решают аналогичную задачу? Если тысячи – это D, не R. – Вы действительно не знаете, получится ли? Или просто не делали этого раньше? – Процесс документируется? Есть гипотезы, эксперименты, выводы? – Знания сохраняются для передачи? Или «умрут» с уходом автора? – Вы расширяете мировой фронтир знаний или догоняете рынок?
Если большинство ответов «нет» – ваша команда занимается Development.
И это абсолютно нормально. Не нужно стесняться буквы D. Хорошая разработка создаёт реальную ценность. Но называя её Research, вы создаёте ложные ожидания – у руководства, у кандидатов, у самих себя.
Почему это вообще важно
Инфляция термина – не абстрактная проблема. Она бьёт по конкретным вещам.
Бюджет. Если всё – R&D, то где приоритеты? Настоящее исследование требует другого горизонта планирования и готовности к провалу. Продуктовая разработка – предсказуемости и дедлайнов. Это две разные модели управления.
Наём. Кандидат ожидает исследовательскую работу, а получает продуктовую разработку. Или наоборот – команда не готова к неопределённости настоящего R. И в обоих случаях кто-то разочарован.
Мотивация. Команда либо разочаруется в «ненастоящем R&D», либо не поймёт, почему от неё ждут прорывов за инженерный бюджет.
Репутация. Рынок учится быстро. Если ваш «R&D-отдел» делает то же самое, что обычная продуктовая команда – это заметят. И кандидаты, и инвесторы, и партнёры.
Честная оценка того, чем занимается ваша команда – это первый шаг к тому, чтобы делать это хорошо. Будь то Research или Development.
Так что разберитесь сперва, чем вы занимаетесь. А потом уже называйте это как угодно.
Обсудить можно в Telegram.
Эта статья основана на встрече сообщества «Тимлид не кодит» 21 мая 2026 года, где участники из Kaspi, Sterdyev, Bereke Bank и AI-стартапов обсуждали границы R&D в казахстанском IT.