Блог NunDesign

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

Все знают, как не просто бывает в командной работе договориться дизайнеру и программеру. И вот, после долгих месяцев трений (до повышенного тона и выяснений, кто виноват) и программер разобрался, где какой скрипт-код как написать, для того, чтобы реализовать нарисованное, и дизайнер приноровился, что рисовать, для того, чтобы это реально было внедрить, и тут - опаньки! - очередной программер исчезает из поля зрения в поисках лучшей жизни. Приводят следующего - и опять встречаем ту же упёртость - это реализовать нельзя!

Чётко видно два подхода. Одни говорят - я в самом деле не знаю, как это сделать, и не встречал, как это кто-то делал бы. Но попробую разобраться. И идёт разбираться, кто-то быстрее, кто-то медленнее, но, в конечном итоге, всё сростается и основная здесь проблема - получить новичку время на исследование-обучение + договориться с дизайнером, что и как они будут делать. Вторые дизайнеров за авторитет не почитают ни в каком приближении, и если эти “художники” добавляют ему каких-то проблем, просто отшивают их, мол, нереализуемо. А заказчики - они что, они качество кода оценивать не будут, для них всё качество заключается в работает/не работает, зато на красивые фантики (заставочки, кнопочки, иконочки) покупаются моментально. Если в компании чрезмерно уделяется внимание внешнему виду в ущерб логике и коду - это плохой метод, потому что в конечном итоге бесперспективный. Но если есть здоровое понимание важности грамотного и красивого интерфейса для утверждения (и дальшейшего развития-совершенствования) проекта, а программер в силу недостаточности опыта не догоняет принятую в качестве стандарта модель - начинается конфликт. В самом деле. Дизайнер, вместо того, чтобы продумывать форму и сценарии показа форм, отношения цветов и отрисованные элементы становится дурацкой пешкой, которая бегает между программером и PM, торгуясь - будем мы делать ТАКОЙ интерфейс или нет (потому что именно ЭТОТ программер, в отличие от ПРЕДЫДУЩЕГО, пока не может быстро реализовать задуманное с графикой). Фигня какая-то. (more…)

Думаю, как можно оптимизировать работу с потенциальными дизайнерами, собеседования с ними, отношение к ним. Заявок приходит довольно много, просматриваются/отсеиваются частично на первом уровне, но ведь понятное дело, что в резюме каждый будет писать “профессиональное владение…” и “богатый опыт…”, по работам в портфолио вовсе не обязательно можно понять уровень специалиста (по разным причинам - с одной стороны не все работы в портфолио можно светить, с другой - нет гарантии, что опубликованные в портфолио работы как-то характеризуют специалиста - на реальном собеседовании оказывается, что “идея была не его, а другого дизайнера”, “пиктограммы рисовал не он” или вообще “он принимал участие в этом проекте, но интерфейс - делал другой человек”).

Читаю интересные замечания о собеседованиях в блоге highly professional scums - “ИНТЕРВЬЮ ГЛАЗАМИ ПОСТРАДАВШЕГО” -речь идёт о найме программеров, но некоторые идеи можно использовать и при поиске практически любого специалиста:

Время собственных правильных кадров надо жалеть и экономить. Будем экономить. Начнём с отбора резюме. Собирает HR+рекрутер (можно в одном лице), по ключевым словам или как угодно ещё (хоть бы и медитацией). Может давать вопросник. Шлёт вакансии, пробует сманивать, постоянно общается со своими кошерными кадрами - чтобы хорошо понимать и чувствовать формальные признаки. Полученную папку резюме просматривает уже лид, или тот, кому лид поручил. Аналогично вакансии пишет лид. Если есть сомнения - резюме выкидывается. Если есть непонятки - их выясняет HR.

Честно говоря здесь достаточно сложно (в нашей конторе) - наш “HR” вообще в специфике не силён, разницу между вёрсткой буклета для печати и html вёрсткой, похоже, так и не понял (-а), поэтому базовый отбор ведётся таки по ключевым словам, вторичный базовый - уже мною. По началу на собеседование приглашались вообще все подряд из списка тех, кто хоть немного в теме - острая нехватка, острая нужда хоть в нескольких, хоть сколько-нибудь просвещённых в теме дизайнеров, шлифовка на ходу, и пусть с ним, что опыт есть только полиграфический - PS знает уверенно, чувство цвета-композиции в норме, вкус есть, стремление обучатся выше нормы - подходит, ура! Немного позже было принято решение строже относиться к анализу резюме на первом уровне, тщательнéе проводить личные собеседования и ещё - выставлять тестовые задания. Практически обязательно и практически для всех. Причина банальна, как афоризмы о любви - ни один, вообще ни один из всех дизайнеров в портфолио не показывал тех работ, того стиля, той лёгкости, яркости, смелости, которые требуются здесь. И при этом трое сумели сообразить, что от них требуется и научиться нужному стилю (ещё одного брали - в самом начале - без тестового задания, но не пожалели, ещё одну тоже брали без тестового задания, но пожалели и пока что жалеем до сих пор). Остальные - воодушевлённо говорили, что ничего сложного в “требуемом” стиле не обнаружили и - конечно да, конечно, смогут, но по концовке тестовые задания выполнялись в том же, их уже наработанном стиле, и не принимались. Одного из таких, который выполнил работу типа “ну-у-у… почти то, почти, но…” всё же взяли на испытательный срок, но за месяц человечек так ничего и не сумел сделать, как надо.

