5 заметок с тегом

работа

Синхронизация команды и работа над общими исходниками

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

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

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

Не смотря на то, что описанные подходы уже используются и проверены временем, заметка будет обновляться по мере нахождения более эффективных приемов работы.

1. В проекте нужен «Мастер»

Задача Мастера в том, чтобы заниматься слиянием исходников (синхронизацией). Хотелось назвать его библиотекарем, но в продуктовых командах — библиотекарь это отдельный исполнитель, занимающийся исключительно библиотекой и гайдлайнами.

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

2. Версии файлов заменяем датами

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

В названиях папок присутствует название проекта, для того чтобы можно было копировать папку куда угодно без дополнительных корректировок и настроек к экспорту. Это исключает путаницу с другими подобными папками.

Формат имени папки строится на привычном дедуктивном методе:
«Project-name-yyyy-mm-dd». Где имя может содержать дополнительную информацию, например «АЕ Анимация иконок меню». Это нужно для более быстрого поиска работ.

Комментарии стоят не везде, а во благо приоритетности и быстрого поиска.

Папка нужна для того чтобы в ней хранить временные файлы и избавиться от бардака в общей папке проекта. Иногда требуется делать экспорт картинок, PDF или дополнительные работы: например, если делаем анимацию в АЕ, то большое число файлов неизбежно.

Изредка, случается, что необходимо иметь две разных версии в один день. Тогда рекомендуется дописывать версии и пояснять их при необходимости:
Project-name-yyy-mm-dd ver-1
Project-name-yyy-mm-dd ver-2

Поскольку мы полностью в курсе только тех изменений, которые произвели сами, необходимо следовать следующему правилу

3. Чужие исходники не трогать

Совместная работа над проектами подразумевает наличие исходников-дубликатов. Если вам необходимо взять исходник другого участника команды — берите его дубликат, а оригинал не трогайте.
Для удобства работы рекомендуется исходники делить именами, например:
Project-name-yyy-mm-dd User 1
Project-name-yyy-mm-dd User 2

Открывая оригинал — вы рискуете по неосторожности испортить чужой исходник не заметив этого. Зачем потом тратить время на поиски и исправления подобных курьезов?

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

В этом скриншоте видно, что в проекте уже теперь две папки — появилась Sedisheva

4. Архив без мусора

В актуальной папке дня рекомендуется держать только те файлы, которые претерпели изменения. Это позволит при необходимости быстро совершить откат, а не перебирать кучу дубликатов в поисках прошлой версии.

Дубликаты, которые нужны только для открытия и копирования отдельных данных лучше переименовывать для отличия.

5. Читаемость исходника

То, насколько легко вы или любой другой участник команды сможет сориентироваться в исходнике зависит от ряда важных моментов:

  1. Как выставлены имена артбордов и групп
  2. Есть ли порядок в рабочей области
  3. Как построена работа с листами
  4. Где хранятся утвержденные и не утвержденные макеты.

Про имена

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

Для отображения разных состояний одних и тех же экранов в нумерации дописывается алфавит.
01. Название экрана — Деятельность на нем
01а. Состояние А
01б. Состояние Б
02. Название экрана — Деятельность на нем

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

1-01. Флоу 1
2-01. Флоу 2
3-01. Флоу 3

Порядок в рабочей области

Хорошим тоном считается нормальная сетка из артбордов. Помимо того, что она радует глаз, так же легко «читается», а главное создает четкую структуру в хаосе драфта из кучи версий.

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

Для отображения нескольких флоу на одном листе я пользуюсь визуальным разделением.

Работа с листами

Разделение проекта на страницы — значительно упрощает работу. Например, использование отдельной страницы для GUI поможет сократить временные издержки на перемещение от экрана с которым работаете до GUI с которого необходимо взять нужный объект.

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

Утвержденные и не очень макеты

Макеты, которые еще не прошли этап утверждения и находятся в редактуре должны быть отличимы. Они или располагаются отдаленно и разделяются визуально, как это было на скриншоте выше с разными флоу, или же хранятся на другой странице. Важен лишь факт разделения.

