Вы довольны своим брифом на разработку сайтов? Он даёт ответы на все ваши вопросы, в нём всё привычно и знакомо и, кажется, лучше не придумаешь. Но вы же понимаете, важно, чтобы заказчик был доволен. Иногда стоит критически взглянуть на свой бриф: действительно ли он понятен заказчику и адекватен его потребностям и возможностям?
Мы спросили заказчиков, размещающих тендеры на нашем портале, что им нравится, а что раздражает в брифах разработчиков.
Содержание брифа
По мнению заказчиков, кроме всевозможных технических деталей, бриф должен уточнять:
Бриф не должен иметь маркетингового, дизайнерского или технического перекоса. Не у каждой компании есть миссия и ценности, не все знают преимущества товаров-конкурентов. Да и зачем они разработчику, которому не заказывается контент?
Заказчик не обязан заранее знать иерархию вложенности страниц и связи между ними – для этого как раз и нужен разработчик, который разбирается в вопросах юзабилити и всяко-разных моментах, о которых заказчик и не подозревает.
Иногда вопросы брифа настолько сложно сформулированы, что для ответа на них заказчику требуется перевод с айтишного на русский. Кстати, контакты разработчика на случай, если что-то непонятно по тексту брифа, должны быть всегда в колонтитулах брифа.
Объем и структура
Не стоит слишком вдаваться в детали. Если бриф превышает 10 страниц, это отпугивает заказчика.
Хорошо, когда вопросы структурированы в логические блоки, а не идут одним нескончаемым списком. Некоторые разработчики делают отдельные брифы на дизайн, но это уже лишне (если вы только не дизайн-студия), т.к. заказчика интересует конечный продукт – сайт. Или другая крайность – включать в бриф на сайт вопросы по разработке фирменного стиля или логотипа компании. Ведь визуальная айдентика бренда – это совсем другая история, для которой требуются совсем иные компетенции, чем при создании сайта. Если разработчик ставит разработку логотипа в один ряд с созданием сайта, сразу возникает вопрос, насколько он вообще умеет делать и то, и другое…
Наглядность и закрытые вопросы
О предпочтениях заказчика проще судить по его оценке других сайтов. Пусть заказчик скажет, что конкретно ему нравится или не нравится в каждом приведённом примере. Это поможет понять, являются ли его предпочтения эстетическими или всё-таки его привлекла некая функциональность, техническое решение или способность решать его практические задачи.
Разработчик выглядит непрофессионально, когда просит заказчика изобразить в брифе эскиз ожидаемого проекта (да, и такое бывает!!!) Если интересно, как заказчик видит страницу сайта, можно задать вопросы о соотношении графики и текста, положении главного меню, количестве колонок и пр. Каркасный макет главной и второстепенной страницы сайта ещё до начала работы дизайнера поможет обсудить расположение основных элементов страницы.
Удобно, когда бриф содержит варианты ответов на вопросы. Заказчик, возможно, впервые в жизни делает сайт, и ему трудно сообразить, какие виды сайтов бывают, какие основные модули могут ему понадобиться. Добавить свой ответ можно при необходимости, но чаще достаточно поставить «галочку» (активное содержимое в Word в помощь – кто не боится его использовать!) С другой стороны, разработчики могут быть в этом даже чересчур креативны. Например, в одном брифе для определения визуальных предпочтений заказчика используются довольно спорные пиктограммы:
Перечитать свой бриф свежим взглядом никогда не повредит: трезво оценить содержание брифа, объем, структуру и наглядность. Дать прочитать бабушке и спросить, понятен ли он ей.
Мы спросили заказчиков, размещающих тендеры на нашем портале, что им нравится, а что раздражает в брифах разработчиков.
Содержание брифа
По мнению заказчиков, кроме всевозможных технических деталей, бриф должен уточнять:
- перечень материалов, предоставляемых заказчиком;
- пожелания к функциональности сайта;
- содержание главной страницы;
- наличие языковых версий сайта;
- необходимость разработки контента;
- сроки исполнения заказа;
- ориентировочный бюджет.
Бриф не должен иметь маркетингового, дизайнерского или технического перекоса. Не у каждой компании есть миссия и ценности, не все знают преимущества товаров-конкурентов. Да и зачем они разработчику, которому не заказывается контент?
Заказчик не обязан заранее знать иерархию вложенности страниц и связи между ними – для этого как раз и нужен разработчик, который разбирается в вопросах юзабилити и всяко-разных моментах, о которых заказчик и не подозревает.
Иногда вопросы брифа настолько сложно сформулированы, что для ответа на них заказчику требуется перевод с айтишного на русский. Кстати, контакты разработчика на случай, если что-то непонятно по тексту брифа, должны быть всегда в колонтитулах брифа.
Объем и структура
Не стоит слишком вдаваться в детали. Если бриф превышает 10 страниц, это отпугивает заказчика. - Во-первых, это наталкивает на мысль, что разработчик не умеет выделить главное;
- Во-вторых – что он перекладывает свои задачи на заказчика;
- Иногда старательно заполненный бриф превращается в настоящую проблему для самого разработчика, потому что некоторые требования трудновыполнимы или несовместимы между собой;
- В конце концов, нужно оставить себе немного свободы для творчества!
Хорошо, когда вопросы структурированы в логические блоки, а не идут одним нескончаемым списком. Некоторые разработчики делают отдельные брифы на дизайн, но это уже лишне (если вы только не дизайн-студия), т.к. заказчика интересует конечный продукт – сайт. Или другая крайность – включать в бриф на сайт вопросы по разработке фирменного стиля или логотипа компании. Ведь визуальная айдентика бренда – это совсем другая история, для которой требуются совсем иные компетенции, чем при создании сайта. Если разработчик ставит разработку логотипа в один ряд с созданием сайта, сразу возникает вопрос, насколько он вообще умеет делать и то, и другое…
Наглядность и закрытые вопросы
О предпочтениях заказчика проще судить по его оценке других сайтов. Пусть заказчик скажет, что конкретно ему нравится или не нравится в каждом приведённом примере. Это поможет понять, являются ли его предпочтения эстетическими или всё-таки его привлекла некая функциональность, техническое решение или способность решать его практические задачи.
Разработчик выглядит непрофессионально, когда просит заказчика изобразить в брифе эскиз ожидаемого проекта (да, и такое бывает!!!) Если интересно, как заказчик видит страницу сайта, можно задать вопросы о соотношении графики и текста, положении главного меню, количестве колонок и пр. Каркасный макет главной и второстепенной страницы сайта ещё до начала работы дизайнера поможет обсудить расположение основных элементов страницы.
Удобно, когда бриф содержит варианты ответов на вопросы. Заказчик, возможно, впервые в жизни делает сайт, и ему трудно сообразить, какие виды сайтов бывают, какие основные модули могут ему понадобиться. Добавить свой ответ можно при необходимости, но чаще достаточно поставить «галочку» (активное содержимое в Word в помощь – кто не боится его использовать!) С другой стороны, разработчики могут быть в этом даже чересчур креативны. Например, в одном брифе для определения визуальных предпочтений заказчика используются довольно спорные пиктограммы:
Перечитать свой бриф свежим взглядом никогда не повредит: трезво оценить содержание брифа, объем, структуру и наглядность. Дать прочитать бабушке и спросить, понятен ли он ей.
