Привет, Хабр! Вот два факта:

1. R&D - это единственный путь к реальным инновациям, которые дают конкурентные преимущества и, потенциально, меняют или даже создают новые рынки

2. Большинство менеджеров и представителей бизнеса боятся столкновения с R&D-задачами как огня, и решаются эти задачи, часто, “вопреки”, а не “благодаря”

Давайте разберемся, почему так происходит и что с этим делать.

Преамбула

Уже несколько лет я хотел изложить свое мнение на эту тему, да все руки не доходили. Я слишком часто сталкивался с ситуациями, когда в рамках общего процесса задачи со многими неизвестными никак не выделялись среди потока остальных задач и к ним применялись абсолютно те же шаблонные формальные подходы и общие производственные метрики. И это ВСЕГДА порождало проблемы. Как минимум - трудности с планированием и адекватной оценкой сроков. Как максимум - провалы проектов и выгорание целых команд. Думаю, многим из вас это знакомо.

На пути того самурая, кто смело взялся за R&D задачу, встают множество дополнительных препятствий: от собственных ментальных ловушек до полного непонимания нюансов исследовательской части работы со стороны коллег и начальства. С другой стороны, именно такого рода задачи и делают нашу работу по-настоящему интересной.

Первым шагом для решения многих проблем, в том числе вышеупомянутых, является их признание. Вы, кем бы вы ни были по должности, должны уметь отличать R&D от всей остальной рутины. Спрятавшись от неизвестности за формализмом, вы лишь оттягиваете болезненное столкновение с реальностью.

Далее я буду приводить примеры из личного опыта, так, что вас ждет несколько невыдуманных историй.

Что такое R&D?

Research And Development - буквально “исследование и разработка”. Разработка - это часть, которая, кажется, относительно, предсказуемой. А исследование - это пространство неопределенностей и заранее неизвестного. R&D задачи бывают очень разными, по сложности и по важности. Область нашего незнания может простираться в разных направлениях, не обязательно только в техническом.

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

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

Неизвестным было то, можно ли тяжелый процесс симуляции как-то масштабировать. Физика ткани - сложная штука, и прототип еле шевелился на отдельном выделенном GPU. Казалось невозможным сделать так, чтобы все это начало работать за миллисекунды на каждый запрос. Выяснить КАК это сделать - и есть R&D.

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

Таким образом, люди выкидывают на ветер миллионы. Порой, бывает трудно остановиться, когда объем инвестиций уже превысил критическую отметку. Инвестиции очень хочется вернуть, а единственный способ сделать это, как кажется - инвестировать еще немного. Эта опасная ментальная ловушка - прямое следствие отсутствия отдельного системного подхода к R&D.

Так что же делать?

Управляемый Хаос

Удивительно, но многие не любят слово “Хаос”, считают его каким-то синонимом беспорядка. Однако, хаос, как математическое понятие - это важная характеристика того, что нас неизбежно окружает, нравится нам это или нет. Любая мелочь может вызвать серьезные последствия. Состояния сложных систем сложно (невозможно) достоверно предсказывать в длительной перспективе.

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

В отношении R&D - это особенно актуально. Выход - уметь читать сигналы реального мира и применять практики Хаос-инжиниринга - когда главным источником данных для анализа - является работающая система, на любом этапе своего жизненного цикла. Тут мы просто применяем научный подход и избавляемся от “шаманских” практик. Проблема в том, что нас окружает много “шаманов”, которым это не нравится.

Ловушка фокуса

Фокусироваться на чем-то одном, а не метаться между различными аспектами общей задачи - звучит, на первый взгляд, разумно. Предсказуемо, контролируемо… Среднестатистическому менеджеру такое нравится. Вот только часто это приводит к проработке одного узла или аспекта заведомо нежизнеспособной модели.

Это, по сути, проблема “локальной оптимизации”: вы шлифуете одну деталь до зеркального блеска, не заметив, что весь механизм устроен неправильно. В классической разработке такое еще может сойти с рук - ценой рефакторинга. В R&D цена ошибки другая: вы можете потратить месяцы на доведение до ума компонента, который окажется бесполезен после первого же столкновения с реальностью.

