Блог NunDesign

Всё-таки поставила эту последнюю версию WordPress`а… Как и обещали все, кто в русскоязычной блогосфере отписался про 2.5 и 2.5.1, новый интерфейс админки не то, что бы совсем ужасает, но выглядит крайне непривычным, да. Мешает всё. Мешает избыток этого небесно голубого (даже если сменить гамму на classic), мешает перелопаченная навигация. Какие такие продвинутые информационные архитекторы консультировали разработчиков на предмет того, почему довольно простую и понятную двухуровневую навигацию нужно разделить на четыре отдельных информационных блока? А эти аяксовые блоки, имитирующие popup-окошки? Какой умный дизайнер придумал делать верхушку этих блоков тёмно-серой, в тон затемнённому основному контенту так, что бы крестик, закрывающий блок терялся и замечался только при пристальном разглядывании?

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

А вот ещё про бэкапы wp-блоггерам будет полезно: объявлен конкурс на лучший способ бэкапа блога, предлагайте ваши решения! Владимир Жилинский уже поделился своими идеями в посте “Резервирование и бэкап - зачем и как“.

И в качестве дополнительной приятности поставила плагин Gravatar, так что теперь в комментах могут показываться ваши авторские аватары. Зарегестрируйтесь на сайте http://www.gravatar.com/, залейте туда сколько хотите картинок ваших юзерпиков, выберите тот, который актуальный и всё. Дальше плагин сам найдёт, какую картинку подставлять в ваших комментариях. Посмотрите предыдущий пост - сразу видно, у кого есть граватары, а у кого стоят дефолтные заглушки!

В общем, надо покрутить, конечно, и потом уже делать выводы. Может и получится быстро привыкнуть. А по поводу всяких неудобных штучек в интерфейсе сегодня одна казусная ситуация напомнила такую спорную вещь: мы всегда стремимся упростить интерфейсные формы, упростить по-максимуму, в идеале - до одной функциональной кнопки. И вот появилась у нас форма с одной кнопкой, содержание (смысл и функциональность) которой менялось в зависимости от состояния формы. “запустить процесс”/”остановить процесс”, типа такого. Оказалось, что юзеров такая продвинутая функциональность сбивает с толку, они ВООБЩЕ не читают, что на кнопке написано. Поймав единожды содержание кнопки, юзеры не могут постоянно следить за кнопкой для того, чтобы узнать, когда содержание кнопки изменится. В том случае нам пришлось доработать кнопку визуальными средствами (Start был зелёненький, с текстом “Start”, а Stop - менялся цвет на красненький). Просто менять текст, не меняя ни расположение, ни форму - плохое решение.

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

А это скрин этой же формы, когда добавляется URL:

А какие интересные решения для подобных же форм вы встречали (или разрабатывали)? Так, чтобы и форма не избыточная, и юзер в заблуждение не вводится?

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

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

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

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

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

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

В дополнение к недавнему посту “Почему увольняют дизайнеров“, а вернее, к некоторым комментариям цитата:

Каждый руководитель хотя бы раз в жизни вынужден иметь дело с сотрудником, который избегает работы, или же не имеет стандарта качества, или просто не может сделать свою работу.
Том Демарко и Тимати Листер, «Человеческий фактор»

(more…)

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

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

(more…)

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

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

У практикующих дизайнеров и у заказчиков как правило совершенно разное понимание загадочного слова “Креатив”. Заказчики - они все чуть ли не до единого в первом интервью говорят о том, что дизайн должен быть суперклассный, креативный, вы же таланты! Дизайнеры, со своей стороны, тоже чаще всего не переносят рисовать “почти” одно и то же, и мечтают о заказе, где можно развернуться во весь размах их безудержной фантазии. А потом оказывается, что на самом-то деле “это”, конечно, у вас супер получилось, но — не подходит, потому что “есть же какие-то всем известные нормы юзабилити…“, или “нельзя в этом месте заставлять пользователя разгадывать ваши загадки…“, или “он что, должен поворачивать голову на 90­˜­°?..“, или ещё, к примеру, распространённый и (на самом деле) честный - “ваш суперкреатив - он расчитан на узкую целевую аудиторию (к примеру - “гики”, или “тинейджеры”, или “озибоченные-интеллектуалы”, не важно), а нам нужен охват аудитории больше и ширше“. И дальше не важно - будет это продумывание нового концепта или доработка понравившегося концепта напильником с целью адаптации креатива для более широкой аудитории — всё одно, дизайнер с грустью наблюдает, как его оригинальная идея шаг за шагом превращается в обычный, в общем-то, дизайн, так сказать, традиционный стиль.

Поэтому если клиент озвучивает фразу “а сделайте нам что-то особое, креативное” - эту фразу лучше фильтровать или (правильнее) сразу транслировать её на реальные его потребности. Ведь на самом деле, что ему нужно?

1. Получить визуальный стиль, который качественно будет отличать его от конкурентов (т.е. не затеряется в общей массе);
2. Получить визуальный стиль, который качественно будет отличать его от конкурентов в лучшую сторону;
3. Вызывать расположение у потенциального клиента, положительные эмоции;
4. Способствовать (или не мешать) росту аудитории и повышению уровня продаж.

(more…)

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

1. Традиционные инфосайты - СМИ. Самый известный тип информационных сайтов. Мировые или региональные новости, политика или общие темы, авторитетные издания, вылизывающие качество новостей или жёлтая пресса - все имеют общие характеристики: минимум графического оформления, максимум текстового контента, контент разбивается на типы, рубрики, выборки, из которых формируются миниинформационные блоки - “актуальные новости” или “архив новостей”, “новостийные сообщения” или “развёрнутая аналитика”, “колонки журналистов издания” или “читатели пишут”, “главная навигация” или “вспомогательные навигационные блоки” - главная задача - систематизировать эти блоки, упорядочить вывод инфомации на странице таким образом, чтобы посетитель разобрался, где что искать/читать/комментировать. Графика на 99% - тоже информационная - иллюстрации к заметкам, фоторепортажи, портреты героев текстов. Какого-то суперглянцевого дизайна для таких проектов не требуется - он даже во вред будет. Главное в оформлении - юзабельность, читабельные тексты, нормальные контрасты для потокового текста и для акцентов.

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

2. Служебные сервисы. Типичный пример - Google Analytics; информация - данные, контент как бы тоже текстовый, но суть его не в пассивном поглощении информации, а в действии, к примеру ga нужен для того, чтобы что-то обработать, сделать какие-то выводы, узнать, “как посетители в действительности работают с Вашим сайтом. Вы сможете усовершенствовать дизайн своего сайта, опираясь на аналитические данные, повысить качественный трафик и переходы и увеличить свой доход.” Так же (как и в первом случае) пользователю отдаются различные типы данных, разбитые на группы; у дизайнера подобных сервисов сложнейшая задача - продумать интерфейс (и навигацию, и модульную сетку, и цвета) таким образом, чтобы максимально облегчить пользователю работу со статистикой, не испугать его массивами цифр, упорядочить максимально. Графика - маркеры-иконочки, определяющие различные типы данных или иллюстрации-графики данных.

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

(more…)