Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Как-то особо полезной информации не заметил.
Думаю, что исходный проект можно было бы разработать намного дешевле при таком подходе. Уверен, что и скорость выхода на окупаемость при таком подходе выше.
То, что все достаточно просто и занудно — да, но именно правильная простая работа часто ключ к успеху, а не «секрет» какой-нибудь.
То, что все достаточно просто и занудно — да, но именно правильная простая работа часто ключ к успеху, а не «секрет» какой-нибудь.
На самом деле, 26 человек (на данный момент), добавивших пост в избранное, уже показывают, что не зря опубликовал.
Всё гениальное — просто.
Все ли так делают?
Все ли так делают?
Да просто выглядит этот план как «план ради плана», а не ради юзера, так как по сути ничего полезного он не несет кроме мысли «не торопитесь, досконально все проверяйте по 100 раз и только тогда...».
Я думаю что даже для «нулевых» новичков сдесь много воды, а уж Профи и подавно просто прокрутии колесико дальше.
ИМХО конечно.
Я думаю что даже для «нулевых» новичков сдесь много воды, а уж Профи и подавно просто прокрутии колесико дальше.
ИМХО конечно.
Тут сама последовательность интересна, имхо, в которой программирование сервера является последним шагом перед релизом. Мне очень непривычно.
Идея в том, что от лозунга «Делаем быстрый плохой релиз» переходим к «Делаем продуманный и дешевый релиз» (и пошагово расписано как это сделать). Про почему и зачем, если есть деньги на быстрый и доработки после него, можно отдельную заметку написать. А если денег на проект немного, то и рассуждать особо не о чем.
Какой-то «сферический конь в вакууме» получился. Четкий план — это хорошо, только в жизни все по другому обычно получается.
Не вижу причин не придерживаться плана в целом, кроме лени. Естественно, что-то из-за реальной жизни будет несколько меняться, но схему в общем и этапность имеет смысл сохранять. Причем, подобный план может предлагать как заказчик, так и исполнитель (т.е. тестирование и ui делает дизайнер, а не команда стартапа).
Нужно начинать этот текст с того, что вы сделали, а затем рассказывать — как вы это сделали. Иначе невозможно понять — эффективная-ли это методика.
Это не конкретный success story. Возможно, через несколько месяцев так или иначе опубликую результаты ее сознательного применения (сейчас по ней делаю несколько проектов).
Схема же выработана на основе предыдущего личного опыта. Практически во всех прошлых проектах она бы принесла ощутимые результаты.
Схема же выработана на основе предыдущего личного опыта. Практически во всех прошлых проектах она бы принесла ощутимые результаты.
про «сутки не притрагиваться» — ооочень правильное замечание.
спасибо! статья в некоторых местах напомнило рецепт приготовления! :)
Жалко что в Хабре поздно зарегистрировался, а то до сех пор бы ездил на своей машине. Я серьезно.
вы сейчас пересказали одну из глав книги Getting Real?
Думаю, что нет, там главы короче :).
Если серьезно, то, цитата из разговора в «аське» об этой статье:
Я с ней согласен: just do it, пошагово. В своей практике, к сожалению, этого не наблюдаю (что люди кроме того что знают еще и делают, а новички еще и не знают).
И да, книги «Getting Real», «Rework» и «Дизайн пользовательского интерфейса II. Искусство мыть слона» рекомендую.
Если серьезно, то, цитата из разговора в «аське» об этой статье:
Пост из разряда все знают, но никто не выполняет почему-то
а потом: ну отчего же ничего не получилось
Я с ней согласен: just do it, пошагово. В своей практике, к сожалению, этого не наблюдаю (что люди кроме того что знают еще и делают, а новички еще и не знают).
И да, книги «Getting Real», «Rework» и «Дизайн пользовательского интерфейса II. Искусство мыть слона» рекомендую.
Хм… То есть считаете, что плясать нужно от дизайна, а не от функционала (после определения целей и т. п)?
А путь:
— сценарии использования (наброски от руки или ещё как различных последовательностей экранов с комментариями)
— серверный прототип, демонстрирующий основной функционал (выдаёт минимальный html без всяких украшательств, максимум раскидка по сетке, и джаваскриптов, если скрипты не являются существенной частью сервиса, как, например, в гуглдоках)
— проработка юзабилити (тут изменяются при необходимости сценарии, вносится аякс и т. п. с соответствующей минимальной поддержкой со стороны серверного прототипа)
— разработка нормальной серверной части (тот, функционал, что будет в первом релизе), то есть движка, как правило, доработка внутренностей прототипа при зафиксированных интерфейсах
— разработка дизайна, вёрстка, натягивание вёрстки на движок (можно начать параллельно с предыдущим пунктом)
— тестирование юзабилити/дизайна, внесение изменений по результатам
— …
— релиз
считаете порочным? Имхо, «мой» путь позволяет на более ранней стадии собирать фидбэк от потенциальных пользователей по функционалу и юзабилити (главное не зарыться в фичереквестах, и чётко зафиксировать что будет в релизе, а что в следующих версиях и изменять список только в критических или легко реализуемых случаях) при реальном использовании сервиса, а вот как «Попробуйте пользоваться сами, запишите замечания, исправьте» на html-страницах без поддержки сервера, а, тем более, на рисунках от руки не представляю.
А путь:
— сценарии использования (наброски от руки или ещё как различных последовательностей экранов с комментариями)
— серверный прототип, демонстрирующий основной функционал (выдаёт минимальный html без всяких украшательств, максимум раскидка по сетке, и джаваскриптов, если скрипты не являются существенной частью сервиса, как, например, в гуглдоках)
— проработка юзабилити (тут изменяются при необходимости сценарии, вносится аякс и т. п. с соответствующей минимальной поддержкой со стороны серверного прототипа)
— разработка нормальной серверной части (тот, функционал, что будет в первом релизе), то есть движка, как правило, доработка внутренностей прототипа при зафиксированных интерфейсах
— разработка дизайна, вёрстка, натягивание вёрстки на движок (можно начать параллельно с предыдущим пунктом)
— тестирование юзабилити/дизайна, внесение изменений по результатам
— …
— релиз
считаете порочным? Имхо, «мой» путь позволяет на более ранней стадии собирать фидбэк от потенциальных пользователей по функционалу и юзабилити (главное не зарыться в фичереквестах, и чётко зафиксировать что будет в релизе, а что в следующих версиях и изменять список только в критических или легко реализуемых случаях) при реальном использовании сервиса, а вот как «Попробуйте пользоваться сами, запишите замечания, исправьте» на html-страницах без поддержки сервера, а, тем более, на рисунках от руки не представляю.
Сценарии использования — положительно.
Динамический серверный прототип (не просто хтмл/css/js) — отрицательно, если это не обкатка какой-нибудь новой для команды программистов технологии (отдельный вопрос, здесь не касаемся).
Все примерно как у вас, только программисты подключаются после дизайна и юзабилити тестирования. До этого верстальщики максимум. Почему так? Большинство стартапов не являются технически сложными, сомнений что это можно реализовать нет. Вопрос именно в пользователе: будет пользоваться или нет, будет платить за сервис (так или иначе) или нет. Дополнительно, программисты дороже, поэтому желательно, чтобы у них было меньше часов и меньше переделок.
С другой стороны, если вы, например, делаете систему распознания голоса, то дизайн после (если не нужно привлекать инвестиции), сначала должно нормально заработать распознание.
Динамический серверный прототип (не просто хтмл/css/js) — отрицательно, если это не обкатка какой-нибудь новой для команды программистов технологии (отдельный вопрос, здесь не касаемся).
Все примерно как у вас, только программисты подключаются после дизайна и юзабилити тестирования. До этого верстальщики максимум. Почему так? Большинство стартапов не являются технически сложными, сомнений что это можно реализовать нет. Вопрос именно в пользователе: будет пользоваться или нет, будет платить за сервис (так или иначе) или нет. Дополнительно, программисты дороже, поэтому желательно, чтобы у них было меньше часов и меньше переделок.
С другой стороны, если вы, например, делаете систему распознания голоса, то дизайн после (если не нужно привлекать инвестиции), сначала должно нормально заработать распознание.
С преждевременным подключением программистов одна идея: выпустить первый релиз быстрее. Это получается за счет качества продуманности релиза. Потом идут исправления и «как же мы об этом сразу не подумали». Именно на этом моменте можно сэкономить приличное кол-во денег. Особенно, если у вас уже есть явные конкуренты и рынок не пустой.
Ну так потому и динамический прототип (плавно перерастающий в релиз движка :) ), чтобы можно было провести проработку и тестирование юзабилити на реальных задачах реальными пользователями (закрытое альфа-тестирование, например) — сложно заставить потенциального пользователя ввести сотню форм в «никуда», чтобы получить от него фидбэк, например, о том, стоит ли разбивать ФИО или дату рождения на 3 разных поля или лучше сделать это одним полем (тут даже такие «мелочи», как уровень «компьютерной грамотности» персонала клиентов надо учитывать — например, не редкость переключение между полями форм мышкой, а не табом). А вот заверив потенциального клиента, что эти данные никуда не пропадут и будут доступны ему и в окончательной версии продукта, можно рассчитывать на энтузиазм с его стороны (административными методами вызывающий энтузиазм у его персонала :) ) в плане реального тестирования и реальных отзывов об удобстве ввода не одной, не десяти, а сотни или даже тысяч форм.
Ну и ещё, если тестеров интерфейса привлекать со стороны (не важно, знакомые, потенциальные клиенты, фрилансеры или фирма, оказывающая такие услуги), то динамический прототип позволяет контролировать действительно ли они выдали свои рекомендации по изменению UI на основе опыта ввода сотни форм за день или ввели одну и забили. А это, как вы понимаете, совсем разные сценарии в плане юзабилити.
Впрочем, если сервис предназначен не для автоматизации рабочих мест в бизнесе, не для большого онлайна (в смысле сколько средний пользователь будет проводить времени на нём, например, «напоминалки» и домашняя бухгалтерия совсем разные в этом плане по сравнению с соцсетями и браузерными ММО играми), а для периодического нечастого использования простым пользователем, то разработка «от дизайна» имеет право на жизнь :)
Ну и ещё, если тестеров интерфейса привлекать со стороны (не важно, знакомые, потенциальные клиенты, фрилансеры или фирма, оказывающая такие услуги), то динамический прототип позволяет контролировать действительно ли они выдали свои рекомендации по изменению UI на основе опыта ввода сотни форм за день или ввели одну и забили. А это, как вы понимаете, совсем разные сценарии в плане юзабилити.
Впрочем, если сервис предназначен не для автоматизации рабочих мест в бизнесе, не для большого онлайна (в смысле сколько средний пользователь будет проводить времени на нём, например, «напоминалки» и домашняя бухгалтерия совсем разные в этом плане по сравнению с соцсетями и браузерными ММО играми), а для периодического нечастого использования простым пользователем, то разработка «от дизайна» имеет право на жизнь :)
Ориентация, скажем, на то, что обычно появляется в блоге «Я пиарюсь».
Ваши подходы так же важны, но они более дорогие и дополнительно покрывают более тонкие моменты, т.е. можно просто позже применять. Тут же важно добиться приемлемости результата первого релиза, т.е. чтобы им пользовались и за него платили деньги (по сути проверка идеи стартапа на прототипе). А потом уж, как у любого успешного сервиса, бесконечные доработки для увеличения пользовательской базы и прибыли.
Ваши подходы так же важны, но они более дорогие и дополнительно покрывают более тонкие моменты, т.е. можно просто позже применять. Тут же важно добиться приемлемости результата первого релиза, т.е. чтобы им пользовались и за него платили деньги (по сути проверка идеи стартапа на прототипе). А потом уж, как у любого успешного сервиса, бесконечные доработки для увеличения пользовательской базы и прибыли.
В качестве онлайн-альтернативы Balsamiq Mockups рекомендую https://gomockingbird.com/
В нем можно включить модульную сетку под 960px/16 колонок.
В нем можно включить модульную сетку под 960px/16 колонок.
>>favicon
Видимо вы не пользовались своим же руководством, делая сайт вашей компании.
Видимо вы не пользовались своим же руководством, делая сайт вашей компании.
Интересно, что статья неплохо согласуется с идеями Алана Купера.
«Getting Real» мне (не имеющему опыта в вопросе) показался спорным из-за того, что шел вразрез с принципами Купера.
«Getting Real» мне (не имеющему опыта в вопросе) показался спорным из-за того, что шел вразрез с принципами Купера.
Спасибо, интересно.
Обычно я делаю не так — рисую макет на бумаге, потом в ворде, а потом сразу пишу ТЗ
Обычно я делаю не так — рисую макет на бумаге, потом в ворде, а потом сразу пишу ТЗ
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как не продать машину