Архив

Tag Archives: it

Кто-то сказал: «Человеку свойственно ошибаться, но чтобы провалить дело капитально, необходим компьютер»
__________________
Алан Купер «Психбольница в руках пациентов»
catdeletecomp
Реклама

Знакомые ищут математика программиста в компанию, работаюшую для нефтянки http://moikrug.ru/vacancies/870790732/

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

1. Реализация спектрального, вейвлет анализа, фильтрации акустических шумов в MatLab
2. Программирование ПЛИС National Instruments
3. Синхронизация и сбор аналоговых сигналов с территориально распределенных контроллеров
4. Разработка интерфейса оператора

Предполагается работа с зарубежными заказчиками.

Контакт: Максим saenco.org на gmail.com

На задней стороне книги приведен портрет автора, напомнивший мне по стилю стимпанк – такой высокотехнологичный гном.

При этом Джефф Раскин более чем заслуженный специалист в области пользовательских интерфейсов. Среди его детищ и Apple Macintosh и (никому правда ныне неизвестный) персональный компьютер Canon Cat, консультант множества компаний, выпускающих вычислительную и телекоммуникационную технику.

Он также придумал однокнопочную мышь для Macintosh, подход «drag and drop».

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

Могу сказать, что на страницах этой книги мне удалось найти ряд таких советов.

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

 

Итак – основные мысли и идеи, которые я выжал для себя.

Как обычно сначала нужно сказать о проблемах.

«Конечный продукт с точки зрения пользователя – это интерфейс». Чаще всего это действительно так. И интерфейсы имеют тенденцию к усложнению, часто имеют то, что Алан Купер называет «когнитивным сопротивлением».

Разработчики вынуждены лавировать между тем, чтобы использовать уже устаканенные подходы (чтобы облегчить обучение) с подходами новыми (которые делают интерфейс более легким и удобным).

По аналогии с законами робототехники Азимова предлагаются два закона проектирования интерфейсов

  1. «Компьютер не может причинить вред данным пользователя, или своим бездействием допустить, чтобы данным был причинен вред».
  2. «Компьютер не должен тратить впустую время пользователя или заставлять его выполнять действия сверх необходимого»

Вводится важное понятие «локус внимания» пользователя, которым должен манипулировать правильно спроектированный интерфейс. Информация, попавшая в локус внимания попадает в кратковременную память, где хранится около 10 секунд.

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

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

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

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

Вводится понятие монотонности – для интерфейса, предусматривающего только один способ выполнения действия.

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

Приведен ряд моделей для числовой оценки скорости работы с элементами интерфейса.

  • Модель GOMS, которая позволяет оценить время, которое требуется пользователю на выполнение той или иной операции при использовании интерфейса. Вводится определенная нотация, отвечающая нажатию на клавишу, указанию позиции курсором, перемещению руки с мышки на клавиатуру и т.д. С помощью такой нотации и правильно настроенных коэффициентов времени возможна довольно точная оценка, что особенно важно при сопоставлении ряда вариантов интферфейса.
  • Закон Фитса – позволяет вычислить время, необходимое для перемещения курсора и установку в определенную область экрана. Вычисления показывают, что для выбора пункта меню в стиле Apple Macintosh (привязанного в верхней грани экрана) требуется примерно в два раза времени меньше чем для выбора пункта меню в стиле Windows (расположенного под заголовком окна)
  • Закон Хика – описывает время, которое тратит пользователь на выбор их n вариантов

Выражу ряд мыслей в этаком плакатном духе

1. Диалоговым окнам нет.

Автор приводит вполне логичные доводы против применения окон типа «OK» или «YES», «NO». Первое как требующее действия с нулевой ценностью, второе как вызываеющее автоматическую реакцию без прочтения сообщения (привычки, привычки…).

2. Пользователь должен иметь возможность отменить любое свое действие.

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

3. Должно запоминаться место в каждом документе (веб-странице), с которым пользователь работал в последний раз.

Как хорошо, что эту идею восприняли разработчики ПО для чтения электронных книжек.

4. Режимы это безусловное зло.

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

Приводится пример с режимом «LOCK» обозначенным кнопкой. Понять – что произойдет при нажатии на эту кнопку – блокировка или наоборот выход и режима блокировки далеко не так просто, даже и с помощью tool-tips.

Hint. Возможно использование квазирежимов (режим с удерживанием, например с зажатой клавишей Shift), потому что пользователь в состоянии их контролировать.

5. Пользовательские настройки это зло.

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

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

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

