Comments 33
запись вопросов была бы более интересной, народ там микрофон с трудом между собой делил
Цели проекта, задачи, понимание кто будет им пользоваться на первых порах и как их на это мотивировать — это все тоже документация.
На техническую документацию может и правильно не тратить время, но уж на такую системообразующую — надо.
На техническую документацию может и правильно не тратить время, но уж на такую системообразующую — надо.
Понятно, что какие-то документы там и сям нужны. Другое дело, что жить по документации (как это принято в корпоративном секторе, где выстраиваются отношения заказчик-подрядчик) не стоит. Например, Software Requirements Specifications, по которым мы пытались жить в начале проекта — лишнее для стартапа. Эта регламентация нам больше навредила чем помогла.
Слишком много времени она съедает, а к прототипу не фига не приближает.
Слишком много времени она съедает, а к прототипу не фига не приближает.
Именно, поддержка документации стоит очень многих усилий, и если быть особым педантом и поддерживать актуальность каждой строчки — больше, чем поддержка и разработка самого проекта.
Прототип — лучший документ.
Задачи в таск-трекере вестись, конечно, должны обязательно.
А вот 300-страничный документ с подробным описанием всех сущностей, полей, связей, и прочим — считаю вообще не нужен. Эти сущности, поля, связи и прочее будут сто раз меняться. Be agile.
Прототип — лучший документ.
Задачи в таск-трекере вестись, конечно, должны обязательно.
А вот 300-страничный документ с подробным описанием всех сущностей, полей, связей, и прочим — считаю вообще не нужен. Эти сущности, поля, связи и прочее будут сто раз меняться. Be agile.
тех.документация нужна пользователям, чтобы ТП не свалилась от шквала запросов
ну, если доросли до ТП, то и стартапом зваться уже как-то неудобно :)
Да, наверное, стоило уточнить, что речь идет о технической документации на этапе разработки. Пользовательские хелпы, факи, гайды и пр. — другая песня.
имхо, Вы не правы. ТП может быть и у стартапа, в команде которого только один человек
Я не настаиваю. Правда, дело не в количестве человек, а в том, что на этапе стартапа можно и не думать о ТП, а давать все as is. Свежие продукты Google, например, так ведь «обслуживаются»?
Опять неверно. Такое поведение обычно только Google может себе позволить: это раскрученный бренд. Если же никому не известная компания будет продавать свой продукт без ТП, то его, скорее всего, даже и не купят. Бесплатных аналогов без ТП обычно хватает.
А стадия стартапа — это как раз первые продажи.
А стадия стартапа — это как раз первые продажи.
А вот тут я не согласен в принципе, большинство успешных стартапов (e.g. Facebook) начинали зарабатывать на рекламе, ни о каких продажах и не думалось. А уж если стартап получил инвестиции (о чем и шла речь на секции GDD09), то о продажах на начальном этапе заботиться вообще грех, нужно более масштабные цели разрабатывать.
Широков как раз и говорил, что если проект нацелен на то, чтобы поскорее срубить пару миллионов, то он им не интересен.
Широков как раз и говорил, что если проект нацелен на то, чтобы поскорее срубить пару миллионов, то он им не интересен.
Мы говорим о разных стартапах: вы о соц.сетях, я — про софтверный бизнес. Естественно, тут разные критерии.
Хабр тоже изначально без ТП обходился.
Хабр тоже изначально без ТП обходился.
а, ну тогда звиняйте, я не телепат :)
честно сказать, мне сложно представить как сейчас «софтверный стартап» может выжить (разные IPhone apps не в счет — да и там тоже с ТП туго, уверен :)), по моему скромному мнению разработчики по большей части к крупным структурам стараются присосаться.
честно сказать, мне сложно представить как сейчас «софтверный стартап» может выжить (разные 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 переводится как Кремниевая Долина, а силикон применяется несколько в других областях и Силиконовая Долина вообще-то на английском ассоциируется с порнографией.
Не хочу показаться занудой, но это неграмотно. Silicon Valley переводится как Кремниевая Долина, а силикон применяется несколько в других областях и Силиконовая Долина вообще-то на английском ассоциируется с порнографией.
«Не отвлекайте программистов на совещания о бизнес-логике — не будет ни кода, ни бизнес-логики.» — долго думал, потом понял, что не совсем понял, а может и совсем не понял.
Основная потеря тут в том, что пятиминутное совещание по бизнес-логике выбивает программиста из колеи на часы. В то время как (1) вклад программиста в формирование бизнес-логики не шибко коррелирует с требованиями рядового пользователя и (2) программисты — единственные кто создают ценность в стартапе.
Второй пункт очень сомнителен, потому как можно сказать с уверенностью, что любое новое предприятие фактически изобретает что-то известное ранее. Готовое решение может и улучшить и разрушить проект.
Тут речь не о value proposition проекта, а о том из чего оно делается. И вот то из чего оно делается чаще нет нужды изобретать. Не нужно строить свой кирпичный заводик, чтобы построить дом.
Я хотел написать исключительно про баланс. Какая-то часть компонент должна быть использована из того что есть, а какая-то должна быть создана с нуля, даже если на рынке есть подходящие компоненты. Угадать процент самописи — великое дело. В случае промаха можно получить еле шевелящегося монстра, которого проще убить чем тянуть.
Первый пункт какой-то общий… Какая документация? Вообще любая?
Как минимум «на бумаге» должно быть четко изложено, откуда идем, куда идем и какими путями. Даже два человека не всегда друг друга понимают сразу. Каждый понимает задачу по-своему, будучи уверенным, что задачу он понял. А потом удивляемся, и откуда у нас лебедь, рак да щука… Кроме того, постепенно логика каждого участника может уводить его впоследствии все дальше и дальше не только от того, что придумал генератор идеи, но и от того, что было понято сначала…
Как минимум «на бумаге» должно быть четко изложено, откуда идем, куда идем и какими путями. Даже два человека не всегда друг друга понимают сразу. Каждый понимает задачу по-своему, будучи уверенным, что задачу он понял. А потом удивляемся, и откуда у нас лебедь, рак да щука… Кроме того, постепенно логика каждого участника может уводить его впоследствии все дальше и дальше не только от того, что придумал генератор идеи, но и от того, что было понято сначала…
Смущает момент про диктатуру инженеров. Есть ведь еще customer development, который нужно начинать до готовности прототипа, и это работа скорее не для инженера.
Sign up to leave a comment.
Советы стартапам от Проблематора на GDD