UX research in Yandex

http://piter-united.ru – [28.11.2014]


If you need coding, go to Indian; if you need solution, go to Russian

Ссылка на оригинал.

—-

If you need coding, go to Indian; if you need solution, go to Russian

Любой русский программист, после пары минут чтения кода, обязательно вскочит и произнесет, обращаясь к себе: «Переписать это все нафиг!» Потом в нем шевельнется сомнение в том, сколько времени это займет, и остаток дня русский программист потратит на то, что будет доказывать самому себе, что это только кажется, что переписать — это много работы. А если взяться и посидеть немного, то все получится. Зато код будет красивый и правильный. Hа следующее утро русский программист свеж, доволен собой и без единой запинки докладывает начальству, что переписать этот кусок займет один день, не больше. Да, не больше. Hу, в крайнем случае, два, если учесть все риски. В итоге начальство даст ему неделю и через полгода процесс будет успешно завершен. До той поры, пока этот код не увидит другой русский программист.

А в это время в соседних четырех кубиках не будет ни на секунду утихать работа китайских программистов, непостижимым образом умудряющихся прийти раньше русского программиста, уйти позже, но при этом сделать примерно втрое меньше. Эта четверка давно не пишет ничего нового, а только поддерживает код, написанный в свое время индусом и дважды переписанный двумя разными русскими. В этом коде не просто живут баги. Здесь их гнездо. Это гнездо постоянно воспроизводит себя при помощи любимой китайской технологии повторного использования кода — copy/paste. Отсюда баги расползаются в разные стороны посредством статических переменных и переменных, переданных по ссылке (ведь китайский программист не может смириться с неудобствами, вызванными тем, что он не может изменить значение внешнего параметра).

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

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

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

О, канадский программист — это особый тип. Он, ни на минуту не задумываясь, как рыцарь без страха и упрека, бросится фиксить самый свирепый баг китайского кода. Этот Баг живет там уже три года, и китайцы уже четырежды (каждый по разу) сообщали начальству, что он пофиксен. Hо Баг каждый раз возвращался, как Бэтмен в свой Готхем.

Итак, канадский программист, воспитанный на героической патетике американского футбола — бросаться в бой головой вперед — сделает то, чего китайцы не рисковали делать в течение трех долгих лет. Он, при помощи дебаггера, отследит место, где статическая переменная приняла значение -1 вместо правильного 0, и решительным движением заведет рядом вторую переменную с правильным значением. Баг погибнет в неравной схватке с героем. Hо победа будет достигнута тяжелой ценой. Работать перестанет все, включая только что переписанный русским программистом код. Это повергнет русского программиста в задумчивость на целых два дня, после чего он сделает, в общем-то, предсказуемый вывод о том, что дизайн с самого начала был неправильным, и все надо переписать. Hа это нам нужна неделя. Да, неделя, не больше. Канадский программист смело бросится налаживать все, и станет еще хуже, хотя казалось бы… Эта суета выведет из медитации индуса, который придумает и вовсе гениальное решение — отбранчить код. Согласно его плану, мы теперь будем поддерживать две версии одного и того же кода — одну работающую, но с Багом, другую без Бага, но не работающую. Русский программист, услышав об этом плане, сломает линейку об стол и обзовет жену дурой, но на митинге возразить не решится.

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

Индусы в деле

Индусы заполняют software industry как тараканы. Обладают «запахом и вкусом», которые создают специфическую атмосферу, поэтому нельзя не коснуться этой животрепещущей темы. Введем несколько ключевых понятий. Одно из основных это индокритическая масса. Индокритическая масса возникает при наличии хотя бы одного индуса менежера и пары-тройки индусов программистов. Следующее понятие — индоцепная реакция. Индоцепная реакция возникает спонтанно при наличии индокритической массы. Приводит к бурному и неконтролируемому увеличению индокритической массы. Основной функцией индокритической массы является политическая деятельность; программирование — это побочный продукт. День, прошедший без политической интриги, считается полностью пропавшим. Элементы индокритической массы обмениваются информацией с околосветовой скоростью и обладают невероятной г…нистостью. Мозг индуса-программиста так хорошо натренирован на многоходовых политичеcких интригах, что программирование дается ему играючи. Задачей любого программиста не-индуса является недопущение индокритической массы.

Русский программист никогда не чинит чужого, бессмысленного, объектно-неориентированного, спагетти-кода

— Че, не работает?

— Ща мы енто дерьмо выкинем и мухой напишем наш родной, мудрый, обьектно-ориентированный, офигительный код.

— Усе, готово.

— А протестировать…

— Че, тестировать?! У нас код работает правильно и всегда!

