Как разработать бета-версию продукта.

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

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

3. Поиск команды. Если деньги есть — набираешь штат. Если нет — обходишься силами друзей или обращаешься к фрилансерам.

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

На дальнейших этапах план работ разделяется на более подробные части: продукт (в том числе его IT-разработка), маркетинговый план и план поиска инвестора.

Нужно подготовить документ, который называется Definition of Done (DoD). В нем должны быть обозначены условия завершения каждого этапа и прописаны все результаты, которых нужно достичь — числовые пороговые значения (так называемые Key Performance Indicators, или KPI’s).

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

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

6. Разработка методологии работы. Методологией называется часть плана работ, которая касается продукта. В общем плане мы пишем, что делать, в методологии — как. Работа делится на этапы, и в вольной форме описывается, как она будет проходить на каждом этапе и как понять, что этап закончен.

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

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

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

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

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

Например, сайт нашего проекта iReputation был написан на языке Rubi on Rails, потому что разработчик со знанием этого языка нашелся быстрее. Но то же самое позволяла сделать и платформа Microsoft или самый простой PHP.

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

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

Реальный пример из фарминдустрии: создатели интернет-сервиса считали, что доктора работают в одной клинике, и предусмотрели на сайте только одну графу. В реальности один врач чаще всего работает на несколько клиник сразу. Казалось бы — ерунда, но переделывать пришлось половину системы: ограничение задевало не только интерфейс, но и отчетность.

10. Когда все предыдущие пункты выполнены, можно приступать к работе. Ее результатом должен быть прототип или бета-версия, с одной стороны, и список потенциальных инвесторов, с которыми вы уже знакомы — с другой.