Александр!

Проблема в том, что клиент думает, будто дизайн заканчивается на картинках. На деле большая часть дизайнерских решений принимается на этапе разработки — причём неважно, осознаёт ли это клиент. Что произойдёт, если пользователь нажмёт на эту кнопочку при незаполненной форме? Почему дизайнеры не нарисовали листалку — специально или забыли? Что делать, если в реальной базе данных на странице оказывается в три раза больше текста, чем предусмотрено дизайном? Как выглядит 404-я ошибка при ширине экрана 2000 пикселей?

В этом огромном потоке вопросов очень небольшая часть затрагивает бизнес и реально волнует клиента.

Большинство дизайнеров отдают клиенту картинки, тот отдаёт их программистам. Поскольку дизайнер ни о чём не позаботился, а клиент ни о чём не подозревает, все решения достаются бесконтрольным программистам:

Естественно, получается уродец. Дизайнер кладёт скриншоты в портфолио, на реальный продукт без боли не взглянешь.

Ещё год назад бюро пыталось осуществлять авторский контроль над разработкой через клиента:

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

Часто оказывается, что программисты работают над каким-то замечанием дизайнеров месячной давности, которое уже давно потеряло актуальность. Ещё во время разработки ясно, что выходит уродец, дизайнеры истерят, запуск несколько раз откладывается, в конце концов клиент вынужден открыть полууродца.

Чтобы повысить эффективность коммуникации в проекте, нужно оставить клиенту принятие ключевых решений, а общение о поведении кнопки на форме обратной связи вести напрямую с программистами:

Решения в любом проекте принимаются постоянно. Ни подписание ТЗ, ни утверждение чертежа не способны зафиксировать конструкцию будущего самолёта. Если вы создаёте пользовательский интерфейс, большая часть решений во время его разработки будут дизайнерскими — кто бы их ни принимал. Лучше, чтобы решения принимали дизайнеры совместно с клиентом, а затем напрямую, через технического директора, транслировали их в разработку.

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

Как реагировать на заявления клиента о том, что их разработчики смогут справиться своими силами? Представьте себе — я не могу здесь посоветовать. О том, как действую я — в совете о ФФФ:

«Я просто искренне рассказываю о своих личных неудачах. Необязательно называть конкретные проекты — главное честно нарисовать их историю и взять на себя полную ответственность за их неудачу. Виноват не клиент и не его программисты, а то, что мы позволяли им рыть себе яму нашими руками бесконечными доделками и бесконтрольностью разработчиков.

А в конце я предупреждаю, что мы работаем по-новому всего несколько месяцев и этого слишком мало для убедительной статистики. Однако раньше у нас не было таких управляемых проектов и счастливых клиентов (за редкими исключениями), и к предыдущей схеме мы уже не вернёмся никогда.

Получается, что мне не приходится убеждать клиента, потому что у меня просто нет альтернативы. Конечно, мне жаль, если мой клиент пойдёт по пути других клиентов других студий, но это будет его решение».