Comments 44
баян
Теперь банановый.
Бумажные описания не очень-то цепляют — в них не видно финиша
Видимо никудышные описания. Мне казалось что смысл описания - именно в том, чтобы очертить границы того, что надо сделать.
Дело не в качестве описаний. Дело в том, что часто (вне зависимости от качества и подробности документации) разработчики обращаются не к ней, а к визуальным документам — дизайну, прототипу, схемам страниц.
Прототип не отменяет текстовые спецификации, он дает еще один взгляд на них. Который для многих гораздо нагляднее и удобнее.
Прототип не отменяет текстовые спецификации, он дает еще один взгляд на них. Который для многих гораздо нагляднее и удобнее.
По нашему опыту талмуды с большим количеством текста программистами и менеджерами проекта игнорируются. Доходит до смешного они начинают задавать вопросы, ответа на которых есть в этих документах.
Картинки с небольшими компактными приложениями много доходчивее.
Картинки с небольшими компактными приложениями много доходчивее.
Я, конечно, понимаю, что «Хабр уже не тот» ©, где много букв прокатывает все реже. И да, статья уже была републикована на GUI.ru, но ведь не все читают GUI.ru и тем более мой блог. Но все равно, не очень понятна такая трешовая реакция. Хабру не нужны авторские материалы? За качество не буду говорить, но по-моему мнению и тех, кто статью републиковал — по крайней мере достаточно сносное.
спасибо. по делу.
спасибо, очень интересно.
А кто создает прототип на html+js? Как я понял, команда разработки в этом не участвует. Значит, созданием прототипа занимаются менеджеры и аналитики?
Просто я слабо представляю себе менеджера, делающего html макет и аналитика, прикручивающего к нему заглушки на js.
А кто создает прототип на html+js? Как я понял, команда разработки в этом не участвует. Значит, созданием прототипа занимаются менеджеры и аналитики?
Просто я слабо представляю себе менеджера, делающего html макет и аналитика, прикручивающего к нему заглушки на js.
Есть два варианта интерактивных прототипов — грубо говоря, черно-белые на основе wireframes и цветные, на основе дизайна. Первые может генерировать автоматом менеджер или аналитик (если они сделаны в программе, которая это умеет), вторые делаются HTML-верстальщиком. В зависимости от свободных людей в команде, интерактивный прототип делается либо тот же человек, что верстает начисто, либо еще один. Многие считают, что делать две верстки дорого, но плюсов гораздо больше. Но не буду забегать вперед — об этом как раз во второй и третьей части :)
большое спасибо, вопрос исчерпан.
А вот, кстати, и вторая часть :)
спасибо. Давно не заходил к Вам в блог, вот и пропустил обновление:))
Спасибо. Читал статью на вашем блоге, интерестно. Особенно приятно, что публикация проиллюстрирована реальными примерами работ, которые можно посмотреть (http://uimodelling.com/) живьем (это относится к следующим частям).
Мог бы - поставил бы +
Мог бы - поставил бы +
Классная статья! второй день собирался прочитать, наконец-то добрался :) как раз сейчас выводим это у нас в компании на новый уровень, и я собираюсь этим серьезнее заняться. теперь буду читать вторую часть. Спасибо!
Спасибо! Сейчас как раз закинул третью часть — там последние штрихи :)
спасибо :) я вчера перечитал почти весь Ваш блог. и нашел там третью статью :)
Надеюсь, нашлось еще много интересного :)
да, у Вас действительно полезные статьи, читал одну за другой, не мог оторваться :) единственное чего не нашел - описание документов которые вы используете и их поддержки по ходу проекта. например у нас принято несколько: Vision/PFD(proposal for development), Estimate и SRS (Software requirements Specification), всей документацией на данный момент у нас занимаются руководители проектов. Думаю, что стоит добавить спецификацию по дизайну с более-менее четкими требованиями, насколько это возможно. и возможно стоит разнести в разные документы test cases и use cases со ссылками из Project Chapter документа. Также, я думаю, что стоит выделить отдельно человека для поддержки документов по проекту. в общем, хочется улучшить проектную документацию и повысить качество и эффективность работы команд. поэтому я сейчас стараюсь ознакомиться максимум с тем что уже есть и придумано, чтобы не изобретать велосипед. :) а за Ваши статьи большое спасибо! очень полезные :)
Спасиб еще раз! До документов я пока не добрался — писал про самые вкусные и понятные вещи вроде схем страниц и прототипов, но постепенно дойду и до них :) Мы пишем Vision, SRS и серию других документов. Не знаю точно, что именно у вас понимается под Estimate, но судя по предположению (объем работ, расчет сроков и стоимости) — также покрывается, но другими документами. Тут все зависит от построенного в компании процесса, так что их названия и состав могут различаться. Но в любом случае те три вещи, что у вас указаны — описание проекта, его оценка и техническое задание — в каком-то виде есть всегда.
Про устав проекта, кстати, я писал недавно, а про остальное пока не успел :) Но со временем все это появится, так что подписывайтесь на RSS :)
Про устав проекта, кстати, я писал недавно, а про остальное пока не успел :) Но со временем все это появится, так что подписывайтесь на RSS :)
Автор, огромное спасибо! Подписался на RSS.
Sign up to leave a comment.
Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 1. Классификация