Comments 48
Сокращенная компиляция 37 signals с собственным опытом автора - не будет лишней.
UFO just landed and posted this here
Это правило хорошо подходит к первому проекту, к начинаниям
Когда не знаешь, что делать, лучше делать что-нибудь, чем ничего.
Плюс к этому опыт не есть цель, зачастую, но приятное дополнение :)
Плюс к этому опыт не есть цель, зачастую, но приятное дополнение :)
UFO just landed and posted this here
Возможно, что это правило работает. Но мой опыт подсказывает (а я сделал уже три онлайн-сервиса, один из которых недавно пиарился на хабре - picbite.com), что лучше хорошенько подумать перед тем, как начать делать. Человеческие усилия все-таки не резиновые, у нас у всех есть нервы и не вечное время, достаточно сделать один-два сервиса, которые окажутся никому не нужны для того, чтобы голова заработала в другую сторону. К сожалению, я понял это когда уже сделал эти ошибки.
UFO just landed and posted this here
Самая основная ошибка в том, что я слишком хорошо относился к своей идее. Она мне нравилась. Я думал, что она всем будет нужна. Ведь такого еще не было. И мою реализацию этой идеи по-настоящему оценят.
Поэтому стоит относится к своей идее критично. И если ты относишься критично, то ты зарубаешь автоматом все идеи, которые тебе не нравятся до конца и ищешь ту, которая тебе до конца понравится целиком и полностью, которая пройдет через этот фильтр критичности. Возможно, что это та идея, про которую ты можешь сказать "Ну если она никому не понравится, то для меня это будет полезно". Вот за нее и нужно браться.
Еще один момент я вынес для себя - не нужно вначале хвататься за UGC (user-generated content). Но это мое сугубо внутреннее видение. Лучше сделать именно какой-нибудь сервис.
Еще один важный момент - не запускать в паблик идею с обрезанными фичами. Чем больше из задуманных фич будет в самом начале, тем лучше, т.к. многим может понравится одна из твоих фич и именно благодаря этой фиче проект может выстрелить на дигге, кто-то может написать о нем в своем блоге и т.д. Конечно, фичу можно добавить потом, но лучше чтобы она была когда проект только появился и будет у всех на слуху, когда о нем будут писать.
Ну и самое основное - хорошенько подумать о реализации проекта, который требует титанических усилий. Может ну его, в топку? :)
Поэтому стоит относится к своей идее критично. И если ты относишься критично, то ты зарубаешь автоматом все идеи, которые тебе не нравятся до конца и ищешь ту, которая тебе до конца понравится целиком и полностью, которая пройдет через этот фильтр критичности. Возможно, что это та идея, про которую ты можешь сказать "Ну если она никому не понравится, то для меня это будет полезно". Вот за нее и нужно браться.
Еще один момент я вынес для себя - не нужно вначале хвататься за UGC (user-generated content). Но это мое сугубо внутреннее видение. Лучше сделать именно какой-нибудь сервис.
Еще один важный момент - не запускать в паблик идею с обрезанными фичами. Чем больше из задуманных фич будет в самом начале, тем лучше, т.к. многим может понравится одна из твоих фич и именно благодаря этой фиче проект может выстрелить на дигге, кто-то может написать о нем в своем блоге и т.д. Конечно, фичу можно добавить потом, но лучше чтобы она была когда проект только появился и будет у всех на слуху, когда о нем будут писать.
Ну и самое основное - хорошенько подумать о реализации проекта, который требует титанических усилий. Может ну его, в топку? :)
Одна из не сработавших идей - Softicana. Хотя у Интела там что-то работает. Но не думаю, что в таком виде это кому-то нужно.
строка "делай что-нибудь, не получится - будет опыт" - это помощь в мотивации :)
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Всегда можно найти кому нужен этот сервис. Вопрос в том, как много таких будет и сумеешь ли ты донести информацию об этом сервисе им или нет.
Да, часть идей можно отсечь при правильной критике и т.д. Но в некоторых случаях, чтобы узнать наверняка надо реализовать.
Да, часть идей можно отсечь при правильной критике и т.д. Но в некоторых случаях, чтобы узнать наверняка надо реализовать.
Почитайте об «Экстремальном Программировании». Уроки, которые вы извлекайте, уже извлечены, систематизированы и собраны в этой методике.
UFO just landed and posted this here
Code Complete читали? Если нет - рекомендую :)
>>Поэтому уделяй меньше времени красоте кода и стройности базы данных
... и потом переписывай всё с нуля, т.к. кривой код ты сам через пару месяцев не поймёшь (даже если он свой), а про БД вообще молчу.
... и потом переписывай всё с нуля, т.к. кривой код ты сам через пару месяцев не поймёшь (даже если он свой), а про БД вообще молчу.
Нужен компромисс между качеством и скоростью.
Базу конечно планировать надо с самого начала, код моно улучшать рефакторингом. xP вам в помощь.
Базу конечно планировать надо с самого начала, код моно улучшать рефакторингом. xP вам в помощь.
Согласен, что нужен компромис. Только вот незадачка, рефакторинг есть улучшение качества кода без изменения интерфейса. Если планирование отсутствует и делается "потом исправлю", то интерфейс получается.... Его вообще не получается и встречаются функции типа foo и т.д.
PS Про XP знаю не по наслышке и сам практиковал порядка 7 - 8 практик.
PS Про XP знаю не по наслышке и сам практиковал порядка 7 - 8 практик.
Что же вы хабракат игнорируете? )
Даже никакой интриги не оставляете читающим :)
Даже никакой интриги не оставляете читающим :)
С точки зрения маркетинга:
Оцениваем чего нехватает юзверям на нашем сайте/вообще в сервисах трынета, реализуем это, тестим "на кошках" пока любой новичек не сможет сходу с этим работать без проблем и не будет вызвать дискомфорта, рисуем десяток макетов проводим опрос какой больше нравится, выбираем его и допиливаем пока не станет максимально удовлетворять юзверя.
Оцениваем чего нехватает юзверям на нашем сайте/вообще в сервисах трынета, реализуем это, тестим "на кошках" пока любой новичек не сможет сходу с этим работать без проблем и не будет вызвать дискомфорта, рисуем десяток макетов проводим опрос какой больше нравится, выбираем его и допиливаем пока не станет максимально удовлетворять юзверя.
"Поэтому уделяй меньше времени красоте кода и стройности базы данных и больше новым фичам, новым возможностям."
Извените, а вы можете себе представить страшный и ужасный код, с кучей налепленных новых фич. Во-первых, какой же хороший опыт можно из этого извлекти. Во-вторых, так как не будет "красоты кода и стройности базы данных", то 100% будет множество багов, а о правильности работы сайиа в целом, я вообще молчу. Возникает вопрос, зачем писать корявую штуку, с кучей хороших и новых фич? Что бы проект был успешным, нужна планировка! а вот потом ее уже можно изменять или дополнять, но основа должна быть в любом случае.
Извените, а вы можете себе представить страшный и ужасный код, с кучей налепленных новых фич. Во-первых, какой же хороший опыт можно из этого извлекти. Во-вторых, так как не будет "красоты кода и стройности базы данных", то 100% будет множество багов, а о правильности работы сайиа в целом, я вообще молчу. Возникает вопрос, зачем писать корявую штуку, с кучей хороших и новых фич? Что бы проект был успешным, нужна планировка! а вот потом ее уже можно изменять или дополнять, но основа должна быть в любом случае.
В оправдании тезиса "Поэтому уделяй меньше времени красоте кода и стройности базы данных и больше новым фичам, новым возможностям." и в опровержение тезиса "Что бы проект был успешным, нужна планировка!" можно сказать, что пользователям по сути все равно что внутри, если это работает так, как им надо. Доказательство: недавно на хабре выкладывали часть кода с facebook'а - что-то я не заметил там особой красоты кода, вполне может быть, что и БД там не самая "стройная". Однако, в неуспешности проект не обвинишь :).
Вопрос в том что для того, чтобы в дальнейшем можно было с меньшими трудозатратами и легкостью поддерживать проект, добавлять новые фичи и исправлять баги - нужно планирование, это 100%. Так что по остальным пунктам я с Вами полностью согласен.
Вопрос в том что для того, чтобы в дальнейшем можно было с меньшими трудозатратами и легкостью поддерживать проект, добавлять новые фичи и исправлять баги - нужно планирование, это 100%. Так что по остальным пунктам я с Вами полностью согласен.
Согласен, я это даже рассматриваю немного с другой стороны. Упрощенно, мы имеем некую механизм, на вход которого подаются данные, на выходе получаем нужные нам данные. Не так важно насколько красиво работает механизм, ведь в итоге получается то, что нам нужно. Главное чтобы это было быстро и чтобы программист мог внести изменения довольно быстро при необходимости. Но важно понимать, что красивый код это не самоцель.
В качестве примера можно привести некую программу, которая обрабатывает текстовые файлы. На входе имеем doc, на выходе получаем pdf. В данном случае совершенно не важно насколько красиво написан код и сколько он работает, 1 секунду или 5. Главное, что он
1) не глючит
2) по времени работает в пределах разумного
А если это так, то неважно какой код, на выходе нас интересует именно конечный результат, pdf-файл.
В качестве примера можно привести некую программу, которая обрабатывает текстовые файлы. На входе имеем doc, на выходе получаем pdf. В данном случае совершенно не важно насколько красиво написан код и сколько он работает, 1 секунду или 5. Главное, что он
1) не глючит
2) по времени работает в пределах разумного
А если это так, то неважно какой код, на выходе нас интересует именно конечный результат, pdf-файл.
UFO just landed and posted this here
Статья просто супер. Один из основных кирпичиков большого опыта, сказанного ранее на хабре. Предлогаю выпустить совместную книгу по разработке старапов от лица хабра
6. Больше работы не значит больше денег. Вполне возможно, что потратить свои усилия лучше сначала на небольшой сервис, чтобы получить для начала хотя бы небольшую отдачу. Чем потратить все усилия на сложный сервис, который окажется никому не нужен.
Как разработчик веб-сервисов, готов подписаться под всеми 5-ю пунктами и под 6-м от Gangsta (коммент на один выше).
я так думаю лучше тратить силы не на реализацию, а на банальный опрос, только нужно правильно понять у кого спрашиваешь, а то можно спросить не у тех :)
Проблема с опросами состоит в том, что не обязательно кардинально новую хорошую идею все оценят положительно.
Как то у Форда спросили, интересовался ли он у покупателей что они хотят, до того, как сделал свою знаменитую Model T (его первая машина). Он сказал, что нет, не спрашивал, так как если б спрашивал, они попросили бы улучшенную лошадь.
У Скотта Беркуна (http://www.scottberkun.com, ex IE manager, автор интересных книг), есть интересное эссе про Idea Approval Index.
Суть в том, что чем меньше людей соглашается с идеей, тем сильнее будут изменения ей привнесенные, если только эта идея действительно заработает.
И чем больше людей с новой идеей соглашаются, тем сложнее назвать ее инновацией.
То же самое и с фокус группами. Apple выпуская свой неудачный Newton опрашивала народ, купили бы они такой девайс или нет. Все говорили да, а на самом деле не покупали и продукт провалился.
Вообще у кого есть возможность, почитайте его книгу "Myths of Innovations", очень интересная.
Как то у Форда спросили, интересовался ли он у покупателей что они хотят, до того, как сделал свою знаменитую Model T (его первая машина). Он сказал, что нет, не спрашивал, так как если б спрашивал, они попросили бы улучшенную лошадь.
У Скотта Беркуна (http://www.scottberkun.com, ex IE manager, автор интересных книг), есть интересное эссе про Idea Approval Index.
Суть в том, что чем меньше людей соглашается с идеей, тем сильнее будут изменения ей привнесенные, если только эта идея действительно заработает.
И чем больше людей с новой идеей соглашаются, тем сложнее назвать ее инновацией.
То же самое и с фокус группами. Apple выпуская свой неудачный Newton опрашивала народ, купили бы они такой девайс или нет. Все говорили да, а на самом деле не покупали и продукт провалился.
Вообще у кого есть возможность, почитайте его книгу "Myths of Innovations", очень интересная.
тогда мы не рассмотрели (как в случае с Newton) маркетинговую компанию, я осмелюсь спросить, она разве не может начатсья с формы опроса? можно-же заинтриговать тоже обычным опросом.
PS: А вот Ньютон я держал в руках и очень счастлив этому! И даже купил-бы наверное если-бы мне было годов побольше :)
PS: А вот Ньютон я держал в руках и очень счастлив этому! И даже купил-бы наверное если-бы мне было годов побольше :)
Маркетинговая компания может, конечно, но суть опроса проводимого ими была именно в выяснении, нужен ли "фокус группе" данный продукт. Насколько я знаю, это был последний раз, когда Apple делала опрос фокус групп.
Причин для провала Ньютона было много большой размер, малое время работы от батареии, распознование графити, которое хромало очень. Palm сделала девайс попроще, с меньшими возможностями, но которые работали более стабильно. В итоге Palm выиграл пальму первенства.
Причин для провала Ньютона было много большой размер, малое время работы от батареии, распознование графити, которое хромало очень. Palm сделала девайс попроще, с меньшими возможностями, но которые работали более стабильно. В итоге Palm выиграл пальму первенства.
так вот может Apple спросила не тех? Постараюсь привести пример: предоставляем сервис исключительно онлайновый справочник компаний с прайс-листами. 1. Опрашиваем людей на улице возле скажем филармонии. Получим результат, что большинство не оценит идею. 2. Опрашиваем людей возле бизнес центра, а тут совсем другая история! Конечно фокус группа должна коррелировать с теми для кого мы делаем продукт. И если мы поймем, что есть нестыковка, то можем либо сметь фокус группу, либо отказаться от идеи. Честно говоря для меня это самый сложный вопрос :)
Может быть, конечно, хотя маловероятно.
Продукт делался для бизнесменов, чтобы помочь им управляться с контактами и расписанием. Соответственно их и опрашивали. Наверняка есть случаи, когда фокус-группы очень полезны и важны, но таких немного, как мне кажется.
Одна из причин этого люди не могут нормально предсказать себя когда они в нормальном состоянии (не говоря уж об измененных страх там, стресс или возбуждение).
То есть юзер говорит да, хочу купить, буду пользоваться. Но по каким-то причинам не покупает и не пользуется. Это как в юзабилити не спрашивай юзеров, что им нужно. Дай им это, и посмотри что они будут делать :)
Вообще, как мне кажется, если бы существовал простой ответ на вопрос "делать Y или нет", то не было б неудачных проектов (коих большинство, кстати), мир был бы лучше, а гаджеты умнее и дешевле :)
Продукт делался для бизнесменов, чтобы помочь им управляться с контактами и расписанием. Соответственно их и опрашивали. Наверняка есть случаи, когда фокус-группы очень полезны и важны, но таких немного, как мне кажется.
Одна из причин этого люди не могут нормально предсказать себя когда они в нормальном состоянии (не говоря уж об измененных страх там, стресс или возбуждение).
То есть юзер говорит да, хочу купить, буду пользоваться. Но по каким-то причинам не покупает и не пользуется. Это как в юзабилити не спрашивай юзеров, что им нужно. Дай им это, и посмотри что они будут делать :)
Вообще, как мне кажется, если бы существовал простой ответ на вопрос "делать Y или нет", то не было б неудачных проектов (коих большинство, кстати), мир был бы лучше, а гаджеты умнее и дешевле :)
"Palm - пальма первенства" - крутой каламбур!
Отличный комментарий. Заставил подумать.
Как раз работаю над своим проектом, так что интересно.
Здесь проскользнула очень интересная мысль
" ... иногда просто руки опускаются.
... ты получаешь опыт, и это самое главное. "
Вот, что, лично для меня, является мотивацией в то время, когда кажется, что ничего не получается и всё делаю зря.
" ... иногда просто руки опускаются.
... ты получаешь опыт, и это самое главное. "
Вот, что, лично для меня, является мотивацией в то время, когда кажется, что ничего не получается и всё делаю зря.
в СНГ явно новый трэнд - РАБОТОГОЛИЗМ (
Sign up to leave a comment.
5 уроков, которые я извлек из создания своих онлайн сервисов