Показаны сообщения с ярлыком project managment. Показать все сообщения
Показаны сообщения с ярлыком project managment. Показать все сообщения

21 февр. 2012 г.

Почему большинство UX – дерьмо

Перевод нашумевшего поста из Лондона Why most UX is shite, который мне «подсветил» O'Reilly Radar.

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

Взглянув на план мероприятия, я поняла, что должна в течение 15 минут говорить о том, как «изготовить хороший UX». С чего начать. Я подозреваю, что Джеймс ожидал услышать что-то вроде того поста на ReadWriteWeb, опубликованного за день до моего выступления на конференции MonkiGras на тему 5 признаков хорошего UX:
  • элегантный UI;
  • зависимость пользователей;
  • стремительное развитие UX;
  • замедление; 
  • UX меняет вас.
Ненавижу такие списки. Смотришь на них и думаешь: ну да, в этом что-то есть, определённо. Нам просто нужно сделать такой UX и всё будет отлично. Глупость.

Если бы всё было так просто, нас бы уже завалили первоклассными UX. Но вместо этого в выступлениях или статьях, мы видим всё ту же горстку примеров, написанных в этом году о UX.

Выходит, не так это и просто. И вот поэтому, я назвала свою тему по-другому: «Почему большинство UX - дерьмо». В основном на конференции присутствовали разработчики работающие в стартапах, в Open Source проектах и разработчики ПО для предприятий, я подумала, что такая тема должна быть им интересна.

Сегодня можно найти тысячу способов, как превратить UX в продукт-мусор. Из своего собственного опыта, я сталкивалась с несколькими разработчиками «серийными преступниками». UX – это не то, что можно  отложить в backlog до следующей недели. Здесь необходимо знать “Как” и “Что”, чтобы сэкономить время и перестать заниматься мелочами, которые не имеют смысла.

1. Вы не принимаете решений (заставьте пользователей вашего продукта сделать это).
 
С этим я сталкиваюсь постоянно. Как это происходит и что я наблюдаю каждый раз.

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

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

Решение разработчика: КАК УДОБНО КОМПАНИИ или ТО, ЧЕГО НЕ БУДЕТ В ЭТОМ ПРОДУКТЕ, РАЗРАБОТКА ДЛЯ ЦЕЛЕВОЙ АУДИТОРИИ или КАК ЛУЧШЕ ДЛЯ ВСЕХ. Пользователь сам выберет, как ему удобно, продолжая искать в других местах.

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

Т.е. всё начинается с верхушки. Что делает и чего не делает ваша компания. Что делает и чего не делает ваш продукт для клиента.

Ранее такие решения по UX не принимались, потому что клиенты, как и компании сомневаются в правильности своих действий, решений, желаний и могут ошибаться. С точки зрения качества UX, лучше ПРИНЯТЬ неверное решение, чтобы научиться на своих ошибках. Лучше всего это реализовывать через тестирование, до того как продукт принесёт убытки покупателям.

В реальности, большинство людей больше заинтересовано в своей карьере – не ошибиться и получить бонус, чем в том, чтобы предоставить клиенту хороший UX.

2. Вы думаете, что ваше мнение важно (Если вы не конечный пользователь, то, скорее всего, это не так).

Прежде чем оспаривать эту точку зрения, убедитесь, что правильно поняли, что именно я имею в виду.

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

Конечные пользователи, с которыми вы вряд ли часто видитесь, и сослуживцы, которых вы видите изо дня в день. Как вы думаете, кто из них сильнее влияет на вас?

Я бы очень хотела верить в то, что все дизайнеры способны поставить потребности конечного пользователя выше своего эго, но давайте будем реалистами. Если вы – мой босс, и я знаю, что вам понравится, ваше мнение будет решающим. Шансы на то, что это не приведёт к лучшему UX, велики.

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

3. Вы не оцениваете его (Вероятно, вы даже не определили характеристики «хорошего UX», не говоря уже о том, пытались ли вы собрать данные для этого).

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

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

