Краткая инструкция для дизайнеров по передаче задач в разработку

Вы — дизайнер. Вы нарисовали макет и хотите претворить его в жизнь. Инструкция поможет вам получить хороший результат.

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

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

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

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

3. Помогите сказать «нет». Если под вашим давлением разработчик возьмёт некачественную задачу, а потом не сможет её решить, пострадаете в первую очередь вы. Лучше узнать о проблеме на берегу, чем в открытом море. Помогите разработчику отказаться от негодной задачи:

  • Чего не хватает в макете?
  • Какие могут быть проблемы?
  • Что я не учёл?

3. Убедитесь, что назначен дедлайн и забиты «гвозди». Задача без дедлайна не может быть решена по определению. Одного дедлайна недостаточно, нужны промежуточные чекпоинты — «гвозди».

Если разработчик не знает принцип «сделать», мягко подтолкните его вопросами:

  • Когда сделаешь?
  • Что будет к этому сроку?
  • Когда посмотрим промежуточные результаты?
  • Сколько времени нужно на тестирование? Когда его нужно начать, чтобы уложиться в срок?

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

5. Крутите педали. Не ведите себя как плохой клиент, который только воротит носом и насыпает правки. Проактивно помогайте разработчику решить задачу — прорисовывайте дополнительные сценарии, придумывайте поведение, предлагайте решения, изобретайте упрощения. Ваша работа помочь разработчику сделать.

6. Не лезьте не в своё дело. Не сомневайтесь в профессионализме разработчика. Не лезьте в код. Если у разработчика не получится реализовать, задавайте наводящие вопросы, чтобы разработчик мог сохранить лицо:

  • А как вы пробовали решить проблему?
  • А почему вот это не сработает?
  • А я вот слышал о таком способе…

7. Примите результат. Выделите себе отдельное время, чтобы проверить работу. Не рассчитывайте, что разработчик сделает это качественно. Он видит только часть системы и не может быть конечным контролёром.

Итого
Не будьте мудаком. Работайте. Помогите разработчику сделать. Растите разработчиков, чтобы сделать коммуникацию проще, а результаты лучше.

P. S. Расскажите разработчику об инструкции по сделыванию, это упростит коммуникацию.

Поделиться
Отправить
Запинить
Популярное