Comments 131
UFO just landed and posted this here
Самое страшное, когда приходят с копи-пастом какого-нибудь шаблонного технического задания, найденного на просторах сети, с минимальными изменениями. Или когда бизнес-аналитика компании-исполнителя просят подготовить развернутое техническое задание по результатам получасового совещания с заказчиком.
Из опыта фриланса, если заказчик без ТЗ и даже не собирается его делать, после того, как ты ему даже объяснишь зачем оно — это не серьйозный заказчик и 90%, что ты потратишь с ним время впустую.
UFO just landed and posted this here
Из опыта фриланса, если заказчик без ТЗ и даже не собирается платить что бы мы его сделали, то просто нужно говорить сумму с запасом для рисков. Зачем терять заказчика.
нет я имел ввиду тип людей, которые говорят, я незнаю придумай сам или на твое усмотрение. Человек который делает проэкт должен знать, что и как ему нужно.
Много раз попадались такие заказчики. И в 90% все проходило отлично.
Тут надо смотреть его личную заинтересованность в проекте если он даже не озаботился тз это одно,
а если он понятия не имеет как лучше реализовать это другое.
Часто встречал что исполнители начинают требовать описать в тз особенности реализаций.
Тут надо смотреть его личную заинтересованность в проекте если он даже не озаботился тз это одно,
а если он понятия не имеет как лучше реализовать это другое.
Часто встречал что исполнители начинают требовать описать в тз особенности реализаций.
Он может вообще такого термина как ТЗ не знать и это ещё ни о чем не говорит. Главное чтобы у него было комплексное видение того, что он хочет получить. Если нет и в разумные сроки сформировать не может, тогда лучше держаться подальше или сформулировать (и согласовать, конечно) ТЗ самому. Ведь исполнителям не хочется брать на себя ответственность и риски за принятие решений, которые потом будут пересмотрены с формулировкой «я совсем не это имел в виду».
Эм, Scrum?
Абсолютно согласен с вами!
Спасибо! Интересно и похоже на правду.
Безусловно хорошо прописанная концепция-техзадание значительно упрощает жизнь. Только когда ее начинаешь воплощать в жизнь — сразу всплывают десятки и сотни мелочей, которые могут существенно повлиять на функциональность и внешний вид. Надо постараться учесть максимум мелочей заранее, а остальные не бояться заносить в концепцию.
А по поводу статистики — могу добавить свои пять копеек. У меня уже год есть концепция, пусть и не так подробно расписанная, но вот с командой, особенно с программистами, как-то пока не очень складывается. Что-то делается плохо или затягивается сильно и не делается, в общем непросто, но я не отчаиваюсь и продолжаю пытаться. Проект интересный, жаль потерянное время, но вера в то, что рано или поздно он заработает и «потрясет мир» подпитывает. Вот сейчас нашли программиста и ищем еще одного со знанием rails, чтобы таки запуститься.
P.S. Ошибки проверьте в тексте внимательно, попадаются иногда.
Безусловно хорошо прописанная концепция-техзадание значительно упрощает жизнь. Только когда ее начинаешь воплощать в жизнь — сразу всплывают десятки и сотни мелочей, которые могут существенно повлиять на функциональность и внешний вид. Надо постараться учесть максимум мелочей заранее, а остальные не бояться заносить в концепцию.
А по поводу статистики — могу добавить свои пять копеек. У меня уже год есть концепция, пусть и не так подробно расписанная, но вот с командой, особенно с программистами, как-то пока не очень складывается. Что-то делается плохо или затягивается сильно и не делается, в общем непросто, но я не отчаиваюсь и продолжаю пытаться. Проект интересный, жаль потерянное время, но вера в то, что рано или поздно он заработает и «потрясет мир» подпитывает. Вот сейчас нашли программиста и ищем еще одного со знанием rails, чтобы таки запуститься.
P.S. Ошибки проверьте в тексте внимательно, попадаются иногда.
Спасибо. Перечитал n-ый раз, исправил ошибки.
>> Спасибо! Интересно и похоже на правду.
Ох, как же мне жаль, что уже сотня человек посчитала эту статью за правду и добавила в избранное.
В общем если коротко (развернутые обоснования по каждому пункту в случае чего тоже могу дать. Но сейчас хочется выделить главное):
— Читая топик, сложилось впечатление, что его писал школьник/студент с очень небольшим реальным опытом разработок. Веб-разработок в частности. Очень удивился, посмотрев в профиле возраст и описание автора.
— половина описанных вещей в топике — просто бред
— половина оставшейся части это антисоветы, то есть является тем, о чем НЕ нужно думать в процессе развития концепции, проектирования и запуска проекта. Особенно новичкам (автор вначале упоминул, что статья исключительно для новичков)
Итог:
— статью «для новичков» писал сам новичок
— полезность статьи не то что нулевая, она вредна для прочтения новичками
— автор, имей чувство ответственности, удали статью, это лучшее что можно сделать.
Ох, как же мне жаль, что уже сотня человек посчитала эту статью за правду и добавила в избранное.
В общем если коротко (развернутые обоснования по каждому пункту в случае чего тоже могу дать. Но сейчас хочется выделить главное):
— Читая топик, сложилось впечатление, что его писал школьник/студент с очень небольшим реальным опытом разработок. Веб-разработок в частности. Очень удивился, посмотрев в профиле возраст и описание автора.
— половина описанных вещей в топике — просто бред
— половина оставшейся части это антисоветы, то есть является тем, о чем НЕ нужно думать в процессе развития концепции, проектирования и запуска проекта. Особенно новичкам (автор вначале упоминул, что статья исключительно для новичков)
Итог:
— статью «для новичков» писал сам новичок
— полезность статьи не то что нулевая, она вредна для прочтения новичками
— автор, имей чувство ответственности, удали статью, это лучшее что можно сделать.
Может приведёте ссылки на статьи на хабре, которые, по вашему мнению, полезны для чтения по этому поводу?
Проблема в том, что я так до сих пор и не пойму по какому «этому поводу». То есть остается непонятно, о чем вы хотели написать, какую цель статьи ставили. То ли вы хотели рассказать о том, как надо работать над концепцией проекта, то ли вы хотели написать о факторах успеха проектов, то ли вы хотели написать о том, как начинать проект — непонятно.
Вот пару хороших статей близкой тематики:
habrahabr.ru/blogs/startup/107380/
habrahabr.ru/blogs/startup/66273/
И вне хабра тоже:
the-notebook.org/21/04/2006/idei-dlya-startapa/
(Кстати ооочень рекомендую к прочтению все статьи Пол Грэма о стартапах и бизнесе в целом. Список статей например искать здесь habrahabr.ru/blogs/development/73402/ )
Вот пару хороших статей близкой тематики:
habrahabr.ru/blogs/startup/107380/
habrahabr.ru/blogs/startup/66273/
И вне хабра тоже:
the-notebook.org/21/04/2006/idei-dlya-startapa/
(Кстати ооочень рекомендую к прочтению все статьи Пол Грэма о стартапах и бизнесе в целом. Список статей например искать здесь habrahabr.ru/blogs/development/73402/ )
По-моему, целый параграф про статистику объясняет цели моей статьи. У абсолютного большинства молодых web-проектов нет какой-либо адекватно оформленной концепции. В этой статье Я предложил свой вариант написания концепции web-проекта.
По поводу ссылок:
Только habrahabr.ru/blogs/startup/107380/ может новичкам хоть как-то помочь. Остальное всё общие советы для людей, работавших в web-проектах.
При этом Вы не привели источников относительно web-пректов.
По поводу ссылок:
Только habrahabr.ru/blogs/startup/107380/ может новичкам хоть как-то помочь. Остальное всё общие советы для людей, работавших в web-проектах.
При этом Вы не привели источников относительно web-пректов.
Вы не написали самого главного — какие ваши проекты были сделаны с использованием этой концепции? Насколько они успешны? Покажите их пожалуйста.
Официальный сайт Волгоградского планетария — volgogradplanetarium.volgadmin.ru
какие параметры его успешности?
Как Вы могли понять, Я рассматриваю только один параметр — наличие адекватной концепции проекта.
может тогда и сайт не надо было делать? раз есть «концепция» — значит все успешно.
volgogradplanetarium.volgadmin.ru/Photo.aspx — вот на этой странице четко прослеживается концепция. Правда, реализация пока подкачала :)
Вы пишете:
>> В этой статье рассмотрены анализ успешности «зелёных» web-проектов, причины их провалов и методика написания концепции проекта
и приводите некую статистику.
А далее в статье идет бред про логику, кодировку utf8, magic_quotes, придумывание девиза и логотипа и прочую херню. Вы действительно думаете, что выбор кодировки проекта каким-либо раком относится к успешности проектов? Или может быть причины провалов проекта кроются в остутствии innoDB? А может серверное сжатие как-то связано с методикой написания концепции проекта? Нет. Тогда почему >50% вашей статьи занимают непонятно откуда взявшиеся (а, главное, зачем) технические детали?
Вы сказали, что речь пойдет об анализе успешности проектов. В статье кроме пары унылых абсолютно поверхностно затрагивающих тему графиков об этом нет ничего.
Вы сказали, что расскажете о методике написания концепции (сама формулировка даже неправильна. Не существует «методики написания концепции»). В статье вместо этого вы вообще о несвязных вещах начали рассказывать.
Это я все к чему объясняю — действительно непонятно, что же вы хотели донести и какую тему раскрыть. Вы обозначаете одну тему — а пишите о несвязных вещах
>> В этой статье рассмотрены анализ успешности «зелёных» web-проектов, причины их провалов и методика написания концепции проекта
и приводите некую статистику.
А далее в статье идет бред про логику, кодировку utf8, magic_quotes, придумывание девиза и логотипа и прочую херню. Вы действительно думаете, что выбор кодировки проекта каким-либо раком относится к успешности проектов? Или может быть причины провалов проекта кроются в остутствии innoDB? А может серверное сжатие как-то связано с методикой написания концепции проекта? Нет. Тогда почему >50% вашей статьи занимают непонятно откуда взявшиеся (а, главное, зачем) технические детали?
Вы сказали, что речь пойдет об анализе успешности проектов. В статье кроме пары унылых абсолютно поверхностно затрагивающих тему графиков об этом нет ничего.
Вы сказали, что расскажете о методике написания концепции (сама формулировка даже неправильна. Не существует «методики написания концепции»). В статье вместо этого вы вообще о несвязных вещах начали рассказывать.
Это я все к чему объясняю — действительно непонятно, что же вы хотели донести и какую тему раскрыть. Вы обозначаете одну тему — а пишите о несвязных вещах
Спасибо за строгие комментарии по делу.
Хотелось бы увидеть пост по этой теме от вас — думаю он был бы полезен.
Хотелось бы увидеть пост по этой теме от вас — думаю он был бы полезен.
— Какой успешности? Вы тему топика прочитали?
— Какой методике? Я где нибудь про методику писал? Или Вы хотели, чтобы Я сначала дал академически правильное понятие концепции, затем академическим языком рассказал об этапах построения этой концепции, а потом академическим тоном пожелал людям далёким от всего этого воплощать в жизнь эту академическую мутатень?
Отмечу:
— Что статей на подобную тему Вы так и не привели.
— Какой методике? Я где нибудь про методику писал? Или Вы хотели, чтобы Я сначала дал академически правильное понятие концепции, затем академическим языком рассказал об этапах построения этой концепции, а потом академическим тоном пожелал людям далёким от всего этого воплощать в жизнь эту академическую мутатень?
Отмечу:
— Что статей на подобную тему Вы так и не привели.
Ох, как же сложно с вами разговаривать.
>> Какой успешности? Вы тему топика прочитали? Какой методике? Я где нибудь про методику писал?
Еще раз цитирую ваше же предложение в статье, перечитайте его раза 3:
«В этой статье рассмотрены анализ успешности «зелёных» web-проектов, причины их провалов и методика написания концепции проекта»
>> статей на подобную тему Вы так и не привели.
Я привел 3 статьи, касающиеся концепции проектов и их успешности. Допускаю, что при их прочтении вы нашли мало общего со своей статьей, но это не потому что приведенные мною статьи не на «подобную тему», а потому что ваша статья не отвечает заявленной теме.
>> Какой успешности? Вы тему топика прочитали? Какой методике? Я где нибудь про методику писал?
Еще раз цитирую ваше же предложение в статье, перечитайте его раза 3:
«В этой статье рассмотрены анализ успешности «зелёных» web-проектов, причины их провалов и методика написания концепции проекта»
>> статей на подобную тему Вы так и не привели.
Я привел 3 статьи, касающиеся концепции проектов и их успешности. Допускаю, что при их прочтении вы нашли мало общего со своей статьей, но это не потому что приведенные мною статьи не на «подобную тему», а потому что ваша статья не отвечает заявленной теме.
В общем если коротко (развернутые обоснования по каждому пункту в случае чего тоже могу дать. Но сейчас хочется выделить главное):
Пожаааалуйста :)
Пожаааалуйста :)
Спасибо за топик. Огромное спасибо.
У самого есть идеи, но после прочтения понял, что лучше в учении побольше провести времени, чем в последующем «бою».
Всё же правильно говорят, что тактильные ощущения от карандаша и бумаги лучше стимуоируют работу головного мозга, чем сидение в коде которое выхолащивает первоначальный энтузиазм и оптимизм.
У самого есть идеи, но после прочтения понял, что лучше в учении побольше провести времени, чем в последующем «бою».
Всё же правильно говорят, что тактильные ощущения от карандаша и бумаги лучше стимуоируют работу головного мозга, чем сидение в коде которое выхолащивает первоначальный энтузиазм и оптимизм.
Имеется ли У проекта адекватно оформленная концепция?
Смешались в кучу люди кони (с)
Рядом с вполне адекватными вещами какой то бред про magic_quotes и сжатие данных. Выделяйте такие вещи тогда отдельно в техническое описание, а то к концепции это имеет очень слабое отношение.
Насчет «концепт арта», не пытались использовать специализированный софт для мокапов? Обычно в процессе обсуждения и развития идеи эти интерфейсы по 10 раз переделываются. Вам не лень перерисовывать? :)
Рядом с вполне адекватными вещами какой то бред про magic_quotes и сжатие данных. Выделяйте такие вещи тогда отдельно в техническое описание, а то к концепции это имеет очень слабое отношение.
Насчет «концепт арта», не пытались использовать специализированный софт для мокапов? Обычно в процессе обсуждения и развития идеи эти интерфейсы по 10 раз переделываются. Вам не лень перерисовывать? :)
Насчет уникальности идеи — спорное утверждение. Есть например много успешных примеров локализации «старших братьев».
Тут главное оказаться в нужном месте в нужное время.
Тут главное оказаться в нужном месте в нужное время.
magic_quotes, сжатие данных и пр. — это ограничения, которые оказывают критическое влияние на структуру проекта. Эти ограничения необходимо учитывать с самого начала.
Использовать специализированный софт, Я пробовал — для меня это неэффективно. Я пишу концепцию, так сказать, «на коленке». Доступ к компьютеру есть не всегда, поэтому для меня проще нарисовать.
Использовать специализированный софт, Я пробовал — для меня это неэффективно. Я пишу концепцию, так сказать, «на коленке». Доступ к компьютеру есть не всегда, поэтому для меня проще нарисовать.
Что значит ограничения? Это банальные настраиваемые вещи которые никуда не упираются. Настройки серверной части меняются в считанные секунды.
ок, вот только стартап надо делать на ruby on rails, что, съели, ненужен magic_quotes
Насчет мокапов согласен, сам Axure пользуюсь, практически всегда прототип сайта раза по 4 (как минимум) переделывать приходиться.
Не стоит смешивать понятия концепции и ТЗ. На мой взгляд, концепция — систематизированные «желания заказчика». ТЗ — план работы для разработчика. Если угодно, концецпция должна дать качественный ответ на вопросы «Что будем делать?» и, иногда, «Кто будет делать?», а ТЗ — на вопрос «Как делать?».
В случае с небольшими проектами, когда заказчик — это два или три человека, а разработчики — группа людей, которые могут разместиться в одной комнате, то концепция и ТЗ могут быть объединены. Если же «заказчик» — большая организация с внутренними подразделениями и им нужен серьезный web-инструмент удобный для всех, тогда надо делить концепцию и ТЗ. При этом, концепция должна быть полностью понятна людям сторонним от мира разработки, но написана не в виде эссе, а быть логичным структурированным и систематизированным документом. Любой, кто будет работать с web-ресурсом, прочитав концепцию, должен четко понять как он будет работать с ресурсом и какие возможности ему будут предоставлены. В свою очередь, ТЗ должно разрабатываться на основании концепции и, в первую очередь, оно предназначено для разработчиков. Естественно, ТЗ должно быть максимально конкретизировано.
В статье и в комментариях прочел много здравых мыслей, даже сделал себе тезисный конспект из наиболее лаконичных и важных высказываний.
Эта статья дает лишь один ответ на вопрос из заголовка — «Разработка Концепции/ТЗ — обязательна для любого проекта», но этот ответ слишком бесформенный и всеобъемлющий, практически как 42.
Кстати, раз уже были упомянуты мокапы, кто-то может поделиться линокм на хороший обзор существующих средств для создания макетов интерфейса?
В случае с небольшими проектами, когда заказчик — это два или три человека, а разработчики — группа людей, которые могут разместиться в одной комнате, то концепция и ТЗ могут быть объединены. Если же «заказчик» — большая организация с внутренними подразделениями и им нужен серьезный web-инструмент удобный для всех, тогда надо делить концепцию и ТЗ. При этом, концепция должна быть полностью понятна людям сторонним от мира разработки, но написана не в виде эссе, а быть логичным структурированным и систематизированным документом. Любой, кто будет работать с web-ресурсом, прочитав концепцию, должен четко понять как он будет работать с ресурсом и какие возможности ему будут предоставлены. В свою очередь, ТЗ должно разрабатываться на основании концепции и, в первую очередь, оно предназначено для разработчиков. Естественно, ТЗ должно быть максимально конкретизировано.
В статье и в комментариях прочел много здравых мыслей, даже сделал себе тезисный конспект из наиболее лаконичных и важных высказываний.
Эта статья дает лишь один ответ на вопрос из заголовка — «Разработка Концепции/ТЗ — обязательна для любого проекта», но этот ответ слишком бесформенный и всеобъемлющий, практически как 42.
Кстати, раз уже были упомянуты мокапы, кто-то может поделиться линокм на хороший обзор существующих средств для создания макетов интерфейса?
В Гугле таких линков множество, к примеру: www.1stwebdesigner.com/design/wireframing-mockup-prototyping-tools-plan-designs/
Резюме: если у Вашего проекта нет плана ему капец.
Спасибо, кэп!) Такое надо почаще повторять, но к сожалению это встроено в гены человечества- наступать на грабли.
Спасибо, кэп!) Такое надо почаще повторять, но к сожалению это встроено в гены человечества- наступать на грабли.
Хорошая статья, но на мой взгляд не всегда проекты обречены на провал из-за отсутствия своей идеей. По сути некоторые проекты развивались как копии своих зарубежных аналогов с незначительными изменениями, НО были рассчитаны на пользователей определенных регионов. Далеко ходить не надо, примеры я думаю известны многим.
Да, ТЗ это конечно главное, но тупо лень. (некоторые даже заказывают написание у людей ничего непонимающих в идее :)
Во-первых подборка проектов мне кажется немного странной. Если человек не нашел команду или финансирования для реализации проекта, как его можно считать провальным? Проект то еще даже не начинали делать, а его уже занесли в провальные.
Во-вторых, расписывание детальной концепции я считаю пустой тратой времени, потому что ну не угадаешь как оно обернется. Сидишь, расписываешь детали, тонкости, а потом выясняется, что это вовсе не нужно пользователям. Все эти кодировки, используется сжатие не используется, такие мелочи, что на них внимание не стоит обращать и тратить силы. По ходу развития проекта все станет ясно, пользователи сами подскажут в какую сторону развиваться, да и когда увидишь проект в деле, сам поймешь, что к чему. Мне кажется(возможно я не прав) главное реализовать основную идею, выкатить ее, собрать отзывы, на этом этапе может быть сразу понятно, стоит ли дальше развиваться. Если ты нащупал золотую жилку, есть хороший отклик, то нужно уже раскручивать проект всеми силами, как водяную мельницу, набрасывать на нее воду. Если нет, ну что ж, в этот раз не угадал. Наверняка у многих было такое, приходит в голову какай-та идея и не выходит :), кажется, ну вот она точно будет успешной, загораются глаза и даже не хочется детально смотреть и изучать рынок, чтобы не разочаровывать себя. А потом по ходу реализации понимаешь, что на самом деле идея то, отнюдь не супер и может быть даже не взлетит. В общем, я выступаю за концепцию разведки боем :)
Во-вторых, расписывание детальной концепции я считаю пустой тратой времени, потому что ну не угадаешь как оно обернется. Сидишь, расписываешь детали, тонкости, а потом выясняется, что это вовсе не нужно пользователям. Все эти кодировки, используется сжатие не используется, такие мелочи, что на них внимание не стоит обращать и тратить силы. По ходу развития проекта все станет ясно, пользователи сами подскажут в какую сторону развиваться, да и когда увидишь проект в деле, сам поймешь, что к чему. Мне кажется(возможно я не прав) главное реализовать основную идею, выкатить ее, собрать отзывы, на этом этапе может быть сразу понятно, стоит ли дальше развиваться. Если ты нащупал золотую жилку, есть хороший отклик, то нужно уже раскручивать проект всеми силами, как водяную мельницу, набрасывать на нее воду. Если нет, ну что ж, в этот раз не угадал. Наверняка у многих было такое, приходит в голову какай-та идея и не выходит :), кажется, ну вот она точно будет успешной, загораются глаза и даже не хочется детально смотреть и изучать рынок, чтобы не разочаровывать себя. А потом по ходу реализации понимаешь, что на самом деле идея то, отнюдь не супер и может быть даже не взлетит. В общем, я выступаю за концепцию разведки боем :)
Согласен с «разведкой боем». Для полного осознания концепции проекта можно реализовать его прототип, с минимально необходимым функционалом. И запустить на него своих друзей, потестировать.
«Разведка боем» хороша, если её можно осуществить в короткие сроки.
А если прототип проекта нужно разрабатывать больше полугода? В этом случае, правильная концепция заложенная в начале, позволит сэкономить уйму времени, потраченных на исправление и доработку.
А если прототип проекта нужно разрабатывать больше полугода? В этом случае, правильная концепция заложенная в начале, позволит сэкономить уйму времени, потраченных на исправление и доработку.
Я имел в виду не полноценный прототип, а т.н. «нулевой» прототип. Возможно, я ошибаюсь, но если на разработку нулевого прототипа требуется больше полугода, то начать следует с концепции прототипа :)
Садо-мазо получается, извините.
Так можно до старости дорости стартапером.
Нужно обязательно исследовать рынок. И лучше это делать ДО составления концепции и тем более запуска проекта. Но для этого нужно иметь либо железобетонно работающую технологию/алгоритм, испробованный на практике, либо новое концептуальное преимущество, которое составляет дополнительную или альтернативную ценность.
Правда это уже немного другая тема: не потому что не было концепции, а потому что не было изучения потребностей ЦА.
Так можно до старости дорости стартапером.
Нужно обязательно исследовать рынок. И лучше это делать ДО составления концепции и тем более запуска проекта. Но для этого нужно иметь либо железобетонно работающую технологию/алгоритм, испробованный на практике, либо новое концептуальное преимущество, которое составляет дополнительную или альтернативную ценность.
Правда это уже немного другая тема: не потому что не было концепции, а потому что не было изучения потребностей ЦА.
По вашей логике в web-проектами могут заниматься только люди, которые уже работали web-проектах.
Конечно надо. Я сказал о том, как бывает, когда идея овладевает тобой настолько, что затуманивает разум и все видится в розовом свете. Ты можешь строить планы, чуть ли не до захвата мира, но на самом деле они являются следствием эйфории и слишком оптимистичного взгляда. Даже если подходить с холодной головой, не угадаешь. Слишком много неопределённостей.
Лучше не гадать) Если проект действительно нужен людям, то не стоит откладывать его разработку, даже если еще туман насчет монетизации. Вспомните тот же Гугл с Яндексом — их создатели знали что это «тема» и она востребована.
Опыт подсказывает, что дешевле поспрашивать людей, для которых делается проект, а еще лучше — экспертов в обществе этой ЦА. Тогда может быть 2 пути развития: либо полный отказ от проекта (идея не востребована и т.п.), либо коррекция концепции (скорей всего значительная).
Опыт подсказывает, что дешевле поспрашивать людей, для которых делается проект, а еще лучше — экспертов в обществе этой ЦА. Тогда может быть 2 пути развития: либо полный отказ от проекта (идея не востребована и т.п.), либо коррекция концепции (скорей всего значительная).
Когда слышу про «экспертизы идей» возникает сразу два вопроса:
— почему эти эксперты сами не удовлетворяю известные им потребности людей (а если им потребности не известны, то как они могут судить востребована или нет идея)
— что помешает им украсть идею, если она всё же окажется востребованной, но почему-то в голову ещё никому не пришла
— почему эти эксперты сами не удовлетворяю известные им потребности людей (а если им потребности не известны, то как они могут судить востребована или нет идея)
— что помешает им украсть идею, если она всё же окажется востребованной, но почему-то в голову ещё никому не пришла
Для стартапа, а речь, я так понимаю, об этом, раз идея с 0, я бы предложил Scrum. Некоторые практики XP могут пригодиться, да и то — не все. А вообще, мы же все тут понимаем, что софт пишут люди и никакие практики не спасут проект, если команда не тянет.
Вы знаете что скрам это методология управления проектом, а не его программирования?
Ну так и речь идет о том, как успешно реализовать свой проект. Данные методологии именно для этого и нужны.
Как человек, работающий по Scrum не первый год, я это отчетливо понимаю. А вы считаете, что сила команды — в навыках кодинга? Ну, значит, у нас просто разный взгляд на разработку, не будем холиварить.
Причем тут методики программирования к разработке концепции проекта? Или я чего то недопонимаю?
Мне кажется, что главные вопросы которые должен задать себе автор проекта:
1. Какую задачу решает проект (в чем его польза для пользователей)
2. Как много людей огорчит закрытие проекта
1. Какую задачу решает проект (в чем его польза для пользователей)
2. Как много людей огорчит закрытие проекта
Хотелось бы предложить и другую точку зрения (ничуть не заявляя о неправоте вышеуказанной)
Концепция, особенно такая обьемная это огромный океанский лайнер — с ним очень хорошо, но за 2 минуты он не развернется.
Если мы говорим о проекте рассчитанном узкую/небольшую/заинтересованную аудиторию и уверены в целях задачах и бизнес-модели проекта — то все хорошо и нам не придется резко менять направление.
Если же рынок новый или массовый или за аудиторию надо цеплятся то изменения станут не эксцессом а способом жизни и развития. Взгляните на гугл с его постоянными тестами UI, яху с его сотнями версий главной страницы итд — многие большие веб компании с которыми я говорил делают десятки изменений в неделю, а то и в день — какие то решения стреляют — какие то — нет. Так и с всей идеей в целом. И вот тут, как мне кажется, иногда нужно подумать о прототипе как о концепции — эти два месяца и 35 страниц — не стоит ли в некоторых случаях вложить те же усилия в разработку прототипа для теста и дальше уже вкладывать силы в спецификацию идеи — когда станет понятно что работает а что нет. Такие вот мысли.
В любом случае очень интересно было читать и смотреть. Всегда восхищался людьми готовыми так кропотливо работать над идеей — меня никогда на это не хватает :)
P.S. За последнюю неделю нло вытащило из песочницы просто прекрасную пачку записей, главная просто преобразилась, отличная тенденция по-моему, пришельцам спасибо! ;)
Концепция, особенно такая обьемная это огромный океанский лайнер — с ним очень хорошо, но за 2 минуты он не развернется.
Если мы говорим о проекте рассчитанном узкую/небольшую/заинтересованную аудиторию и уверены в целях задачах и бизнес-модели проекта — то все хорошо и нам не придется резко менять направление.
Если же рынок новый или массовый или за аудиторию надо цеплятся то изменения станут не эксцессом а способом жизни и развития. Взгляните на гугл с его постоянными тестами UI, яху с его сотнями версий главной страницы итд — многие большие веб компании с которыми я говорил делают десятки изменений в неделю, а то и в день — какие то решения стреляют — какие то — нет. Так и с всей идеей в целом. И вот тут, как мне кажется, иногда нужно подумать о прототипе как о концепции — эти два месяца и 35 страниц — не стоит ли в некоторых случаях вложить те же усилия в разработку прототипа для теста и дальше уже вкладывать силы в спецификацию идеи — когда станет понятно что работает а что нет. Такие вот мысли.
В любом случае очень интересно было читать и смотреть. Всегда восхищался людьми готовыми так кропотливо работать над идеей — меня никогда на это не хватает :)
P.S. За последнюю неделю нло вытащило из песочницы просто прекрасную пачку записей, главная просто преобразилась, отличная тенденция по-моему, пришельцам спасибо! ;)
Спасибо. Очень четко и правильно.
Меня тоже поразили низкоуровневые технические детали в концепции.
Концепция — высокоуровневый абстрактный документ, описывающий вИдение будущего продукта/сервиса. Если дополнить концепцию как следует цифрами и выкладками — получится классический бизнес-план. Планирование дальнейшей реализации — классическое управление проектами. И т.д. — венчурное финансирование, маркетинг..., — хорошо проработанные области знаний.
Короче, каша какая-то у Вас получилась. Вывод, конечно, правильный у Вас: если что-то собрались делать — надо подходить к этому серьезно, или вообще не браться.
Концепция — высокоуровневый абстрактный документ, описывающий вИдение будущего продукта/сервиса. Если дополнить концепцию как следует цифрами и выкладками — получится классический бизнес-план. Планирование дальнейшей реализации — классическое управление проектами. И т.д. — венчурное финансирование, маркетинг..., — хорошо проработанные области знаний.
Короче, каша какая-то у Вас получилась. Вывод, конечно, правильный у Вас: если что-то собрались делать — надо подходить к этому серьезно, или вообще не браться.
По поводу уникальности идеи:
— Да, можно взять и реализовать уже существующую идею или создать изменённую копию чужого проекта. Но сразу возникает две трудности: это требует специальной подготовки и навыков ведения web-проектов, и это не всегда законно. По крайне мере, среди участников моей статистики все проекты с чужими идеями закончились провалом.
По поводу таких мелочей, как кодировка, сжатие и тд.:
— Я их включил в концепцию, потому что они являются критическими. Если их опустить в самом начале, то через некоторое время, скорее всего, придётся переписывать основную часть web-проекта. Потери времени на перестроение проекта будут гораздо больше, чем время на изначальное определение этих составляющих.
— Да, можно взять и реализовать уже существующую идею или создать изменённую копию чужого проекта. Но сразу возникает две трудности: это требует специальной подготовки и навыков ведения web-проектов, и это не всегда законно. По крайне мере, среди участников моей статистики все проекты с чужими идеями закончились провалом.
По поводу таких мелочей, как кодировка, сжатие и тд.:
— Я их включил в концепцию, потому что они являются критическими. Если их опустить в самом начале, то через некоторое время, скорее всего, придётся переписывать основную часть web-проекта. Потери времени на перестроение проекта будут гораздо больше, чем время на изначальное определение этих составляющих.
Да, бросьте. Успех проекта уж точно не определяется уникальностью идеи, да и вообще если идея — уникальная, это вовсе не значит, что хорошая. Вконтакт — клон facebook, но facebook — тоже клон. Даже клон клона может быть успешным.
Также отсутствие конкуренции, даже самой малой, самой непрямой, может быть недобрым знаком того, что дело обречено.
Высказывание, что нельзя смотреть сайты конкурентов — тоже весьма спорное, есть риск изобрести велосипед заново, потратив кучу времени.
Наоборот подход — посмотреть и сделать по-другому явно проще.
Как верно заметили выше, нет смысла скатываться в технические дебри LAMP'а. Мне думается, писать надо на чем умеешь, а не на том, что популярно.
Напоследок замечу, что провал не определяется такой ерундой, как кодировки, сжатие и оптимизация базы. Нафига Вам сжатие — если посещаемость 0? Все это притянуто за уши. Для организации работы есть такие инструменты, как Assembla, советую вместо блокнота. Сам сейчас делаю свой стартап на ней.
Также отсутствие конкуренции, даже самой малой, самой непрямой, может быть недобрым знаком того, что дело обречено.
Высказывание, что нельзя смотреть сайты конкурентов — тоже весьма спорное, есть риск изобрести велосипед заново, потратив кучу времени.
Наоборот подход — посмотреть и сделать по-другому явно проще.
Как верно заметили выше, нет смысла скатываться в технические дебри LAMP'а. Мне думается, писать надо на чем умеешь, а не на том, что популярно.
Напоследок замечу, что провал не определяется такой ерундой, как кодировки, сжатие и оптимизация базы. Нафига Вам сжатие — если посещаемость 0? Все это притянуто за уши. Для организации работы есть такие инструменты, как Assembla, советую вместо блокнота. Сам сейчас делаю свой стартап на ней.
— Не видя сайтов конкурентов, люди пишут уникальные вещи, а видя — пишут тоже самое, только изменённое.
— Я привёл лишь одно из описаний концепции. Можете свободно переделать по любимый ваш язык программирования.
— Я привёл лишь одно из описаний концепции. Можете свободно переделать по любимый ваш язык программирования.
А чей клон facebook?
У меня как то сложилось мнение о том, что это первая социальная сеть.
Хотя есть вероятность того, что это тень от успешности проекта
У меня как то сложилось мнение о том, что это первая социальная сеть.
Хотя есть вероятность того, что это тень от успешности проекта
Все смешалось — кони, люди...
Вольное обобщение технологий MSF, RUP, ГОСТ:
Этап 1: Видение проекта — цели, задачи, аудитория, ограничения на ресурсы (временные, денежные, человеческие и другие).
Этап 2: Концептуальный дизайн — сценарии использования, основные модели поведения, уточнение данных первого этапа.
Этап 3: Логический дизайн — модели форм, диалогов, общая архитектура, потоки данных.
Этап 4: Физический дизайн — конкретные языки программирования, основные библиотеки, архитектура проекта и т.п.
При этом magic_quotes — это даже не физический дизайн. Это аспекты реализации, про которые на этапе концепции не то чтобы знать не нужно, но и знать вредно.
Так про какой (какие?) же из этих этапов вы хотели написать?
Про все.
С этими технологиями, которые Вы привели, Я знаком. Толку от них для начинающего web-разработчика никакого. Поимите, в статье речь идёт о проектах, которые делают люди, которые до этого не разу ничем подобным не занимались. Здесь концепция описывается на простом и достаточном уровне для таких людей.
С этими технологиями, которые Вы привели, Я знаком. Толку от них для начинающего web-разработчика никакого. Поимите, в статье речь идёт о проектах, которые делают люди, которые до этого не разу ничем подобным не занимались. Здесь концепция описывается на простом и достаточном уровне для таких людей.
Концепция нужна для того, чтобы увидеть идею проекта без лишних деталей. Острой бритвой провести по проекту и сказать, что:
— «сосиска в булке» — есть концепция хот-дога
— «булка весом 30гр с сосиской на 20гр 2-го сорта, длиной 10 см, заправленная кетчупом хейнц» — не есть концепция хот дога.
Ибо уберите булку совсем — и хот-дога уже нет, а замените булку с 30гр на 25гр и ничего не произойдет. «Все что я знаю про проект» — это называется как угодно — ТЗ, ТП, рабочая документация, но это не концепция!
Твиттер был вообще частично переписан с руби на скалу. И что? У них поменялась концепция? Отнюдь — он как был твиттером — лучшим в мире сервисом микроблогов, так им и остался. Изменилась лишь архитектура и реализация.
— «сосиска в булке» — есть концепция хот-дога
— «булка весом 30гр с сосиской на 20гр 2-го сорта, длиной 10 см, заправленная кетчупом хейнц» — не есть концепция хот дога.
Ибо уберите булку совсем — и хот-дога уже нет, а замените булку с 30гр на 25гр и ничего не произойдет. «Все что я знаю про проект» — это называется как угодно — ТЗ, ТП, рабочая документация, но это не концепция!
Твиттер был вообще частично переписан с руби на скалу. И что? У них поменялась концепция? Отнюдь — он как был твиттером — лучшим в мире сервисом микроблогов, так им и остался. Изменилась лишь архитектура и реализация.
Мощно задвинул.
Цель д.б. одна (абстрактно сформулированная), иначе это уже несколько проектов. Для достижения цели необх. решение нескольких задач. В данном конкретном случае, грубо говоря, цель — организация денежного потока для владельцев ресурса путем удовлетворения неких потребностей клиентов. И дальше начинается: какого потока? каких потребностей? каких клиентов? что значит удовлетворить? как у них появится/проявится эта потребность? как они нас найдут? как все это будет организовано? и т.д.
Слово «абстрактный» — это не ругательное, как многие думают (что-то типа эфемерное, пустое, не имеющее отношения к реальной жизни, пустая болтовня, вздорный вымысел, удел импотентных философов и т.д.). Это пирамида мышления, когда вышележащий слой определяет бытие (смысл, цели, требования, ограничения, контроль и обратная связь) нижележащих. Ошибки/недоработанность в верхних слоях фатальны. В проектном управлении есть даже эмпирическое правило, стоимость ошибки 100:10:1 (по мере убывания абстрактности — от концепции… и до спецификаций на разработку).
Цель д.б. одна (абстрактно сформулированная), иначе это уже несколько проектов. Для достижения цели необх. решение нескольких задач. В данном конкретном случае, грубо говоря, цель — организация денежного потока для владельцев ресурса путем удовлетворения неких потребностей клиентов. И дальше начинается: какого потока? каких потребностей? каких клиентов? что значит удовлетворить? как у них появится/проявится эта потребность? как они нас найдут? как все это будет организовано? и т.д.
Слово «абстрактный» — это не ругательное, как многие думают (что-то типа эфемерное, пустое, не имеющее отношения к реальной жизни, пустая болтовня, вздорный вымысел, удел импотентных философов и т.д.). Это пирамида мышления, когда вышележащий слой определяет бытие (смысл, цели, требования, ограничения, контроль и обратная связь) нижележащих. Ошибки/недоработанность в верхних слоях фатальны. В проектном управлении есть даже эмпирическое правило, стоимость ошибки 100:10:1 (по мере убывания абстрактности — от концепции… и до спецификаций на разработку).
В точку.
Если человек вместо того, чтобы во время проектирования корабля вместо его общих черт — массы, водоизмещения, будет думать о материале ковров в каюте капитана, то его судно просто затонет, когда его спустят на воду. Даже ковры не помогут:)
Если человек вместо того, чтобы во время проектирования корабля вместо его общих черт — массы, водоизмещения, будет думать о материале ковров в каюте капитана, то его судно просто затонет, когда его спустят на воду. Даже ковры не помогут:)
Я понимаю, о чем Вы тут пишете. И с одной стороны с Вами согласен. Концепция сама по себе — это понятие абстрактное, строящиеся на уровне представления и правил формирования проекта.
Но концепция не может быть оторвана от технической части. Именно благодаря пониманию технической части мы можем создавать и развивать концепции. Я и Вы знаем технические аспекты web-проектов, поэтому можем отбросить их и работать с концепции на уровне абстракции, но у большинства людей, которые начинают свой нелёгкий путь web-разработчиков этих знаний нет. Вот поэтому Я постарался в статье объединить и абстрактные понятия и критические технические моменты.
Но концепция не может быть оторвана от технической части. Именно благодаря пониманию технической части мы можем создавать и развивать концепции. Я и Вы знаем технические аспекты web-проектов, поэтому можем отбросить их и работать с концепции на уровне абстракции, но у большинства людей, которые начинают свой нелёгкий путь web-разработчиков этих знаний нет. Вот поэтому Я постарался в статье объединить и абстрактные понятия и критические технические моменты.
Вы описали только техническую часть, это не концепция, с скорее набросок ТЗ.
Однако в успехе веб проекта кроме технической части есть еще другие. Очень важные вопросы это кто ваши клиенты, и как собираетесь привлечь их на свой сайт.
Однако в успехе веб проекта кроме технической части есть еще другие. Очень важные вопросы это кто ваши клиенты, и как собираетесь привлечь их на свой сайт.
— Про целевую аудиторию пункт имеется.
— Про то, как привлечь целевую аудиторию, как раскрутить проект, как продать проект, как юридически оформить и тп. Я не писал, так как эти моменты определяются целью проекта и не обязательно в нём присутствуют. Я четко обозначил в стать, что в мою концепцию необходимо дописать всё, что относится к вашему проекту (пункт «остальное»).
— Про то, как привлечь целевую аудиторию, как раскрутить проект, как продать проект, как юридически оформить и тп. Я не писал, так как эти моменты определяются целью проекта и не обязательно в нём присутствуют. Я четко обозначил в стать, что в мою концепцию необходимо дописать всё, что относится к вашему проекту (пункт «остальное»).
Спасибо за топик. Сам убеждаюсь, что без документированной коцепции или идеи проекта из него ничего не получится. Но у меня несколько замечаний чисто технических — многие вещи, исключая первоначальные наброски, куда удобнее делать в программных средствах, для этого предназначенных. Говорю так, потому что сколько раз терялись бумажные листики с важной информацией, которую восстановить не удавалось.
Хороший топик. Каждый проект я начинал раньше с ассоциативных карт на альбомных листах, и описания в тетради :) Подход ваш мне нравится.
Спасибо за цифры)
Спасибо за цифры)
Офигеть, и ЭТО — на главной хабра, 93 человека добавили в избранное, итоговая оценка 45… Ребят, что происходит с хабром? Почему откровенный бред (хех, кодировка и magic_quotes в vision!) так интересен, неужели при таком интересе сложно почитать нормальные статьи по управлению проектами? (я уж и не надеюсь на изучение методологий)
Не думал, что когда-нибудь скажу это, но хабр явно уже не тот. Или я уже не тот.
Не думал, что когда-нибудь скажу это, но хабр явно уже не тот. Или я уже не тот.
Пока есть люди, оставляющие такие комментарии, есть еще надежда. Спасибо, друг!
Полностью согласен. Чтобы варить кашу почитайте рецепт, чтобы разрабатывать проекты — почитайте «управление проектами», например, Кита Локера и Джеймса Гордона. А вот статья — это нечто. Посоветовал человек — ошибок блин поменьше делать :)
понаехали ;-)
Здесь хотя бы из личного опыта человек сам написал, а не компиляшка западных новостей при почти полном непонимании сути из-за банального отсутствия опыта. Что нередко бывает, как вы понимаете.
Из «песочницы», по приглашению НЛО.
Увы, с начала праздников каждая вторая статья по приглашению НЛО — унылое г.
Увы, с начала праздников каждая вторая статья по приглашению НЛО — унылое г.
Статья такая средненькая, но спасибо.
Я сам пишу проект даже больше для себя и группы людей, но концепция направлена на всех. Да и в общем цели заработка денег нет вообще — цель создать этот проект, чтобы люди получили этот инструмент, и мне удобно будет.
Я сам пишу проект даже больше для себя и группы людей, но концепция направлена на всех. Да и в общем цели заработка денег нет вообще — цель создать этот проект, чтобы люди получили этот инструмент, и мне удобно будет.
Тот проект что единственный продолжает жить скорее всего и имеет описанную концепцию, но не в том виде что вы нам тут понаписали. Сам активно работаю над стартапом, могу выделить вещи которые должен четко понимать автор проекта прежде чем искать инвестора и команду для реализации:
— нужно ясно представлять что будет являться продуктом (продукт может быть бесплатным, но должен иметь ценность и интерес для пользователя)
— нужно ясно представлять кто твой «покупатель», что должно побудить его воспользоваться твоим продуктом (идея продукта может быть не уникальной если планируется уникальный способ продвижения который позволит набрать достаточную аудиторию).
— нужно заранее продумать бизнес-модель по которой будет работать проект (способы монетизации, модерации, наполнения, доставки и другое, для каждого типа проекта свое). Представьте один день/неделю/месяц работы вашего стартапа в подробностях на этапе работающего бизнеса.
— и главное на мой взгляд выделить основной функционал и реализовать только его выкинув при этом ко всем чертям всякую универсализацию/реализацию на все случаи жизни (если она не является продуктом конечно). Если действительно что-то еще понадобится вы допилите это в процессе.
И еще, без сильного разработчика способного поднять проект (в одного или с командой) имеющего долю в проекте скорее всего не обойдется.
— нужно ясно представлять что будет являться продуктом (продукт может быть бесплатным, но должен иметь ценность и интерес для пользователя)
— нужно ясно представлять кто твой «покупатель», что должно побудить его воспользоваться твоим продуктом (идея продукта может быть не уникальной если планируется уникальный способ продвижения который позволит набрать достаточную аудиторию).
— нужно заранее продумать бизнес-модель по которой будет работать проект (способы монетизации, модерации, наполнения, доставки и другое, для каждого типа проекта свое). Представьте один день/неделю/месяц работы вашего стартапа в подробностях на этапе работающего бизнеса.
— и главное на мой взгляд выделить основной функционал и реализовать только его выкинув при этом ко всем чертям всякую универсализацию/реализацию на все случаи жизни (если она не является продуктом конечно). Если действительно что-то еще понадобится вы допилите это в процессе.
И еще, без сильного разработчика способного поднять проект (в одного или с командой) имеющего долю в проекте скорее всего не обойдется.
Добавлю так же что за 4 месяца работы над моим проектом он видоизменился чуть менее чем полностью, неизменным осталось лишь направление в котором он будет работать и некоторые аспекты бизнес-модели, всё остальное было не один раз пересмотрено при попытке составить еxecutive summary (краткое но полное описание проекта, концептуально, но без воды). Меняйте видение проекта до тех пор пока не получится одной страницей ясно и четко изложить суть проекта инвестору/клиенту чтобы он его заинтересовал. Не можете объяснить суть на бумаге кратко — значит сами не до конца понимаете что хотите в конце концов получить.
По-моему, статья не для тех, кто собирается искать инвестора/команду, то есть относится к будущему проекту как к серьезному бизнесу. Скорее ЦА статьи — те, у кого появилась какая-то идея, которую хочется реализовать: «стрельнёт» — замечательно, нет — придумаю другую. Даже что может считаться «стрельнёт» может различаться очень сильно, и не всегда выражаться в деньгах, более того, проект может быть расчётно-убыточным, но удачным с других, более важных для автора, позиций, например, тщеславие, а может альтруизм.
Ошибка есть в логике рассуждений и статистике.
Адекватно оформленная концепция есть только у 1 проекта (2%). И угадайте, в каком состоянии находится этот проект? Он активно развивается.
Из этого вы делаете вывод, что все дело — в концепции проекта, причем под концепцией понимаете то, что вы (автор поста) понимаете, хоть выше много критикуют ваше представление о том, что же есть концепция.
Получается вывод уровня «все серийные убийцы ели огурцы». Успешный проект с концепцией, неуспешные — без концепции. Значит в ней и дело. Но, возможно, если бы вы проанализировали гораздо больше проектов, так чтобы среди успешных был не один проект, а хотя бы 10, вы бы заметили, что некоторые успешные проекты не имели никакой «бумажной» концепции, только идеи в голове создателя. А авторы многих провальных проектов — догадались, что надо записать на бумаге про использование magic_quotes, но им почему-то это не помогло.
Ваши рассуждения позволили вам самому запутаться, и поверить, что все дело — вот в этой странной папочке.
Адекватно оформленная концепция есть только у 1 проекта (2%). И угадайте, в каком состоянии находится этот проект? Он активно развивается.
Из этого вы делаете вывод, что все дело — в концепции проекта, причем под концепцией понимаете то, что вы (автор поста) понимаете, хоть выше много критикуют ваше представление о том, что же есть концепция.
Получается вывод уровня «все серийные убийцы ели огурцы». Успешный проект с концепцией, неуспешные — без концепции. Значит в ней и дело. Но, возможно, если бы вы проанализировали гораздо больше проектов, так чтобы среди успешных был не один проект, а хотя бы 10, вы бы заметили, что некоторые успешные проекты не имели никакой «бумажной» концепции, только идеи в голове создателя. А авторы многих провальных проектов — догадались, что надо записать на бумаге про использование magic_quotes, но им почему-то это не помогло.
Ваши рассуждения позволили вам самому запутаться, и поверить, что все дело — вот в этой странной папочке.
Конечно, можно переиграть в сторону того, что проекты закрывается не по причине отсутствия концепции, а из-за отсутствия финансирования или необходимых людей. Но проблема отсутствия концепции остаётся актуальной.
Огромное количество людей пытаются создать свой web-проект без какого-либо описания, без создания адекватной концепции. Я давольно часто на них натыкаюсь и начинаю расспрашивать об их проекте. А они двух предложений по поводу своей идеи связать не могут… Это очень плохо. А ещё хуже, что среди этих идей есть действительно новые и свежие. Эти идеи так и останутся не воплощенными у умах авторов.
Я эту статью написал именно для таких людей, которые хотят начать свой первый web-проект.
Огромное количество людей пытаются создать свой web-проект без какого-либо описания, без создания адекватной концепции. Я давольно часто на них натыкаюсь и начинаю расспрашивать об их проекте. А они двух предложений по поводу своей идеи связать не могут… Это очень плохо. А ещё хуже, что среди этих идей есть действительно новые и свежие. Эти идеи так и останутся не воплощенными у умах авторов.
Я эту статью написал именно для таких людей, которые хотят начать свой первый web-проект.
Но вот только никак не соотносится наличие концепции со включенным или выключенным сжатием :) В процессе реализации концепции даже платформу можно целиком поменять, да не один раз, а вы в концепцию такие мелочи засовываете. Концепция, по-моему, должна описывать ЧТО пользователь видит перед собой, что он может сделать, какие результаты получить. А КАК это будет реализовано — дело десятое, если удовлетворяет «системным требованиям»
Фиксировать такие вещи, конечно, нужно, хотя бы чтобы не упустить при тестировании, но их место явно не концепции, а хотя бы в ТЗ, а то и в исполнительной документации (хотя бы в отчётах «для себя», в readme, а то и только в комментариях в коде).
Фиксировать такие вещи, конечно, нужно, хотя бы чтобы не упустить при тестировании, но их место явно не концепции, а хотя бы в ТЗ, а то и в исполнительной документации (хотя бы в отчётах «для себя», в readme, а то и только в комментариях в коде).
Это самое «ЧТО» нельзя адекватно описать без знания «КАК». Люди, которые начинают впервые писать свой проект, очень далеки от ТЗ, поэтому лучше хоть описывают эти моменты в концепции.
Почему же нельзя? Для этого даже HTML не нужно знать, достаточно иметь минимальный опыт работы с браузером, даже термины типа «выпадающий список» не нужны. Например что-то вроде «пользователь может загрузить свой видеофайл, опционально задав ему тэги, может делиться своими видеофайлами с друзьями, может искать файлы по тэгам» — вот, базовая концепция какого-то видеохочтинга, типа ютуба — нужны тут знания даже клиент-сайд, не говоря о сервер-сайд? Можно достичь результата без дополнительных данных? По-моему, можно — любой нормальный программист справится, да ещё не один вариант реализации предложит. Использовать для этого PHP, Java или ASM, не говоря о каких-то настроеках типа magic quotes — это вопрос реализации, которую нужно выбирать после формулировки концепции, сравнивая какие средства для этой концепции лучше подходят, а не наоборот.
(дополню) + какие ограничения накладываются: например, «силами одного человека, который знает только PHP».
От цели и ограничений идут средства. А не от балды.
От цели и ограничений идут средства. А не от балды.
Я и Вы можем манипулировать такой абстрактной концепцией, которую предлагаете Вы, и можем создать реальный проект без учёта magic_quotes, по одной простой причине — у нас есть техническая подготовка.
Статья же посвящена людям, у которых опыта ведения и разработки web-проектов нет. Вы хоть может представить, что будет, если все они будут создавать концепции оторванные от технической части? Будет неимоверное количество нереальных для исполнения идей.
Концепция тесно связана с технической частью и этот факт опускать нельзя.
Статья же посвящена людям, у которых опыта ведения и разработки web-проектов нет. Вы хоть может представить, что будет, если все они будут создавать концепции оторванные от технической части? Будет неимоверное количество нереальных для исполнения идей.
Концепция тесно связана с технической частью и этот факт опускать нельзя.
Берутся первые попавшиеся решения:
PHP? Потому что другого не знаю.
Wordpress? Мне нравится.
UTF-8? В статье посоветовали.
Gzip? Читал, что он полезен.
А спустя месяц начинают ползти несоответствия: Wordpress оказывается не совсем подходит под проект, а у строк в UTF-8 неправильно считается длина. Начинаются переделки: костыли-подпорочки к вордпрессу, переписывание всего со strlen на mb_strlen. Со временем, костылей становится больше, все внимание переключается исключительно на техническую сторону, в проект начинают привлекаться внешние специалисты, кончаются деньги…
… и если в этих муках рождается проект… и радостный автор публикует о нем статью на хабре, то героически подпертый Wordpress, рассчитанный на 3000 юзеров в день, героически падает в первые же 5 минут от 3000 юзеров в час, а те счастливцы, кто успел его посмотреть — дружно рапортуют о том, что, занимаясь техническими деталями, вы забыли про собственно идею. И то, что вы с таким адским трудом сделали — никому на самом деле и не нужно.
PHP? Потому что другого не знаю.
Wordpress? Мне нравится.
UTF-8? В статье посоветовали.
Gzip? Читал, что он полезен.
А спустя месяц начинают ползти несоответствия: Wordpress оказывается не совсем подходит под проект, а у строк в UTF-8 неправильно считается длина. Начинаются переделки: костыли-подпорочки к вордпрессу, переписывание всего со strlen на mb_strlen. Со временем, костылей становится больше, все внимание переключается исключительно на техническую сторону, в проект начинают привлекаться внешние специалисты, кончаются деньги…
… и если в этих муках рождается проект… и радостный автор публикует о нем статью на хабре, то героически подпертый Wordpress, рассчитанный на 3000 юзеров в день, героически падает в первые же 5 минут от 3000 юзеров в час, а те счастливцы, кто успел его посмотреть — дружно рапортуют о том, что, занимаясь техническими деталями, вы забыли про собственно идею. И то, что вы с таким адским трудом сделали — никому на самом деле и не нужно.
Я же четко написал, что можете менять мой шаблон концепции под свои нужды. Меняйте, Я Вам не запрещаю.
По поводу технических решений, которые Я привёл:
— Спорить нам на этой почве глупая затея. Как и Вы, так и Я можем привести десяток причин почему кодировка utf-8 хороша или плоха.
Я вставил в мою схему концепции web-проекта технические нюансы, лишь для того, чтобы люди задумывались о них в самом начале, а не перед запуском проекта.
По поводу технических решений, которые Я привёл:
— Спорить нам на этой почве глупая затея. Как и Вы, так и Я можем привести десяток причин почему кодировка utf-8 хороша или плоха.
Я вставил в мою схему концепции web-проекта технические нюансы, лишь для того, чтобы люди задумывались о них в самом начале, а не перед запуском проекта.
Как же вы не хотите понять: ни кодировка UTF-8, ни PHP, ни апач, ни вордпресс, ни джумла, ни зенд фреймворк — не хороши и не плохи сами по себе.
Они хороши или плохи применительно к конкретной задаче. А когда человек ставит во главу угла технологию, не беря в расчет задачу, то он рискует взять технологию, которая будет великолепно-прогрессивно-чудесна, но совершенно не адекватна решаемой задаче.
Они хороши или плохи применительно к конкретной задаче. А когда человек ставит во главу угла технологию, не беря в расчет задачу, то он рискует взять технологию, которая будет великолепно-прогрессивно-чудесна, но совершенно не адекватна решаемой задаче.
Я Вас понял с самого начала.
В нашем споре две крайности:
— Привязка концепции к технологии приводит к вырождению самой идеи проекта.
— Отрыв концепции от технологии приводит к порождению нереальных для выполнения проектов.
Что лучше и что хуже никто ответить не может. Поэтому Я постарался в этой статье частично связать концепцию с технологиями.
В нашем споре две крайности:
— Привязка концепции к технологии приводит к вырождению самой идеи проекта.
— Отрыв концепции от технологии приводит к порождению нереальных для выполнения проектов.
Что лучше и что хуже никто ответить не может. Поэтому Я постарался в этой статье частично связать концепцию с технологиями.
Технологии тоже бывают ключевые, а бывают вспомогательные.
Gzip и настройки PHP — явно не стержневая технология проекта. С таким же успехом в концепцию можно было бы включить производителя мышки, которой будет пользоваться разработчик при разработке системы, и музыку, которую он при этом будет слушать.
Gzip и настройки PHP — явно не стержневая технология проекта. С таким же успехом в концепцию можно было бы включить производителя мышки, которой будет пользоваться разработчик при разработке системы, и музыку, которую он при этом будет слушать.
Почему-то мне кажется, что человек без технической подготовки на уровне php-программиста про magic_quotes вообще не знает.
По-моему, чтобы создавать концепции веб-проектов достаточно обывательского представления о возможностях современной ИТ вообще, и веб-технологий в частности. Автор проекта составляет концепцию, а затем передаёт её постановщику задач, вот тот уже составляет ТЗ для программистов
По-моему, чтобы создавать концепции веб-проектов достаточно обывательского представления о возможностях современной ИТ вообще, и веб-технологий в частности. Автор проекта составляет концепцию, а затем передаёт её постановщику задач, вот тот уже составляет ТЗ для программистов
Повторю свой комментарий — не только можно (адекватно описать ЧТО без КАК), но и нужно. Представьте, что вы зашли в лифт с Марком Цукербергом или Аррингтоном или Сергеем Брином, и вам надо за 30 секунд рассказать им о чем ваш проект. Вы таки будете им втирать про magic_quotes?
Виталий, поздравляю с первым хабра топиком =)
Пардон, хотел привести как пример того стартапа, где казалось бы всё соотвествует вашему представлению идеального следования ТЗ.
А главная причина фейла всегда одна:
— продукт не пользуется спросом
Даже если он занимает полгода — лучше взять и сделать его по скраму вместе с начальством (или наоборот, с хорошей комманой) только лишь с видением и не бояться в дальнейшем это видение менять под рыночные нужды. Так было с твиттером, так и с фейсбуком, да кажется редко у кого был успех сразу после первой версии продукта.
А главная причина фейла всегда одна:
— продукт не пользуется спросом
Даже если он занимает полгода — лучше взять и сделать его по скраму вместе с начальством (или наоборот, с хорошей комманой) только лишь с видением и не бояться в дальнейшем это видение менять под рыночные нужды. Так было с твиттером, так и с фейсбуком, да кажется редко у кого был успех сразу после первой версии продукта.
Кстати, делать лучше тоже не на бумажке, а например в Visio — у самого потом глаз будет радоваться и другим будет не стыдно показать.
Помню лет 10-12 назад я в школе доклад написал ручкой на бумаге (на компьютер средств особо не хватало), так меня тогда еще засмеяли за мою архаичность :)
Помню лет 10-12 назад я в школе доклад написал ручкой на бумаге (на компьютер средств особо не хватало), так меня тогда еще засмеяли за мою архаичность :)
Как по мне, так важно знать целевую аудиторию проекта, объем рынка
— что бы понять про окупаемость, уместно ли его начинать.
И начать что-то делать.
Все остальное вырисовывается в процессе. Схемы бд, спецификации и прочее.
Сам, делая свой проект, уже раз 10 менял схему бд и постоянно фантазирую на тему решений,
что-то подкручивая, что-то убирая.
Убежден, что написав 38(или сколько там) страниц текста, Вы, на 30ти из них закопали свое время в землю
— получится все равно не так, как Вы планировали. В особенности, если это первый Ваш стартап.
Но если Вы так ответственно подошли к планированию, во всяком случае Вам гораздо легче будет привлекать инвестиции. Инвесторы это любят — продуманность, и толстый документ её подтверждающий.
Есть и обратная сторона этой медали. Чем больше Вы думаете — тем больше отдаляете от реализации.
Чем дальше от реализации тем дольше нужно ждать результата.
Результатов нет — энтузиазм умирает.
Желаю успехов в реализации, в любом случае. :)
Соответственно основная проблема в проектах, на мой взгляд
— отсутствие деятельности, как таковой. И Ваша статистика это вроде подтверждает.
— что бы понять про окупаемость, уместно ли его начинать.
И начать что-то делать.
Все остальное вырисовывается в процессе. Схемы бд, спецификации и прочее.
Сам, делая свой проект, уже раз 10 менял схему бд и постоянно фантазирую на тему решений,
что-то подкручивая, что-то убирая.
Убежден, что написав 38(или сколько там) страниц текста, Вы, на 30ти из них закопали свое время в землю
— получится все равно не так, как Вы планировали. В особенности, если это первый Ваш стартап.
Но если Вы так ответственно подошли к планированию, во всяком случае Вам гораздо легче будет привлекать инвестиции. Инвесторы это любят — продуманность, и толстый документ её подтверждающий.
Есть и обратная сторона этой медали. Чем больше Вы думаете — тем больше отдаляете от реализации.
Чем дальше от реализации тем дольше нужно ждать результата.
Результатов нет — энтузиазм умирает.
Желаю успехов в реализации, в любом случае. :)
Соответственно основная проблема в проектах, на мой взгляд
— отсутствие деятельности, как таковой. И Ваша статистика это вроде подтверждает.
Я что даю 100% гарантию, что моя схема приведёт к успеху?
Вы приписываете этой статье просто чудодейственные свойства.
Вы приписываете этой статье просто чудодейственные свойства.
Одна из главных трудностей, когда разговариваешь с профессионалами своего дела, то, что они разговаривают на своем языке, который для большинства просто непонятен. Это касается не только IT сферы.
С моей точки зрения людей (не профессионалы IT сферы) можно разделить на три уровня понимания (с возрастом и приобретаемыми знаниями уровень может меняться).
Для примера возьмем меня в разные годы.
2008 г. — Низкий (Low) – Судя по данным интернета, сайты пишутся только на HTML и в блокноте.
И сделать это, могут только великие и уважаемые программисты. Такие слова как: PHP, CSS, JS, сервер – это страшные и ужасные слова, которые понимают только программисты.
2009 — Средний (Middle) – PHP,CSS, JS, сервер – это уже не страшные и ужасные слова. Оказывается, в природе есть еще CMS и не только. Я немного могу править HTML и CSS, научился ставить Денвер на компьютере и т.д.
2010 — Высокий (High) — купил домен, смог поставить CMS, начал иногда понимать, что спрашивают у меня программисты.
Поэтому, когда человек приходит со своей гениальной идеей к профессионалу IT сферы, и они дадут обычному человеку (уровень низкий и средний) написать Тех. Задание, то вероятность того, что на основе этого Тех. Задания, его не поймут или засмеют или сделают, так как ему не надо, составляет около 66%. И только в остальных случаях с ним смогут разговаривать и может даже понять чего он хочет.
Статья в общем понравилась, поскольку обозначает определенные шаги, которые надо выполнить для того чтобы идея сформировалась не только в голове, но и на бумаге и в прототипе. И если кто-то сможет подготовить статью, как для начинающих пользователей (уровень понимания низкий и средний) правильно составлять техническое задание (для разных типов сайтов (визитка, блог, сайт компании и т.д.)) и какими инструментами, программами пользоваться, я думаю, многие буду этому человеку благодарны.
С моей точки зрения людей (не профессионалы IT сферы) можно разделить на три уровня понимания (с возрастом и приобретаемыми знаниями уровень может меняться).
Для примера возьмем меня в разные годы.
2008 г. — Низкий (Low) – Судя по данным интернета, сайты пишутся только на HTML и в блокноте.
И сделать это, могут только великие и уважаемые программисты. Такие слова как: PHP, CSS, JS, сервер – это страшные и ужасные слова, которые понимают только программисты.
2009 — Средний (Middle) – PHP,CSS, JS, сервер – это уже не страшные и ужасные слова. Оказывается, в природе есть еще CMS и не только. Я немного могу править HTML и CSS, научился ставить Денвер на компьютере и т.д.
2010 — Высокий (High) — купил домен, смог поставить CMS, начал иногда понимать, что спрашивают у меня программисты.
Поэтому, когда человек приходит со своей гениальной идеей к профессионалу IT сферы, и они дадут обычному человеку (уровень низкий и средний) написать Тех. Задание, то вероятность того, что на основе этого Тех. Задания, его не поймут или засмеют или сделают, так как ему не надо, составляет около 66%. И только в остальных случаях с ним смогут разговаривать и может даже понять чего он хочет.
Статья в общем понравилась, поскольку обозначает определенные шаги, которые надо выполнить для того чтобы идея сформировалась не только в голове, но и на бумаге и в прототипе. И если кто-то сможет подготовить статью, как для начинающих пользователей (уровень понимания низкий и средний) правильно составлять техническое задание (для разных типов сайтов (визитка, блог, сайт компании и т.д.)) и какими инструментами, программами пользоваться, я думаю, многие буду этому человеку благодарны.
ТЗ должен писать человек разбирающийся и в технологиях, и в предметной области (бизнс-аналитик, системный аналитик, постановщик задач, ...), в крайнем случае только в технологиях, потому и не пишут статьи о том, как написать ТЗ, для человека, который не знает чем отличается HTML от CSS.
От автора идеи в идеальных условиях, по-моему, требуется только выдать эту самую идею, сформулировать цель и задачи проекта и как-то убедить работать с ним профессионалов, которые сделают всё, начиная от грамотного бизнес-плана и ТЗ до юзабилити-тестирования и продвижения, причём автору с программистами (кодерами) общаться необязательно и даже вредно :) Сложности начинаются на этапе убеждения профессионалов, они почему-то часто не любят работать бесплатно и даже за долю в прибыли, если вклад автора составляет только «интеллектуальная собственность». Приходится задумываться о поисках инвестиций и/или брать в команду непрофессионалов
От автора идеи в идеальных условиях, по-моему, требуется только выдать эту самую идею, сформулировать цель и задачи проекта и как-то убедить работать с ним профессионалов, которые сделают всё, начиная от грамотного бизнес-плана и ТЗ до юзабилити-тестирования и продвижения, причём автору с программистами (кодерами) общаться необязательно и даже вредно :) Сложности начинаются на этапе убеждения профессионалов, они почему-то часто не любят работать бесплатно и даже за долю в прибыли, если вклад автора составляет только «интеллектуальная собственность». Приходится задумываться о поисках инвестиций и/или брать в команду непрофессионалов
1. пхп не для стартапа. фэйсбук, вконтакте, ага, вот только сейчас все по другому. rails лучше всего. хотя имхо.
2. задача проекта. так, подумаем, какую цель ставили себе создатели твиттера? НИКАКУЮ. Единственное принципиальное отличие — 140 символов. До этого был майспэйс, рсс и тд и тп.
2. задача проекта. так, подумаем, какую цель ставили себе создатели твиттера? НИКАКУЮ. Единственное принципиальное отличие — 140 символов. До этого был майспэйс, рсс и тд и тп.
Писать концепцию 2 месяца? Такая долговременная беременность идеей в итоге закончится выкидышем. И все эти девизы, цели и кривые таблички с концепт-артом, аккуратно сложенные в папочку, отправятся в помойку. Просто потому что энтузиазм улетучивается уже через неделю, если нет подвижек в реализации.
Лучше начинать сразу делать что-то реальное, а потом выбросить на помойку код, который написали, чем изливать свои мечты (а по-другому это не назовешь) на бумагу. На самом деле это один из видов прокрастинации. Я ж не могу начать, пока все не спланировал, не записал. Составил концепт-арт, теперь можно и чайку попить, ага.
Лучше начинать сразу делать что-то реальное, а потом выбросить на помойку код, который написали, чем изливать свои мечты (а по-другому это не назовешь) на бумагу. На самом деле это один из видов прокрастинации. Я ж не могу начать, пока все не спланировал, не записал. Составил концепт-арт, теперь можно и чайку попить, ага.
Хорошее замечание. Не надо мне писать было про два месяца — не к месту.
Объяснюсь:
— На концепцию Я потратил 2 месяца по объективным личным причинам и пишу свой проект уже больше полугода тоже по объективным личным причинам. Если бы у меня была возможность отбросить эти причины и полноценно заниматься моим проектом, то время бы сократилось примерно в 6 раз.
Кстати, несмотря на долгие сроки энтузиазм мой в норме, тоже по объективным личным причинам.
Объяснюсь:
— На концепцию Я потратил 2 месяца по объективным личным причинам и пишу свой проект уже больше полугода тоже по объективным личным причинам. Если бы у меня была возможность отбросить эти причины и полноценно заниматься моим проектом, то время бы сократилось примерно в 6 раз.
Кстати, несмотря на долгие сроки энтузиазм мой в норме, тоже по объективным личным причинам.
Sign up to leave a comment.
Концепция web-проекта или почему мы убиваем свои идеи?