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

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

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

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

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

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

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

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

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

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

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

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

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

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