Методы Маркетинга

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

Для тех, кто не читал первую часть: Как рождаются идеи.



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

Август, 2008 год. Делим. Первое, что мы сделали, это разбили работу на несколько больших частей. В нашем случае это были: веб-сайт, сам сервис и Flash редактор. Над каждой частью работал один человек. Каждую неделю мы проводили отчетные встречи, на которых каждый участник команды рассказывал о своих достижениях/проблемах.

Вот на этом этапе мы допустили первую ошибку. Встречи раз в неделю — это очень мало для быстрой разработки пилота. Планируйте встречи каждый день! Длительность встречи не должна превышать 30 минут и каждая встреча должна быть разбита на этапы. Мы для себя вывели следующие этапы:

• Анализ сделано/не сделано в итерации
• Обсуждение и решение возникших проблем
• Планирование следующей итерации
• А туда ли мы идем? (этот пункт нам пришел позже, о нем будет история далее)

Каждая встреча должна “на выхлопе” содержать понятные задания для каждого участника. Не должно быть иносказаний и слишком больших задач (необъятных) в рамках итерации.

Сентябрь, 2008 год. Собираем и тестим. Примерно через 5 недель у нас появилась первая сборка рабочей версии, которую можно было назвать альфой. Некоторое время у нас ушло на то, чтобы самим изловить самые явные баги и недоработки. После чего, мы сели за стол и написали план доработок на следующий этап.

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

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

• Не просите их найти баги или недоработки. Это вы и сами можете и не это главное на данном этапе.
• Спросите их — решает ли ваш сервис проблему/задачу? И насколько это удобно именно для них.

В нашем случае это выглядело примерно так:

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

Что мы ждем от вас:
Расскажите, удалось ли вам решить эту задачу в рамках вашего проекта? Насколько это было просто? С какими проблемами вы столкнулись?

И тут нам открылась истина — мы промазали, мы расфокусировали наше внимание. Вместо того, чтобы сконцентрироваться на той функциональности, которая решает задачу, мы сделали огромное количество мишуры. Делали, потому что на встречах казалось — “а что, это же полезно!”

Вот так, примерно, выглядела наша схема альфа версии: