Блог NunDesign

Разработчики (и, в частности, дизайнеры интерфейсов, любых - веб, или windows приложений), если имеют опыт работы с разными командами, разными компаниями (т.е. разным руководством), сталкиваются с абсолютно разным представлением о том, что такое “правильный” интерфейс. Можно выделить три основные тенденции:

1. Правильный интерфейс - это функциональный интерфейс. В таких командах главный упор делается на продуманный механизм разрабатываемого проекта, на идеальный движок, все силы уходят на то, чтобы ядро было безупречным, чтобы (web или windows) приложение работало без сбоев при любой нагрузке, чтобы максимально полно и качественно реализовать затребованные заказчиком функции и сделать доступными управление этими функциями из интерфейса приложения. И складывается так, что для разработки этого приложения (или ряда приложений) привлекаются лучшие, высокооплачиваемые специалисты-разработчики, аналитики и программисты. Такие факторы, как удобство пользования этим приложением или уж тем более красота интерфейса, считаются вторичными, это приводит к тому, что и специалисты подбираются уже менее тщательно, команда специалистов незначительна по сравнению с командой программистов (обычно вообще один-два человека, иногда даже удалённых). Функциональность реализована, но пользоваться ею неудобно, а о визуальной привлекательности лучше не вспоминать.
2. Правильный интерфейс - это удобный интерфейс. Забота о пользователе ставится во главу угла (я не говорю о том, что это не правильно). Для разработки привлекаются талантливые информационные архитекторы, проектировщики взаимодействия, специалисты по юзабилити-тестированию, удивительно, но факт: в команде на пять программистов - семь ответственных талантливейших человек, отвечающих за создание правильного интерфейса + привлечённые для тестирования (эмуляция целевой аудитории) люди. Работу свою они выполняют качественно, приложение получается на самом деле с интуитивно понятным интерфейсом, удобное в использовании, только вот группа разработчиков подводит - то у них база падает при увеличении нагрузки, то кнопка нажимается через раз, да и сама функциональность не достаточно продумана и реализована поверхностно, хотя другие разработчики из этой же темы давно уже ушли на порядок вперёд. Удобно, но не функционально и не привлекательно.
3. Правильный интерфейс - это красивый интерфейс. В последнее время приходилось анализировать большое количество как виндовых программ, так и веб сервисов, встречались среди них примеры с на самом деле привлекательным, талантливо исполненным интерфейсом - очень эффектные веб сайты, необычайно и привлекательно отрисованные формы программ, с гармонично подобранными цветовыми гаммами и потрясающей графикой. Честно говоря, ни одно из них не осталось под руками в работе, отношение к ним осталось, как к миленьким игрушкам, которые стоило запустить, чтобы посмотреть, что там у нас рисуют западные прогрессивные разработчики, полюбоваться и забыть навсегда ввиду абсолютной непрактичности приложения. Не говорила бы об этом примере, если бы не сталкивалась. В такой ситуации разработка приложения в целом - это постоянное дорисовывание и перерисовывание интерфейса, его элементов, в процессе разработки делается 50 вариантов эскизов и на ежедневных митингах с руководством 90% времени - это обсуждение того, почему у этой иконочки “вот видите? зубчик на скруглении неаккуратный”, а “вот эта панелечка на один пиксель левее остальных”, и такое прочее. Команда же программеров чувствует себя изгоями - они не получают чёткую постановку задачи, им не дают технических возможностей реализовать всё достаточно правильно, им не дают человеко-ресурсов (когда в команде пару человек более-менее грамотные, остальные 10-15 - новички типа студенты), и даже времени на правильную реализацию.Типичный пример: так, ребятки, нам для послезавтрашней презентации сделайте быстро и красиво первую, пилотную версию (делают, что успевают, но к презентации версию предоставляют). А потом после презентации попытки объяснить руководству, что этот прототип был сделан в спешке на скорую руку, и для правильной реализации дайте же нам две недели! Две недели не дают, говорят, что функциональность устраивает, но через месяц разработки, когда костыли под костылями уже не удерживают конструкцию, удивляются и оскорбляются - что вы, мол, возитесь, и почему у вас всё время ничего не работает! Работает, но кое-как. В подобных ситуациях зачастую: красиво, но неудобно и не функционально.

