Блог NunDesign

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

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

Люди - все они, разные, по характерам, по типам, по специальностям, все они, все мы — хотят работать или нет? Правильно ли утверждение, что желание работать — это нездоровое желание? Можно хотеть есть, или сексом заниматься, или красивую игрушку купить, (но чтобы поесть — нужно немного поработать! ©обительзла1), можно желать самоутвердиться (к примеру, как специалист в своей области), можно желать властвовать, и для удовлетворений всех этих естественных желаний ПРИХОДИТСЯ работать эту самую работу. Но как же тогда с мотивацией? Кто же тогда на самом деле ответственнен за её наличие? И какое место здесь займёт самодисциплина каждого отдельного сотрудника? Мда. Не очень хочется приводить примеры из офисной жизни, попробуем издалека, на не “рабочих” процессах.
(more…)

Многие старички в веб-девелопменте отмечают великую разницу в объёмах доступной информации по разработке в, скажем, конце прошлого века (сравнительно с настоящим моментом). Дизайн, программирование, проектирование, есть масса бумажной литературы, электронных книг и видеоуроков, просто онлайн-документации. Проводятся конференции, семинары и прочие мероприятия для обмена опытом. И здесь, конечно же, Москва в фаворе (не в упрёк, я же понимаю, что ничего не происходит само по себе - просто больше энтузиастов, больше людей, которые не тупят над проблемами в местечковых болотцах, а готовы организовать движняк, потратить на это время и бюджеты, найти спонсоров, организовать, пригласить, проанонсировать - это тоже тяжкий труд, я знаю). Украина сейчас тоже подтягивается по количеству интересных мероприятий, тот же UA WEB, те же конференции по маркетингу. Но всё равно мало и редко, в Москву же не наездишься. Те же РИТ-РИФ-КИБ так и остались в мечтах, потому что “а здесь кто работать будет?” И вот ещё одна апрельская тема — IT-Online пригласили Эдварда Йордона, автора книги «Путь камикадзе» (Death March) провести однодневный семинар (один день в Москве, один в Питере) «Управление безнадежными проектами».

Коротко о том, о чём будет идти речь: будут обсуждаться вопросы “в области управления проектами: как успешно выполнить самый безнадежный проект? Существует ли эффективный способ вдохновения команды на достижение поставленной цели? Как сэкономить время, отбросить сомнения и достичь потрясающих результатов?”

Рассматриваемые темы:

• Политика в безнадежных проектах
• Переговоры во время безнадежного проекта
• Управление персоналом в безнадежном проекте
• Процессы безнадежного проекта
• Динамика процессов
• Симуляторы и «военные учения» для моделирования безнадежных проектов
• Контроль в проектах «смертельного марша»
• Инструментальные средства в «смертельном марше»
• «Безнадежный проект» как стиль жизни

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

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

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

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

Lisa
Здесь проблема как раз в том, что очень сложно организовывать что-то красиво и грамотно, когда тот, кто заведомо находится в “старшей” позиции может через твою голову давать задания твоим сотрудникам.
Скажем, для меня это одна из самых больших проблем была - найти баланс между “я - всеобщий секретарь” и все вообще идет через меня и “я не знаю, кто из клиентов какие задания надавал моим сотрудникам”.
Я очень хорошо знаю, что и там, где не ты главный, можно очень много порядка навести Если поставить перед собой такую задачу. Но преодолевать сопротивление со всех уровней - очень тяжело. И сбрасывая с себя хоть какой-то уровень - ощущаешь облегчение. Причем как вариант - отказываешься от обучения и выращивания подчиненных и делаешь всю работу самостоятельно, такой этап тоже был и он проще и порой благодарнее, чем отказ от начальников

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

Как обычно, после (извиняюсь) многобуквенной вступительной речи переходим к реальным примерам из жизни. В районе плюс минус нового года у нас было много заказов на разработку маленьких рекламных сайтов - и на эскизы, и на порезку-вёрстку. Объёмы были чуток сверх человеческой нормы, ребята работали в том числе и сверхурочно, и я вместе с ними и рисовала, и верстала в зависимости от того, куда был перекос нагрузки, и даже обсуждалось, что нужны ещё люди. Потом объёмы начали как-то заметно снижаться, хотя в личной переписке с канадским арт директором тот уверял меня, что всё ОК и объёмы вернутся. И только через пару месяцев, в приватной беседе мне сообщили, что этот арт-директор в посленовогоднее время стал интенсивно собирать команду своих дизайнеров, в офис - и рисующих, и верстающих. И сейчас у него работают около 10 ребят, и ему с ними КОМФОРТНЕЕ работать, потому, что проще поставить задание, проще обсудить на словах и на пальцах (а не сочинять в письменном виде), что он по-прежнему сопротивляется работе с, к примеру, JIRA, хотя у него есть доступ и аккаунт (ни одной задачи он в джире так и не создал), что его в такой схеме не травмирует разница во времени, и оперативность разработки увеличивается на, по существу, рабочий день (на самом деле были стабильные проблемы с тем, что по правилам нашего офиса сотрудники работают с 10 утра до 19, и, понятное дело, если задание присылается в пять вечера, то результат канадские менеджеры смогут получить только на следующий свой рабочий день, или же должны подтверждать согласие оплатить дедлайн, сверхурочные). Таким образом практически произошло вытеснение нашей команды из этой линейки работ, так сказать, естественным образом.

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

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

