Как подготовить технологический проект к экспертизе для получения статуса участника «Сколково»

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

Возникают вопросы: что именно разработано компанией? В чем технологическая задача? Какие аналоги существуют? Что уже создано, а что только планируется? Кто будет выполнять заявленные работы?

Именно поэтому подготовку проекта к экспертизе при получении статуса участника проекта «Сколково» полезно начинать не с попытки сделать текст убедительнее, а с внутренней проверки проекта.

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

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

Зачем технологическому проекту предварительная самопроверка

Внутри компании проект воспринимается совсем иначе, чем снаружи.

Основатель помнит, почему три года назад было принято определенное техническое решение. Разработчики понимают внутренние сокращения. Коммерческий директор знает клиентов. Руководитель проекта помнит, какие функции относятся к текущей версии, а какие появятся позднее.

Для внешнего специалиста всего этого контекста нет. Он видит документы. Если необходимые связи в них не показаны, читателю приходится самостоятельно догадываться, как одна часть проекта связана с другой.

Отсюда первый принцип подготовки: проект должен быть понятен без устных пояснений его авторов.

Самопроверка помогает обнаружить три типа проблем.

Особенно полезно проводить такую проверку до финальной редакции. Нет смысла полировать формулировки, пока в содержании остаются пробелы.

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

Что должно быть понятно из описания проекта

Хорошее описание позволяет последовательно ответить на несколько вопросов:

• Какую проблему решает проект?
• Как эта проблема решается сейчас?
• Почему существующих подходов недостаточно?
• Что предлагает компания?
• Как работает технология?
• Что именно разработано самой командой?
• В чем отличие от релевантных аналогов?
• Что уже подтверждено?
• Что еще предстоит разработать?

Если для ответа приходится открывать пять разных файлов и самостоятельно соединять информацию, структуру стоит пересмотреть.

Начинайте не с преимуществ

Одна из частых ошибок — открыть документ перечислением достоинств:

• «высокая производительность»;
• «масштабируемость»;
• «уникальный алгоритм»;
• «гибкая архитектура».

Но читатель еще не понимает, что это за продукт.

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

Отделяйте продукт от технологии

Для оценки технологического проекта полезно разделять два уровня.

Продукт отвечает на вопрос: что получает пользователь?

Технология: за счет какого технического решения это работает?

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

Вывод: функциональное описание отвечает на вопрос «что умеет продукт», техническое — «как достигается результат».

Как подготовить информацию о технологии

Этот раздел лучше собирать вместе с техническими специалистами. Редактор или руководитель проекта не должен самостоятельно восстанавливать принцип работы по презентациям отдела продаж.

Начните с технического интервью.

Что спросить у разработчиков

• Какую техническую задачу решаем?
• Какие подходы использовались раньше?
• Какие ограничения обнаружены?
• Какой подход разработала компания?
• Какие основные компоненты входят в систему?
• Какие компоненты собственные?
• Какие используются в готовом виде?
• Как взаимодействуют элементы?
• Какие технические гипотезы проверялись?
• Какие результаты уже получены?
• Какие характеристики измерялись?
• Что еще находится в разработке?

Затем информацию нужно структурировать.

Удобная модель описания технологии

1. Исходная техническая проблема. Что необходимо изменить или обеспечить?

2. Существующие способы. Какими технологиями задача решается сейчас?

3. Ограничение. Почему для конкретной задачи существующих подходов недостаточно?

4. Собственное решение. Что разработала компания?

5. Принцип работы. Как технология получает входные данные или воздействует на объект и формирует результат?

6. Техническое отличие. Что изменено по сравнению с релевантными решениями?

7. Результат. Какие характеристики уже получены?

Получается понятная цепочка: проблема → разработка → механизм → отличие → результат.

Как отделить собственную разработку от готовых технологий

Для современных цифровых продуктов этот вопрос особенно важен.

Практически любая IT-разработка использует сторонние компоненты:

• языки программирования;
• библиотеки;
• фреймворки;
• облачные платформы;
• базы данных;
• API;
• готовые модели;
• оборудование.

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

Полезно составить внутреннюю таблицу.

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

Как подготовить сравнение с существующими решениями

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

В поле анализа могут попасть:

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

Далее выбираются критерии сравнения.

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

Слабое сравнение

«Наше решение современнее, удобнее и эффективнее».

Более полезное сравнение

Компания показывает: какой принцип используется в аналоге → какой принцип используется в собственной разработке → в чем техническое различие → к какому результату оно приводит.

Если количественный показатель достоверно измерен, можно использовать его. Если нет — не стоит превращать предположение в цифру.

Как описывать рынок и потенциальных пользователей

Технологическая сила проекта не отменяет необходимости ответить на вопрос: кому нужен результат разработки? Но здесь компании часто уходят в другую крайность — пытаются доказать перспективность огромным размером рынка. Для понимания проекта полезнее конкретика.

1. Сначала определите пользователя

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

2. Затем определите покупателя

Пользователь и тот, кто принимает решение о приобретении, могут быть разными людьми или организациями. Для B2B это особенно характерно.

3. Покажите сценарий применения

Не просто: «Решение предназначено для промышленных предприятий». А какой тип предприятия → какой процесс → какая проблема → как применяется продукт.

4. Не подменяйте анализ рынка красивыми цифрами

Большая оценка глобального рынка сама по себе не показывает, кому компания собирается продавать продукт.

Для практической оценки важнее понимать:

• целевые сегменты;
• потенциальных пользователей;
• сценарии использования;
• существующие альтернативы;
• логику выхода на рынок.

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