Я стараюсь располагать весь драфт на отдельной странице и копировать оттуда последние версии макетов в проектные страницы. Чтение версий драфта чаще всего происходит слева направо, сверху вниз, а для групп экранов просто сверху вниз, т.е самые свежие макеты расположены всегда правее и ниже всех остальных.

 21   2017   оптимизация   организация   работа

Структура хранения проектов

cover! white

О том, как больше не мучать себя беспорядком в рабочей папке и находить проект со скоростью обслуживания болида на пит-стопе

Организация рабочего пространства в проекте — половина успеха в проделанной работе. Хранение присланных исходников от клиента, найденных иллюстраций, купленных, отретушированных и еще до кучи разных — задача на первый взгляд не тривиальная, но важная.

Чтобы побороть разрастающийся хаос в процессе работы придумал, нашел, скорректировал для себя ряд правил. Сейчас, спустя годы обкатки я наконец могу эти правила рекомендовать.

При этом, следовать правилам с рвением добиться завсегда идеалов не стоит, это может перерасти в убийство времени ради порядка. Наша задача стоит добиться легкой ориентации в проекте и быстрого нахождения файлов. Поэтому самым главным правилом является «Не усложняй».

Не усложняй

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

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

Базовые правила

  1. Должен быть универсальный шаблон для новых проектов;
  2. Каждый проект хранится в отдельной папке;
  3. Имя папки должно содержать имя клиента и проекта;
  4. Все файлы, относящиеся к проекту разбиваются на 5 категорий и хранятся в соответствующих директориях;
  5. Версии рабочего файла идут через двойную нумерацию с префиксами -001-01, -002-01 и т. д.;

Шаблоны

Для экономии времени на организацию каталога в новом проекте, использую папку-шаблон _Inc Project. Нижний слэш переносит папку вверх списка.

В ней хранятся ряд других папок, для дополнительных файлов:

Approved — Финальные файлы, на передачу;

  • Data — Для документации, заданий и исходников высланных клиентом;

Revision — PNG макеты для обсуждения и комментариев. Если проект идет в сбор на Invisionapp, каждую итерацию правок я сохраняю в поддиректоритою с указанием даты и времени. Например, «2016-05-17 13.20»;

  • Source — содержит в себе все данные, которые я нашел для данного проекта или посчитал интересными: Скриншоты, ссылки на сайты-примеры, фотографии с фотостоков. Все это опять же сортируется в поддиректории buy, search, url.
Помимо папок, корень содержит в себе еще два файла-шаблона для Illustrator и Sketch и служит основной директорией для рабочих файлов.

Ранее для рабочих файлов я использовал папки с именами WIP (work in progress), затем просто work, пока не понял что эту папку использовал строго для того чтобы файлы не пошли вперемешку с остальными. А раз все прочие уже раскиданы по другим дополнительным папкам, то зачем делать лишние телодвижения и двигаться в отдельную папку, когда корень проекта идеально подходит для основных исходников?

Имена файлов

Все достаточно просто. Люди придумали много вариантов того, как называть файл (особенно для верстки), но я как человек чаще творящий и значительно реже верстающий (и то сугубо для своего бложика) никаких особых правил по именам не придумывал.
Их всего 3:

  1. Называть файл понятно и доступно: call-me-latter.psd — значит картинка для блока «перезвонить» на сайте;
  2. Приоритетный файл проекта включать вверх нижним слешэм, вспомогательным исходникам давать простые имена;
  3. Использовать дедуктивный метод сортировки, в котором первое число — итерация для клиента, а второе — личная.
Проект прошел одну итерацию с заказчиком. Его имя _store-new-tp-002-02.ai

Сортировка проектов

Я пробовал сортировать проекты по годам и месяцам. Это было худшим решением за всю жизнь, потому что если для одного и того же клиента делался ряд проектов и мы не помнили когда именно решали задачу — поиск исходников становился неэффективным и затратным по времени. Чаще всего именно так и происходило.

Затем стал заводить одну общую папку для конкретного клиента и уже в ней держал проекты, а в начале писал дату формата гггг-мм.
При обслуживании постоянных клиентов это обретало смысл. Хотя сейчас понимаю, что достаточно было просто писать версию «переиздания», а не ссылаться на даты.
Ниже можно наблюдать структурирование папок с 2009 по 2016 года.