6. Использовать в описании элементов интерфейса сочетание «существительное-глагол», когда требуется применить некое действие к некоему объекту, что как показывают исследования позволяет увеличить скорость работы, уменьшить число ошибок.

7. Различие интерфейсов для опытных и начинающих пользователей – зло.

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

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

9.Не бывает интуитивно понятных интерфейсов. Точнее так «для того чтобы интуитивно изучить интерфейс нужно иметь большой опыт», поскольку интуитивно понятный интерфейс, это знакомый интерфейс.

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

11. Следовать принципу: не предоставляйте пользователю тех средств управления, которые должны работать всегда или никогда. Если пользователь может в следующий момент выполнить только одно действие – пусть программа выполнит его сама.

12. Ну и та мысль, которая уже несколько навязла в зубах: тщательное проектирование не замедляет, а, наоборот, ускоряет процесс разработки.

13. Советы дизайнера Edward Tufte по принципам отображения информации:

  • данные следует показать прежде всего
  • следует максимально увеличивать долю чернил (пикселов), используемых для отображения данных
  • следует максимально уменьшать долю чернил (пикселов), не используемых для отображения данных

Кроме того автор выдвигает несколько теорий, которые могут показаться довольно безумными, но в какой-то степени они воплощаются в жизнь.

  1. Например, полный отказ о файловой системы и имен отдельных файлов. Лучшее имя текстового файла, это его содержимое. Тут можно сказать, что Evernote со своим быстрым поискам по всем заметкам реализовывает такой подход, но лишь в рамках одной задачи – хранение заметок. Также Evernote реализует еще один полезный прием при поиске информации – пошаговый поиск, когда результаты поиска выводятся сразу после начала редактирования поискового фрагмента текста.
  2. Или широкое внедрение печатных команд прямо в печатаемый пользователем текст (например: Я пишу этот текст, а потом печатаю команду [send-to: me@ya.ru] и тут же инициируется почтовый клиент, который отправляет данный текст по почте).
  3. Или еще одна странная идея: в момент когда мы редактируем текст, а нам приходит письмо, то оно просто вставляется в тот текст, который мы сейчас редактируем, а далее мы решаем – как поступить со свалившимся нам текстом. Предвижу матюки, которыми будут сопровождаться подобные прерывания в работе.
  4. Ликвидация разделения рабочей среды пользователя на множество приложений, предлагающих свой контекст и каждое. Мне эта идея кажется довольно утопичной.
  5. Навигация по данным по принципу ZoomWorld, которое помогает ориентироваться в данных, за счет запоминания пространственного их размещения друг относительно друга (слева, справа, вложенные). Насколько мне известно, подобный подход не получил пока распространения, Раскин рассказывает о примере внедрения подобного интерфейса при создании информационной системы для больницы.
  6. Отказ от имен пользователей (login) и идентификация пользователя исключительно по паролю, который генерирует система для каждого пользователя.

 

 

Что мне не очень понравилось – это болезненно частое упоминание компьютера Canon Cat и клавиши LEAP на его клавиатуре. Ну, честное слово, мне это совсем не интересно. Если этот компьютер такой удобный, то почему про находки, которые были сделаны при его разработке особенно ничего не слышно сейчас?

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

 

Что приятно – можно видеть что за последние лет 5 во многих случаях разработчики следуют ряду советов и работать с программным обеспечением становится проще и безопаснее.

В дополнении с дочитываемой мною сейчас «Психбольницей в руках пациентов» Алана Купера книга помогает мне выстроить линию поведения при обсуждения основных противоречий в пользовательском интерфейсе разрабатываемых нами программ.

Сегодня на Стратоплане стартует Программа-2012.

Воодушевленный прохождением клуба IT-менеджеров, я согласился стать модератором в нескольких клубах:

  • Клуб IT-менеджеров,
  • Клуб тренерского мастерства,
  • Клуб предпринимательства,
  • Клуб стратегического планирования.

Клубы рассчитаны на 3 месяца обучения в формате вебинаров раз в одну-две недели.

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

Человеческий фактор (PEOPLEWARE)
Том ДеМарко и Тимоти Листер

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

О менеджменте

Что такое менеджмент – никогда не так: «Менеджмент это умение пинать сотрудников»
Руководство – это умение принести вовремя тарелку супа больному сотруднику, который вышел на работу.
Модульный подход не совсем пригоден для человеческих ресурсов.
Уникальность участников является залогом активности и эффективности межпроектных отношений.
Человек, способный заставить проект шевелиться – стоит двух, просто выполняющих работу.
Нужно выделять время на размышления. Именно проект, сдача которого запланирована на фиксированную нереальную дату, более всего нуждается в частых мозговых штурмах, неформальной проектной тусовке, гибкой методологии.
Сверхурочные сотрудников, сидящих на окладе – это плод воображения наивного руководителя. Нельзя при этом бесконечно эксплуатировать трудоголиков.
Поощрение атмосферы не позволяющей допускать ошибки просто заставляет людей занимать оборонительные позиции.
Ergo: нужно поощрять нечастые ошибки.
Лучшие из начальников умеют рисковать.

Английская и испанская теории (системы ценностей):
•    Испанская – путь к накоплению богатства – извлекать пользу из природных ресурсов или рабского труда.
•    Английская (приведшая к доминированию в мире) – ценности можно создавать путем изобретательства и технологий.

О качестве

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

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

О производительности и времени

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

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

Производительность сотрудников может отличаться в 10 раз. Наиболее производительный сотрудник в 2.5 раза более продуктивен чем средний.

А главное, что исследования показали, что этот эффект касается и организаций в целом, то есть люди рассортировываются по компаниям. Эффект накопления.
Одна из основных проблем, снижающих производительность – шум на рабочем  месте.  В IBM – площадь 9 м2 на сотрудника.

Open-space зло.  Экономия денег на пространстве – влетает в копейку.

Фактор С = время непрерывной работы / время присутствия.

Ergo: Есть смысл оценивать значение этого фактора для сравнения условий работы и способов организации труда

Красные платки, как маркер занятости и неготовности к коммуникации.

Эффект Готорна – практически любое изменение ведет к кратковременному повышению эффектвности. Это, например, в отношении методологий.
Ergo: Скрам хорош тем, что изменения можно вносить раз в две недели.
Ergo: Нужно иметь такой запас изменений, чтобы не давать всем заснуть.

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

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

О развитии сотрудников и образовании команды

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

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

Большая ошибка – когда руководитель не является участником команды.
Ergo: значит нужно пытаться влиться в команду если она есть, а если нет – думать о центре кристаллизации.

Что убивает команду:
•    Физическое разделение
•    Дробление рабочего времени – по множеству целей, когда люди участвуют во множестве рабочих групп

Прирожденный руководитель на уровне подсознания понимает, что именно будет полезно для команды.
Ergo: Думать об этом!

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

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

Хорошая метафора для команды разработки – это не команда футболистов, а скорее хор или музыкальная группа.

Люди ищут руководителей открытых. Они полны решимости не подвести их, даже если те пытаются испортить то или иное решение.

В успешной компании руководители не делают работу самостоятельно.  Руководитель не входит в команду, потому что команда это сетевая, а не иерархическая структура.
Дискуссионно и противоречит тезису о том, что хорошо бы быть руководителю членом команды. Касается ли это руководителей проектов? Линейных руководителей?

О переменах

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

 

Одна из мыслей, которая меня поразила в большой степени:

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

Конференция проходила 17 декабря в питерском офисе Яндекса.

В твиттере был шторм по тегу #pbconf

Что мне понравилось в организационном плане:

  • Двухсторонние бейджики (во всяком случае у спикеров)
  • Наличие плюшек и кофе в любой момент
  • Достаточно удобный зал

Спасибо большое организаторам.

Фотки в FB.

О докладах

После уже сделанных обзоров, среди которых мне особо понравился обзор Сергея Атрощенкова (наверное за то, что он меня не поругал =) сложно добавить много нового, однако попробую вставить свои 5 копеек.

Роман Чернин (Яндекс) «Фэйлы внедрения планирования»

Роман рассказал об эволюции системы управления, которая развивается через кризисы.

О специфике продуктовой разработки, в отличие от заказной нет, соответственно, заказчика, нет требований и нет сроков.

Следовательно неизбежны проблемы с принятием решений.

И о чудо — спасением является Product Manager — адвокат пользователя.

Однако Product Manager плохо ложатся в иерархию.

Ольга Павлова (UsabilityLab ) «Framework для планирования проекта с точки зрения менеджера продукта»

Самые дизайнерские слайды на конференции.

Цикл: Мечта (что) — концепция (как) — макет (как работает) — результат (тесты проходят) — публикация ($)

Управление продуктом это управление чей-то мечтой. Заказчику нужно давать чаще играться с продуктом на всех стадиях его развития, потому что говорить с Заказчиком как со взрослым не получается.