Итог: рынок должен быть связан с продуктом через конкретного пользователя и конкретную задачу.

Почему важно показать компетенции команды

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

Связь должна выглядеть так: задача проекта → необходимая компетенция → специалист с соответствующим опытом.

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

Не нужно превращать описание команды в набор громких биографий. Важна релевантность.

Что стоит показать

Для каждого ключевого участника:

• роль в проекте;
• направление ответственности;
• релевантное образование — когда оно действительно имеет значение;
• опыт по тематике проекта;
• релевантные разработки, исследования или проекты, если такие данные существуют;
• конкретные задачи в рамках текущей разработки.

Типичная ошибка

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

В результате возникает вопрос: кто именно будет выполнять техническую часть?

Как связать технологию, рынок и команду

Одна из лучших внутренних проверок — построить простую карту соответствий.

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

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

Именно такие несоответствия полезно находить до подачи документов.

Какие противоречия в документах создают вопросы

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

Разные версии стадии готовности

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

Нужно четко разделить: что создано → что тестируется → что разрабатывается → что планируется.

Разные определения продукта

В одном разделе компания создает «аналитическую платформу», в другом — «систему управления», в третьем — «алгоритм прогнозирования». Иногда все три формулировки корректны, но необходимо показать их связь.

Разные показатели

В одном документе указана одна характеристика, в другом — другая. Если это результаты разных испытаний или версий продукта, контекст нужно объяснить.

Не совпадает рынок

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

План работ не соответствует описанию готовности

Если технология уже заявлена как полностью разработанная, но большая часть будущего плана посвящена ее созданию, возникает логический вопрос.

Вывод: перед внешней оценкой документы необходимо читать не по отдельности, а как единый рассказ о проекте.

Почему полезно провести «холодное чтение»

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

Попросите его после чтения ответить:

• Что разрабатывает компания?
• Какую проблему решает?
• Как работает технология?
• Что является собственной разработкой?
• В чем отличие от существующих решений?
• Кто будет создавать технологию?
• Кто потенциальный пользователь?
• Что уже сделано?
• Что еще предстоит сделать?

Если ответы существенно отличаются от того, что имела в виду команда, проблема находится в документах, а не в читателе.

Что проверить непосредственно перед экспертной оценкой

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

Проверьте терминологию

Одни и те же сущности должны называться одинаково. Если «модуль интеллектуальной обработки» и «аналитическое ядро» — один компонент, лучше не заставлять читателя догадываться об этом.

Проверьте цифры

Каждая существенная цифра должна иметь понятное происхождение.

Особенно:

• технические показатели;
• результаты испытаний;
• рыночные данные;
• количественные сравнения.

Проверьте времена

Четко разделите:

• разработано;
• разрабатывается;
• планируется разработать.

Одно неверное время глагола способно изменить смысл целого абзаца.

Проверьте аналоги

Убедитесь, что сравниваются действительно релевантные решения и используются проверяемые сведения.

Проверьте команду

Для ключевых этапов должно быть понятно, кто отвечает за реализацию.

Проверьте план

Этапы разработки должны логически продолжать текущее состояние проекта.

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

Чек-лист готовности документации

Перед передачей материалов на экспертизу инновационного проекта можно провести последнюю внутреннюю проверку.

Проект

1. Понятно, какой продукт создается?
2. Сформулирована конкретная проблема?
3. Понятен потенциальный пользователь?
4. Описан сценарий применения?

Технология

1. Объяснен принцип работы?
2. Выделена собственная разработка?
3. Сторонние компоненты обозначены корректно?
4. Показана технологическая задача?
5. Объяснены ключевые технические отличия?

Аналоги

1. Проведен поиск релевантных решений?
2. Есть понятные критерии сравнения?
3. Использованы проверяемые источники?
4. Нет необоснованного заявления «аналогов нет»?

Результаты

1. Достигнутые результаты отделены от планируемых?
2. Значимые показатели подтверждаются?
3. Для количественных утверждений есть исходные данные?
4. Ограничения проекта не скрыты за рекламными формулировками?

Рынок

1. Определены потенциальные пользователи?
2. Сегменты связаны с реальными сценариями применения?
3. Рыночные показатели имеют источник?
4. Коммерческая логика не противоречит техническому описанию?

Команда

1. Указаны ключевые специалисты?
2. Понятны их роли?
3. Компетенции связаны с задачами проекта?
4. Есть ответственные за основные направления разработки?

Документы

1. Терминология единообразна?
2. Цифры совпадают во всех материалах?
3. Стадия готовности описана одинаково?
4. План соответствует текущему состоянию?
5. Нет противоречий между технической и коммерческой частями?

Если некоторые пункты не проходят проверку, это не повод искусственно переписывать проект. Сначала нужно выяснить фактическое положение дел, а затем корректно отразить его в документах.

Чего не стоит делать перед экспертизой

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

Не стоит:

• называть интеграцию собственной технологией без объяснения;
• приписывать продукту неподтвержденные характеристики;
• увеличивать показатели рынка ради впечатления;
• скрывать наличие аналогов;
• представлять планы как достигнутые результаты;
• добавлять компетенции, которых у команды нет;
• копировать описание другого проекта;
• использовать сложные термины только ради научности текста.
• Сильнее работает спокойное и конкретное описание.

Что есть → как работает → чем отличается → чем подтверждается → что планируется дальше.

Экспертиза начинается с понятности проекта

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

Полезная последовательность выглядит так: проблема → технология → собственная разработка → аналоги → отличия → результаты → рынок → команда → план развития → подтверждающие материалы.

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