Структура образца 2009-11, когда было все раскидано по годам. В 11 году начал добавлять папку Source. Структура была старой, как в прошлом слайде. Позже в 2012 году просто навел порядок. Ближе к концу 2012 составил полный список папок. В 2013 список папок утвердился до необходимого минимума. 2016, Обновленная структура папок. Удалена папка WIP, которая до удаления уже звалась work.
В качестве примеров прилагаю скриншоты папки клиента SDI Solution. Именно тут видно как я пробовал различные варианты и отказывался от разных функций.

Согласитесь, удобнее искать по имени, а не привязке к дате.

Кто-то спросит: Зачем в папке имени проекта фигурирует имя клиента?
Ответ: Папка с конкретным проектом, отправленная по почте теряет часть структуры и начинается боль, если таких папок больше чем одна. Я сохранил однажды на флешку несколько проектов от разных клиентов, а имена папок были «A4 акция» и «А4 + Диск», ругался на себя пока не надоело путаться и не переименовал папки по-человечески.

Сортировка папок

Итак, с внутренними папками клиентов мы разобрались. А как быть, когда число клиентов перешло за первую десятку?

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

При переходе на мак, я не стал дублировать проекты с компьютера и просто создал новую папку. Это фигурирует во всех скринах, но смысла на это обращать внимания нету.

Компании прописываю капсом. Так оказалось проще отличать компанию от частного лица или того хуже от кого-то залетного, но требующего остаться на сохранении.

 10   2016   оптимизация   организация   работа

Ошибки клиента — эффективность и цены

cover!

Ценообразование связано напрямую затратами  времени × сил , где ценностью является результат работы, предоставляемый клиенту пользу, силу или статус.

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

Связано это с недостаточным уровнем знаний исполнителя. Дешевый исполнитель не профи и большую часть работ делает не автономно, а руками. Либо вовсе использует не эффективный инструмент, который сковывает возможностями.

И говорит о том, насколько сложна задача. Убедительно говорит, потому что сам в это свято верит. Так у проекта растут сроки, из-за них поднимается себе стоимость и проект раздувается до неприличия.


Наглядный личный пример:


Задача: Избавиться от 10 шрифтов включая начертания в проекте, заменив их на 2-3 аналогичных бесплатных.

Проверь себя дзгнер: сколько тебе понадобилось бы времени, чтобы заменить все шрифты в этом проекте? (ответ ниже)

Верный ответ: 5 мин.

Как так получилось? Да легко!
Illustrator: Type → Find font…
Sketch: Style text

Примеров, в которых нужны не только профильные знания, но и эффективность даже придумывать не нужно: «Обнови старую шапку и подвал на всех страницах на утвержденные новые», «Обнови меню на всех страницах магазина», «Обнови везде картинку / кнопку / стиль ссылки» и проч. В случае, когда цена базируется на строгом контроле времени подобная эффективность становится архиважной. Для исполнителя — потому что он может реализовать свой потенциал в бо́льшем числе проектов. Для заказчика — получает продукт в горячие сроки.

В итоге «дорогой» профессионал сэкономил бы время и деньги клиента, помимо того, что в целом по умолчанию помогает зарабатывать. Важно что специалист может просто выполнять творческую деятельность, не преследуя целей повышения конверсии, удобства работы с информацией или скорость поиска. Эти «мелочи» дорого обходятся клиенту и его бизнесу.

Посчитаем на утрированном примере ценообразование на сроках:


| |Специалист                      |Профессионал |

|Час работы: |200 руб.        |800 руб. |

|Потрачено времени:              |min: 30 мин
max: 3 часа |5 минут |

|Итого к оплате: |от 100 руб. до 300 руб | 67 руб.  |


Ручной работой, я бы вряд-ли уложился в час. И это мы не учитываем самого факта эффективности результата труда, на сколько инвестиция в дизайн оказалась оправданной.


И как быть?

Клиент не худрук и насквозь не видит навыки исполнителя, лишь догадывается насколько успешен исполнитель, разглядывая портфолио как простые картинки. И результат работ тоже. Тогда вопрос, как выбрать хорошего исполнителя?

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

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