Планировать от и до все равно не получится.

Важно в планах закладывать время на согласование. Понятное дело, 1/3 времени запросто можно провести за переговорами. Хорошо еще если в переговорке, а не в open space.

Для себя не уловил стиль поведения на самом сложном на мой взгляд переходе — от макета к результату.

Георгий Липатов (iFree) «Полёт на Марс, или как не обидеть слона»

Классная презентация с использованием движка prezi.com

На этом докладе пришлось вспомнить про однофакника, который был руководителем проекта «Фобос-грунт» по ОКР. Эх, так мы и не выпили за успешное завершение проекта.

Соль. В конце проекта выясняется, что на Марс должен был лететь слон. Кстати, а почему не мамонт? =)

Ну следовательно нужны были итерации, нужен был деревянный прототип. Тут вроде ничего нового.

Иван Потапов (First Line Software) «Планирование аналитической части проекта»

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

Одно запомнилось: «Во всем виноват аналитик. Если в проекте он есть.»

Если серьезно, то оказывается есть PMA — аналог PMBOOK.

На этапе проектирования нельзя применять методы оценки с декомпозицией.

Аналитик должен женить ГОСТ 34 серии и Backlog.

Опять же надо планировать время на работу с заказчиком (у него может вообще не быть своего аналитика).

А также что важно — аналитиков не хватает!

Юрий Ветров (mail.ru) «Планирование аналитической части проекта»

Тут не обошлось без коварных происков конкурентов — Юрий так и не смог запустить свою презентацию на Маке. Следовательно волновался, отвечая на вопросы. При этом скорость речи была такая высока, что мой карандашик не успевал следить за ходом мысли и лишь в один момент сделал пометку — узнать что такое метод KJ.

Игорь Винокуров (Команда Глеба Архангельского) Мастер-класс по корпоративному тайм-менеджменту.

Мастер класс был «правильный» и скучноватый. Презентация на основе MindManager смотрелась довольно кустарно — я не оценил.

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

Что хотелось бы запомнить — 12 принципов внедрения новых правил.

Я их к сожалению все не записал, но некоторые вот:

  • Неработающее правило — хуже его отсутствия.
  • Правило должно умещаться на листе А4.
  • Всегда будут нарушители правил.
  • На это всегда должна быть реакция.
  • Утверждать правила можно только после того, как убедишься, что они работают.

В итоге сбежал с окончание этого мастер-класса и поспел на

Мария Петрова (Яндекс) «Планирование в распределенных командах»

Эмоциональное выступление.

Собеседование нужно проходить лично — даже для распределенных команд.

Кристина Стоянова (Яндекс.Деньги) «Как спланировать дизайнера»

Блокирующая задача должна быть одна. На то она и блокирующая.

Интерактив от Афиша-Рамблер «108»

Получилось весело — особенно в начале, когда можно было попасть в вихрь командообразования. В результате стал одним из  «топ-менеджеров» и выиграл свою колоду карт для покерного планирования.

Ирина Томилова «Чего хотят тестировщики? Или как  после планирования жить хорошо»

Признаться, перед своим докладом я стал приходить в состояние желе, и поэтому решил не слушать Ирину.

Андрей Базулин «Как я организовал музыкальный фестиваль и при этом не потерял друзей»

Ну о себе со скромностью молчу, сошлюсь лишь на свой слайдкаст.

После своего доклада я заклевал носом и прослушал доклад

«Заметки о планировании со стороны разработчика» Дмитрия Качмара из Яндекса.

Тут явно были внутрикорпоративные разборки, учитывая хохот взаимные уколы.

Мем: Проект не удался, потому-что менеджер — тряпка!

Константин Горский (Яндекс) «Планирование дизайнеров»

Костя произвёл очень приятное впечатление, с выдумкой. С серьезным видом сообщил, что «муза не пришла и доклад не подготовил»

Мем Костиного выступления — спасительная зеленая кнопка. Тут же я вспомнил про Юру Ветрова и его синюю mail.ru кнопку.

Сказать по совести — ни yandex ни mail меня не устраивают по дизайну. После gmail страшно даже заглядывать в почту.

Иван Селиховкин «О неуставных отношениях в команде»

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

Было приятно, хотя «своих в доску» людей так и не встретил.

На конференции УЗДМ-2009 (кстати, тоже в СПБ) я чувствовал себя чуть более в своей тарелке. Вот и как выбирать между IT и NDT? =)

_________________________________

ps. Похоже свои наушники заголовные потерял. А вдруг найдутся?!