войти зарегистрироваться

Problemator

Problemator
хабраиндекс
0,01

Советы стартапам от Проблематора на GDD

Как известно, 10 ноября в Москве с успехом прошла конференция Google Developers Day 2009. В основном на мероприятии затрагивались темы Google Wave, геосервисы, Google Chrome, Open Social, мобильные приложения, инструментарий для разработчиков, инвестиции и стартапы.

Мы выступали в секции «Венчурный капитал и инвестиции в стартапы». В дискуссии, помимо ведущего, участвовало два человека: Илья Широков из компании DST (озвучивал позицию инвесторов), от нас выступал Андрей Богданов (отдувался за стартаперов).



Учитывая, что видео получилось урезанное, предлагаем на ваш суд наши советы стартаперам «как пройти путь идея -> продукт -> бизнес -> бренд с меньшими потерями» в тезисном виде:

* Забудьте про документацию — у вас нет на нее времени.
* Не изобретайте того, что было сделано до вас — используйте готовые решения.
* Дружите с Silicon Valley — мы знаем только один мировой интернет-бренд, который не от туда (Скайп).
* Будьте быстрыми — рынок не любит старых идей.
* Экономия стартапу нужна не ради экономии, а ради эффективности — не экономьте на людях.
* Не отвлекайте программистов на совещания о бизнес-логике — не будет ни кода, ни бизнес-логики.
* Только инженеры создают ценность в стартапе — все остальные являются обузой.
* Когда вы думаете о маркетинге — думайте о знакомых тех, до кого вы достучитесь и об их знакомых.
* Решайте большую проблему — в первую очередь по кол-ву потенциальных пользователей.
* Хотите стать большими — станьте платформой, помогайте другим бизнесам экономить или зарабатывать деньги.
* Используйте разные средства коммуникации между собой — формат часто определяет будет ли содержание.
* Вы должны олицетворять ваш продукт — везде и всегда.
* Помните слова Калашникова «Самое сложное — сделать просто».
* Не обманывайте пользователя — он только этого и ждет, чтобы заклеймить вас как очередных проходимцев.
* Не давайте юзеру лишнего выбора — он может не выбрать ничего (парадокс выбора).
* Вас волнуют только дефолтные пользовательские опции — о «расширенных» возможностях подумаете потом, если повезет.
* Измеряйте всё в поисках большей эффективности.

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