Русский программист немедленно сносит всю операционку и ставит свою. Пользуется только «cracked software» и «open source». Скорость генерации кода приближается к световой. При наличии трех-четырех русских программистов на проекте характерен туннельный эффект самопроизвольного возникновения кода. Русский программист говорит по-русски даже с представителями других национальностей. Предпочитает использовать русские матерные выражения для сообщений об ошибках. При подходе менеджера кладет ноги на стол и продолжает говорить по телефону.

Немного про китайцев

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

Как говорится, «сказка ложь, да в ней намёк»:

За прошедший год (2005) количество аутсорсинговых заказов индийским программистам выросло более чем на треть, а три индийских софтверных гиганта дружно перешагнули отметку прибыльности в 1 миллиард долларов США/год при общем доходе в 6.7–6.9 миллиардов долларов США. Объем рынка аутсорсинга в Индии уже превысил 50 миллиардов долларов в год — крупнейшие компании США и Европы, почувствовав выгоду от приглашения опытных и одновременно дешевых программистов, просто завали индусов заказами в страховой, аэрокосмической, банковской, торговых областях.

Поэтому, компания Infosys, являющаяся второй по величине софтверной компанией Индии, решила увеличить до марта 2006 года штат программистов еще на 20,200 человек (вдобавок к уже имеющимся 46 тысячам программистам). При этом управляющий директор Infosys Нандан Нилекани (Nandan Nilekani) уверен, что наблюдающийся сейчас рост числа заказов — лишь предвестник основной волны аусторсинга, поскольку индийские программисты при высоком качестве работы обходятся западным компаниям в 50 раз дешевле американских или в 3 раза дешевле российских или украинских. К тому же, практически все индусы с детства умеют говорить на английском языке, что выгодно отличает их от восточно-европейских конкурентов. Поэтому, только за последние три месяца Infosys получила 34 новых крупных заказа на услуги программистов от компаний США, Западной Европы и Японии. В том числе и крупнейший на сегодняшний момент заказ стоимостью 140 миллиона долларов на создание приложений для офисов ABN Amro в Северной Америке и Европе, а также многомиллионные заказы от компаний Oracle и Boeing Co.

Очень рекомендую посмотреть: Primate Programming(tm) Inc.


Пользовательские требования к интерфейсу

Как получается удобный для пользователя веб-интерфейс?

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

Зачем?
- Чтобы с нуля сделать интерфейс, удобный дня пользователя.
- Чтобы проверить готовый интерфейс на «профпригодность».

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

Какие у него возможности, желания и потребности? А какая цель (а не задача)?
Затем надо понять, а как именно пользователь осуществляет свою цель. И разбить цель – на задачи, которые решает пользователь в процессе достижения своей цели. И так – для каждого пользователя, для каждой цели. Получится список задач пользователей, которые можно типизировать; при этом удобно выделить приоритеты от имени ваших пользователей.

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

По этому шагу рекомендую презентацию Татьяны Татьяны Табаковой — о выявлении интернет-потребностей.

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

Не забудьте об отклонениях (исключениях) от сценария – вдруг пользователь нажмет «Отмена», вместо «Ок» — что будет? А если какая-то информация для системы не доступна — пользователю придётся всё заново вводить?
По этому шагу обязательно нужно посмотреть презентацию Ольги Павловой — о том, как написать пользовательский сценарий.

В итоге упражнения должен получиться список экранов (страниц). Они могут повторяться (вы это можете увидеть сразу, или в процессе дальнейшей работы): скорее всего, это один и тот же экран, объединяйте смело.

Шаг 3. Создать список страниц
Дайте страницам человекопонимаемое название экранам: такое, как будет использоваться в дальнейшем, в интерфейсе.
Посмотрите на список экранов – и увидите, что некоторые встречаются чаще, чем другие, и требуются в различных сценариях, но с одинаковой важностью; или же есть несколько экранов, с которых начинается сценарий – это ключевые страницы, которые будут «опорой» вашего интерфейса. А еще есть шаблонные экраны, на основе которых можно реализовать несколько схожих по функционалу и назначению страниц – это типовые страницы.
Соберите в список все страницы; маркируйте ключевые и типовые.

Шаг 4. Составить структуру навигации
Есть список страниц, есть список сценариев: и там, и там есть приоритеты. Теперь надо определить последовательность исполнения сценариев, поставить акцент на важные сценарии (посмотрите, где находится вход в каждый из пользовательских сценариев).

Можно поколдовать с концепцией: вынести в иерархии важные «хотелки», дополнить второстепенными. Удобно сделать в программе Flying Logic. Полный список страниц, их вложенность удобно отобразить в Excel’е — в итоге получится структура навигации интерфейса: все страницы должны быть перечислены, ключевые сценарии должны исполняться в первую очередь.
Профит: сразу видно структуру меню.

