Блог: заметки с тегом разработка

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

Автор блога — Mon, 11 Dec 2017 09:57:06 +0400

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор блога — Sun, 03 Dec 2017 21:28:09 +0400

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

1. Осознайте ответственность. Как только вы возьмёте задачу, между вами и дизайнером возникнут отношения исполнитель ↔ клиент. Вы — исполнитель. За взятую задачу будете отвечать вы и только вы, поэтому, если не сможете реализовать, если не успеете, если в дизайне чего-то не хватит — проблемы ваши. Хороший дизайнер поможет решить проблему, но целиком полагаться на помощь дизайнера безответственно.

Представьте, что задача — это пластилин. Как только вы берёте задачу, вы берёте «пластилин» в руки. Вернуть «пластилин» дизайнеру можно только двумя способами: 1) сделать и отдать слепленную фигурку — результат, 2) провалить задачу и отдать измятый пластилин — недоделанную работу и набор причин, почему вы провалились. Пока «пластилин» у вас в руках, за него отвечаете вы.

2. Поймите задачу. За задачу отвечаете вы, поэтому на вашей совести задать все вопросы, запросить все материалы, оговорить все нюансы по задаче. Если чего-то не хватает или вы не верите, что справитесь — не берите задачу. Если взяли — сделайте, не смотря ни на что.

Чтобы понять задачу задавайте вопросы:

В чём польза задачи?

Кто этим будет пользоваться?

Почему её важно сделать именно сейчас?

Как эта задача связана с другими частями системы и с другими задачами? Что ещё придётся изменить в связи с этим в других местах?

К какому сроку вы бы хотели получить решение?

Почему это критично реализовать к указанному сроку?

Если задача сложная, сами напишите, как собираетесь её решить и утвердите получившуюся спецификацию у дизайнера.

Не бойтесь сказать «нет». Вы всем поможете, если не возьмёте негодную задачу, а если возьмёте и не справитесь — всех подведёте.

3. Назовите дедлайн. Дизайнеру нужен результат. Результат не бывает без срока. Оцените задачу и назовите дату, когда задача будет решена. В срок заложите всё, что необходимо для решения задачи: время на разработку, согласование с дизайнером, возможную переделку, тестирование, полировку и публикацию. В обещанный день и час решение должно быть в продукте, а не на вашем тестовом стенде, потому что результат — это запуск.

4. Забейте гвозди. Решение задачи зависит от дизайнера. Только он может сказать сделано или нет, поэтому до запуска вам необходимо показать ему промежуточные результаты несколько раз. Это нужно вам, чтобы сделать вашу работу. Поэтому договоритесь с дизайнером о конкретных датах — гвоздях, когда вы покажете промежуточные результаты. Если задача на неделю, у вас должно быть два — три гвоздя.

5. Оставьте запас времени. Не планируйте впритык. Что-то обязательно пойдёт не так. Вы столкнётесь с неуловимым багом, дизайнер десять раз попросит подвинуть кнопочку, проект не соберётся, комп заглючит, свет отрубят. Заложите 20% запаса в срок, он вас спасёт.

6. Сделайте. Добейтесь результата в срок. Если не будете укладываться — придумайте, как упростить и предложите упрощение дизайнеру. Знать, что не успеваете и молчать — отстой. Упростить и не согласовать с дизайнером — отстой. Не успеть и молча продолжать делать — отстой. Ждать, что упрощение придумает дизайнер — отстой.

7. Сдайте. Утвердите работу у дизайнера. Он ваш клиент. Если он не сказал «ОК», вы не сделали, даже если вы всё запрограммировали и всё работает. Пока не сдали «пластилин» в ваших руках.

Итого
На входе у вас << задача, макеты, пожелания дизайнера по сроку.

На выходе в день старта >> ваше понимание задачи (спецификация), дедлайн, набор контрольных точек — гвоздей.

В день дедлайна >> «ОК» от дизайнера и опубликованное в продукте решение.

P. S. Если всё-таки сорвали срок, признайте это как можно быстрее. Если дизайнер согласен работать с вами дальше, вернитесь к пункту 1. У вас должно возникнуть новое понимание задачи, новый дедлайн и новый набор контрольных точек.

P. P. S. И без детского сада, пожалуйста. Вам не нужен менеджер, чтобы следить за своими задачами.