Эти компании не имеют хорошей метрики оценки качественного UX. Безусловно, при оценивании UX существует множество трудностей, но это чрезвычайно важный момент.

Если вы ДЕЙСТВИТЕЛЬНО хотите создать качественный UX, то должны понимать, что и как делают люди, насколько эффективен ваш теперешний UX и насколько лучше он может стать. В цифрах. Потому что на самом деле это именно то, что должно интересовать компанию.

4. Вам в принципе всё равно (В компаниях, которым не всё равно, внимание уделяется организации, системе отчётности и культуре, выстроенной вокруг клиента).

Это плавно подводит нас прямо к сути проблемы. В большинстве компаний не заботятся о UX и признают его важность только на словах. Но приложения должны выглядеть круто, не правда ли? Мы должны стремиться к этому.

Почему ни одна компания не делает «дизайн», как у Apple, хотя многие критикуют iPhone? Да потому что iPhone – это признак того, что компания уделяет огромное внимание UX. Apple организовывает работу таким образом, чтобы поддерживать создание такого продукта.

Это не ново, правда ведь? Но много ли вы сможете назвать корпораций, которые бы пытались скопировать организационную структуру Apple, или то, как они поддерживают деловые контакты и ведут отчётность, или какое место в организации отводится дизайну?

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

В конце концов большинство менеджеров заботит именно это, а не UX!

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

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

Хороший UX – это целая культура. И нанимать фрилансера на должность UX дизайнера равносильно как положить пластырь на ногу с гангреной.

Создайте хорошую организацию, а мы создадим хороший UX.

Если вам нужен лучший UX, забудьте о том, какой новый секси интерфейс вы видели сегодня. Начните долгую и трудную работу над организацией, частью имиджа которой будет забота о UX.

Стройте организацию разработки проекта таким образом, что бы мы User Experience люди помогли сделать вам хороший UX.

28 мая 2010 г.

Дизайн в холостую

Перебирал архивы с проектами, обнаружил несколько хороших дизайнов, которые просто гниют... Очень жаль конечно :( А ведь эскизы датированы 2007 - 2008 годом и до сих пор смотрятся вполне вменяемо :)

Хочу поделиться опытом общения с некоторыми заказчиками. Порой бывает так, что у заказчика есть супер-пупер идея, он ею бредит, жгет и его так прет, но... но прет его 2-3 недели, бывает 1,5 месяца, потом инициатива и заинтересованность в собственном проекте падает до нуля или в минуса и заказчик закрывает проект, и берется за следующую собственную "гениальную" идею, не смотря на то, что проект был рассчитан как минимум на несколько месяцев. Я не говорю о том, что заказчик исчезает с этой планеты с вашими сурсами, нет, напротив, заказчик вменяемо, корректно закрывает проект.

17 мар. 2010 г.

Русская вики статей Джоэла Спольски

Возможно не многие знают, но есть русская вики с более чем 70 статьями Джоэла Спольски, а тут русская версия сайта, с небольшим количеством статей.
Рекомендую к прочтению Руководство по UI дизайну для программистов.

20 окт. 2009 г.

Овладение хаотичным управлением проектов. Управляйте внесением изменений в требования к проекту.

Продолжение статьи на тему хаотичного управления проектом - Taming Chaotic Project Management - Introduce a Scope Change Management Process.

Свободный перевод

А вам директор IT отдела когда-нибудь говорил за ночь до выхода новой системы, что собирается запустить этот модуль в простой форме, чтобы посмотреть, насколько хорошо он работает? Ох уж это ненавистное расползание границ проекта! Я открою вам секрет: внесение изменений в требования не должно сразу же вызывать протест со стороны его руководителей, лично не касающихся самого рабочего процесса. Такие перемены должны гарантировать, что игра стоит свеч, если речь идет об изменении требований. Поэтому давайте рассмотрим, как внедрить схему внесения изменений в требования и сроки работ в хаотичную культуру управления проектами.

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

