Не так давно, один из моих старых друзей посетовал на то, что у них в компании возникают проблемы на проектах создания сайтов. Суть в следующем. Компания занимается разработкой аналитических ИТ систем для банков и ПИФов. Разрабатываемые системы имеют веб интерфейс и внешний и/или внутренний сайт. Все бы хорошо, но когда доходит до оформления внешнего сайта часто возникает проблема с приемкой. Несмотря на составленный и подписанный бриф для дизайнера и соответствие эскизов заявленному брифу Заказчику хочется внести небольшие изменения. А затем еще немного подправить. И еще немного… и так, пока не получится НЕЧТО. Причем нечто очень страшное. После чего Заказчик просит взять другой эскиз и в нем немного подправить. Если отказаться на любой из стадий поправить эскиз, то получается конфликт с Заказчиком, которому трудно понять, почему ему отказывают в такой ерунде, как, например, сделать шрифт на кнопках курсивом. Разработка внешнего оформления сайта является не последним этапом и задерживает остальные этапы проекта, что грозит штрафами для компании подрядчика, а принимать эскизы без правок Заказчик не хочет. В общем, получается тупиковая ситуация. Если отказаться править – Заказчик не станет подписывать внешнее оформление, а может и вообще разорвать контракт, а если править – сорвутся сроки и не известно еще, что он захочет править дальше. Честно говоря, я подумал было что проблема просто в плохом управлении проектом, но ошибся. Проблема, на мой взгляд, в том, что для таких творческих продуктов как внешнее оформление сайта трудно найти критерии, по которым можно однозначно сказать, соответствует продукт требованиям Заказчика или нет. Я попытался разрешить эту проблему совместно с моим другом (на основании его опыта и изученных уроков на его фирме) и членами сообщества аналитиков. Публикую предложенные мной действия для снижения вероятности возникновения подобной ситуации с комментариями сообщества.
1. Необходимо определить роли, обязанности и полномочия дизайнера и клиента
Клиенты, с которыми работает компания, не являются веб дизайнерами. Необходимо выделить время в начале проекта, чтобы определить и разъяснить Заказчику зоны ответственности, а также полномочия и обязанности. Необходимо показать, что клиент ответственен за саму концепцию сайта, и должен сосредоточится на определении нужд пользователей сайта, формулировке требований, а такие мелочи, как точные цвета, шрифты и тому подобные вещи оставить профессионалу (дизайнеру). Ведь дизайнер лучше знает, как обеспечить выполнение требований заказчика через цвета и дизайн. Также, необходимо четко и ясно объяснить, что именно ожидается от Заказчика.
2. Изучить и понять бизнес заказчика
Дизайнеру необходимо не только посмотреть бриф, но еще и изучить, что за компания заказывает сайт, возможно, познакомиться с представителем заказчика, который будет осуществлять приемку. Нужно стремиться, чтобы веб дизайнер сам осознал нужды Заказчика.
3. Изучить пользователей сайта
До начала работы необходимо встретиться с несколькими пользователями сайта, если это возможно (организует Заказчик). Понимание потребностей пользователей ведет не только к более качественной работе, но и является одним из аргументов в общении с Заказчиком.
Комментарии: сомнительно. т.е. это слегка полезно, но не настолько чтобы тратить на это силы.
4. Предоставлять заказчику только один шаблон
При показе нескольких шаблонов, Заказчик зачастую будет стремиться объединить несколько шаблонов взяв из них сильные (на его взгляд) стороны и убрав слабые, что приведет к шаблонам – Франкенштейнам, которые никому не нужны.
Комментарии: не всегда возможно предоставить только один шаблон (эскиз). Клиент может сразу, в задании обозначить необходимость предоставления нескольких шаблонов.
5. Предложить варианты
Насколько я понял, обычно, Заказчику предлагают показать варианты сайтов, которые ему нравятся. Проблема в том, что довольно проблематично для дизайнера получить из сайтов именно те элементы, которые понравились Заказчику. Думаю, стоит самостоятельно предлагать Заказчику некий набор сайтов, с хорошо известными дизайнеру сильными и слабыми сторонами (акцентами), из которых Заказчик выбирает те, которые ему нравится.
Комментарии: эта практика направлена на то чтобы уловить общий дух желаемого дизайна, а не элементы. Таким образом, если Заказчик показывает пять сайтов из которых четыре красные на черном с логотипом в левом нижнем углу, можно сразу определить его требования, хотя как правило, сам Заказчик еще не может их сформулировать. Этот этап необходим.
6. Разработать контент для главной страницы до разработки эскизов
Необходимо написать контент до того, как начата разработка эскиза и проводить демонстрацию эскиза уже с наполнением.
7. Презентация дизайна
Не высылать эскизы по почте и не предоставлять их без пояснений. Лучше всего устроить показ эскиза с объяснениями сильных сторон данного дизайна, что сразу отметет часть претензий.
8. Предоставлять сопровождающие материалы (возможно, в бумажном виде тоже)
Возможно, что решающее слово по эскизу будет не у сотрудника, с которым вы ведете переговоры и которому проводите презентацию. Необходимо подготовить качественные материалы, которые сотрудник с которым вы работаете, сможет показать своему начальству, в случае необходимости. Печатные материалы должны быть тщательно продуманы и хорошего качества.
9. Делить проект на этапы с раздельными сроками и бюджетом
Тогда стадия создания дизайна и эскизов не будет тратить бюджет и сроки остального проекта.
Комментарии: Обязательно необходимо делить проект на этапы, но проблема обычно в том что несмотря на разбиение на этапы, проект в целом почти всегда имеет дедлайн. Этап дизайна (обычно первый) этому дедлайну может повредить.
10. Сделать этап внешнего оформления сайта последним этапом
Внешнее оформление сайта определяется функционалом (который определяется потребностями заказчика), а не наоборот.
11. Разрабатывать эскизы внешнего оформления сайта параллельно с другими этапами
Эскизы разрабатываются параллельно с контентом, навигацией и прочим. При согласовании только эскизов внешнего оформления существует высокая вероятность того, что что-то в других разделах (например в навигации) было упущено и при переделке или доработке может значительно повлиять на внешнее оформление.
Ссылки:
[1] http://www.lessonslearned.ru/taxonomy/term/33