ВиталийМазуревич
Добавил комментарий
12 апреля 2016, 15:41
Мнения
10 заповедей технического задания (с толкованием)
Мила, спасибо. Внедрять надо просто, быстро и решительно. Просто в какой-то момент начать разработку по такой схеме и продавать Заказчику именно такой подход. Почитайте статью вот тут - http://www.cossa.ru/152/112680/ - здесь реальны доводы в пользу такого подхода. Что же касается черновика на начало работы, то у нас есть специально разработанная система документации, которая позволяет с самого начала зафиксировать продукт. Подробнее можете тут посмотреть - https://vimeo.com/143387909
Добавил комментарий
6 апреля 2016, 17:57
Мнения
10 заповедей технического задания (с толкованием)
Михаил, тут речь идёт о том, что автор ТЗ должен понимать предметную область сайта, атрибуты сущностей и связи между ними, а также формат этих атрибутов. Т.е. нужно понимание архитектуры БД сайта, но именно на уровне сущнойстей. Знать код для этого совсем не обязательно, это уже вотчина разработчика.
Добавил комментарий
6 апреля 2016, 13:47
Добавил комментарий
6 апреля 2016, 13:46
Показать еще активности
Добавил комментарий
1 июня 2016, 17:52
Как подготовиться к веб-разработке и получить от этого удовольствие
ТрендыПрекрасный материал. Я бы его в почтовые ящики компаниям подкладывал! Абсолютный must read!
Добавил комментарий
12 апреля 2016, 15:41
10 заповедей технического задания (с толкованием)
МненияМила, спасибо. Внедрять надо просто, быстро и решительно. Просто в какой-то момент начать разработку по такой схеме и продавать Заказчику именно такой подход. Почитайте статью вот тут - http://www.cossa.ru/152/112680/ - здесь реальны доводы в пользу такого подхода. Что же касается черновика на начало работы, то у нас есть специально разработанная система документации, которая позволяет с самого начала зафиксировать продукт. Подробнее можете тут посмотреть - https://vimeo.com/143387909
Добавил комментарий
6 апреля 2016, 17:57
10 заповедей технического задания (с толкованием)
МненияМихаил, тут речь идёт о том, что автор ТЗ должен понимать предметную область сайта, атрибуты сущностей и связи между ними, а также формат этих атрибутов. Т.е. нужно понимание архитектуры БД сайта, но именно на уровне сущнойстей. Знать код для этого совсем не обязательно, это уже вотчина разработчика.
Добавил комментарий
6 апреля 2016, 13:47
Добавил комментарий
6 апреля 2016, 13:46
Добавил комментарий
18 января 2016, 11:31
Чем проектирование отличается от шарлатанства
МненияЗамечательный материал. Готов подписаться под каждой строчкой. Спасибо!
Добавил комментарий
28 октября 2015, 19:49
Дизайн или ТЗ — что раньше?
ТрендыИван, на мой взгляд, всё, что вы написали - разумно. У нас точно так же прототип является частью работ по проектированию продукта. Да, ценник на эту услугу может быть несколько больше, чем у компаний, которые на этапе проектирования делают только ТЗ. Опять же опыт подсказывает, что, сэкономив на проектировании, потом приходится втридорога оплачивать ошибки.
Добавил комментарий
28 октября 2015, 19:43
Дизайн или ТЗ — что раньше?
ТрендыАлександр, вы задали очень верный вопрос. На самом деле, описание всех возможных схем оплаты при описанном мною подходе, достойно отдельной статьи на cossa. Поэтому я коротко опишу схему, которая работает у нас. Когда на оценку приходит проект, то формируется проектная команда во главе с менеджером по продажам – проектировщик, арт-директор и тимлид. Все читают входящую документацию и формируют пул своих вопросов к ней. Проектировщик составляет mind-map продукта, в которой указана постраничная структура продукта и краткий обзор его функций. Mind-map презентуется членам проектной команды, участники вносят свои изменения, и по итогам у всех в головах к этому моменту формируется концепт будущего продукта. Именно этот концепт и оценивается каждым отделом. Менеджер по продажам заворачивает это в коммерческое предложение, которое не просто содержит смету, но и описывает, что именно за эти деньги делается. Безусловно, все специалисты закладывают в свою оценку разумные риски, чтобы не отсекать абсолютно все «хотелки» клиента. Таким образом на руках у Заказчика оказывается КП, которое описывает перечень работ и содержание продукта, который оценивается нашей компанией. В 99 случаях из 100 КП требует презентации с привлечением проектировщика и конечно менеджера по продажам. На презентации вам надо объяснить заказчику, чтό вы оценили и дать понять, что если у клиента другое видение продукта (сейчас или потом), то возможно потребуется переоценка. Опыт показывает, что если честно объявить клиенту о том, что вы делаете конкретную оценку и не накручиваете сверху риски его «хотелок», то между вами растёт доверие, которого так не хватает на нашем рынке. Более того, схема оплаты проектов у нас в компании поэтапная: Заказчик оплачивает этап проектирования (50/50), потом дизайн (50/50) и потом разработка (50/50). И по сути каждый новый этап может быть нами переоценён до его начала, если на предыдущем этапе возникли правки, которые значительно сказываются на бюджете.
Надеюсь, что смог в столь коротком формате комментария ответить на ваш вопрос. В противном случае – стучитесь в FB – https://www.facebook.com/vitaly.mazurevich – пообщаемся.
Добавил комментарий
28 октября 2015, 19:43
Дизайн или ТЗ — что раньше?
ТрендыМаксим, спасибо. На первый вопрос я ответил комментарием выше. Опять же, повторюсь, готов пообщаться в FB, потому что искренне болею за проектирование. Поэтому перейду ко второму вопросу.
Утверждать прототип надо только после его презентации клиенту. Это должна быть встреча, на которой проектировщик рассказывает о том, как им проектировался продукт, почему на странице расположен тот или иной компонент, и как эти компоненты работают. Очень важно в презентации не упускать деталей и рассказывать абсолютно все, даже те вещи, которые вам лично кажутся очевидными. Это значительно минимизирует число хотелок на стадии дизайна. Хорошо, кстати, взять на такую встречу и дизайнера (в идеале: презентовать сначала ваше решение ему, утвердить его с ним и потом уже презентовать клиенту). Если личная встреча невозможна, то рекомендую составлять нотации к прототипу, в которых будет описано все то же, что говорится на презентации. Мой опыт показывает, что при подобной организации процессов, на стадии дизайна вылезают либо совсем «безумные» правки, которые продюсер выносит за рамки текущего релиза или оценивает допкостом в рамках текущего, либо правки сводятся к игре со шрифтами и увеличению логотипа.
Добавил комментарий
28 октября 2015, 19:42
Дизайн или ТЗ — что раньше?
ТрендыСергей, спасибо за вопрос и верное уточнение. В разрезе моего материала, на самом деле не так важно, о чём идет речь – о вайрфреймах, прототипах или мокапах (в терминах статьи на которую вы ссылаетесь). Я использую термин «прототип» скорее в собирательном ключе. Вне зависимости от уровня детализации этого «прототипа» все плюсы и минусы методологий, описанных мною в материале, сохраняются.
Популярные новости
19 ноября 2024, 15:41
19 ноября 2024, 11:26
19 ноября 2024, 10:57
18 ноября 2024, 12:00
18 ноября 2024, 11:48
Как подготовиться к веб-разработке и получить от этого удовольствие
Прекрасный материал. Я бы его в почтовые ящики компаниям подкладывал! Абсолютный must read!