Существуют общие характеристики процесса управления внесением изменений в требования к проекту.
  • Получение разрешения на внесение изменений тесно связано с полномочиями организующей стороны
  • Финансирующая сторона дает свое согласие на корректировку работ по проекту, прежде чем предоставляет следующий уровень полномочий
  • В запросе на внесение изменений должны быть четко оговорены результаты и эффективность проекта
  • Каждый запрос на внесение изменений имеет порядковый номер
  • План работ по проекту согласовывается с финансирующей стороной перед его запуском
Я бы порекомендовал отделу руководства программой перед началом работы уточнить, что является стандартом управления содержанием проекта. Ранее мы уже использовали один стандарт управления содержанием проекта, который может стать начальной точкой в создании нового. Также целью управления разработкой проекта является проверка запрошенных изменений на уровне принятия решений. После получения одобрения со стороны руководства IT отдела, начните работу по организации работы над несколькими проектами наряду с этим. В случае необходимости обсудите процедуру внесения изменений с финансирующей стороной и кураторами проекта. Задача состоит в том, чтобы привлечь новые предложения в отношении схем, которые будут работать в вашей организации.

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

10 окт. 2009 г.

Овладение хаотичным управлением проектов и 8 обучающих советов о том, как разработать проект

Прочитал одну интересную статью Taming Chaotic Project Management - 8 Training Tips for how to develop project schedules, думаю очень многим было бы полезно и интересно ее прочитать.

Давно замечено, что срок разработки проекта НЕ РАВНО сумма времени каждого его этапа.
Каждый проект и заказчик имеет ряд своих "дополнительных настроек", которые не всегда можно предусмотреть. Существует множество факторов и рисков способных перенести срок завершения проекта.

Свободный перевод

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

Главной рекомендацией по организации вашего управления проектом является обеспечение ваших коллег, чью профессиональную подготовку в сфере проектного руководства вы хотели бы увеличить обучающими и руководствующими программами. Вот 8 советов, которые помогут вашим менеджерам спланировать их действия и шаги по проектному расписанию.
  1. Крайне необходимо определить дату завершения проекта
    Существует время и место для предполагаемой даты завершения. Предоставление механизмов и методов, гарантирующих вероятность и осуществимость проекта в заданный срок, является ключевым моментом. Например, впервые сидя напротив финансового директора на собрании по вопросу установки новой системы, не стоит говорить: "Наш 'малыш' будет установлен второго февраля". На самом деле, самое время произнести: "Какая замечательная идея, с кем мы должны работать, чтобы проект осуществился?" (Только если это на самом деле замечательная идея). Средства и методы, которые помогут чувствовать себя комфортно в роли старшего исполнительного, оправдают себя и в работе с директорами и менеджерами.

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

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

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

  5. Остерегайтесь технических оценок
    Мы способны дать одну и ту же оценку 8 разными путями. Если вы спросите 8 разных людей, у вас будет 8 разных оценок. Вы в замешательстве? В хаотичной среде управления проектом опыт не там. Это воздействует на объем работ и на соблюдение сроков. Мне нравиться работать в команде, получать от ее каждого представителя ответственного за работу отчет о том, сколько усилий и времени он потратит. Кроме того, что это за рабочие усилия, если 80 часов простого кодирования откладывается на 6 недель?

  6. Составьте настолько детальный график, насколько необходимо для вашего им управления
    Моя любимая "картинка" это строительство точки внешнего вида к точке интерфейса. Я открываю Visual Studio, копирую биллинг файл, обновляю ссылки. Как видите слишком много деталей для графика. Однако, возможно, в этой организации несколько моментов критичны: Аргументы в полях ввода, конфигурация и конструкция интерфейса, тестирование, соединения элементов тестирование и системное тестирование. Это приведет меня к прогрессу, я смогу контролировать график.

  7. Когда речь идет о контроле графика, не заходите слишком далеко
    Если объем работ 80 часов, проверьте время, затраченное на работу, по индивидуальным временным отчетам. Если программист потратил 80 часов усилий, но записал всего лишь 12 часов работы, можно сказать программа на 90 % завершена. Используйте этот метод до тех пор, пока программист не объявит о полном завершении работы.

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