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

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

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

8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итого

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

Источник: fff.works