Сергей Петров
11 ноября 2011

Добрый день!

Разрабатываем крупный проект. На определённом этапе в команду к нам по воле заказчика попадает человек, который должен быть ответственным за дальнейшее развитие проекта. До запуска проекта остаётся немного времени и этот человек, проанализировав рынок, принимает решение переработать полностью дизайн проекта, потому что якобы его визуальная часть не соответствует целевой аудитории. При этом весь дизайн уже давно согласован с заказчиком, технологи его заверстали, а программисты уже прикрутили. Получается, что такое решение отбросит сроки запуска ещё на несколько месяцев. Невооружённым глазом видно, что проблема в том, что ответственному человеку просто не нравится дизайн и поэтому он хочет его переделать.

Как бы вы поступили в данной ситуации?



Поговорите с клиентом. Узнайте его отношение к смене дизайна и его оценку риска отсрочки. Откровенно скажите, что вас беспокоит, но не давите.

Я могу ошибаться, но вы, вероятно, участвуете в проекте как исполнитель. Поскольку дизайн уже принят и внедрён, вам нужно только принять решение — участвовать в следующей итерации за дополнительные деньги или выйти из игры, посчитав, что новый человек поведёт проект в страну уныния.

Думаю, вы переоцениваете время на «переодевание». Если продукт действительно собран и работоспособен, поменять оформление — дело нескольких недель. Иногда — одной ночи.

У меня такое случалось не раз по собственной инициативе. Как ни странно, подобные «микрореволюции» хороши уже именно на готовом продукте, а не на фазе дизайна. Нет ничего хуже, чем порождать один за другим комплекты графических файлов, не приближаясь к реализации.
Разумеется, речь не о глобальной смене сценариев, навигации и принципов интерфейса.

Может показаться, что это противоречит принципу фиксации дедлайна, но в соответствии с идеей ФФФ у вас уже есть готовый продукт, просто его первую версию увидят одни разработчики. Вы с чистой совестью перекрашиваете яхту, готовую к спуску. И между прочим, на это нужна воля, ведь всем уже хочется открыть шампанское.

Я не знаю, кто из вас прав. Представьте на секунду, что ваш новый ответственный — Стив Джобс.

Ещё раз — перекрашиваете, а не меняете корпус, такелаж и что там ещё у яхты.

См. совет о первой версии

P. S.
Это был пятничный совет по взаимоотношениям с клиентом. Хотите получить совет по самой эффективной системе переговоров без оружия? Присылайте вопросы.
P. P. S.
Совет помог? Напишите в комментариях.
P. P. P. S.

Дата следующего набора в Школу стажёров пока неизвестна.

 
Мы напишем вам, когда будет открыт набор. Без спама.

Поделиться

Комментарии

Всеволод Рудой
11 ноября 2011

Люди, внезапно пришедшие в проект, начинают настаивать на изменениях. Это они так пытаются показать свою компетентность — и это нормально. Обратить же свое внимание надо не на поведение, а на то, что заказчик прислушался к мнению этого человека, и делегировал ему право корректировать вашу работу.

Сходу два неправильных решения:
1. Молча внести все предложенные изменения.
2. Настоять на запуске уже принятого сайта.

Вы авансом решили, что новый человек не принёс ничего полезного, даже поставили слово «якобы», когда упомянули его пожелания. Этот подход — неприятие авансом другой точки зрения — сильно ограничивает кругозор, а в данном случае осложнит вам сдачу проекта, поскольку, напомню, заказчик прислушивается к мнению этого человека.

Выход, который я вижу — это начать диалог:
1. «Включить зануду» и выдавить из ответственного человека максимум информации про визуальные предпочтения ЦА, не в общих «что-то молодёжное», а как можно конкретней. Законспектировать, записать на видео. Кроме этого получить список изменений с максимальной конкретикой.
2. Проработать список изменений, структурировав его по целесообразности и трудоёмкости. Примерно определить количество изменений, которое входит в бюджет и во временные сроки.

Теперь собственно встреча, на которой обсуждается всё вышесказанное. Не забывайте обосновывать свои решения. Глупо надеяться, что клиент телепат и поймёт причины, по которым вы против пёстрого фона под текстом.


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Несмотря на то, что между нами была договорённость о работе по ФФФ, клиент был в бешенстве 4 Расскажите, пожалуйста, вносят ли клиенты свои правки в макеты? Можно ли в договоре добавить пункт, что срок увеличивается пропорционально времени на согласование дизайна? 5 Как в бюро отвечают на вопросы «А почему ещё не готово?» и как борются со срывами сроков? 4




Недавно всплыло

Расскажите об управляемости. Домашнее задание 4 2 Как создавался новый сайт бюро. Часть вторая 2 4