комментарии (33)

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

    На техническую документацию может и правильно не тратить время, но уж на такую системообразующую — надо.
    • Понятно, что какие-то документы там и сям нужны. Другое дело, что жить по документации (как это принято в корпоративном секторе, где выстраиваются отношения заказчик-подрядчик) не стоит. Например, Software Requirements Specifications, по которым мы пытались жить в начале проекта — лишнее для стартапа. Эта регламентация нам больше навредила чем помогла.

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

        Задачи в таск-трекере вестись, конечно, должны обязательно.

        А вот 300-страничный документ с подробным описанием всех сущностей, полей, связей, и прочим — считаю вообще не нужен. Эти сущности, поля, связи и прочее будут сто раз меняться. Be agile.
  • тех.документация нужна пользователям, чтобы ТП не свалилась от шквала запросов
    • ну, если доросли до ТП, то и стартапом зваться уже как-то неудобно :)
      • Да, наверное, стоило уточнить, что речь идет о технической документации на этапе разработки. Пользовательские хелпы, факи, гайды и пр. — другая песня.
      • имхо, Вы не правы. ТП может быть и у стартапа, в команде которого только один человек
        • Я не настаиваю. Правда, дело не в количестве человек, а в том, что на этапе стартапа можно и не думать о ТП, а давать все as is. Свежие продукты Google, например, так ведь «обслуживаются»?
          • Опять неверно. Такое поведение обычно только Google может себе позволить: это раскрученный бренд. Если же никому не известная компания будет продавать свой продукт без ТП, то его, скорее всего, даже и не купят. Бесплатных аналогов без ТП обычно хватает.

            А стадия стартапа — это как раз первые продажи.
            • А вот тут я не согласен в принципе, большинство успешных стартапов (e.g. Facebook) начинали зарабатывать на рекламе, ни о каких продажах и не думалось. А уж если стартап получил инвестиции (о чем и шла речь на секции GDD09), то о продажах на начальном этапе заботиться вообще грех, нужно более масштабные цели разрабатывать.

              Широков как раз и говорил, что если проект нацелен на то, чтобы поскорее срубить пару миллионов, то он им не интересен.
              • Мы говорим о разных стартапах: вы о соц.сетях, я — про софтверный бизнес. Естественно, тут разные критерии.

                Хабр тоже изначально без ТП обходился.
                • а, ну тогда звиняйте, я не телепат :)

                  честно сказать, мне сложно представить как сейчас «софтверный стартап» может выжить (разные IPhone apps не в счет — да и там тоже с ТП туго, уверен :)), по моему скромному мнению разработчики по большей части к крупным структурам стараются присосаться.
                  • дособеру еще инфы, выложу небольшой How-To про Web Optimizer — типичный сотфверный стартап
  • А как же Амазон? Насколько я знаю, у них шбаб-квартира в Сиэтле, а не в Силиконовой Долине. ru.wikipedia.org/wiki/Amazon#.D0.98.D1.81.D1.82.D0.BE.D1.80.D0.B8.D1.8F
    • Да, Амазон — несомненно интернет-бренд, выросший из обычного стартапа. И вроде тот гараж в котором Безон начинал не в SV. Будем знать.
      • С другой стороны, у Амазона весьма тесные связи с Сан-Франциско: там расположена их дочерняя компания Alexa Internet. ru.wikipedia.org/wiki/Alexa_Internet
  • «Дружите с Силиконовой Долиной»
    Не хочу показаться занудой, но это неграмотно. Silicon Valley переводится как Кремниевая Долина, а силикон применяется несколько в других областях и Силиконовая Долина вообще-то на английском ассоциируется с порнографией.
    • Спасибо. Исправил.
  • «Не отвлекайте программистов на совещания о бизнес-логике — не будет ни кода, ни бизнес-логики.» — долго думал, потом понял, что не совсем понял, а может и совсем не понял.
  • Основная потеря тут в том, что пятиминутное совещание по бизнес-логике выбивает программиста из колеи на часы. В то время как (1) вклад программиста в формирование бизнес-логики не шибко коррелирует с требованиями рядового пользователя и (2) программисты — единственные кто создают ценность в стартапе.
  • Второй пункт очень сомнителен, потому как можно сказать с уверенностью, что любое новое предприятие фактически изобретает что-то известное ранее. Готовое решение может и улучшить и разрушить проект.

    • Тут речь не о value proposition проекта, а о том из чего оно делается. И вот то из чего оно делается чаще нет нужды изобретать. Не нужно строить свой кирпичный заводик, чтобы построить дом.
      • Я хотел написать исключительно про баланс. Какая-то часть компонент должна быть использована из того что есть, а какая-то должна быть создана с нуля, даже если на рынке есть подходящие компоненты. Угадать процент самописи — великое дело. В случае промаха можно получить еле шевелящегося монстра, которого проще убить чем тянуть.
  • Первый пункт какой-то общий… Какая документация? Вообще любая?

    Как минимум «на бумаге» должно быть четко изложено, откуда идем, куда идем и какими путями. Даже два человека не всегда друг друга понимают сразу. Каждый понимает задачу по-своему, будучи уверенным, что задачу он понял. А потом удивляемся, и откуда у нас лебедь, рак да щука… Кроме того, постепенно логика каждого участника может уводить его впоследствии все дальше и дальше не только от того, что придумал генератор идеи, но и от того, что было понято сначала…

    • Речь идет, в основном, о громоздкой технической документации, определяющей каждый винтик программного продукта, на которой настаивают разработчики из корпоративного сектора, желающие устаканенных требований до начала проекта.
      • Тогда, если это действительно именно советы, было бы неплохо излагать мысль более конкретно. Лозунг хорош в рекламе, чтобы привлечь к нему внимание. А советуя, все-таки, думаю, надо было бы точно и ясно сказать, какая документация имеется в виду :)
  • Смущает момент про диктатуру инженеров. Есть ведь еще customer development, который нужно начинать до готовности прототипа, и это работа скорее не для инженера.
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.