Ларри Константин - Человеческий фактор в программировании
- Название:Человеческий фактор в программировании
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Ларри Константин - Человеческий фактор в программировании краткое содержание
Хорошее программное обеспечение создается людьми. Так же как и плохое. Именно поэтому основная тема этой книги — не аппаратное и не программное обеспечение, а человеческий фактор в программировании (peopleware). Первое издание «Constantine on Peopleware» признано классическим трудом в области информационных технологий. Новая книга Ларри Константина включает все 52 легендарные статьи из предыдущей книги и 25 новых эссе.
Peopleware охватывает все аспекты, связанные с ролью людей в разработке программного обеспечения. Это качество и продуктивность, модели и методы, динамика поведения коллектива, руководство проектами, разработка интерфейсов и взаимодействие между человеком и компьютером, психология и процессы мышления. В данное издание включены два новых раздела, посвященных организационной культуре и юзабилити программных продуктов.
Название оригинала на английском языке: The Peopleware Papers by Larry L. Constantine
Человеческий фактор в программировании - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Для большинства разработчиков сайты бета-тестирования являются основным источником обратной связи. Таким способом можно получить ценную информацию, особенно если компания устанавливает тесные рабочие отношения с рядом хороших сайтов. Однако с точки зрения разработки и совершенствования интерфейсов в бета-тестировании есть серьезные ограничения.
В частности, если продукт довольно «хрупок» или сыроват, покупатель может столкнуться буквально с сотнями сбоев или небольших трудностей за один день обычного использования. Попытки отметить все неполадки по мере их появления настолько нарушают ход работы, что все, за исключением самых заинтересованных и озабоченных бета-тестеров, фиксируют только часть возникших осложнений. Обеспечение пользователей диктофонами увеличивает долю выявляемых ошибок, но это также мешает обычному порядку работы.
Для преодоления этих ограничений в больших компаниях по производству программного обеспечения стало модным создавать лаборатории или исследовательские центры по анализу юзабилити. В этих отделах применяется аудио- и видеоаппаратура. Как правило, в них устанавливается зеркало для наблюдения за использованием системы. Такие центры обычно оснащаются разнообразными компьютерами и рабочими станциями.
Главным недостатком здесь является то, что в лаборатории люди ведут себя не так, как у себя дома, не говоря уже о затратах на создание и функционирование такого отдела. Если вы хотите узнать, как люди работают с тем или иным программным обеспечением, такие исследования нужно проводить в контексте. Для этого можно применить какой-нибудь вариант контекстного опроса, например метод, впервые предложенный Карен Холтцблатт (Karen Holtzblatt) и ее коллегами из Digital Equipment Corporation (Holtzblatt и Beyer, 1993 [40]).
Суть контекстного подхода заключается в исследовании действий пользователей при выполнении обычной работы в обычных условиях. Это напоминает исследования на местах, которыми занимаются антропологи и этнографы. За людьми наблюдают во время их работы, а в беседах выясняются детали ее выполнения. Почти не вмешиваясь в рабочий процесс, опытный интервьюер может получить довольно подробную информацию о том, как в действительности применяется продукт.
Конечно, для наблюдения за тем, как некто пользуется некой системой, такая система должна быть. На ранних стадиях разработки часто применяют прототипы, а на более поздних этапах — альфа- и бета-версии. Иногда хороший исследователь может получить полезную информацию всего лишь с помощью бумажных прототипов — простых статических рисунков с предлагаемыми макетами экрана.
Идеи для новых инструментов и компонентов можно получить, наблюдая за применением уже созданных инструментов. Даже небольшие изменения, привносимые пользователями, могут существенно упростить рабочий процесс. В распоряжение пользователей можно предоставить программное обеспечение, производимое вашими конкурентами, чтобы узнать его узкие места. Или же можно изучать действия людей при выполнении работы без программных инструментов. Суть не в автоматизации ручного труда, а в выяснении того, как и где программное обеспечение может быть полезным.
Центральная идея контекстных методов — выйти из своего офиса и взаимодействовать с пользователями в их офисах. Это не только помогает получить более точные данные для проектных решений, но и сокращает расходы. Конечно, создание отдела юзабилити-исследований стоимостью в полмиллиона долларов может вызвать шум на бирже. Это сигнал рынку — ей-богу, наша компания действительно стремится производить хорошие пользовательские интерфейсы и применять принципы разработки, ориентированные на пользователя. Однако даже простой блокнот, диктофон и поездки на автомобиле могут привести к появлению хорошего программного обеспечения.
С другой стороны, большинству людей не по душе, когда кто-нибудь стоит рядом и наблюдает за их работой. Кроме того, сам процесс наблюдения оказывает влияние на их действия. Когда разработчик интерфейсов или юзабилити-исследователь садится рядом с пользователем и начинает делать записи, то возникают взаимоотношения, изменяющие образ действий пользователя. Разработчик бессознательно дает пользователю подсказки: резкий вдох, быстрые пометки в блокноте, тихое «ах» или «хм-м», откидывание на спинку стула или наклон вперед, или ерзание на стуле. Мириадами путей пользователь получает тонкие сообщения о своих действиях или о том, что он должен предпринять вместо своих невероятно глупых метаний. Возникает большой соблазн «помочь», и типичные разработчики любят вмешиваться и подсказывать, когда клиент не находит оптимального способа применения «их» продукта. Неопытные и неквалифицированные исследователи часто могут вмешаться еще более явным образом: «Ну, давайте я покажу вам более простой способ», «Ах, ну, щелкните здесь мышью», «Нет, совсем не так».
Это работает и по-другому. Пользователь знает, что вы находитесь рядом и наблюдаете. Он знает, что вы лучше разбираетесь в системе, поэтому он рассчитывает на вашу помощь и либо напрямую задает вопросы, либо оглядывается на вас.
В общем и целом, наверное, лучше не находиться рядом. Означает ли это, что нужно возвращаться в офис и строить ту самую юзабилити-лаборато-рию с зеркалом? Не обязательно.
Простая технология может быть удивительно эффективной. Закрепите видеокамеру за спиной пользователя и сфокусируйте ее на клавиатуру и экран. Рядом с экраном расположите переносное зеркало таким образом, чтобы в камеру было видно лицо пользователя. Вот и все.
В типичном исследовании ведется видеозапись того, как пользователь применяет какой-либо компонент программного обеспечения. Сначала запись просматривают исследователи, чтобы изучить действия пользователя. Возможность видеть его лицо дает исследователям дополнительную информацию о происходящем. Когда видно, что пользователь удивлен, раздражен, озадачен или нетерпелив, это многое говорит о деталях интерфейса.
Затем исследователь просматривает отрывки из этой записи вместе с пользователем. Это необходимо для прояснения намерений или реакций пользователя, его мыслей и действий при работе с тестируемым программным обеспечением. Именно здесь зеркало оказывается полезным. Когда при просмотре люди видят самих себя, особенно выражение своего лица, они часто могут с поразительной точностью вспомнить свой «внутренний диалог» и собственные ощущения, которые были во время записи. Если постараться получить эту информацию и понять ее, то такие данные могут показать, что именно нужно вашим пользователям.
Читать дальшеИнтервал:
Закладка: