Понятно, что какие-то документы там и сям нужны. Другое дело, что жить по документации (как это принято в корпоративном секторе, где выстраиваются отношения заказчик-подрядчик) не стоит. Например, Software Requirements Specifications, по которым мы пытались жить в начале проекта — лишнее для стартапа. Эта регламентация нам больше навредила чем помогла.
Слишком много времени она съедает, а к прототипу не фига не приближает.
Именно, поддержка документации стоит очень многих усилий, и если быть особым педантом и поддерживать актуальность каждой строчки — больше, чем поддержка и разработка самого проекта.
Прототип — лучший документ.
Задачи в таск-трекере вестись, конечно, должны обязательно.
А вот 300-страничный документ с подробным описанием всех сущностей, полей, связей, и прочим — считаю вообще не нужен. Эти сущности, поля, связи и прочее будут сто раз меняться. Be agile.
Я не настаиваю. Правда, дело не в количестве человек, а в том, что на этапе стартапа можно и не думать о ТП, а давать все as is. Свежие продукты Google, например, так ведь «обслуживаются»?
Опять неверно. Такое поведение обычно только Google может себе позволить: это раскрученный бренд. Если же никому не известная компания будет продавать свой продукт без ТП, то его, скорее всего, даже и не купят. Бесплатных аналогов без ТП обычно хватает.
А вот тут я не согласен в принципе, большинство успешных стартапов (e.g. Facebook) начинали зарабатывать на рекламе, ни о каких продажах и не думалось. А уж если стартап получил инвестиции (о чем и шла речь на секции GDD09), то о продажах на начальном этапе заботиться вообще грех, нужно более масштабные цели разрабатывать.
Широков как раз и говорил, что если проект нацелен на то, чтобы поскорее срубить пару миллионов, то он им не интересен.
честно сказать, мне сложно представить как сейчас «софтверный стартап» может выжить (разные IPhone apps не в счет — да и там тоже с ТП туго, уверен :)), по моему скромному мнению разработчики по большей части к крупным структурам стараются присосаться.
С другой стороны, у Амазона весьма тесные связи с Сан-Франциско: там расположена их дочерняя компания Alexa Internet. ru.wikipedia.org/wiki/Alexa_Internet
«Дружите с Силиконовой Долиной»
Не хочу показаться занудой, но это неграмотно. Silicon Valley переводится как Кремниевая Долина, а силикон применяется несколько в других областях и Силиконовая Долина вообще-то на английском ассоциируется с порнографией.
«Не отвлекайте программистов на совещания о бизнес-логике — не будет ни кода, ни бизнес-логики.» — долго думал, потом понял, что не совсем понял, а может и совсем не понял.
Основная потеря тут в том, что пятиминутное совещание по бизнес-логике выбивает программиста из колеи на часы. В то время как (1) вклад программиста в формирование бизнес-логики не шибко коррелирует с требованиями рядового пользователя и (2) программисты — единственные кто создают ценность в стартапе.
Второй пункт очень сомнителен, потому как можно сказать с уверенностью, что любое новое предприятие фактически изобретает что-то известное ранее. Готовое решение может и улучшить и разрушить проект.
Тут речь не о value proposition проекта, а о том из чего оно делается. И вот то из чего оно делается чаще нет нужды изобретать. Не нужно строить свой кирпичный заводик, чтобы построить дом.
Я хотел написать исключительно про баланс. Какая-то часть компонент должна быть использована из того что есть, а какая-то должна быть создана с нуля, даже если на рынке есть подходящие компоненты. Угадать процент самописи — великое дело. В случае промаха можно получить еле шевелящегося монстра, которого проще убить чем тянуть.
Первый пункт какой-то общий… Какая документация? Вообще любая?
Как минимум «на бумаге» должно быть четко изложено, откуда идем, куда идем и какими путями. Даже два человека не всегда друг друга понимают сразу. Каждый понимает задачу по-своему, будучи уверенным, что задачу он понял. А потом удивляемся, и откуда у нас лебедь, рак да щука… Кроме того, постепенно логика каждого участника может уводить его впоследствии все дальше и дальше не только от того, что придумал генератор идеи, но и от того, что было понято сначала…
Речь идет, в основном, о громоздкой технической документации, определяющей каждый винтик программного продукта, на которой настаивают разработчики из корпоративного сектора, желающие устаканенных требований до начала проекта.
Тогда, если это действительно именно советы, было бы неплохо излагать мысль более конкретно. Лозунг хорош в рекламе, чтобы привлечь к нему внимание. А советуя, все-таки, думаю, надо было бы точно и ясно сказать, какая документация имеется в виду :)
Смущает момент про диктатуру инженеров. Есть ведь еще customer development, который нужно начинать до готовности прототипа, и это работа скорее не для инженера.
Советы стартапам от Проблематора на GDD