Недооценка важности какого-то этапа, или низкие критерии качества любой части процесса разработки встречаются часто и в большинстве случаев снижают качество работы в целом, иногда - обесценивают (и я была свидетелем того, как закрывались практически готовые, разработанные проекты ввиду их полной коммерческой нецелесообразности при данной реализации, а бюджета на полную переделку уже не было). Часто это приводит к безграмотному использованию человеческих ресурсов. Я встречала, к примеру, в целом неплохую команду разработчиков (что-то около 40 программеров, большей частью веб-сервисы) - и на всю команду ВООБЩЕ ни одного дизайнера, ВООБЩЕ ни одного грамотного верстальщика. Помню, сколько времени талантливый дотнетчик тратил на то, чтобы хоть как-то причесать интерфейс, по ходу разбираясь с тонкостями вёрстки, с html и css и консультируясь по поводу подбора цветов для оформления интерфейса и элементов интерфейса. И это в то время, когда гораздо рациональнее и для конторы в целом выгоднее, если бы он писал только свой движок - но у конторы некому поручить эту работу, а тот удалённо сотрудничающий с ними индус, который рисует им эскизы для интерфейсов (дико уродские, честно-честно) и потом их “режет” в базовую html вёрстку (адаптацией вёрстки в движок он никогда не занимался и поэтому понятия не имеет, отчего матерятся программеры и после его трудов полностью перевёрстывают полученный макет).

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

Приведу цитату (скопировано из раздела “советы” на сайте Артёма Горбунова):

Все физические проявления хорошего интерфейса эстетичны — экраны, текстовый набор, иллюстрации и визуализации. Плохой интерфейс уродлив.
[Тафти, Рудер, Херлберт, Мюллер-Брокман, Брингхерст и другие...]

Кого в вашей компании называют “дизайнером”? Понимаю, что вопрос не совсем корректный - тут зависит от того, чем компания, собственно, занимается, но всё равно интересно. К примеру, на прошлый пост о дедлайне и голимой вёрстке (трансляция в ЖЖ), где я использовала термин “дизайнер-верстальщик”, uznick ответил, что “А вот не надо совмещать дизайнеров и верстальщиков :)”. Отчасти ведь прав, не поспоришь. Но есть тема для обсуждения.

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

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

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

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

Но бывают и совсем другие дедлайны. Которые от безграмотного менеджмента и неуважения к разработчикам. Когда проект у людей висит уже не первый месяц, они что-то там возились, оптимизировали и даже разрабатывали функциональность, потом забрасывали на какое-то время, потом вдруг, скажем, под вечер в среду присылают письмо с архивом (!) проекта, частично даже без исходников (precompiledWeb), мол, ребята, вы там причешите в стиле (***) - в общем, нашего предыдущего большого проекта. Всё это без описания функциональности и без документации на сам проект, типа вы же такие умненькие, разберётесь. Типа, там же только таблицу стилей подредактировать. Запускаю проект (ага, без исходного кода, без связей, ещё повозиться надо, чтобы он вообще запустился, чтобы вообще хоть как-то увидеть интерфейс глазками, покликать по функциональным элементам), и тихо млею от того, насколько безграмотно организовано филе… больше сотни .aspx страниц, без шаблонов, с кошмарнейшим html кодом - доктайп не прописан ни в одной из, сплошные незакрытые или закрытые ошибочно теги (открыт параграф, закрыт спан), зато всё оформление прописано атрибутами в самих тегах. Да и значения атрибутов в одном теге то в двойных кавычках, то в одинарных, то совсем без оных. Встроенный в редактор валидатор кода зашкаливает, и это естественно - он подчёркивает всё, где видит неправильность, т.е. его использовать для правки смысла не имеет. А ещё часть функциональных элементов (сложных гридов, к примеру, с сортировками/фильтрами/настройками внутри, или календарик для фильтра по датам) вообще собираются js скриптом полностью - т.е. те же теги и атрибуты тегов - шрифты, цвета, фончики, извиняюсь. Какой css?? Ну и, повторюсь, весь этот хлам без сопроводительной документации. И даже тот факт, что запускающая для проекта страница называется Test.aspx, разработчики должны были понять сами ага. (more…)

Хотелось бы собрать статистику: по каким причинам — профессиональным и человеческим — увольняют дизайнеров и веб-дизайнеров? Не будем рассматривать ситуации, когда компания не подошла специалисту (денег мало, работа не интересная, надоело) и он уволился сам, не дожидаясь, так сказать. В теме возможны всё-таки две ситуации - когда дизайнер отработал испытательный срок и не был принят (не прошёл), и - чуть печальнее и тяжелее - когда необходимо уволить человека, проработавшего на компанию приличное время. И ещё маленькая оговорка: давайте учитывать, что под “дизайнер” будем понимать любого специалиста из дизайнерской группы — художника-дизайнера, или технического дизайнера (верстальщика), или ещё какие-то разновидности дизайнеров из IT-отрасли. Поделюсь своим опытом, может, добавлю из рассказов знакомых; интересные дополнения из комментариев включу в текст в режиме UPD (от “такого-то”).

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

