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