Просьбу сначала принести макеты я слышу постоянно. Такая просьба логична: не видя дизайн, разработчику сложно оценить объём работы: «Вообще не представляешь, что делать придётся». Давать невыполнимые обещания никто не любит.

Недостаток «каскадной модели», когда разработчики ждут дизайн, не в том, что дизайнер отходит на второй план. Участие дизайнера в разработке зависит от договорённостей о дизайнерском управлении разработкой. Проблема в потере времени и фичеризме: сначала программисты простаивают, дожидаясь дизайна, затем, участники проекта стремятся реализовать все придуманные фичи. Фиксированного дедлайна в этот момент ещё нет, и добавить недельку не страшно. Проект раздувается, как воздушный шарик.

Чтобы договориться, я объясняю программистам пользу фиксации дедлайнов: если дизайнер придумает фичу, которую будет невозможно реализовать в запланированный срок, её пофлексят. И, конечно, головную боль разработчиков снимают спецификации, которые они готовят, получив дизайн. Спецификации позволяют «поженить» дизайн с реальностью в середине проекта, принять решение о флексе. Спецификация — это и есть ТЗ, которое так хотят разработчики, но появляется она, когда о проекте уже многое известно.

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

Вне бюро я также столкнулся с проблемой «сначала нарисуйте». Но без сильного желания клиента работать именно со мной показать пользу планирования итерации до начала работы оказалось гораздо сложнее.

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

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

В результате дизайнер и разработчик пилят продукт, а не спорят.

У меня пока недостаточно информации для оценки идеи. Я знаю только, что клиенту мой подход понравился.