Вообще много чего странно. Ещё в 2005-м, 2006-м, ещё в ЖЖ-шном блоге, когда писались заметки о различных офисных проектах, всё представлялось, что описываются обычные трудности новичковой компании, что где-то — от отсутствия опыта, в том числе и менеджмента, где-то — от недосформированности команды профессиональных разработчиков, но в любом случае все проблемы временные и решаемые. Когда три-четыре года назад ЖЖ-шные френды в комментариях писали, что подобные ошибки в управлении - типичные признаки говноконторы, я не соглашалась и утверждала, что мы семимильными шагами шагаем к великому будущему, всему в скором времени научимся и благополучно выпрыгнем из говноконторского уровня. Но три-четыре года — не маленький возраст, и уже стыдно как-то по-прежнему допускать всё те же ошибки, казалось бы, уже пройденные и осознанные. Ежели дитё в 10 лет продолжает сосать соску и писяться в постель - это уже не нормально, не здорóво. И ещё хуже то, что вместо того, чтобы срочно приниматься за исправление, лечение (возможно, хирургическое вмешательство), становится нормой политика “не обращать внимание”, “перерастёт” и “как нибудь само рассосётся”. Ага.

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

Приезжаю и узнаю следующее: Ещё в начале недели, как оказалось, один из канадских менеджеров прислал сюда, на Украину, ТЗ и скетч на порезку и вёрстку сайта. Уже бред: во-первых, обнаружились (позже) траблы с почтовым сервером, который канадский, а мы тянем переписку M$ Exchange, и она благополучно глючит, о чём я не единожды писала и администрации, и канадскому админу. И то письмо с заданием попало в очередную перенастройку почтового сервера и ПОТЕРЯЛОСЬ. Ладно, с админскими траблами понятно, недопустимо, но так сложилось. При этом господа канадцы даже не попытались узнать - получили ли здесь их письмо, почему не было уведомления о получении-прочтении-приступании_к_работе. Я уехала в Киев (в среду поздним вечером) в полной уверенности, что на два рабочих дня у моих дизайнеров всё распределено, распланировано и чётко формализовано, т.е. благополучно. К четвергу канадские красавцы опомнились и таки спросили - мол, как там наш сайт поживает? Какой сайт? — удивился наш технический директор. А тот, который вы давно должны были нам вернуть в готовом виде!! Ага, догадался технический директор, вы послали задание почтой, а она у вас (а значит, и у нас) не работает и письмо потерялосЯ. Опять торкается канадский админ с наездом (уже), тот всё-таки занялся проблемой почтового сервера, обнаружил, что письма и в самом деле не ходят, в четверг же ближе к вечеру проблему пофиксил, о чём и уведомил всех. Те же красавцы ещё раз пересылают ТЗ и скетч НАПРЯМУЮ ДИЗАЙНЕРУ, который занимается вёрсткой. Тот начинает работу, но, поскольку время уже позднее, не заканчивая, уходит домой. В пятницу заболевает, и в понедельник продолжает болеть. Про проект никто не вспоминает.

В понедельник я, уже после Киева, приезжаю на работу, спрашиваю, мол, как оно тут без меня? Всё супер, всё в порядке! — говорит техдир. У меня в почте ни одного письма за те дни, когда меня не было. У него по дизайнерским темам тоже ни одного. В джире ни одного нового таска. А ближе к вечеру. Раздаётся тревожный звонок. Где же сайт? Спрашивает канадский управляющий. Извиняюсь, говорю, о чём речь, собссно? Вы, там! Чем вы там занимаетесь! Сайта нет! Мы присылали! Заказчик уже терпение потерял! И всякое такое нелицеприятное в адрес украинского дизайнерского отдела. Начинаю разведку. Сначала пытаюсь через техдира - он говорит, мол, да, что-то такое было в четверг вечером, но у меня писем на эту тему нет, исходников сайта на порезку тоже нет - не присылали. Выясняю через нашего админа. Ага, говорит, письмо есть, только напрямую верстаку, но вытащить его я не могу. Перезваниваю заболевшему верстальщику - он говорит, ага, мол, было такое, но я болею… Вытаскиваю из его машины присланные в четверг исходники. А дело уже вечером (канадцы просыпаются и приходят на работу, когда у нас часа три-четыре дня). Разумеется, в сверхурочном режиме запустили исходники в работу, порезали, сверстали сайт и отправили в Канаду. Успели, все счастливы. Ура. Ура? Млин, с каких это пор задание присылается напрямую разработчику, что такое, унизительно сделать карбан копи любому старшему? Обсуждалось миллион раз, объявлялось как обязательное требование. Таня, ты же типа в Киеве была. Ну и что? У меня всё время был доступ к почте, я всё время была в онлайне в вашем любимом млин MSN мессенджере, у меня ни грамма информации о том, что этот проект вообще был и уж тем более о том, что он был срочным и не по вине украинского офиса к тому же просроченным (из-за проблем с почтовым сервером).

