Эксперт Сергей Фоменко
Действующие продажи не отменяют исследовательскую задачу. В заявке важно разделить то, что компания уже поставляет клиентам, и то, что ей ещё предстоит разработать и проверить. Если всё описание сводится к росту выручки существующего продукта, технологический проект теряется. Если же команда скрывает продажи и называет готовую функцию экспериментом, возникает противоречие с фактами.
Опишите текущий продукт без попытки «омолодить» его
Начните с честной версии на сегодня: какие функции работают, кому продукт поставляется, какие ограничения уже известны. Не называйте прототипом промышленно используемую функцию и не выдавайте планируемые возможности за готовые. В то же время не нужно считать каждую продажу доказательством, что исследования завершены. Продукт может решать часть задачи и одновременно иметь технические пределы, над которыми работает команда.
Покажите границу между коммерческой и исследовательской частями. Например, действующий сервис выполняет базовую обработку, а новая разработка должна повысить устойчивость при определённых условиях. Но конкретные показатели, способы измерения и результаты приводите только свои, подтверждённые. Универсальные цифры из чужого кейса здесь не помогают.
| Что уже есть | Что ещё исследуется | Как связать в заявке |
|---|---|---|
| Рабочая функция продукта | Новое техническое решение | Показать предел текущего подхода и цель разработки |
| Первые продажи | Применение результата в продукте | Отделить факт спроса от доказательства технической новизны |
| Пользовательская обратная связь | Проверяемая инженерная гипотеза | Объяснить, какую проблему выявило применение |
| План продаж | План исследований и испытаний | Не подменять одно другим |
Эта схема помогает сформулировать границу проекта. Она не означает, что любой продающийся продукт подходит под требования Фонда: оценка зависит от содержания конкретной разработки.
Сформулируйте технический вопрос, который ещё открыт
Разработка начинается там, где команда может назвать неопределённость и способ её проверить. Обычная доработка интерфейса по понятному техническому заданию сама по себе не становится исследованием. Нужно объяснить, почему существующее решение недостаточно для поставленной технической цели, какие подходы рассматриваются и по какому результату будет понятно, что задача решена.
Старайтесь не писать «мы планируем создать уникальную платформу» вместо исследовательской задачи. Слова о новизне требуют предмета сравнения. Какая характеристика меняется? При каких условиях? Что в существующей архитектуре мешает достигнуть цели? Если ответы есть только в голове главного разработчика, сначала зафиксируйте их в рабочем документе.
Когда исследования ведутся параллельно с продажами, полезно вести версии отдельно. Заказчик получает стабильную функцию; экспериментальный модуль проходит испытания. В заявке ясно укажите, какая часть относится к текущей коммерциализации, а какая — к плану работ. Иначе эксперт увидит одну и ту же функцию одновременно «готовой» и «ещё разрабатываемой».
Покажите связь будущего результата с рынком
Действующие клиенты могут подтвердить, что проблема применения реальна, но нельзя выдавать их пожелания за техническое доказательство. Отдельно опишите, где именно новый результат может быть применён и какую функцию улучшит. Если есть документированные пилоты или данные обратной связи, используйте их точно; если нет — не выдумывайте имена, показатели и обещанные контракты.
Коммерциализация результата — это путь от разработки к применению, а не только прогноз выручки. Покажите, какой продукт или процесс получит новую функцию, что нужно проверить до внедрения и от каких условий зависит масштабирование. В этой части не требуется изображать зрелый рынок, если команда пока проверяет гипотезу. Требуется последовательное объяснение.
Общая логика подачи заявки описана в статье о статусе участника «Сколково». Для действующего продукта особенно важно, чтобы разделы о текущем состоянии, НИОКР и коммерциализации не противоречили друг другу.
Соберите план разработки из проверяемых этапов
Вместо общего обещания «улучшать технологию» перечислите этапы: что команда проверит, какой материал или прототип подготовит и как оценит результат. Не обязательно обещать заранее положительный исход эксперимента. Исследование может показать, что выбранный подход не работает; это тоже влияет на следующий этап. План становится сильнее, когда в нём видна логика решений.
Сроки, ресурсы и метрики должны соответствовать возможностям команды. Если ключевые права на разработку принадлежат другой организации или испытания зависят от внешнего доступа, отразите это в плане. Не включайте в проект задачи, которые невозможно выполнить в заявленных условиях только ради впечатляющей дорожной карты.
- Зафиксируйте фактические функции продаваемой версии.
- Опишите техническое ограничение, которое остаётся несмотря на продажи.
- Сформулируйте гипотезу и способ её проверки.
- Свяжите ожидаемый результат с применением в продукте.
- Сверьте этапы НИОКР, ресурсы и коммерческий раздел на противоречия.
Проверьте заявку глазами внешнего читателя
Попросите человека, не участвовавшего в разработке, ответить: что уже работает, что ещё предстоит исследовать и как будущий результат будет использоваться? Если ответы смешиваются, перепишите соответствующие абзацы. Эта проверка полезнее механического добавления слов «инновация» и «коммерциализация».
Когда границу между готовым продуктом и новым проектом сложно сформулировать, может помочь внешняя подготовка к экспертизе; профильная услуга описана на странице получения статуса участника. Но решение принимается по содержанию проекта, а не по тому, насколько уверенно звучит заявка. Честное разделение готового и будущего делает её понятнее.
Если существующая версия работает слишком хорошо
У команды может возникнуть соблазн придумать «большую научную проблему», хотя ближайшие задачи сводятся к поддержке клиентов и обычному развитию сервиса. Не нужно искусственно превращать каждое изменение интерфейса в исследование. Лучше честно проверить, есть ли отдельная техническая неопределённость и ресурсы для её решения. Если их пока нет, подготовка убедительной заявки должна начинаться с проекта, а не с текста.
Обратная ситуация — исследовательская работа ведётся, но её результаты не попадают в продукт. Тогда нужно показать, как команда планирует оценить применимость результата и что станет основанием для внедрения. Одного перечня экспериментов недостаточно: эксперт должен увидеть связь между проверкой гипотезы и дальнейшим использованием результата.
Нужна проверка материалов проекта? Сначала соберите подтверждённые данные и определите, какие вопросы относятся к заявке, а какие — к самой разработке.