Comments 24
Почему вопрос ставится или-или?
Почему не использовать И текстовое описание И макет для наглядности? Ведь не так уж сложно нарисовать макет по готовому текстовому описанию или описать словами готовый макет?
Почему не использовать И текстовое описание И макет для наглядности? Ведь не так уж сложно нарисовать макет по готовому текстовому описанию или описать словами готовый макет?
Я так понимаю, что макеты хотят использовать те, кто не может описать словами. В примере вместо макета (который съедает ресурсы подготовки ТЗ) можно использовать схему расположения элементов на странице.
Согласен с автором - конечно необходимо и текстовое описание, нельзя обойтись лишь одним из описаний...
К сожалению не могу приложить готовое ТЗ, оно представляет собой доку на 28-ми страницах, половина это действительно макеты - остальная - текстовое описание...
К сожалению не могу приложить готовое ТЗ, оно представляет собой доку на 28-ми страницах, половина это действительно макеты - остальная - текстовое описание...
Не вижу смысла сравнивать - должно быть и то и другое. Ты же не отдаш программеру макет и скажешь "программируй" :) Надо и то и другое. Так почему бы не предоставить это все и дизайнеру и программеру?
Техническое задание это еще и юридический документ, приложение к договору. Поэтому текст там является крайне важным. Может не быть рисунков, но текст быть обязан! Текст в ТЗ не заменит ничто. Разве что проиллюстрирует.
Короче все просто: не true/false, т.е. не 0% и 100%, а 30% на 70% или 50% на 50% или 20% на 80% в зависимости от задачи.
Однозначность удобна компутерам, а также ограниченным умом людям, а также тем, кому лень сочинять сложные алгоритмы.
Поэтому так любят холивары, что вот выясним истину и одни в говне, а другие в малине.
Мир не битовый, как показывает практика :)
Однозначность удобна компутерам, а также ограниченным умом людям, а также тем, кому лень сочинять сложные алгоритмы.
Поэтому так любят холивары, что вот выясним истину и одни в говне, а другие в малине.
Мир не битовый, как показывает практика :)
К чему за полтора года пришел я (особенность момента – команда разработчиков осталась неизменной, что, безусловно, дает бонус во взаимопонимании):
Веб-сайт, в конечном итоге, представляет из себя набор интерфейсов (в первом приближении), таким его привык видеть заказчик, таким его привыкли видеть вообще все -). Таким образом, мне кажется, что тз нагляднее создавать в виде общей карты сайта связанной с требуемыми схемами (макетами) ссылками, а каждый макет описывать специально оформленными вставками, либо, если описание громоздкое, снабжать ссылками на соответствующие страницы хелпа (подробного описания).
Таким образом, заказчик видит тз в очень доступном виде и легко в нем ориентируется (больше правок на стадии проектирования = меньше правок на стадии разработки), разработчики видят общую картину и легко переходят к частному, детальному описанию, документ, в целом, достаточно однозначный и слабо поддается вариативным трактовкам.
Разрабатываю я тз в InDesign-е, чей инструментарий позволяет оформить макеты в очень наглядном и эстетичном виде, при этом подчеркивая их схематичность, позволяет снабдить страницы документа перекрестными ссылками, на выходе выдает четкий pdf файл с работающими ссылками между страницами с картой/схемами/описанием.
P.s. Соберусь со временем, напишу более подробный материал по созданию тз в InDesign-е.
Веб-сайт, в конечном итоге, представляет из себя набор интерфейсов (в первом приближении), таким его привык видеть заказчик, таким его привыкли видеть вообще все -). Таким образом, мне кажется, что тз нагляднее создавать в виде общей карты сайта связанной с требуемыми схемами (макетами) ссылками, а каждый макет описывать специально оформленными вставками, либо, если описание громоздкое, снабжать ссылками на соответствующие страницы хелпа (подробного описания).
Таким образом, заказчик видит тз в очень доступном виде и легко в нем ориентируется (больше правок на стадии проектирования = меньше правок на стадии разработки), разработчики видят общую картину и легко переходят к частному, детальному описанию, документ, в целом, достаточно однозначный и слабо поддается вариативным трактовкам.
Разрабатываю я тз в InDesign-е, чей инструментарий позволяет оформить макеты в очень наглядном и эстетичном виде, при этом подчеркивая их схематичность, позволяет снабдить страницы документа перекрестными ссылками, на выходе выдает четкий pdf файл с работающими ссылками между страницами с картой/схемами/описанием.
P.s. Соберусь со временем, напишу более подробный материал по созданию тз в InDesign-е.
На тему прототипирования в InDesign есть хорошая статья от В.Головача. Большое ему спасибо за неё. Это была моя "входная дверь" в страну прототипов.
Но я уже давно перешел на Axure RP. И там помимо инструментария для прототипирования есть модуль подготовки спецификации, что достаточно удобно.
Но я уже давно перешел на Axure RP. И там помимо инструментария для прототипирования есть модуль подготовки спецификации, что достаточно удобно.
Модуль подготовки спецификации — а в чем его функциональность?
Для каждого экранного прототипа можно добавить описание. Модуль занимается тем, что формирует структурированный doc-файл со скриншотами экранов и добавляет им указанное описание. На самом интерактивном прототипе описание тоже видно, это достаточно удобно для разработчиков: открыл конкретную страницу и тут же видишь пояснения.
Вроде выше писали. Уверен, что логику работы лучше описывать текстом(показать ее сложно), а то, где нужно показать как это выглядит в тот или иной момент - макетом.
Макеты и правда важны. Я делаю так: макеты, и к каждому текстовый комментарий, объясняющий что это за поля, куда ведет эта ссылка, какое ограничение по символам у поля и .т.п. Ну и вступительный текст вначале, конечно, еще до макетов.
Мы тоже используем Axure - лучшая программа для прототипирования интерфейсов.
Именно в ней мы разрабатывали свой интерактивный макет (html) после тщетных двух недельных попыток объяснить аусорсинговой компании (по телефону и электронной почте), что мы имели в виду под этим статическим макетом и этим описанием. Результат виден в проекте ОФИСНАЯ ПЛАНЕТА.
Именно в ней мы разрабатывали свой интерактивный макет (html) после тщетных двух недельных попыток объяснить аусорсинговой компании (по телефону и электронной почте), что мы имели в виду под этим статическим макетом и этим описанием. Результат виден в проекте ОФИСНАЯ ПЛАНЕТА.
И мы и мы :) Вещь просто супер! Тут можете посмотреть на сгенерированный проволочный прототип
http://www.brauberg.com/develop/ - обратите внимание на банер - Java скрипт был сгенерирован аксурой атоматически.
http://www.brauberg.com/develop/ - обратите внимание на банер - Java скрипт был сгенерирован аксурой атоматически.
господа! по-моему проблема в том, что никто из веб-разработчиков не представляет что такое на самом деле ТЗ.
во-первых, есть ГОСТы на создание ТЗ. Например в 19 госте есть вот такой раздел: http://www.csrs.ru/gost/19_201_78.htm
из описания: "стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения."
если создается система, собираемая из нескольких, объемная и сложная - посмотрите 34 ГОСТ.
ГОСТы разрабатывали не идиоты, в них действительно есть много полезного. хотя бы прочтите их.
во-вторых, ТЗ должно быть написано так, чтобы и разработчик и заказчик понимали одно и то же (sic!), а как оно будет реализовано на самом деле не важно. те моменты, которые проще объяснить графикой - объяснять графикой, где понятнее словесное описание - словами, если нужно в этом месте загнуть уголок страницы, чтобы обратить на нее внимание - загибайте уголок страницы.
смысл в том, что все пишут ТЗ исключительно из желания прикрыть собственный зад, забывая об истином назначении этого документа - зафиксировать намерения и договориться о взаимопонимании.
во-первых, есть ГОСТы на создание ТЗ. Например в 19 госте есть вот такой раздел: http://www.csrs.ru/gost/19_201_78.htm
из описания: "стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения."
если создается система, собираемая из нескольких, объемная и сложная - посмотрите 34 ГОСТ.
ГОСТы разрабатывали не идиоты, в них действительно есть много полезного. хотя бы прочтите их.
во-вторых, ТЗ должно быть написано так, чтобы и разработчик и заказчик понимали одно и то же (sic!), а как оно будет реализовано на самом деле не важно. те моменты, которые проще объяснить графикой - объяснять графикой, где понятнее словесное описание - словами, если нужно в этом месте загнуть уголок страницы, чтобы обратить на нее внимание - загибайте уголок страницы.
смысл в том, что все пишут ТЗ исключительно из желания прикрыть собственный зад, забывая об истином назначении этого документа - зафиксировать намерения и договориться о взаимопонимании.
UFO just landed and posted this here
Sign up to leave a comment.
ТЗ: макеты или текст?