Тестовое задание формулируется примерно следующим образом: “…Выберите любую программу, любой сервис, виндовый или нет, онлайновый или - можете даже придумать что-то вообще абстрактное - что бы вам хотелось “порекламировать”, с чем бы вам было приятно работать. Выберите тулз, которым пользуетесь часто и который вам нравится. Сделайте для него эскиз рекламного сайта в формате [logo]+[name]+[слоган]+ [menu]+[рекламные, информационные, дополнительные блоки]+[дубль menu]+[copyright]. При этом меню - даётся структура из 4-5 как бы обязательных пунктов и несколько необязательных пунктов, которые можно добавлять или нет и даже называть по-разному в зависимости от того, что собирается прорекламировать в своём тестовом задании испытуемый. При этом если для тестового задания человек берёт какой-то известный тулз/сервис (к примеру, ребятки, которые приняты и сейчас успешно работают, рисовали эскизы на сайт WinAmp`а, Opera, каких-то виндовых плейеров, игрушек) - то позволительно зайти на официальный сайт этого тулза/сервиса и снять от туда форму логотипа (который, в свою очередь, позволительно - не меняя концепцию лого, вернее, его узнаваемую форму) переделать в стиле разрабатываемого эскиза - вплоть до цветовой гаммы (всё равно это никто, кроме меня не увидит), взять рекламные тексты и жизнерадостные слоганы, краткие описания тулза, технические характеристики или системные требования к установке и вообще всё, что может понадобиться. Если же “рекламируется” абстрактный, не существующий тулз/сервис - позволительно всё сформировать из текстов “loren ipsum” - важно показать стиль, технику, сообразительность.

Дальше я показываю - очень не мало - работ, уже выполненных в требуемом стиле, рассказываю о цветах (и цветовых сочетаниях) и модульных сетках, уместных в подобных эскизах, показываю, чем (обычно) отличаются “корпоративные презентационные” сайты от почти таких же по контенту и навигации “рекламных” сайтов - рисовать можно как в первом стиле, так и во втором. Смотрим примеры, записываем на листочке (блин, давно надо было сделать шаблон и распечатать кучу копий - задание-то одно и то же даётся, только просто кажется, что если записываю задание дизайнеру на его глазах, ручкой - он лучше понимает, постановка для него становится менее формальной) задаю вопросы и отвечаю на его вопросы - чтобы не осталось непоняток и отправляю рисовать (домой отправляю, потому что из приходивших у всех дома были компы и ни один не пожаловался, что тестовую работу ему рисовать негде, правда, не забываю спрашивать об этом на всякий сл.). Да, по ходу предлагаю ещё иногда (если вижу какое-то подозрение во взгляде) пообщаться с нашими дизайнерами - убедиться в том, что ни одно тестовое задание здесь никогда не использовалось в работе, т.е. никто ничего не тырит, дабы не было даже сомнений. И всё, дальше жду.

А дальше в подавляющем большинстве случаев остаётся только удивляться. Вот господин (бодрый такой, нагловатый и разговорчивый), на собеседовании убеждавший меня в своих талантах, в том, что он всё понимает и да-да-да именно так и сделает, и вообще его брат - артдиректор в крутой компании, и он сам тоже крут, и ему оплату испытательного срока - 1,2 килобакса не меньше, присылает тест, такой… в общем совсем ноль. Всем нулям ноль. Даже звонить/отвечать ему не хочется. Была такая идея - публиковать отвратительные тестовые работы таких-вот красавцев здесь (хотя бы), но тут вот подсказывают, что - ну его, могут быть и проблемы. Это, как раз, к слову о том самом авторском праве на контент. Но никто не мешает обсуждать тестовые работы кандидатов с нашими, уже родными, уже принятыми и успешно работающими в команде дизайнерами. Иногда и обсуждаю - недавно приходила на собеседование “общая знакомая” - тоже как бы опыт, академические знания, подтверждённые дипломом, требования к зарплате (на исп. срок) вполне как у профессионала, куча амбиций и строгости во взгляде… Ссылки на работы из портфолио обсудили с дизайнерами. Видимо, это совсем не то. Видимо, здесь даже тестовое задание не спасёт отца русской демократии.

А дизайнеры нужны-ы-ы но (цитата из той же статьи):

Нанимать нехороших кадров просто потому, что не получается нанять никаких других - плохая, глупая идея. Мифический «средний» программист тоже не нужен. Вообще. Деление здесь практически бинарное - может писать код или не может писать код. Бывает, что может студент. Бывает, что не может эксперт с мировым именем. У интервью две задачи; первая - выяснить, «может» или «не может»; вторая - выяснить, «нравится» или «не нравится».

Просто замените слово “программист” на “дизайнер” - и получите тот же самый бинарный выбор - или встречу или не встречу или сможет делать те эскизы, которые нужны, или не сможет. Есть опыт. что полиграфист с нулёвым опытом работы с экранной графикой за неделю работы навёрстывает необходимую для работы информацию и делает суперские макеты. Есть опыт, что 18-летний (кажется, уже 19-ти) студент, совмещая обучение в не самом простеньком ВУЗе с работой в нашем офисе, успевает сделать столько хорошей работы, что им довольны все - в том числе сотрудники-дизайнеры, потому что подкидывает много идей, шаблонных решений и вообще лапочка. Есть печальный опыт - когда принятый дизайнер не делает то, что ожидают от дизайнера вообще (и тягостно, и грустно, и жалко - там семейные обстоятельства, «перипетии жизненных коллизий» два раза ©Алексей Матюшкин и всё такое…), и от жёстких решений спасает пока только то, что есть очень лёгкая работа в большом объёме для на редкость не требовательного заказчика - но ведь это всё равно не правильно, не правильно. Всё таки следует быть увереннее в себе и своих задачах (а, значит, и требованиях к их реализаторам), прагматичнее и категоричнее. Ещё цитата из той же статьи:

По результатам такого телефонного общения и теста - большАя часть плохих программистов отсеивается. Резать надо нещадно. Если есть сомнения и кандидатов мало - можно привезти одного-двух лишних; обычно такое делается в начале серии интервью, потом становится понятно, что так делать не надо. Хотите пробовать - пробуйте.
Бывает (редко) - повезло, не отсеяли лишнего. Чаще мало лишнего отсеивается. Хуже нанять лишнего. Уволить морально тяжело. Лечить последствия. Переписывать код. Менять планы. Или смириться. Лучше сразу не нанять. Лучше не донанять. Лишний кадр - это ещё и овертайм. Не только себе, но как минимум ещё и лиду. Нафиг лишний кадр.

Лучше сразу не нанять. Лучше не донанять. Теперь я это знаю на практике, на реальной работе.

Уже сейчас, новичкам-дизайнерам, которые только-только, читаю о значимости “командной работы”. Уже сейчас, среди совсем новичков и среди “почти не новичков”, ориентируюсь на мелкие командные пары-связки “рисующий”+”верстающий” (немного в прошлом посте об этом уже было, и о трудностях даже в парных связках), выравнивая по скорости работы, по характерам - к примеру, на сегодняшний день “рисующий” рисует эскизы приблизительно с той же скоростью, как его в паре верстающий эти эскизы завёрстывает в сайты с шагом -1 (т.е. к тому времени, когда у верстающего заканчивается работа над сайтом N, рисующий как раз заканчивает работу над сайтом N+1) - это очень здорово, но получится ли так же успешно у следующей связки? Пока неизвестно, и ставить их на поток в ответственных больших сайтах страшновато (тем более объём по безответственным простым сайтам ещё огромный).

А ведь это только первый шаг. Потом дизайнеры будут учиться работать с нашими программерами (которые, кстати говоря, тоже не подарочки, каждый первый со своими тараканами) , и не в паре, а в большой команде, и договариваться придётся по куче организационных вопросов - от именования файлов в файловой структуре до системы обмена уведомлениями по поводу модификации (оформления) разных блоков, форм и прочего… Вообще вопросы организации командной работы, конечно же, ширее ширше сложнее в целом, и договариваться приходится всё время, изо дня в день.

Вот берём к примеру проект. Большой. Работает команда (не считаем менеджеров-управленцев), из разработчиков - 8 программистов на нашей стороне и чуть меньше (но не менее квалифицированных) - на заокеанской, с нашей стороны -+ один дизайнер и + один тимлидер, к которому сводится весь код, который и выкладывает “сегодняшнюю” версию на публичный тестовый сервер. И проект, кажется, интересный, и не только идея - но и… как это называется? Когда, если будет закончен и запущен - станет чудо как престижным, потому что уже сейчас потенциальные, почти-почти реальные партнёры - это монстры всея сети, имена которых известны даже школьникам, и уж, кажется - долой совдеповское представление о том, как должна быть организована работа! Ведь не важно - как после, через пол года, через год повернётся ситуация, но написать в том же портфолио-резюме строчечку о том, что участвовал в таком масштабном, для таких известных… это же грандиозно! Значит, не может быть в командной работе зашоренности на реализации логики отдельного модуля!

И опять сталкиваемся с тем же. Что-то программер ваяет, сочиняет, пишет, в восемь вечера коммитит в SVN свой (работающий) кусочек кода, который включается в проект и выкладывается на тестовый сервер. Где СамыйОтветственныйУправляющий тестирует (для него это не модуль, для него это - страница сайта, на которую он заходит и кликает на ссылочки, заполняет формочки), смотрит с ужасом на страницу, про которую ему типа уже доложили, что “сделано”, и говорит - ребята! Здесь же ничего не сделано! Это нельзя показывать президенту компании! А презентация для него состоится через два часа!

Дизайнер, в начале девятого вечера получивший новый код, судорожно принимается причёсывать формы, прописывать классы, оформлять гриды и отрисовывать новые кнопочки, тестировать в куче браузеров, выкладывать новую версию (ок, более менее), но тут обнаруживается, что ещё один программер залил новый модуль (логика работает), в котором элементы форм накиданы подряд, один контрол (уже до того отредактированный дизайнером) заменен на совсем другой (ага, ессно визуализация вся поехала) и нужно ещё пару часов на именно этот модуль, а времени-то уже к 10 вечера! А красавцы-то в восемь (как им по графику положено) закончили программировать свою логику, залили код, и, ни слова не сказав тому же дизайнеру, честно ушли, домой. Чисто формально придраться не к чему.

Чисто формально. Реально с таким формальным подходом они подставляют не только дизайнера (Таня, здесь же ничего не оформлено! - Да этот модуль только что появился, когда бы я успела? (Тех.директору) - Чем вы там все занимаетесь? Это же никому нельзя показывать! - Но программист же сделал логику, как заявлено, логика-то работает? - Нифига здесь не работает! Это нельзя никому показывать! Уберите пока эту страницу из проекта вообще, чтобы они даже случайно сюда не зашли, пусть лучше UnderConstruction, чем эта фигня! Вы же целый день там работали, неужели нельзя было сделать по человечески?) , но и себя, в конечном итоге. Потому что там, у главного руководства, будет поставлена галочка: модуль программиста А не выполнен, работа не сделана.

Я уже не говорю про чисто человеческое отношение. Так же, как этому программисту глубоко наплевать на работу проекта в целом (а заказчик-то смотрит не на кусок кода, он смотрит как раз на проект в целом), так же - и на других участников проекта. В половину девятого вечера дизайнер Таня обнаруживает новый модуль? Сама, кстати говоря? Но это ведь её проблемы, что опять, так же, как и изо дня в день, будет сидеть до позднего вечера править новый код? У программера-то отмечено - рабочий день до восьми, значит, в восемь вечера залил-встал-ушёл. Логика то в его коде работает.

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

Решаемо. Можно договориться. Можно научиться договариваться, если не умеем пока. Хочет ли программист, чтобы его “сегодняшнюю” работу чекнули как выполненную? Могу предположить, что - да, хочет. Нарвавшись не единожды на то, что никто не будет читать его великолепный код, но и непричёсанную логику показывать - тоже не будут, может ли программист расчитать своё время таким образом, чтобы успеть увидеть свой код включенным в проект (а значит - оформленным как полагается)? Дык легко. Никто тут не программит прямо как совсем уж раб индийский - и за кофиём посвистеть время есть, и анеки почитать, и по асе тоже…

Сколько у программиста уйдёт времени на то, чтобы сказать дизайнеру о том, что “вот эти данные” выводятся не тем контролом (который уже был оформлен), а другим совсем, потому что там ещё пейджинг нужен и ещё что-то (да кто же спорит? Не дизайнер спорит, уж точно), и что естественно надо его пересмотреть, потому что у грида по дефолту есть бордеры, которые для данного макета неуместны, что “этот контрол” перестал быть самостоятельной таблицей и теперь включается “сюда” и “сюда” (а значит один заголовок оказался лишним + потерялось наследование от старшего объекта в таблицах стилей) и т.д. Вроде ведь не только в одной стране сидим, - в одном помещении, но как показывает практика, с программистом, открытым для командной работы (пусть он хоть в другой стране находится, хоть за океаном) сотрудничать легче (и в целом выходит успешнее), чем с таким же мурлом с местечковым мышлением за соседним столом. Ну как объяснить? Что каким-бы ни был гениальным его личный кусок кода - если он не будет включенным в проект, вся его гениальность так и останется невостребованной?