БИБЛИОТЕКА CАЙТОСТРОИТЕЛЬСТВА

новости, статьи, обзоры по веб-дизайну и графике, разработке, оптимизации и продвижению веб-сайтов

Приветствую, уважаемые! Как вы все поживаете? Как прошли новогодние праздники? Хорошо ли вам без наших выпусков? Что-то и в самом деле проблемы с периодичностью. Пока что продолжим тему выживания дизайнеров в IT отрасли

Что делать с этими цыплятами?

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

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

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

Капризы со сценариями форм вообще удивляют. Ок, хорошо, сделали прогу, есть у неё триальная версия, возможность зарегестрироваться по ключу и возможность купить напрямую. Есть интерфейсная форма в триальной версии, в которой присутствуют кнопки “Buy” и “Register”. При клике на “Register” открывается модальное окно (т.е. поверх предыдущего, и предыдущее недоступно, пока не будет закрыто верхнее), в котором можно ввести ключ и + опять же кнопки - “Buy”, “Try”, “Cancel”, “Register”, и определён сценарий, что можно ввести ключ, нажать “Register” и зарегестрировать прогу. При клике на “Buy”, ясный пень, уйти на оплату. Для двух оставшихся реализовали следующий сценарий: при клике на “Try” предполагается, что юзер передумал вводить ключ, закрывается модальное и становится доступным предыдущее из триальной версии. При клике на “Cancel” - вообще сюрприз, закрывается вся программа! Спрашиваю - с чего вдруг? Где они вообще встречали такой удивительный по юзабельности интерфейс? Пользователь видит полноценное окно поверх основного - с кэпшином, крестиком (на закрытие окна), функциональными элементами и предполагает, что при нажатии на “Cancel” закроет именно это окно, а не все открытые, не всю прогу целиком. Всмысле нормальный пользователь (а ЦА проги - это как раз не гики оторванные, а среднеобученный юзер, который, к тому же, пользует программу с целью РАЗВЛЕЧЕНИЯ). Программер же в ответ начинает спорить, объясняя правильность именно своего сценария тем, что это же МОДАЛЬНОЕ ОКНО! Здрасьти, говорю, а где ты написал юзеру, что это модальное окно и по Cancel`у закроется и оно, и основное? Где ты вообще оставил обычному юзеру мануал по поводу того, что такое модальное окно и особенности управления модальными окнами?

В общем не важно, через PM, ессно, переразобрали сценарий по формам и кнопкам, на вопрос программера “а как я буду делать вот это…” - отправили всё-таки разбираться, сейчас интерфейс (последнюю версию ещё не видела) должен стать более естественным и привычным. А вот проблему поставить на виндовую форму нестандартную кнопочку (набор картинок, имитирующих поведение кнопки - с кликом, с фокусом, с disable и т.д.) - ещё нет, ещё не умеем, опять. Опять. Блин. Уже предчувствую, как будет колбасить нашего заказчика - он до сих пор считает, что знания это что-то вещественное, принадлежащее компании в целом, и если какая-то технология отработана, то при уходе носителя технологии следующий новичёк прям за неделю всё освоит и реализует как и ожидал заказчик. Я даже знаю, чуть ли не дословно, что он скажет.

С верстальщиками (как-то после нового года все эти недопрофессиональные проблемы приобрели массовый характер) то же самое - опять проблемы между рисующим дизайнером и техническим. Опять несоответствие отрисованного эскиза отвёрстанному сайту, опять отговорки - дизайнер нереализуемую фигню нарисовал (мол, эта фичечка того не стоит, чтобы из-за неё ТАК усложнять код) - и снова до конфликтов. Разбираем - что ТОГО стоит, чем можно пожертвовать и где верстальщик проявил элементарную лень разбираться с макетом, чуть более сложным, чем предыдущие. И, кажется, это всё решаемые вещи, там подучился, там разузнал, там - договорился, но как-то очень явно именно последние посленовогодние дни давит проблема недостаточности знаний/опыта у новичков, проблема постоянного выяснения отношений и конфликтов именно на почве можно/нельзя реализовать. А ведь ещё месяц-полгода назад уж было решили, что вышли на уровень взаимопонимания и сделать можно всё - было бы желание (и,может, время) и договориться можно обо всём.

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

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

У меня есть в тему совершенно личный пример. Человек, который на одном месте долго сидеть и бездельничать физически не может, работает в конторе (не нашей) сисадмином - большая распределённая сетка, куча сервисов и все дела. Но он выбил себе свободный график - иногда сутками-неделями сидит в офисе, чего-то там сетапает, настраивает, слушать невозможно про все его офисные приключения. Потом, настроив всё и всем, может неделю не показываться и дальше - периодически на несколько часов заезжать, юзерские проблемы помогать решать. Объясняет это так: а зачем мне здесь сидеть - всё работает! И удержать невозможно было. Так же, как и заставить уйти в шесть вечера из офиса (ага, счас, это вы клиентам объясните, что у меня с 9 до 12 плановая профилактика!). Получается, что этот (и в самом деле талантливый, решающий все проблемы, не имеющий нерешаемых проблем) сисадмин - типичный арабский скакун - штучка дорогая, но малоуправляемая. Крайности, конечно, в жизни всё с менее чёткими границами, и не всегда с первого взгляда-первого рабочего дня получается узнать про новичка и предсказать его будущее. Да и у нас, конечно, всё настроется, не первый раз (увы), просто нужно переждать очередной ледниковый переходной период.

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

Немного из комментариев к заметке:

Scratch: На тему "скакунов и першеронов" — так правильно. Скакун — он всегда дорог, сложно управляем и так далее… И он действительно может очень многое. (только не тягать центнеры туда-сюда, туда-сюда, туда-сюда…)
Ему простор нужен.
А насчет всех "внутрикорпоративных передряг" и прочих переходных периодов — вот тут как раз выплывает такая вещь, как "команда". Отношения к административному делению фирмы не имеет, кстати.
Команда — она сама по себе. Это неделимая единица. И команда, после того как сформирована, обычно не меняется (за исключением очень редких случаев).
Тимлидер в данном случае — это не просто мощный программер, который может (теоретически) управлять группой человек. Это именно тот человек, к которому прислушивается данная конкретная команда. Не более того. И он может даже не быть супер-программистом или супер-дизайнером, или кем-то еще. Он просто является сердцем команды, идейным двигателем и так далее…
Некоторые фирмы, которые построены таким образом, очень даже успешно работают на рынке (как пример — Ашманов и Со Товарищи). И очень часто — многие другие, обычно — не очень большие фирмы.
Кстати, очень многие авторы говорят о создании именно такой вот команды, в которой все всех как раз понимают, знают и уважают. Но — такая команда неудобна в управлении. Потому что она, опять же, неделима. И внутрикорпоративная ротация часто и идет как раз для того, чтобы такие вот команды не образовывались.
Зачем? Элементарно. Если нет команды, то при увольнении одного сотрудника не уйдут все остальные, да и сотрудники будут посмирнее. Не будут требовать себе "работать с тем-то или с тем-то", ну и так далее. Попытка представить человека как что-то заменяемое часто и делает человека чем-то заменяемым — человек просто меняет фирму :)
И тогда и выплывают все бока с "незаменимых у нас нет" — так ведь говорят, кажется?

Anton Naumov: во-первых, командное деление — прерогатива продуктовых компаний. проектоориентированные компании не имеют монолитных команд. есть пул разработчиков и пул проектов. это эффективнее. nothing personal, никакого масонского заговора, just business.
во-вторых, ни разу не видел тим лида, который был бы слабее подчиненных. разве что в аспектах. но никак в целом. все знакомые мне лиды люди с колоссальным опытом девелопменат. а успешные лиды — еще и с колоссальным опытом управления. именно это и дает им авторитет. хорощий человек — не профессия.
в-тетьих, было бы ошибкой думать, что при увольнении одного сотрудника начнется массовый исход. я пытался как-то сорвать команду полностью. я не был лидом, но разговоры подрывные вел, каюсь. никто. команда просто развалилась. даже если уходит тим лидер, не всегда уходит команда. а уж если девелопер уходит… отряд не заметил потери бойца, называется картина. это миф, нет в реальности такой единицы, как комнада. во всяком случае я не видел ни разу. это только во дворе каждый за каждого, в бизнесе каждый сам за себя.

Обсудить эту заметку можно в блоге NunDesign. Конечно, мне интересно ваше мнение.

ИНТЕРЕСНО ПОЧИТАТЬ:

:: Предновогоднее дизайнерское - они похожи на свои работы.
Когда руководство решило уволить одного из наших дизайнеров, зачем-то выпрашивала "давайте ещё недельку, давайте ещё месяц", мол, разрисуется ещё, покажет ещё. И когда прижали уже серьёзно, а тут один заказчик утвердил для себя эскиз именно дизайнера1 - радовалась как дитё новогоднему подарку....>>

:: Азбука анализа пользовательских задач в веб-дизайне
Очень часто анализ задач не выполняется, недостаточно полно документируется, либо выполняется, но не используется при проектировании....>>

:: Autokadabra: наборы иконок
Турбомилк делится опытом: "Разработчики обратились к нам с непростой задачей — нарисовать иконки для всех легковых автомобилей на свете. Но не простые иконки, а "перекрашиваемые", чтобы пользователи могли выбирать любой цвет для своего авто."...>>

:: Прототипирование web-сайтов. Собирая воедино
Самые дорогие ошибки - это ошибки, допущенные в начале проекта, так как именно на начальных этапах принимаются наиболее важные решения. По мере развития проекта стоимость ошибки снижается....>>

:: CSS Sprites: все, что вы знали, но боялись спросить
Сейчас уже много где написано и упомянуто про технику CSS sprites (aka CSS Image Maps). Я не буду открывать Америку и рассказывать о ней дотошно еще раз, а просто хочу привести несколько примеров и полезных ссылок. И пару советов из собственной практики....>>

:: Учимся рисовать: Урок "Рисуем глаз"
Глаза, наверное ,самый важный элемент на лице. С помощью них мы общаемся с человеком. Но, некоторые глаза рисуют так ,что перед нами не человек, а манекен....>>

:: Рунет-2008: конкурс прогнозов
В прошлом году перед Новым годом "Вебпланета" провела опрос экспертов, предлагая назвать несколько значительных событий, которые станут существенными для Рунета-2007. Некоторые из этих предсказаний действительно сбылись....>>

:: Usability тестирование. О регистрации движений глаз
После конференции UserExperience Russia 2007 стало ясно - в Россию приходят технологии eye tracking. В связи с этим корреспондент ЮБ задал несколько вопросов ведущему научному сотруднику Института психологии РАН и научному руководителю UsabilityLab Анатолию Костину....>>

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

:: Про молодые кадры в IT
Молодежь стала головной болью менеджеров по персоналу, поскольку представители нового поколения часто необоснованно требуют всего и сразу. Согласно опросу, большинство менеджеров по персоналу в один голос заявляют, что работниками в возрасте до 22 лет тяжелее всего управлять....>>

:: Рисуем сайт "Портфолио Дизайнера"
Любопытный и очень подробный урок, рассказывающий о всех деталях создания скетча на примере темы дизайнерского портфолио....>>

:: Практический CSS: рецепт успеха
По ссылке располагается перевод заметки CSS - A Recipe for Success, в которой рассматривается создание средствами HTML/CSS в браузере некоторого образца меню. В статье освещены довольно интересные случаи, и подробно описано их решение....>>

• Предыдущий выпуск рассылки - #227

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

::: рассылку ведет:     Татьяна Вукс 2008 :::