Рады представить вам вторую часть небольшого цикла статей посвященных истории создания стартапа. В этой части мы расскажем о том, как мы строили работающий прототип, с какими проблема столкнулись, как их решали и, самое главное, как такие ошибки/проблемы не допускать и на чем сконцентрироваться для достижения максимального результата в минимальное время.Для тех, кто не читал первую часть: Как рождаются идеи.
Исходные данные. Сразу хочу отметить, что один из самых главных параметров для удачного старта — команда — у нас уже был. Поэтому этот вопрос в данном цикле мы не рассматриваем. И, как известно из первой части, у нас уже был документ с описанием всех частей проекта.
Август, 2008 год. Делим. Первое, что мы сделали, это разбили работу на несколько больших частей. В нашем случае это были: веб-сайт, сам сервис и Flash редактор. Над каждой частью работал один человек. Каждую неделю мы проводили отчетные встречи, на которых каждый участник команды рассказывал о своих достижениях/проблемах.
Вот на этом этапе мы допустили первую ошибку. Встречи раз в неделю — это очень мало для быстрой разработки пилота. Планируйте встречи каждый день! Длительность встречи не должна превышать 30 минут и каждая встреча должна быть разбита на этапы. Мы для себя вывели следующие этапы:
- Анализ сделано/не сделано в итерации
- Обсуждение и решение возникших проблем
- Планирование следующей итерации
- А туда ли мы идем? (этот пункт нам пришел позже, о нем будет история далее)
Каждая встреча должна “на выхлопе” содержать понятные задания для каждого участника. Не должно быть иносказаний и слишком больших задач (необъятных) в рамках итерации.
Сентябрь, 2008 год. Собираем и тестим. Примерно через 5 недель у нас появилась первая сборка рабочей версии, которую можно было назвать альфой. Некоторое время у нас ушло на то, чтобы самим изловить самые явные баги и недоработки. После чего, мы сели за стол и написали план доработок на следующий этап.
И вот тут мы сделали вторую ошибку, о чем, слава богу, поняли до реализации всех наших доработок во втором этапе. Ошибка заключалась в отсутствии сторонних тестеров. Вся ваша команда никогда не сможет протестировать ваш сервис с точки зрения решения той самой задачи клиента, на которую мы целимся. У всей команды уже будет “замыленый взгляд” на сервис.
Поэтому сразу (повторюсь — сразу) привлекайте сторонних тестеров. Пусть это буду друзья, знакомые, коллеги (не участвующие в проекте), родственники, все равно кто (главное чтобы у них была та задача, которую вы хотите помочь решить). И тут очень важно понять два важных пункта:
- Не просите их найти баги или недоработки. Это вы и сами можете и не это главное на данном этапе.
- Спросите их — решает ли ваш сервис проблему/задачу? И насколько это удобно именно для них.
В нашем случае это выглядело примерно так:
Задача:
Сервис, призванный упростить коммуникацию между членами команды, которая работает над визуальными материалами. Свести к минимуму недопонимания между дизайнером и клиентом. Все члены команды заходят и оставляют свои комментарии прямо на том или ином макете, другие видят оставленные комментарии и могут на них ответить. (к задаче мы добавляли приглашение в сервис)
Что мы ждем от вас:
Расскажите, удалось ли вам решить эту задачу в рамках вашего проекта? Насколько это было просто? С какими проблемами вы столкнулись?
И тут нам открылась истина — мы промазали, мы расфокусировали наше внимание. Вместо того, чтобы сконцентрироваться на той функциональности, которая решает задачу, мы сделали огромное количество мишуры. Делали, потому что на встречах казалось — “а что, это же полезно!”
Вот так, примерно, выглядела наша схема альфа версии:

Больше половины времени мы, можно сказать, потратили зря. Т.к. эти функции были либо не обязательными для достижения цели (но полезными), либо совершенно не нужными! И тут сразу необходимо добавить пункт 4 во все рабочие встречи (он выше был отмечен серым), который говорит “А туда ли мы идем?” Задавайте этот вопрос всегда!
Октябрь, 2008 год. Ломаем. В течение еще 6-7 недель мы ломали и перестраивали практически все. Каждая функция была пересмотрена и передумана. Осталось только то, что действительно необходимо или то, что ломать уже себе дороже :) В результате, из-за этой ошибки, мы потеряли практически 2 месяца. Но, все хорошо, что хорошо кончается и в ноябре, 2008 г. мы получили уже готовую альфу, которая выглядела примерно так:

Вселенная проекта. На основе нашего горького опыта, мы разработали для себя “вселенную проекта” по которой мы оцениваем те или иные функции. Вот небольшой пример этой вселенной.

Как видно, чем ближе к центру функциональность, тем больше она соответствует нашей общей цели и, соответственно, ее необходимо реализовать как можно быстрее. То, что у нас попадает в 9-10, мы просто выкидываем. Не бойтесь выкидывать! Даже если один клиент попросил функцию, умейте сказать НЕТ! Это важно!
Такую же вселенную можно изобразить не только для разработки, но и для маркетинга. Где и как рекламировать сервис, где продвигать и какими средствами.
К идеальному сервису можно прийти если все точки до 8-ой стремятся к центру и по очереди в него попадают.
Ноябрь, 2008 год. Альфа! В ноябре у на была рабочая версия, которую уже можно было назвать именно альфой! Но до беты и RC пока еще далеко :-) Это в следующих частях.
На этом этапе все. У нас есть пилот, который работает, который уже опробован не только нами. Теперь самое время двигаться в сторону получения инвестиций.
Коротко о главном
- поделите работу на части, не пытайтесь объять необъятное
- встречайте каждый день, это позволит вам максимально быстро прийти к результату
- привлекайте сторонних тестеров, пусть они расскажут выполняет ли ваш сервис свою задачу
- не делайте лишнего, все, что не относится к решению задачи — в стол, потом будете поднимать и думать
- и еще раз — не делайте лишнего, сфокусируйтесь именно на том, что должен делать ваш сервис!
Далее в нашем цикле:
Часть III — получили деньги, потеряли деньги. Об ужасном опыте с инвестором, что стоит делать, а что нет.
Ранее было:
Часть I — как рождаются идеи.