В R&D очень важно уметь, периодически, абстрагироваться от узких или промежуточных целей, формируя и уточняя общее видение перед тем, как снова нырнуть в детали. Фокус на мелких задачах дает приятное ощущение прогресса, но важно не попасть в эту ловушку когда вы радуетесь этому прогрессу на пути в никуда.

Очередной пример. Я участвовал в разработке платформы для подбора и продажи автозапчастей. Сложность тут в том, что поиск должен производится по огромным базам артикулов, которые включают всевозможные аналоги. Вы должны находить соответствия между марками и моделями автомобилей, годами выпуска, VIN-номерами, данными производителей, поставщиков и складов, практически, в реальном времени. Сделать такой поиск быстрым - не самая тривиальная задача, учитывая что и сами данные мы собирали из разных источников, практически, с нуля. Одним из наших микро-сервисов был собственный API для расшифровки VIN-номеров. Мы потратили довольно много времени на эту задачу, она оказалась далеко не такой простой, как выглядела на первый взгляд. В итоге - проект отменили и все наработки пошли в стол. А все наши грандиозные планы даже не получили никакой справедливой оценки реализуемости, нам просто не хватило на это времени. Но когда мы пилили эту расшифровку - нам казалось, что мы движемся в хорошем темпе.

План Б

Важно понимать, что в R&D, отрицательный результат - это тоже валидный результат. Бывает, что задача упирается в ранее неизвестный фактор и оказывается просто нерешаемой, в заданных рамках. Если от этого зависит судьба всего вашего проекта, желательно, еще на этапе формулирования условий, подумать о “Плане Б”.

Подумайте, какие активы вы приобретаете на вашем пути и как они могут отбить затраты, полностью или, хотя-бы, частично. Подумайте, о возможных поворотных точках (pivot points). Это следует делать как заранее, так и, периодически, на всем протяжении работы. Подумайте заранее о стратегиях столкновения с рисками. Многие неудачи можно превратить в победы, если думать в соответствующем ключе.

Хороший R&D-процесс генерирует ценность даже на пути к неудаче. Библиотеки, которые вы написали. Наборы данных, которые вы собрали. Экспертиза, которую приобрела команда. Патенты. Статьи. Open-source компоненты. Все это - побочные активы, которые можно монетизировать или переиспользовать, если основная гипотеза не подтвердилась.

Ключевая практика здесь - определение kill-criteria заранее. Еще до начала работы сформулируйте конкретные, измеримые условия, при которых вы останавливаете проект. Это не пессимизм - это профессионализм. Без заранее определенных границ легко стать жертвой sunk cost fallacy, о которой упоминалось выше.

Свежий взгляд

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

Поэтому, в проектах с высокой долей R&D - очень важен свежий взгляд. Иногда, полезно критиковать самого себя, ретроспективно оценивать свои решения, быть готовым их пересматривать. Иногда, важно уметь услышать мнение со стороны. Такое мнение, порой, кажется дилетантским и поверхностным, но, часто именно оно, показывает, как все выглядит извне вашего уютного процесса, в котором вы, безусловно, лучше всех разбираетесь.

Система Старт-Пауза-Стоп

Одна из практик, применяемых для управления неопределенностью. Каждый новый шаг может зависеть от результатов предыдущего. Иногда весь процесс может надолго “повиснуть” в ожидании каких-то данных. Иногда - работу следует полностью остановить, и переключиться на что-то другое. Ваши процессы должны быть адаптированы под три базовых состояния. Пауза основной ветки R&D - автоматически ставит на паузу все подзадачи. Остановка - запускает алгоритм консервации (для дальнейшего переиспользования артефактов, например, в другом проекте, или для возможной расконсервации и продолжения работы в неопределенном будущем). Все участники процессов должны быть вовремя оповещены об изменениях глобального статуса и быть готовы максимально безболезненно переключиться. Такой подход помогает существенно экономить ресурсы, делать процесс более прозрачным и управляемым для бизнеса и не терять наработки.

