Минимальные требования инвесторов к технической стороне проектов

Артур Вельф, IdeaBlog.ru

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

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

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

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

Но как быть в случае создания технически сложных проектов? Хорошо, если в число основателей проекта входит слаженная команда высококвалифицированных программистов, которые готовы потратить несколько месяцев на то, чтобы разработать проект без привлечения инвестиций. А если нет? Если в команде только один высококвалифицированный технарь, который не может сделать проект в одиночку, зато прекрасно сможет найти и скоординировать наёмную команду разработчиков? Ведь разработать проект, который изначально рассчитан на огромные нагрузки, и который не представляется возможным развивать поступательно, начиная с небольшой посещаемости, стоит очень недёшево. Неужели нужно самим изыскивать эти средства и полностью сделать проект, чтобы это не было голой идеей, и только тогда идти к инвесторам? Не совсем так: я уже писал, что стадия идеи проекта - это pre-seed стадия развития стартапа, а seed-стадия состоит из нескольких этапов, реализация первого из которых - создание прототипа проекта и составление на его основе технического задания - уже может дать стартапу полное право утверждать, что проект вышел из стадии голой идеи. Самое главное, что инвестор с этим согласится. Инвесторам, конечно, более приятно видеть уже готовую разработанную систему, однако, как отмечали в интервью все венчурные инвесторы, с которыми я общался, необходимым для них минимумом технической составляющей проектов является наличие прототипа проекта, ТЗ и члена команды стартапа, который способен руководить разработкой высоконагруженных проектов.

Первое, что нужно сделать - это разработать прототип пользовательских интерфейсов проекта и, на его основе, составить ТЗ. Как это делается, очень хорошо описано в блоге Юрия Ветрова, который специально для IdeaBlog.ru составил краткий обзор этого процесса с отсылкой на более статьи своего блога, в которых описываемые вопросы обсуждаются более детально. Итак, обзор процесса проектирования пользовательских интерфейсов от Юрия Ветрова:

Проектирование пользовательских интерфейсов. Краткий обзор процесса

Ключевая деятельность моего отдела в компании Artics - проектирование пользовательских интерфейсов. В основном это веб-технологии - веб-приложения, порталы, интранет-сайты, веб2.0-сервисы и т.п. Сам по себе процесс проектирования достаточно обширный -- и по количеству этапов, и по тем факторам, что учитываются в его ходе, и по используемым инструментам. Многое из этого я описывал в своем блоге. А для IdeaBlog составил обзор всего процесса и его особенностей.

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

Важно ответить на ключевые вопросы:

1.Для кого и для чего эта система. Кто ее основная аудитория и какие задачи этой аудитории она решает? С какими целями создаётся продукт и какие задачи стоят перед ним? Что является важным для успеха продукта, а что - второстепенным?

2.Что должно быть в системе и что она должна уметь. Какие возможности она дает пользователю и какие функции нужны для этого? Какие эксплуатационные, потребительские и другие качества важны для успешной работы системы?

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

Кто-то на детальном проектировании экономит, кто-то не считает его важным. Часто это приводит к возросшим затратам на разработку - функции системы никак не склеятся в единое и понятное целое. А значит результат получится не очень качественный и по потребительским качествам, и по стабильности работы - постоянно нужно будет затыкать дырки. Это как подниматься по лестнице в полной темноте - нужно прощупывать каждую ступеньку вместо того чтобы просто взять и спокойно подняться наверх. Можно оступиться или наступить не туда. Если продукт уникальный и высоковостребованный или нацелен на аудиторию, которая не может отказаться от его использования - потребительские качества могут стоять далеко не на первом месте. Но если рынок конкурентный, удовлетворённость от использования продукта должна быть на высоте.

• Первый шаг - это предпроектный анализ. Нужно понять, что же все-таки требуется сделать. Причем понять не только разработчику, но и самому инициатору проекта. Часто идея звучит достаточно обще. А когда дело доходит до объяснения того что же все-таки нужно делать - сказать это никто не может. Поэтому целевая аудитория, функциональность и другие детали проекта детально проговариваются и записываются.
• После этого можно уже достаточно точно оценить и спланировать работы. Часто оценку дают без предварительного анализа. А потом нервы и заказчика, и разработчика сжигаются быстрее чем калории на велотренажёре. Если проект долгосрочный, запускать его стоит в несколько этапов. Это нужно предусмотреть и при проектировании интерфейса - будет ли целостным продукт, если работает только половина его возможностей?
• Затем мы начинаем непосредственно проектирование. Основной документ, который получается в итоге этого процесса - детальные схемы страниц (wireframes). Они показывают, что представляет из себя каждая страница системы, каковы особенности ее работы. После этого можно начинать работу над дизайном. В дополнение можно подготовить описание работы страниц - сценарии использования (use cases). В них детально описан алгоритм работы пользователя с сайтом - это здорово поможет разработчикам.
• Но самый лучший результат проектирования - интерактивный прототип системы. Это действующая модель пользовательского интерфейса - в него включены основные страницы и процессы работы системы. Несмотря на то, что это только имитация работы - данные не сохраняются и вообще нет работы с сервером - прототип позволяет понять без чтения тонн документации, как работает система. Кроме того, важно проверить верность проектных решений. Для этого отлично подходит юзабилити-тестирование, а его лучше делать на основе чего-то максимального близкого к конечному результату. Проанализировать и исправить ошибки проектирования в прототипе гораздо дешевле и проще, чем впоследствии править финальный программный код и отлавливать появившиеся ошибки.

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

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

Портал «Вечная молодость» www.vechnayamolodost.ru
11.12.2007