Замечания экспертов к заявке в «Сколково»: что исправлять в проекте, а что — в описании

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

Прочитайте замечания как список проверяемых вопросов

Фонд направляет заявителю комментарии экспертов вместе с уведомлением о результате экспертизы через личный кабинет и электронную почту. Сохраните их рядом с отправленной версией заявки: без исходного текста трудно понять, на какой тезис пришёлся ответ. Не начинайте с общего вывода «проект не понравился». Разбейте каждый комментарий на вопрос, который можно закрыть конкретным материалом или изменением проекта.

Например, фраза о недостаточно раскрытой новизне может означать разные вещи: описание не показывает отличие технологии, сравнение сделано не с теми решениями или подтверждающих данных пока нет. Последствия тоже разные. В первом случае нужно яснее объяснить архитектуру, во втором — пересмотреть сравнительную основу, в третьем — получить дополнительные результаты и честно показать стадию разработки.

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

Когда проблема в описании

Иногда у команды есть прототип, испытания и понятная задача, но заявка перечисляет свойства продукта без объяснения механизма. Читатель видит обещание, однако не понимает, за счёт чего его получают. В этом случае полезно собрать цепочку: исходная техническая проблема → подход → что уже проверено → какой результат ожидается на следующем этапе. Не нужно заменять её рекламным описанием продукта.

Проверьте, одинаково ли названы технология, продукт и исследовательский проект во всех разделах. Если в одном месте речь о платформе, в другом — о сервисе, а в третьем — о методе, эксперт может не понять границы заявки. Согласуйте термины и отделите техническую часть от бизнес-плана. Общую последовательность подачи лучше смотреть в материале о заявке на статус участника; здесь важна именно работа с уже полученными замечаниями.

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

Когда дорабатывать нужно сам проект

Если ключевой результат ещё не подтверждён испытанием или расчётом, уверенная формулировка в заявке не заменит доказательство. Команде стоит решить, какое исследование, испытание или расчёт даст нужные данные, кто отвечает за работу и когда результат можно будет описать. До получения данных формулируйте статус честно: гипотеза остаётся гипотезой, прототип — прототипом, а планы — планами.

Также проверьте права на результаты разработки и роль исполнителей. Если существенная часть технологии создана сторонними разработчиками, а документы о правах не собраны, красивое описание проекта не устранит неопределённость. Юридические вопросы лучше разобрать отдельно с профильным специалистом. К заявке возвращайтесь после того, как фактическое положение стало понятным.

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

Составьте карту изменений до повторной подачи

Сделайте рабочую таблицу для команды: комментарий эксперта, место в отправленной заявке, причина, нужное действие, подтверждение, ответственный. Это позволяет не потерять замечания, которые относятся сразу к нескольким разделам. При повторном чтении заявки проверьте, не появились ли противоречия: новая формулировка новизны должна согласовываться с планом исследований и описанием продукта.

1. Сохраните первоначальную заявку и полный текст комментариев.
2. Разделите замечания на редакционные, доказательные и проектные.
3. Для каждого проектного пробела назначьте проверяемое действие, а не «усилить текст».
4. Перепишите связанные разделы как единое объяснение.
5. Перед отправкой попросите человека вне команды пройти путь от задачи к результату без устных подсказок.

Официальный порядок повторной подачи и допустимое число обращений проверяйте на актуальной странице Фонда в день работы с заявкой: эти условия нельзя выводить из старой копии документа. Вопрос здесь не в том, как быстро нажать кнопку повторной отправки, а в том, появилось ли содержательное изменение.

Как оценить готовность новой версии заявки

Задайте три контрольных вопроса. Можно ли понять технологическую задачу без знания продукта изнутри? Показаны ли доказательства ровно там, где на них опирается вывод? Соответствует ли план работ нынешней стадии разработки? Если на любой из вопросов команда отвечает только устным объяснением, соответствующий фрагмент заявки ещё слаб.

Внешняя проверка полезна, когда замечания затрагивают несколько областей и команда спорит о том, что именно исправлять. В этом случае можно начать с анализа проекта и определить, где нужны новые данные, а где — ясное описание уже выполненной работы. Решение о статусе принимает Фонд; доработка заявки не гарантирует положительного результата.