Да, это только один пример подзапущенного за два дня моего отсутствия проекта. Если бы у нас в работе только он был! Ещё много. И веб приложения, и видновз application, на которые надо было скин натягивать, а дизайнеру, славной, талантливой девочке, пришло три постановки задания - от канадского руководителя направления, который ведёт именно эту разработку, от технического директора, который типа ответственный за именно эту разработку, и от тимлидера, который, собссно, и разрабатывает с парочкой подчинённых ему программеров. Канадский руководитель требует одно, тим лидер, глянув свысока на требования канадской стороны, говорит, что в пилотной версии этого ТОЧНО не будет, и для презентации нужно сделать то-то и то-то… И что ей оставалось делать? Показать отрисованный эскиз В КАРТИНКЕ, а в пилотной версии проекта реализовать то, что, грубо говоря, позволено разработчиками и не более. И в процессе пятничной презентации оказывается, что всё плохо, и опять дизайнеры нихрена не делают, и, Таня, я не знаю ничего про ваши технические трудности с реализацией, я вижу не сделанную работу.

И опять Déjà vu. Будто и не было утверждённой модели работы, будто и не обсуждалось, как оптимизировать процессы. Будто опять никто не понимает, что такое приоритеты и как они выставляются, и КОМУ. Будто не обсуждалось всей командой, как и что должно происходить, словно нет команды как таковой, нет командной работы - публика стрелки друг на друга переводит, это не моё, а это не в моей компетенции… Блин. Не в моей компетенции. Какие все некомпетентные, а, главное, равнодушные. Миллион раз было так, что тестировщик, не верно проанализировав баг, постил этот баг на дизайнеров. Я, получив баг, видела, что он чиста программерский и спокойно делала перепост на программера, курирующего этот проект. Нет проблем, не вижу проблем. Но когда человечек, получив “не свой” баг, тупо молчит, мол, это не моё - и всё, трабла зависает, тестировщик уверен, что баг в разработке, программер, который должен был бы этот баг работать, ни разу не в курсе, тот же красавец, который получил баг, сидит занимается (честно и кст., качественно) своей работой.

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

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

Больше всего меня веселят диалоги с менеджерами проектов:

- Почему лажа с дизайном?
- Ну так дизайнеры нарисовали. Я им говорил! Но я же не буду вмешиваться в их работу.
-Ну вернул бы им такое г… обратно.
- Ну так я вернул, а они мне такое же, только зеленым цветом нарисовали.
- А что с аутсорсом?
- Какой ж аутсорс при своих дизайнерах?
- Ну как ж можно так проект было запускать?
- А иначе и не запустили бы вообще.

- Слушай, а чего твой проект конкурентных преимуществ то не имеет? Чем он лучше проекта YY у Яндекса?
- Ну… главное преимущество то, что он у нас вообще есть. Между прочим, у нас есть отдел маркетинга, вот пусть они и решают что там да как… Они ж у нас за стратегию отвечают.

- Здесь есть очевидная нелогичность в интерфейсах. Ребенок даже увидит. Чего не поправил то?
- А это отдел интерфейсов, их епархия. Они меня не проконсультировали.
- А ты их попросил?
- Ну да. Это было еще в ноябре, с тех пор они чего-то молчат.
- Узнал почему?
- Ну не моя эта работа их домогаться…

- А ТЗ на этот сервис есть? В какой форме поступила задача в отдел интерфейсов?
- Стоп! У нас атмосфера стартапа, у нас креатив! А эти всякие ТЗ только тормозят нашу работу. Мы друг друга с полуслова понимаем…

При этом самый показательный коммент самого Anatolix`а:

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

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

Разработчики (и, в частности, дизайнеры интерфейсов, любых - веб, или 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, но делится он между нашими и канадскими дизайнерами поровну. Поскольку дизайнеры - все поголовно жадные на клипарты и фотогалереи, руководство решило, что великая опасность — позволять дизайнерам просто качать понравившиеся имиджи со стока. Поэтому (как минимум если речь идёт о фото, хотя на истоке много чудного векторного, к примеру, добра) работать дизайнеры должны по следующим правилам: со стока берётся превьюшный имидж и тянется с водяными знаками (и, если необходимо - с потерей качества), и ставится в эскиз. Если эскиз принимается канадским директором (ещё не заказчиком - и то хорошо), то фотка покупается и эскиз для реальной уже вёрстки доделывается с качественной, честно приобретённой на стоке фотографией. Выкручиваться же без стоков сложно - наши клипарты уже устарели изрядно, фотостудия пока ещё не светит, хотя по-мелочи используем свои фотоиллюстрации всё чаще, ну и темы, конечно же, сложно здесь найти.

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