- Дизайн
- 2 мин на чтение
- 10169
Краткая инструкция для дизайнеров по передаче задач в разработку
Вы — дизайнер. Вы нарисовали макет и хотите претворить его в жизнь.
Инструкция поможет вам получить хороший результат.
1. Осознайте свою беспомощность. Сами вы макет не внедрите. Даже если умеете программировать, любой серьёзный продукт в десять раз сложнее, чем вы можете себе представить. Трогать продакшен-код вашими дизайнерскими руками вам никто не даст, поэтому работа с разработчиком ваш единственный способ реализовать задуманное. Примите это.
2. Подготовьте качественную задачу. Работа разработчика внедрить то, что вы придумали, а не придумывать решение за вас. Продумайте, прорисуйте и хорошо опишите всё: основной сценарий, краевые условия, исключительные ситуации. Продумайте структуру данных, алгоритмы, триггеры.
При подготовке задачи вы не сможете обойтись без помощи разработчика. Заранее обсудите с ним задачу, расспросите о подводных камнях, вариантах реализации, наиболее сложных моментах в придуманном дизайне.
Не бойтесь переборщить с детализацией задачи. Даже если вы полностью запрограммируете прототип своего макета, разработчику останется ещё уйма работы по его внедрению в настоящий продукт.
3. Помогите сказать «нет». Если под вашим давлением разработчик возьмёт некачественную задачу, а потом не сможет её решить, пострадаете в первую очередь вы. Лучше узнать о проблеме на берегу, чем в открытом море. Помогите разработчику отказаться от негодной задачи:
Чего не хватает в макете?
Какие могут быть проблемы?
Что я не учёл?
4. Убедитесь, что назначен дедлайн и забиты «гвозди». Задача без дедлайна не может быть решена по определению. Одного дедлайна недостаточно, нужны промежуточные чекпоинты — «гвозди».
Если разработчик не знает принцип «сделать», мягко подтолкните его вопросами:
Когда сделаешь?
Что будет к этому сроку?
Когда посмотрим промежуточные результаты?
Сколько времени нужно на тестирование? Когда его нужно начать, чтобы уложиться в срок?
Если разработчик понимает принцип «сделать», попросите назначить дедлайн и забить гвозди напрямую: «Пожалуйста, назови дедлайн и забей гвозди».
5. Крутите педали. Не ведите себя как плохой клиент, который только воротит носом и насыпает правки. Проактивно помогайте разработчику решить задачу — прорисовывайте дополнительные сценарии, придумывайте поведение, предлагайте решения, изобретайте упрощения. Ваша работа помочь разработчику сделать.
6. Не лезьте не в своё дело. Не сомневайтесь в профессионализме разработчика. Не лезьте в код. Если у разработчика не получится реализовать, задавайте наводящие вопросы, чтобы разработчик мог сохранить лицо:
А как вы пробовали решить проблему?
А почему вот это не сработает?
А я вот слышал о таком способе…
7. Примите результат. Выделите себе отдельное время, чтобы проверить работу. Не рассчитывайте, что разработчик сделает это качественно. Он видит только часть системы и не может быть конечным контролёром.
Итого
Не будьте мудаком. Работайте. Помогите разработчику сделать. Растите разработчиков, чтобы сделать коммуникацию проще, а результаты лучше.
Источник: fff.works