Но это же дорого?
Нет, это прибыльно. Но только если люди, к которым вы обратитесь помогут поставить верные цели и составить бизнес-требования, которые будут осязаемы и измеримы. Инвестиция в бизнес не может быть дорогой. Она может быть или неверной или оправданной.

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

 1 комментарий    39   2016   качество   работа   цены

Как вставить прототип в Behance

cover! white transparent

Не все знают что можно вставить прототип на Биханс. Правда не всем это и нужно :)
Прототипы, показывают объемы детализации работы. Это очень удобно и наглядно. Лучше прототипов лишь видео презентация или анимация.
А еще лучше работающее приложение или проект.

Тем не менее, если остались лишь силы на вставку рабочего прототипа из InVision или Marvel, то во втором случае это реально сделать. Как сделать подобное из инвижион я не разобрался, но думаю что это тоже реально.

Инструкция
Заходим в прототип, находим кнопку Share и после клика копируем код из таба Embed

А затем уже вставляем полученный код в Behance

Профит :)

p.s.: Хочется заметить, что прототип, конечно же круто, но пожалуй, он должен не заменять, а дополнять проделанную презентацию в виде анимаций и видео. Сугубо для людей, желающих потыкать и поглядеть все досканально. Все таки люди любят посмотреть все глазами и по-быстрому, а не сидеть и разбираться что где можно сделать, а что просто картинка.

 172   2016   behance   invision   marvel   презентация   прототип   работа

Правильная постановка задания

cover!

Залог продуктивной работы — правильная постановка задания, которое составляется самолично. Таким образом я показываю заказчику насколько верно понял задание и справлюсь ли.
 

Заблуждения

Важно понимать, что пренебречь составлением задания нельзя. Категорически. Это защита от клеветы и намеченная цель для достижения результата.
Если кажется что:

  1. Это пустая трата времени и глупость.
  2. Вы итак друг друга поняли и переписывать обсуждаемое нету необходимости.
  3. Задача мала чтобы уделять этому так много внимания.
  4. Клиент старый и проблем не возникнет.
    … то пора переосмыслить подход к работе.

В любом случае, так кажется до тех пор, пока недопонимание не всплывает наверх. Сами причины — нежелание делать рутинную и неинтересную работу. 
В тех отдельных случаях, где задача мала — я рецензирую в скайпе. Нету ничего зазорного написать 3-5 предложений для малого объема работ, потому что даже тут можно неверно понять (заказчика) или ужасно объяснить (исполнителю) и завалить работу на «победный» повтор.
 

Проблемы долой

Встречаются клиенты, нежелающие работать над заданием . Суждения базируются на экономии времени, а если вдуматься то выходит в точности наоборот: вначале мы тратим время на то чтобы самостоятельно разобраться (это ~вдвое медленнее, чем рассчитывает клиент), затем после неверно проделанной работы мы тратим дополнительное время на разбор ошибки, постановки правильного задания и затем на повторную работу.
Клиент, категорически отказывающийся работать по схеме полноценного разбора задания — даже не рассматривается. Кому нужен такой супер герой «человек-мудак» тяжелый заказчик? 

Умный клиент разжевывает подробности, но чаще встречается дилетант, который не знает что нужно исполнителю и как правильнее это подать. Клиент и не обязан правильно ставить задачу, — потому вас и нашел — чтобы вы сделали классно. Вы же столько лет оттачивали мастерство по ведению проекта начиная с обсуждения задания. (Он даже и не знал что есть такой этап!)

Поэтому ответственность берите на себя. Это работа и мы знаем как провести проект к успеху по шагам. Для этого требуется больше концентрации, внимания и дотошности на данном этапе сотрудничества.

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

 

Сокращаем риски

Один из простых и не менее действенных способов сократить риски при утверждении задания — техника «3+», описанная в книге «Сначала скажите нет». Джим Кэмп использует эту технику для проверки клиента при переговорах для уверенного «закрытия сделки».

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

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

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

Осталась мелочь, начать работать над проектом!

 50   2015   задание   переговоры   работа