Дизайнерское управление разработкой
В бюро возможны два формата работы над технической частью проектов:
Мы сами разрабатываем техническую часть проекта.
Мы обеспечиваем дизайнерское управление разработкой в технической команде клиента вплоть до запуска, чтобы продукт получился таким, как его задумали, без ущерба для качества.
При дизайнерском управлении разработкой особенно важны требования к клиентской команде. Наши принципы работы могут не подойти разработчикам. Мы бы не хотели, чтобы из‑за возможной разницы в подходе пострадал результат, поэтому предлагаем сделать тестовый проект для проверки совместимости между нами.
Кроме того, мы приглашаем независимые команды веб‑разработчиков пройти наш тест заранее, и станем рекомендовать их клиентам для совместных проектов.
Тестовый проект
В проекте формируется команда из дизайнеров с нашей стороны и разработчиков со стороны клиента, моделируется реальная работа. По ходу работы будут появляться неожиданные просьбы как со стороны дизайнера, так и со стороны воображаемого клиента. Если по итогам теста мы не будем уверены, что сможем сделать качественный продукт, мы не сможем взяться за работу.
Мы ведём проекты в Бейскемпе.
Задача: необходимо организовать запись на экскурсионный полёт на Марс через новую форму на сайте —
Семейные положения: женат/замужем, в «гражданском браке», разведён, холост, вдовец.
Образование: высшее, среднее специальное, среднее, студент.
Технические требования
Если фамилия участника ранее менялась, дополнительно заполняется предыдущая. Поля валидируются на клиентской стороне, информация об ошибках выводится сразу после их совершения. Латиница заполняется автоматически из кириллицы. Пол определяется автоматически из ФИО. Частично заполненная форма сохраняется в браузере и не очищается при перезагрузке страницы. Поля появляются и исчезают с плавной анимацией.
Отправленные через форму заявки сохраняются в базе и отправляются администратору по электронной почте. Нужно предусмотреть страницу, где будет выведен список отправленных заявок (её вид — на усмотрение разработчиков).
Форма должна корректно работать на мобильных устройствах.
Важно, чтобы форма была хорошо свёрстана с точки зрения сео.
Необходимо также собирать статистику использования формы: сколько времени занимает заполнение формы, как часто люди допускают ошибки при заполнении, какая конверсия.
План работы технической команды клиента
1.
Неделя 1
Подготовка спецификации на разработку системы, передача исходных материалов
Результат
Все состояния и исключения подробно описаны текстом, согласованы с ведущим дизайнером. У команды разработки есть все необходимые макеты и ответы
2.
Неделя 2
Разработка: ХТМЛ‑вёрстка, разработка фронтенда, реализация, организация сбора статистики
Результат
Прототип создан, форма работает, валидируется, отправляет данные на сервер; работает отображение списка участников, письма отправляются
3.
Неделя 3
Тестирование и отладка, пуск. Отладка под разными браузерами и устройствами. Точка невозврата — третий день этой недели
Результат
Всё готово, открыто, работает на реальном хостинге
Точка невозврата разделяет план на реализацию элементов дизайна и последующие доработки, исправление ошибок, наполнение информацией, тестирование и подготовку к запуску.
Взаимодействие и роли в проектах
В основе совместной проектной работы лежат принцип fix time and budget, flex scope («ФФФ») и общая ответственность за срок выхода конечного продукта. Подход fix time and budget, flex scope буквально означает «зафиксировать срок и бюджет, сделать гибкой функциональность». Ограничение сроков может потребовать в ходе разработки совместного принятия решения об упрощении дизайна или ограничении функциональности.
Основная часть дизайнерских решений должна приниматься во время разработки реального продукта, а не до неё. Срок перехода от графических макетов к реальному продукту должен быть максимально коротким. При возникновении проблем при реализации элементов дизайна предпочтение отдаётся отказу от функциональности ради соблюдения сроков и сохранения высокого качества и потребительских свойств конечного продукта.
Со стороны бюро проектом управляет ведущий дизайнер. Он согласовывает с клиентом дизайн, контролирует сроки и качество, транслирует принятые решения команде разработки. Ведущий дизайнер контролирует и управляет ходом реализации. Зона его ответственности ограничена элементами дизайна, то есть объектами или интерфейсами, над которыми работало бюро в соответствии с заданием, но может предложить клиенту коррективы плана любых других работ для сохранения сроков и качества.
Однако команда разработки — не исполнители дизайнерской воли, а активные и инициативные участники создания продукта. Разработчики участвуют в обсуждении дизайна, задают вопросы, стараются разобраться, почему дизайн именно такой.
Разработчик — самый важный человек в проекте: именно он создаёт реальный продукт своими руками и головой. Что бы ни нарисовали дизайнеры, результат будет таким, каким его сделает разработчик.
Если разработчиков несколько, среди них есть ведущий, который отвечает за взаимодействие с ведущим дизайнером. Но дизайнер напрямую общается со всеми разработчиками. В соответствии с принципом «исполнитель понимает задачу», технолог согласовывает с дизайнером поставленные задачи. Все участники команды разработки должны быть представлены ведущему дизайнеру.
Если при разработке возникают сложности, разработчик первым придёт к дизайнеру, объяснит проблему и предложит альтернативное решение. Разработчик не станет оправдывать неудачное решение тем, что «так было в макете» или «так было в спецификации».
Разработчик не станет требовать от дизайнера точный оттенок цвета выезжающей панели или формулу кривой её ускорения. Вместо этого он возьмёт цвет из макета, разберётся в физике и хорошо анимирует, а потом допилит панель вместе с ведущим дизайнером.
Ожидания от фронтенд‑разработчиков
Плохой технолог
Не вникает в смысл дизайна, забывает о полезном действии и верстает макет по пикселям, в лоб.
Хороший технолог
Мастерски верстает сайты, пишет скрипты, общается с коллегами, планирует время, делает работу в срок без начальника с палкой.
Плохой технолог
Полагается только на свои силы. Надолго застревает на сложных элементах и не обсуждает решение или возможность упрощения. Не заботится о деградациях. «Кроссбраузерно» для него — одинаково во всех браузерах.
Хороший технолог
Не просит дизайнера отрисовать макет для разной ширины браузера, а сам предлагает разумную «резину». Придумывает уместные анимации интерфейса, не требуя разжевать каждый кадр.
Плохой технолог
Не готов править вёрстку и скрипты, разрезанные на шаблоны. Ничем не интересуется. Не делает собственные проекты.
Хороший технолог
С удовольствием исследует новые области, любит нестандартные элементы интерфейса. Щёлкает рутинные задачи автоматизацией, готовыми решениями, снипетами и миксинами.
Плохой технолог
Притворяется хорошим.
Хороший технолог
Видит, в чём сегодня был недостаточно хорош, и завтра становится лучше.
Ожидания от бэкенд‑разработчиков
Разработчики настраивают сервер, хостинг, систему контроля версий, базу данных, админку, бекапы, систему тестирования, сбор статистики. Организуют удобную для совместной работы техническую платформу: создают рабочий и доступный всем участникам прототип продукта, позволяющий вносить изменения в прототип в реальном времени, даже если в «живой» версии используется система релизов.
Бэкенд‑разработчики придумывают алгоритмы поиска, логику кеширования, способы выдерживать нагрузку, защищаться от спама без капчи, обеспечивают бесперебойную работу продукта.
Программа «Бюро+»
Тест проходится одной командой один раз. Он начинается после принятия с клиентом решения о работе бюро в формате дизайнерского управления разработкой и длится три недели.
Однако мы приглашаем команды разработчиков пройти с нами тест, не дожидаясь проектов. Мы будем готовы рекомендовать команды, с которыми у нас совместный тест получится удачно. Мы будем оценивать результат по гибкости в принятии решений по ФФФ, готовности к изобретательству, дотошности в проектировании, качеству и аккуратности кода. Просто напишите нам: mail@bureau.ru.