Блог NunDesign

Разбираем-изучаем с утра по-раньше корпоративную почту; один из новых программеров, работающих на новом же проекте, удивлённо замечает: странно это, говорит, обычно когда разрабатывается новый сервис, люди сначала думают, а потом делают. А здесь как-то странно: сначала делаем, потом обнаруживаем траблы, переделываем; по результатам переделывания обнаруживаем ещё более стрёмные траблы, уже труднее решаемые, переделываем. Цикл может повторяться до момента, когда руководство разочаровывается в проекте, что автоматически означает — разочаровывается в разработчиках, этот проект наваявших. И правильно, кто виноват в том, что программа “не пошла”? Ессно, программеры. Собирается новая команда, которая получает исходные коды предыдущей версии с задачей “переделать”.

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

Поэтому когда заказчик говорит о том, что “рынок нуждается в нормальном инструменте для *таких-то целей*, есть много много людей, которые хотят такой инструмент, он будет продаваться, его только нужно сделать по-грамотному” – он (понятно, что речь вряд ли идёт об одном человеке) всё-таки опирается на свой какой-то уже наработанный опыт, и этот опыт автоматически распространяется на ВСЮ потенциальную аудиторию этого инструмента. Формулируются требования, пишется ТЗ, собирается команда, которая это ТЗ анализирует и приступает к работе. Не углубляясь в подробности описания жизненного цикла разработки сложного программного продукта перейду сразу к этапу тестирования сценариев поведения пользователя в программе на прототипах экранных форм.

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

Получается, что мы должны (пусть ещё и в начале разработки, но всё же уже на лету) менять постановку задачи в целом: для кого всё-таки пишется инструмент? Если заказчик планирует выйти с ним на рынок и рекламировать для универсального пользователя, тех же домохозяек в том числе, он и должен получить продукт для универсального пользователя и домохозяек в том числе; ни к чему тогда такая развёрнутая функциональность, сложные формы, диаграммы и визарды разрешения конфликтов синхронизации данных (долго писать, но как раз этот визард, просто шедевр проектирования с моей точки зрения, удобный и понятный для всех наших и даже одобренный заказчиком, поставил в тупик 100% тестировавших из той самой фокус-группы неподготовленных пользователей). Да, разрабатывается совсем другая программа. И пусть весь интерфейс сводится к двум кнопкам, например, зелёной и красной (да, одной не обойдёшься, бывает), зато легко будет разобраться.

Всё-таки с большим подозрением отношусь пока к тестированию на экранных прототипах. К сожалению, не могла присутствовать лично — мы здесь, они там, за океаном, но что-то там недоработано имхо. Верится с трудом, к примеру, что на достаточно равномерном (скажем, тёмно-синем, ближе к чёрному, с белым текстом) интерфейсе с элементами форм в той же цветовой гамме – тёмно-синие бэкграунды и светлые+белые foreground`ы учасники фокус-группы не смогли выполнить “удалить пользователя” не смотря на то, что кнопка “Delete” – единственная ярко-красная, ещё и с соответствующим текстом. Может, что-то не то было в формулировке задачи?

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

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

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

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

Девчушку, которая пришла к нам работать недавно верстальщиком на простенькие рекламные сайты (для сложных дотнетовских проектов ей ещё изрядное количество времени придётся нарабатывать опыт), посадила рисовать тренировочные эскизы как бы для этой же ветки веб-сайтов. Честно критиковала композицию, сетку, отрисовку каких-то объектов, оформление навигации, блоков, кнопок. У неё получилось два не очень плохих эскиза, которые, думаю, в компаниях с менее [чем наши канадские] придирчивыми заказчиками, очень даже прошли бы как достойные. А задачу я такую поставила с конкретной целью: не достаточно верстальщику знать html+css, не достаточно очень поверхностных знаний о работе с графикой в фотошопе. Фотошоп – такой же инструмент верстальщика, как и редактор кода, чем доскональнее ты знаешь этот инструмент, чем более гибко владеешь им, чем больше у тебя знаний о том, как создаётся макет рисующим дизайнером, тем быстрее будет твоя работа во время интеграции визуального стиля в реальный сайт, тем проще будет договариваться с твоими же партнёрами по разработке. Здесь речь в ПОНИМАНИИ процесса, ещё одна капелька к статусу ХОРОШЕГО ВЕРСТАЛЬЩИКА, к теме, которую мы обсуждали вчера в комментариях к посту в этом блоге и к ярушной трансляции.

Обсуждение вообще вышло довольно примечательным; я, кажется, с чрезмерными претензиями к личным качествам и профессиональным навыкам специалиста, из которого получается хороший верстальщик, а ребята в комментариях только подчёркивали это; Женя Бондарев писал:

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

В какой-то степени Женя прав, даже с меркантильной точки зрения в нашей компании (где программеров в любом случае раз в 5 больше, чем дизайнеров) хороший (а значит, как минимум ведущий) программист будет получать больше хорошего верстальщика, но здесь вот ещё в чём сложность расчётов: на больших проектах задачи распределяются на подзадачи и направления, и кроме PM`а на проекте есть несколько подкоманд программистов, каждой из которых управляет ведущий программист, лучший. Т.е. он не только лучше всех программирует, он ещё занимается менеджерской работой, распределяет задачи внутри своей команды и отвечает за качество кода своих подзадач. Это всё-таки другая ответственность. К сожалению, всегда бывает так (это я по себе знаю), что большую часть задач, которые ставятся перед командой, ведущий специалист может выполнить сам, и, более того, быстрее, лучше, качественнее (и дальновиднее, потому что умеет видеть проект в целом и перспективу), но задач в какой-то момент становится несколько… больше, чем может выполнять один человек за один рабочий день, а клонировать этого самого ведущего программиста пока технологии не позволяют.

(more…)

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

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

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

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

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

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

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

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

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

(more…)

Недавно один из наших программеров в личке поделился сокровенным: оказывается во многих софтконторах, где уровень проектов плюс-минус приближен к нашему, одно из важных требований к программерам – обязательное знание html (xhtml)+css на достаточно глобальном уровне! Надо же… Раньше на эту тему никто у нас и не задумывался, а тут вдруг попёрло что-то, да ещё и подхлёстывается неожиданными дискуссиями в тему “разделения/распределения обязанностей”.

У наших программеров (.NET) такого требования не было и на собеседованиях никто ничего по теме вёрстке у них не спрашивал – основная среда разработки – M$VS, и знания тестировались только возвышенно-программерские. Вёрстку, как следствие, в большинстве своём публика знает только в первом приближении, и в том случае, когда начинается работа с интерфейсом и публике всё же приходится свои рабочие контролы как-то размещать на странице, они городят совершенно безумный код, разумеется, не ручками, а в режиме “design” – этого лучше не видеть, скажу только, что, когда я получаю в работу очередную страницу, основное время уходит на удаление всего того кода, который там предусмотрительно набодяжен.

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