Метрики R&D

Классические метрики разработки - velocity, story points, burndown charts - в R&D работают плохо. Они измеряют скорость движения, но не его направление. Вы можете “сжигать” сторипоинты с космической скоростью, двигаясь не туда.

Для R&D более информативны другие показатели:

• Количество проверенных гипотез за единицу времени - показывает реальную скорость исследования

• Стоимость проверки одной гипотезы - помогает оптимизировать процесс экспериментов

• Время до первого столкновения с реальностью - чем раньше прототип попадает в реальную среду, тем лучше

• Отношение переиспользуемых артефактов к общему объему работы - показывает, сколько ценности вы генерируете “по пути”

Такие метрики не дают иллюзии контроля - они дают реальную обратную связь.

Требования к команде

Одним из важных моментов являются повышенные требования к членам команды, работающим в R&D. К сожалению, для этого спектра задач не подходят те, кто еще не успел набить шишки на реальных проектах. Джуниоры могут быть полезны в рутинной разработке с четким ТЗ, но R&D требует другого: способности работать в условиях, когда ТЗ - это то, что ты сам должен сформулировать по ходу дела. Вы можете попробовать делать такой проект силами джуниоров, миддлов, или аутсорсеров из Индии, но есть большая вероятность, что результат будет плачевным. R&D - требует от команды высокой степени самоорганизованности и САМОдисциплины, а они приходят только с опытом. Одновременно с этим, в команде должна царить творческая атмосфера, ибо лучшие идеи будут рождены теми, кому ИНТЕРЕСНО. Этим процессом, практически, невозможно эффективно управлять с помощью микроменеджмента и заранее определенных формальных методик. Тут возникает парадокс: экономия на людях - выйдет себе дороже. При этом, R&D-команда должна быть компактной, чтобы накладные расходы на коммуникации не пожирали ресурсы.

ИИ

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

Но есть нюанс. ИИ отлично работает в зоне известного - он обобщает паттерны из уже существующих решений. R&D же, по определению, оперирует в зоне неизвестного. ИИ не способен (пока) генерировать по-настоящему новые идеи - он может только комбинировать существующие в ограниченном диапазоне. Это делает его мощным ускорителем для опытного R&D-специалиста, который знает, какие вопросы задавать. Но плохим заменителем такого специалиста.

Полностью заменить R&D-специалистов пока невозможно. Но ИИ уже стал отличным инструментом в руках опытного исследователя - и значимость этого инструмента продолжает расти.

Антикризисный R&D

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

Антикризисный R&D отличается от планового тремя вещами:

1. Скорость важнее качества. Вам не нужен идеальный продукт - нужен работающий прототип, который докажет жизнеспособность новой модели. MVP в буквальном смысле.

2. Ресурсы ограничены. Кризис, как правило, означает урезанный бюджет. Парадоксально, но это иногда помогает: ограничения заставляют принимать более изобретательные решения и отсекают весь “шум”.

3. Высокая толерантность к риску. Когда терять уже почти нечего, появляется пространство для экспериментов, немыслимых в “мирное время”.

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

Итого

R&D - не аномалия в производственном процессе, которую надо “пережить”. Это его естественная и неизбежная часть, особенно там, где технологический ландшафт меняется быстрее, чем вы успеваете обновлять документацию. Попытка загнать исследовательские задачи в рамки линейного конвейерного производства - одна из самых дорогих ошибок, которые может совершить бизнес.

Ключевые принципы, которые стоит запомнить:

• Признавайте R&D-задачи как отдельную категорию - не прячьтесь за общими процессами

• Принимайте неопределенность как рабочий фактор, а не как враждебную аномалию

• Инвестируйте в людей - R&D делают люди, а не процессы

• Готовьте план Б и определяйте kill-criteria заранее

• Измеряйте реальный прогресс, а не иллюзию прогресса

• Используйте ИИ как ускоритель, но не как замену мышления

И, главное: R&D - это про управляемый риск. А умение управлять риском - это то, что отличает инженерию от азартных игр.