Скоро наш журнал обновит свой дизайн
Close
Будь в курсе
Подпишитесь на рассылку, чтобы не пропускать новые выпуски журнала
лекция
Управление и результаты
Дизайнерское управление разработкой
Чтобы создавать крутые продукты, нужно понимать роль команды разработки в любом проекте, будь это сайт, приложение или любая другая айтишная вещь. Кстати, при разработке печатного издания роль команды разработки играет редакция и типография.

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

Мы не знаем, как на самом деле всё устроено внутри Эпла, но из нашего опыта и здравого смысла мы знаем, что такие отношения не продуктивны. Какими бы ни были крутыми дизайнеры и как бы здорово они всё ни придумали, продукт выпускают разработчики. Именно от того, насколько ответственно разработчики подойдут к своей работе, насколько сильна будет их любовь к собственному делу и их желание сделать работу хорошо, зависит, каким получится продукт. В этом смысле роль команды разработки решающая. Ни в коем случае нельзя относиться к разработчикам, как к второстепенной части команды, потому что их руками делается реальный продукт, а дизайнеры делают только макеты — в лучшем случае, какое‑то приближение к реальности. Поэтому очень важно правильно настроить взаимодействие между командами дизайнеров и разработчиков.

ФФФ работает только тогда, когда его признают и используют все участники проекта. Даже, условно, уборщица. Поэтому разработчики должны понимать и признавать все принципы ФФФ:

Также работа должна быть правильно построена.

Как построена работа

Следующий вопрос: как вести проект по этим принципам? Кто принимает решения, кто за что отвечает? Для этого используется дизайнерское управление разработкой. Проект ведёт ведущий дизайнер. Он отвечает за согласование дизайна и решений по флексу с клиентом и за передачу принятых решений и макетов разработчикам. Фактически, это человек, который знает всё о происходящем в проекте и отвечает за успех проекта.

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

После этого макеты показывают разработчикам. Иногда макеты начинают показывать заранее, предупредив, что дизайн не окончательный. Посмотрев макеты, разработчики пишут спецификацию. Спецификация — это не обязательно формальный стостраничный документ. Речь идёт о том, что должен быть документ, например в Ворде или Гугль‑доке, в котором простым языком описано, как всё будет работать.

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

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

Как только спецификация написана, она должна быть утверждена у ведущего дизайнера, и можно начинать вёрстку или какую‑то другую работу, связанную с реализацией. После этого происходит прикрутка к бекэнду, пусконаладка и, наконец, запуск. В этом процессе: дизайн, спецификация, вёрстка, прикрутка, запуск — надо стараться, как можно раньше переходить к следующему шагу. Например, если в макете есть тулбар с 15 иконками, а нарисованы хорошо только 5, не стоит ждать, когда будут доделаны все 15, макеты можно верстать, потому что картинки можно быстро заменить в любой момент. То есть проект не должен останавливаться из‑за мелких недоделок, которые не мешают продолжать работу.

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

Тест для разработчиков

Тестовый проект

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

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

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