Итак, вы создаете дизайн нового веб-сайта или интернет-магазина, и вам нужен веб-разработчик. Он может понадобиться для разработки сайта с нуля или же, возможно, вам просто нужно, чтобы он поработал над некоторыми изменениями, проблемами или дополнительными функциями.
В любом случае, вашими отношениями с веб-разработчиком может быть сложно управлять. Существует так много причин, из-за которых отношения могут развалиться:
- Пропущенные сроки
- Отсутствие связи
- Медленная связь
- Нет связи
- Чрезмерные обещания разработчика
- Разработчик недопоставляет
- Разработчик исчезает
- Отсутствие протокола для небольших допущений/решений
- Ошибки или проблемы не исправляются
Практически каждый дизайнер, может поделиться ужасной историей, касающейся одной из этих вещей. Чтобы не оказаться в подобной ситуации, мы подготовили удобный список вопросов для обсуждения перед началом работы, чтобы помочь нам избежать выше описанных проблем.
Прежде чем мы рассмотрим все вопросы, давайте проясним: это не панацея для всех отношений дизайнеров и разработчиков. В конце концов, это все еще человеческие отношения – и они сложные. Однако открытый разговор об этих предметах поможет начать проект с правильной ноги.
Содержание статьи
1. Как вы будете общаться?
Как вы будете общаться во время работы над проектом? Скайп? Телефонные звонки? Электронные письма? Другие мессенджеры или социальные сети? Не менее важно: как часто вы будете общаться? Каждый день? Раз в неделю? В начале, а потом снова, когда появятся вопросы? Если вы планируете проводить ежедневную проверку, это будет электронное письмо из двух предложений или 15-минутный разговор? Каков план на случай чрезвычайных ситуаций?
Здесь нет неправильных ответов, если вы определяете перспективы с самого начала. Но помните: больше связи не всегда означает лучшее взаимодействие.
Почему это важно
Вы хотите иметь хорошие отношения со своим разработчиком, и для этого вам нужен установленный способ общения. Обычно голосовое общение помогает установить первоначальную личную связь и убедиться, что это отлично подходящий вам человек.
Во время разработки старайтесь найти баланс между проверками слишком часто и слишком редко. Слишком частые проверки приведут к тому что вы будете управлять даже незначимыми мелочами. Слишком редко — и разработчик может сойти с правильного пути. Лучше установить ожидания изначально и придерживаться их.
2. Как вы будете управлять проектом?
Где будут находиться файлы и учетные данные, которые понадобятся разработчику? Где вы будете отслеживать задачи, этапы и сроки? Какое программное обеспечение вы будете использовать? Trello? Asana? Электронная таблица или Google Doc? По сути, определите центральное хранилище для всего, что связано с проектом.
Почему это важно
Во время проект, а управление рабочим процессом и коммуникация должны быть централизованными и отслеживаемыми. Много времени может быть потеряно при поиске файлов, проверок, обновлений, прогресса, вопросов, решений и т.д. Поэтому важно определить, где разработчик может найти все, что ему нужно.
3. Кто командует?
Вы принимаете окончательное решение по проекту? Вовлечена ли команда UI/UX? Есть ли еще кто-нибудь, кто вносит свой вклад в принятие решений? Есть ли отдел маркетинга или менеджер, который хочет принимать решения? Кто-нибудь еще, кроме вас, будет давать указания непосредственно разработчику? Будет ли у клиента прямая связь с разработчиком?
Почему это важно
Вы не хотите отступать от разработки или переделывать работу разработчика. Чтобы избежать этого, важно, чтобы все заинтересованные стороны знали обо всех соответствующих решениях — и чтобы каждое решение регистрировалось в едином центральном месте.
4. Как разработчик должен обрабатывать предположения и небольшие решения?
Сколько свободы имеет разработчик при интерпретации дизайна? Должен ли он строить веб-сайт пиксельно-совершенным в соответствии с дизайном, или он должен делать небольшие предположения относительно согласованности и повторного использования разделов? Если вы разработали адаптивный сайт, вы разработали его для всех точек останова? Вы предоставили заметки об анимации, переходах и эффектах наведения курсора? Вы разработали состояния проверки для полей? (т. е. всплывающие окна: “пароль неверный” или “имя пользователя не существует”). Если вы этого не сделали, разработчик может принимать решения сам?
Почему это важно
Очень часто дизайнеры недовольны тем, что веб-сайт не очень близко соответствует дизайну, или наоборот, когда сайт слишком близко следует дизайну, в ущерб его эффективности или срокам проекта. Сначала определите предполагаемый уровень детализации. Это сделает процесс контроля качества более гладким.
5. Какой график?
Какой крайний срок для проекта, и какой допустимый срок? Есть ли определенная дата, когда сайт должен быть запущен? Если крайний срок является слишком амбициозным, есть ли способ запустить проект поэтапно? Какой должна быть реакция на быстрые изменения? Одна неделя? Меньше часа?
Почему это важно
Если есть жесткие сроки, сообщите об этом разработчику и оставьте время для надлежащего тестирования. После запуска сайта, большинство разработчиков не могут быть на связи в любое время и вносить изменения. Ожидание, пока разработчик внесет исправление, может быть неприятным, но даже небольшие запросы требуют поддержания контроля версий, запуска среды разработки, подключения к серверу, развертывания на рабочем сайте и т.д. Определите заранее, в течение, какого времени вы ожидаете исправления и изменения, и оцените уровень приоритета каждой задачи.
Просто будьте прозрачны со своим разработчиком и доверяйте ему. Честность — лучшая политика.
6. Какова структура объема, контракта и структура оплаты?
Какова плата за проект? Каков ориентир для завершения проекта? Что входит в объем проекта? Когда происходит оплата? Вы нанимаете разработчика для выполнения проекта по почасовой или фиксированной ставке?
Почему это важно
Последнее, что вам нужно — это чтобы разработчик сделал сайт на 95%, а затем не запустил его из-за несоответствия в объеме/контракте/оплате.
Заключение
В целом, определение ожиданий и общение являются здесь критическими вещами. Может показаться немного глупым, обсуждать, как вы собираетесь общаться друг с другом во время проекта, особенно если у вас уже есть хорошее взаимопонимание. Но всегда хорошо просто определить ожидания, чтобы вы не попали в собственную историю ужасов.
Всем успешной работы и творчества!
Источник
Загрузка...
