Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
... очень желательно присутствие лица, принимающего окончательное решение...
Это условие на мой взгляд является гарантом успеха
Это условие на мой взгляд является гарантом успеха
Согласен. К сожалению, не всегда это возможно. Приходится рассчитывать на то, что ожидания главных боссов, правильно поняты людьми отвечающими за разработку сайта на стороне клиента.
Извините. Не является.
За частую получается так что из за недальновидности, ни компетентности, желания поиграть в боса, порулить и т.д. и т.п.
заворачивают такие работы что хочется бросить все...
цитирую: когда Вы приходите к дантисту Вы же не говорите ему как лечить...
А вот дизайнера за частую именно принимающий проекта начинает напаривать своим видением
которое нужно было учесть в начале работы
заворачивают такие работы что хочется бросить все...
цитирую: когда Вы приходите к дантисту Вы же не говорите ему как лечить...
А вот дизайнера за частую именно принимающий проекта начинает напаривать своим видением
которое нужно было учесть в начале работы
хм... строго говоря "гарантом" успеха всего проекта не является, конечно. Имеется ввиду, что без учета других факторов, именно присутствие решающего лица, сокращает время и возможное недопонимание.
Вообще нужно быть внимательнее :), спасибо за замечание!
Вообще нужно быть внимательнее :), спасибо за замечание!
Наиболее неформальным и трудно контролируемым процессом является разработка дизайна
По моему опыту, организовать и проконтролировать работу дизайнеров проще простого. Сложнее всего регламентировать эту работу перед заказчиком, очертив видимые границы проданной работы (особенно это касается дизайн-концепции, т.е. самого креатива).
По крайней мере, у нас в компании таких проблем нет. Нормально выстроенный процесс и хорошая квалификация сотрудников решает большинство проблем.
Под формализацией и трудностью контроля, здесь я имею ввиду как раз управление изменениями и требованиями клиента.
Ошибки в управлении требованиями и изменениями приводят и к трудностям в работе с дизайнерами, т.к. возникает необходимость переделок и переработок.
Ошибки в управлении требованиями и изменениями приводят и к трудностям в работе с дизайнерами, т.к. возникает необходимость переделок и переработок.
Все крайне просто: вот краткая логика работы (если надо, оформлю в виде отдельной статьи):
1. Делаем структуру сайта. В ней описываем, что есть что (текстовая страница или модуль). Согласовываем, правим, еще раз согласовываем и утверждаем.
2. Делаем прототипы всех уникальных страниц. Это схемы блоков сайта, которые не описывают их расположения (хотя аналитик их расставляет по логичным местам), а лишь указывает их наличие на странице. Их местоположение – дело дизайнера. В прототипах рисуются все необходимые элементы. Согласовываем, правим, еще раз согласовываем и утверждаем.
3. По прототипам главной и одной из внутренних рисуем дизайн. Количество версий регламентируем. Количество правок регламентируем. Согласовываем, правим, еще раз согласовываем и утверждаем.
4. На основании остальных прототипов рисуем все остальные дизайн-макеты. Согласовываем, правим, еще раз согласовываем и утверждаем.
В итоге дизайн нарисован и согласован. Это путь довольно неприятен с точки зрения издержек при производстве, т.к. приходится делать много работы, но часто трудозатраты компенсируются отсутствием проблем с пониманием в дальнейшем.
Любое изменении требований клиента управляемо, т.к. у нас логичная цепочка согласованных документов. Ну и наконец, умный консультант (или менеджер) должен не просто слушать «хотелки» клиента, а вычленять их них бизнес-задачи и предлагать эффективные решения.
Есть и иные пути работы. Но более контролируемого процесса я не знаю. Если подскажите – буду благодарен.
1. Делаем структуру сайта. В ней описываем, что есть что (текстовая страница или модуль). Согласовываем, правим, еще раз согласовываем и утверждаем.
2. Делаем прототипы всех уникальных страниц. Это схемы блоков сайта, которые не описывают их расположения (хотя аналитик их расставляет по логичным местам), а лишь указывает их наличие на странице. Их местоположение – дело дизайнера. В прототипах рисуются все необходимые элементы. Согласовываем, правим, еще раз согласовываем и утверждаем.
3. По прототипам главной и одной из внутренних рисуем дизайн. Количество версий регламентируем. Количество правок регламентируем. Согласовываем, правим, еще раз согласовываем и утверждаем.
4. На основании остальных прототипов рисуем все остальные дизайн-макеты. Согласовываем, правим, еще раз согласовываем и утверждаем.
В итоге дизайн нарисован и согласован. Это путь довольно неприятен с точки зрения издержек при производстве, т.к. приходится делать много работы, но часто трудозатраты компенсируются отсутствием проблем с пониманием в дальнейшем.
Любое изменении требований клиента управляемо, т.к. у нас логичная цепочка согласованных документов. Ну и наконец, умный консультант (или менеджер) должен не просто слушать «хотелки» клиента, а вычленять их них бизнес-задачи и предлагать эффективные решения.
Есть и иные пути работы. Но более контролируемого процесса я не знаю. Если подскажите – буду благодарен.
А вот здесь я описывал подход к продажам и финансового контроля издержек, если клиент не знает что хочет.
> В прототипах рисуются все необходимые элементы.
А в чем рисуются прототипы? Меня всегда интересовало, как в протипах можно отобразить различное повдение элементов, например с применением JS-эффектов (разворачивание с анимацией и т.п.)
> Количество правок регламентируем.
Мне тоже все время хотелось ограничить количество итераций по доработкам. И я ограничивал. Но больше для суровости документа :). Впрочем, если итераций больше 3, то ничего хорошего от продукта как правило не стоит ожидать.
> Это путь довольно неприятен с точки зрения издержек при производстве
Так в чем состоят издержки? В том, что создаются прототипы?
А в чем рисуются прототипы? Меня всегда интересовало, как в протипах можно отобразить различное повдение элементов, например с применением JS-эффектов (разворачивание с анимацией и т.п.)
> Количество правок регламентируем.
Мне тоже все время хотелось ограничить количество итераций по доработкам. И я ограничивал. Но больше для суровости документа :). Впрочем, если итераций больше 3, то ничего хорошего от продукта как правило не стоит ожидать.
> Это путь довольно неприятен с точки зрения издержек при производстве
Так в чем состоят издержки? В том, что создаются прототипы?
А в чем рисуются прототипы? Меня всегда интересовало, как в протипах можно отобразить различное повдение элементов, например с применением JS-эффектов (разворачивание с анимацией и т.п.)
Прототип не решает вопросы визуала. Он определяет наличие элементов, не более.
Делают их обычно в MS Visio
Так в чем состоят издержки?
В лишних трудозатратах на подробную структуру / прототипы.
Ключевое слово "лишних" :)
На мой взгляд, разработка прототипов оправдана для сложных проектов, с различными вариантами поведения пользователя. Для простых же проектов, таких как корпоративные сайты, в которых расположение блоков во многом определяется содержанием раздела и может/должно гибко меняться, разработка прототипов действительно лишняя работа.
Кроме того, клиент зачастую с трудом абстрагируется от условности прототипов и воспринимает это как окончательное представление сайта, которое потом нужно только "раскрасить". Это создает дополнительные трудности при согласовании.
На мой взгляд, разработка прототипов оправдана для сложных проектов, с различными вариантами поведения пользователя. Для простых же проектов, таких как корпоративные сайты, в которых расположение блоков во многом определяется содержанием раздела и может/должно гибко меняться, разработка прототипов действительно лишняя работа.
Кроме того, клиент зачастую с трудом абстрагируется от условности прототипов и воспринимает это как окончательное представление сайта, которое потом нужно только "раскрасить". Это создает дополнительные трудности при согласовании.
с берега клиентов Клиенториентированному Исполнителю ...
Еще бы здорово иметь при первичном разговоре (помимо портфолио конечных продуктов) несколько образцов.... или даже портфолио формализованных ТЗ....зачастую Заказчику трудно представить, до какой степени нужна будет формализация... (не все Заказчики профи в таком деле). Удачи!
Еще бы здорово иметь при первичном разговоре (помимо портфолио конечных продуктов) несколько образцов.... или даже портфолио формализованных ТЗ....зачастую Заказчику трудно представить, до какой степени нужна будет формализация... (не все Заказчики профи в таком деле). Удачи!
вряд ли это будет здорово...
во-первых, универсальных ТЗ не бывает. Болванка используемая исполнителем, содержит 30% информации от финального документа, остальное - специфика конкретного проекта - и вам, как новому клиенту она ничего не скажет.
во-вторых, реальное ТЗ является конфиденциальным документом и поэтому не может быть предоставлено в виде портфолио.
ну и в третьих, какой смысл, вам клиенту тратить время на изучение чужих докуметов, если для вас будет разработан индивидуальный, обсуждение которого займет у вас достаточно времени.
во-первых, универсальных ТЗ не бывает. Болванка используемая исполнителем, содержит 30% информации от финального документа, остальное - специфика конкретного проекта - и вам, как новому клиенту она ничего не скажет.
во-вторых, реальное ТЗ является конфиденциальным документом и поэтому не может быть предоставлено в виде портфолио.
ну и в третьих, какой смысл, вам клиенту тратить время на изучение чужих докуметов, если для вас будет разработан индивидуальный, обсуждение которого займет у вас достаточно времени.
спасибо за разъяснение, но подавляющему большинству клиентов вряд ли известны нюансы исполнения ТЗ, оттого возникает некоторая непрозрачность, что не добавляет доверия в отношения Заказчик-Исполнитель.
что касается первичного разговора, то ТЗ в принципе относится к другому, более позднему этапу и как правило, обсуждается с другими людьми на стороне исполнителя.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дизайн сайта. Управление проектом.