Шаг 5. Описать все страницы интерфейса
По-другому: напишите требования к странице. Что Пользователь хочет узнать на этой странице (информация)? А что сделать (действие)?
Эти данные как раз можно вычленить из списка составленных ранее пользовательских сценариев – всех сценариев, которые затрагивают эту страницу (_глаголы_)
Учитывайте контекст, в котором существует страница, и сценарии, при которых пользователь попадает на эту страницу.
Хороший интерфейс разрешает соответствующие информационные запросы пользователя и даёт инструменты для совершения действий (кнопки, ссылки и так далее). И, чем лучше прототип решает две эти задачи, тем больше интерфейс отвечает ожиданиям Пользователя.
Вот он — функционал : )

Итого: список документов «на выходе»
- Описание Пользователей и список жизненных историй
- Cписок пользовательских сценариев
- Список страниц интерфейса
- Структура навигации
- Требования к интерфейсу (описание страниц)

Как этими документами пользоваться

1) Для того, чтобы спроектировать интерфейс системы, нужно:
Используя требования к интерфейсу, создать макеты для всех ключевых и типовых страниц (в зависимости от ресурсов, можно детально описать, что выполняет тот или иной блок, какой функционал в него заложен (информирование или действие)
Для формирования меню пригодится понадобится структура навигации.
Все остальные страницы, которые попали в шаблонные – отрисовать на примере уже созданных макетов
Связать страницы нового интерфейса, пользуясь структурой навигации.

2) Чтобы проверить прототип интерфейса, достаточно:
Убедиться, что все сценарии, присутствующие в списке сценариев, соотвествуют потребностям Пользователей интерфейса и в полной мере реализуются с помощью системы;
Все страницы, описанные в списке страниц, присутствуют в системе;
Каждая из страниц системы удовлетворяет ожиданиям Пользователей, описанным в требованиях к интерфейсу.

 Посмотреть:

Справочно — читать накипевшее:

Перед написанием поста, искала немного другие требования. Нашла несколько интересных материалов. Думаю, они не повредят.

Статья Павла Коноплицкого (2008 год, #uxrussia: почему _для пользователя_).  А также, кратко о различных требованиях и о прототипировании — тут, тут, и тут.


Собираюсь )

Я.Субботник в Санкт-Петербурге пройдет 3 декабря в офисе Яндекса.

Регистрация на мероприятие начнется 23 ноября. Количество мест ограничено.

Для тех, кто не попадёт в число участников или не сможет лично присутствовать на Я.Субботнике, будет организована онлайн-трансляция.

Подробную информацию о мероприятии читайте здесь.


По следам #uxrussia или UX spb уже год

Недавно прошла конференция #uxrussia, на которой я побывала. Было интересно, позитивно, круто. Но я сейчас не об этом )

А вчера участники UX Spb собрались в ИТМО, на встречу, чтобы рассказать о прошедшей конференции тем, кто не смог до неё добраться. А также тем, кто не попал на ту или иную секцию. В общем, пересказать интересные доклады.

33 заявленных человека, восемь вечера _непятницы_, холод на улице, послерабочее настроение и всё такое. В общем, я не ожидала особого ажиотажа.

Ни фига подобного. По ощущениям: нас стало много, заметно больше.

#uxspb

Чуть позже зал уже не вмещал всех желающих. Кстати, вспомнили, что первая встреча сообщества #uxspb состоялась ровно год назад, а эта встреча оказалась юбилейной.

Выступления участников поделились на 3 части: по следам выступлений Peter Morville (доклад) , мастер-класс Андрея Сикорского, и обсуждение доклада Ивана Михайлова.

Докладчики вызывали живую реакцию и заставляли думать


Смеяться

Задавать вопросы и размахивать руками : )

Сикорский и Морвилль не приехали) Поэтому  Ивану Михайлову, как живому докладчику #uxrussia пришлось отдуваться за всех : )  Вопросы-вопросы-вопросы… Что мне и понравилось: можно было обсуждать доклад в своем тесном кругу, непринужденно.

Ой, нет. Еще была Светлана Цикоза, её новый проект Experiemint, для тех студентов, которые хотят учиться и развиваться в UX. Благая цель, между прочим. На этот год Светлана набрала 80 студентов, придумывает им квесты. И заставляет думать головой.

В общем, мы честно не уложились по времени, потому что всё интересно: и сами докладчики, и их точка зрения на доклад или мастер-класс.

Нельзя не отметить людей, которые пересказывали доклады: Лёша Гапонов, Саша Марков, Марина Примакина, Аня Хотинская. А также спасибо Софье Чебановой (за «где собраться») и Юле Крючковой (за фото).

А потом мы выдвинулись в ближайший паб: обсудить новости, пообщаться на другие темы, про проекты, планы, идеи и обучение специалистов UX.

P.S. доклады с #uxrussia опубликованы тут.