(more…)

Из прошлого поста о верстальщиках и программерах могло сложиться (и у некоторых, судя по переписке, сложилось) неправильное впечатление: да, я писала о кривом коде, порождаемом визуальными редакторами, да, я недоумевала - как же так, не ВасиПупкины, не начинающие веб-дизайнеры — вполне себе сложившиеся программисты, и вдруг - режим Design в VisualStudio для быстрого создания типовых форм. Но ведь и фраза “а что, у нас программеры уже напрочь ручками код перестали писать?” не имеет ничего общего с рекомендациями “писать” в блокноте, ни разу. И более того, когда касается не программирования, а вёрстки - своим ребятам я категорически запрещаю верстать в notpad`e, а программерам я вообще не указ. Просто - чем больше проект, тем меньше работы для дизайнера и верстальщика в проекте (когда уже написана общая таблица стилей, уделить пять минут тюнингу новой части сервиса — когда продумана и разработана концепция иконочек, маркеров и прочих фишечек, нарисовать новую козявочку — никакой сложности), но тем больше работы, связанной с тем, что ломается и “едет” дизайн после того, как программер поработал с проектом.

И здесь работа не для тестировщика, ему-то что, он таск отправил - что видит, о том и написал. А техническому дизайнеру - разгадывать шарады, почему что-то куда-то уехало. На днях звонит канадский программер, говорит — “я там ничего такого особого не делал… а блок с прелоадером (очередная крутящаяся козявочка с надписью “Loading…”), которая показывалась всегда в центре экрана, уехала в левый верхний угол“. Что делает дизайнер? Правильно, ломится проверять таблицу стилей - вдруг где-то правила сбились, вдруг где-то и в самом деле неграмотно написано… вроде всё честно. Ломится в код - бывало такое, когда программер добавлял контейнер (div) в код “не правильно”, а где ему показалось удобнее, но в коде тоже всё корректно. В чём глюк, разумеется, нашла - раньше прелоадер показывался на довольно простых условиях, когда генерилась таблица статистики, или подгружались ещё какие-то объёмы данных; но сейчас сценарии усложнились, и блок с картинкой (с тем же, как бы, идентификатором) программеру пришлось сделать серверным контролом. Т.е. с динамически создаваемым именем идентификатора. Т.е. правила, в соответствии с которыми прелоадер показывался в центре экрана, правила, которые назначались блоку по имени идентификатора, больше не применяются - имя-то меняется. (more…)

В списке ключевых слов было обнаружено словосочетание “хорошо ли быть дизайнером“. Зашли по этому сочетанию из гуглпоиска. Мне просто интересно, нашёл ли ответ на свой вопрос сёрфер? Или начитавшись здесь всякого, однозначно решил идти в менеджеры по недвижимости? А что тут ответишь… Однозначно, хорошо быть талантливым дизайнером. При том, что литературы, образовательных и просто дизайнерских сайтов, где публикуют какие-то оригинальные находки, решения - просто не сравнимо больше, чем в том же 1999, способные дизайнеры остаются востребованными (кажется, во всех без исключения регионах). Даже сейчас у меня здоровеннейший список RSS в оперной читалке “каналов новостей” только в рубрике “дизайн”, даже по диагонали не всё просматривать успеваю. Кстати да, RSS я читаю только Оперой (скорость, стабильность, рубрикация, уведомлялки про обновления и отсутствие тормозов в последней версии на МОИХ РЕСУРСАХ). Синхронизирую с домашней машиной (и то не всё подряд) через Google Reader, но не опираюсь на ридер как на основной тулз для RSS, нет. Да, так вернёмся к теме про дизайнеров.

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

То для темы нужна фотка какого-то типичного (!канадского!) пригороднего коттеджика с машинкой (современной!) у центрального входа и счастливой (!) мамашей и детками. То “замените вот эту азиатку на афроамериканскую бизнес-вумен; или мулатку”, то жизнерадостного тинейджера с упаковкой ПОПУЛЯРНОЙ В КАНАДЕ воздушной кукурузы, то ещё что-нибудь особо часто встречающееся у нас в Харькове и Харьковской области Нет, нам без стоков сложно. Но вот не у всех дизайнеров получается делать такие тестовые макетики с водяными знаками стока. Одна девочка преспокойненько ставит элемент в графический блок-коллаж с меткой, просто пишет, где на скетче “не мусор”, а остальным, похоже, это только усложняет жизнь - второй, к примеру, проще оказалось практически полностью отрисовать бизнес-вумен в деловом костюме (не вектором, в фотошопе, с фотореалистичным качеством и нужными цветами, эмоциями, жестами) - но это время, однако же. И это тоже проблема веб-дизайнеров, помимо прочих, о которых публикуется в разделах “офисное” и “дизайн“, ага. В разных организациях она решается по-разному. Пока что я вижу три решения: тырить, покупать на стоках или создавать в собственных фотостудиях. А, четвёртое: + заключить договор с какой-нибудь фотостудией - пусть они там уже сами ищут популярный в канаде попкорн или афроамериканских бизнес-вумен.

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

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

Новички вообще-то не знали, что для того, чтобы сейчас неперетруждаясь получать свою европейскую зарплату этот человек вообще-то в трудный период становления компании, когда нужно было со сложными и яркими проектами ворваться на рынок, пробить свою нишу - этот человек полтора года работал за 400-500-600 едениц по 12-14 часов в сутки. А сейчас - что, сейчас - есть заказчики, есть (стабильно) работа, есть ниша, и значительная заслуга в этом - того самого старичка. А новичкам обидно, что же это получается - это нужно год работать за зарплату не выше средней по городу для того, чтобы к тебе стали относиться серьёзно? И это серьёзное отношение выражать в деньгах и ласке? А описанное выше - преданность, лояльность - для новичков это блеф и отмазка чтобы денег не платить. И отсюда тоже в значительной степени - обиды, недопонимание, капризы. И что-то мне подсказывает, что лет через 10-20, когда станут они (не все, но если кто-то) президентами компаний, возможно - IT-шных, сильно поменяют они своё мнение и отношение к новичкам и к верным старожилам… Но.

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

«…Я — монстр карьерной эквилибристики. Люблю (и умею) находить хорошую работу. Присаживаюсь плотно, монументально и комфортабельно, даже если лениво присаживаюсь на несколько месяцев. Никогда не писал-рассылал «резюме»; всегда приглашён и обласкан знакомыми и незнакомыми почитателями качественной работы за внушающие доверие суммы. Но даже сейчас, когда я артствую в спокойной и сытной крейсерской гавани — меня можно сманить привлекательным стартапским кавардаком.ышесказанное, звучит как мантра. Это и есть мантра, благопретворённая в жизнь. Много всякого было в дороге. Решил составить бессистемный список «условий», испробованных в разных местах, и поговорить с вами о важности отдельных пунктов.»

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

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

В комментариях подняли интересный вопрос, актуальный не для всех вероятных читателей этого блога, скорее для тех, кто работает в софтверных или дизайнерских компаниях и где принята командная работа. Что такое хорошая, сработавшаяся команда, от чего зависит успешность командной работы, в какой степени зависит от авторитета и профессионального уровня тимлидера (team leader)? Вытаскивая из дискуссии:

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

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

Здесь я обещала рассказать о том, что на самом деле ситуации, когда харизматичные тимлидеры способны выдернуть из компании целую команду - эти ситуации абсолютно реальны и периодически случаются, и примеров живых этому не мало. Не всегда успешным оказывается результат такого выдёргивания, но факт остаётся фактом. Рассмотрим из жизни.

(more…)

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

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

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

Вчерашний пост про опросы-вопросы Subscribe.ru, которую запостил Илья (спасибо!) на news2, оказывается, вчера выпрыгнул в топ и до сих пор на первой странице. Удивительное рядом Что же, если кто-то из френдов тоже проголосует за новость - мне будет приятно (хотя название там бр-р-р!) А про внешнее - терпела-терпела, пока не… в общем, не удержусь и поделюсь с вами опубликованной несколько дней назад на ITNews новости “Молодежь покидает IT-сферу“:

Молодые работники сферы информационных технологий покидают эту индустрию, поскольку работодатели на могут удовлетворить их чрезвычайно высокие запросы. Вместе с этим молодежь стала головной болью менеджеров по персоналу, поскольку представители нового поколения часто необоснованно требуют всего и сразу.
Согласно опросу, большинство менеджеров по персоналу в один голос заявляют, что работниками в возрасте до 22 лет тяжелее всего управлять.
По словам Джека Харрингтона (Jack Harrington), одного из основателей кадровой компании Atlantic Associates, молодые сотрудники обычно хотят сразу получать зарплату гораздо выше начального уровня. Также требования молодежи обычно включают в себя частые премии и участие их руководителей в различных филантропических мероприятиях.

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

Посты по теме:

• Предновогоднее дизайнерское - они похожи на свои работы.
• Офисное дизайнерское - веб-дизайнеры и жизненный опыт
• Офисное дизайнерское: квалификация и уровень
• Офисное дизайнерское: тщательнéе!
• Офисное дизайнерское. Про ньюбов и понты
• Веб-дизайнер. Тексты вакансий. Требования.