Психбольница в руках пациентов
Добавить в закладки К обложке
- Отзывы на книгу Алана Купера - Страница 1
- Об авторе - Страница 3
- Благодарности - Страница 4
- Предисловие научного редактора - Страница 6
- Предисловие - Страница 8
- Введение - Страница 9
- Инженер, сведущий в бизнесе, либо бизнесмен, сведущий в технологии - Страница 10
- Часть IКомпьютерная безграмотность - Страница 18
- Что получится, если скрестить компьютер с фотокамерой? - Страница 19
- Что получится, если скрестить компьютер с будильником? - Страница 20
- Что получится, если скрестить компьютер с автомобилем? - Страница 21
- Что получится, если скрестить компьютер с банком? - Страница 22
- Компьютер позволяет легко попасть в беду - Страница 23
- Коммерческое программное обеспечение тоже страдает - Страница 25
- Что получится, если скрестить компьютер с военным кораблем? - Страница 26
- Техноярость - Страница 27
- Индустрия в «несознанке» - Страница 28
- Мотивы создания этой книги - Страница 29
- Глава 2Когнитивное сопротивление - Страница 31
- Поведение, не связанное с физическими силами - Страница 32
- Проектирование6 – слово емкое - Страница 33
- Отношения между программистами и проектировщиками - Страница 34
- Большинство программ проектируются случайным образом - Страница 35
- Проектирование «взаимодействия» против проектирования «интерфейса» - Страница 36
- Отличительные черты продуктов, основанных на программном обеспечении - Страница 37
- Танцующий медведь - Страница 39
- Стоимость дополнительных возможностей программного обеспечения - Страница 40
- Апологеты и уцелевшие - Страница 42
- Наша реакция на когнитивное сопротивление - Страница 44
- Демократизация власти потребителя - Страница 45
- Виноват пользователь - Страница 46
- Программный апартеид - Страница 47
- Часть IIМасштабные издержки - Страница 49
- Управление, ориентированное на крайние сроки сдачи - Страница 50
- Что такое «готово»? - Страница 51
- Закон Паркинсона - Страница 52
- Продукт, вечно не готовый к выпуску - Страница 53
- Поздний выпуск – не беда - Страница 54
- Торг за набор функций - Страница 55
- Кто главный? Программисты - Страница 56
- Возможности не всегда нужны - Страница 57
- Итерации и миф о непредсказуемости рынка - Страница 58
- Скрытые издержки некачественного программного обеспечения - Страница 60
- Дороже разработки ПО обходится только разработка плохого ПО - Страница 61
- Стоимость возможностей - Страница 62
- Издержки прототипирования - Страница 63
- Глава 4Танцующий медведь - Страница 66
- Если это проблема, то почему ее до сих пор не решили? - Страница 67
- Жертва бытовой электроники - Страница 68
- Чем плохи почтовые клиенты - Страница 69
- Чем плохи программы для планирования - Страница 70
- Чем плохи календари - Страница 71
- Массовая веб-истерия - Страница 72
- Что не так с программным обеспечением? - Страница 73
- Программы забывают - Страница 74
- Программы ленивы - Страница 75
- Программы скупы на информацию - Страница 76
- Программы не гибки - Страница 77
- Программы возлагают вину на пользователей - Страница 78
- Программы не несут ответственности - Страница 79
- Глава 5Нелояльность клиентов - Страница 80
- Привлекательность - Страница 81
- Одно сравнение - Страница 83
- Время выхода на рынок - Страница 85
- Часть IIIКак есть суп вилкой - Страница 86
- Вождение на заднем сиденье - Страница 87
- Подготовка катастрофы - Страница 89
- Компьютеры против людей - Страница 92
- Учим собак быть кошками - Страница 93
- Глава 7Ноmo Logicus - Страница 96
- Авиационный тест - Страница 97
- Психология программистов - Страница 98
- Программисты пожертвуют простотой ради контроля - Страница 99
- Программисты обменяют успех на понимание - Страница 100
- Программисты сосредотачиваются на исключительных ситуациях - Страница 101
- Программисты ведут себя грубо и прямолинейно - Страница 103
- Глава 8Отмирающая культура - Страница 105
- Культура программирования - Страница 106
- Повторное использование кода - Страница 107
- Общепринятая культура - Страница 109
- Культура программирования в Мicrоsоft - Страница 110
- Культурная изоляция - Страница 113
- Шкурный интерес - Страница 114
- Дефицитный образ мыслей - Страница 116
- Обесчеловечивает процесс, а не технология - Страница 117
- Часть IVПроектирование взаимодействия – выгодный бизнес - Страница 118
- Персонажи - Страница 119
- Проектируйте для одного персонажа - Страница 120
- Чемодан на колесиках и клейкие бумажки - Страница 121
- Гуттаперчевый пользователь - Страница 122
- Персонаж должен быть конкретным - Страница 123
- Персонаж должен быть воображаемым - Страница 124
- Описание должно быть подробным, а не идеальным - Страница 125
- Реалистичный взгляд на уровень подготовленности - Страница 126
- Персонажи закрывают споры о функциях - Страница 127
- Персонажи нужны проектировщикам и программистам - Страница 128
- Персонаж пользователя, а не покупателя - Страница 129
- Подбор персонажей - Страница 130
- Ключевые персонажи - Страница 131
- Пример: Sony Trans Соm и P@ssport - Страница 132
- Традиционное решение - Страница 133
- Персонажи - Страница 134
- Проектирование для Клевиса - Страница 136
- Глава 10Проектирование ради результата - Страница 138
- Мы решаем задачи, чтобы достичь целей - Страница 139
- Задачи не являются целями - Страница 140
- Программисты занимаются проектированием, ориентированным на задачи - Страница 141
- Проектирование, ориентированное на цели - Страница 142
- Целеориентированные телевизионные новости - Страница 143
- Целеориентированное управление классом - Страница 144
- Цели личные и цели практические - Страница 145
- Принцип соразмерности усилий - Страница 146
- Личные цели - Страница 147
- Корпоративные цели - Страница 148
- Практические цели - Страница 149
- Ложные цели - Страница 150
- И у компьютера есть человеческие черты - Страница 151
- Проектирование и вежливость - Страница 152
- Что такое вежливость? - Страница 153
- Что делает программы вежливыми? - Страница 154
- Вежливая программа интересуется мной - Страница 155
- Вежливая программа относится ко мне уважительно - Страница 156
- Вежливая программа обходительна - Страница 157
- Вежливая программа ведет себя разумно - Страница 158
- Вежливая программа предвидит мои потребности - Страница 159
- Вежливая программа отзывчива - Страница 160
- Вежливая программа не склонна делиться своими личными проблемами - Страница 161
- Вежливая программа в курсе происходящего - Страница 162
- Вежливая программа проницательна - Страница 163
- Вежливая программа уверена в себе - Страница 164
- Вежливая программа всегда сосредоточена - Страница 165
- Вежливая программа покладиста - Страница 166
- Вежливая программа дает мгновенное удовлетворение - Страница 168
- Вежливой программе можно доверять - Страница 169
- Пример: Drumbeat от Elemental - Страница 170
- Расследование - Страница 171
- Кто кому служит - Страница 172
- Проектирование - Страница 173
- Откат - Страница 174
- Прочие моменты - Страница 175
- Глава 11Проектирование для людей - Страница 176
- Сценарии - Страница 177
- Повседневные сценарии - Страница 178
- Обязательные сценарии - Страница 179
- Сценарии исключительных ситуаций - Страница 180
- Адаптирующийся интерфейс - Страница 181
- Вечные середняки - Страница 182
- Представь себе! - Страница 184
- Словарь - Страница 185
- Языковой прорыв - Страница 186
- Реальность смеется последней - Страница 187
- Пример: Logitech Scanman - Страница 188
- Малкольм, боец фронта Всемирной паутины - Страница 189
- Чед Марчетти, мальчик - Страница 190
- DPI Магнум - Страница 191
- Игра «Представь себе!» - Страница 192
- Высококлассная обрезка - Страница 193
- Высококлассное изменение размеров - Страница 194
- Высококлассный поворот изображения - Страница 195
- Первоклассные результаты - Страница 196
- Преодоление разрыва между устройствами и программами - Страница 197
- Меньше значит больше - Страница 198
- Часть VВозвращаемся на место водителя - Страница 200
- Последовательность - Страница 201
- Юзабилити-тестирование - Страница 202
- Юзабилити-тестирование до программирования - Страница 203
- Интеграция юзабилити-тестирования в процесс проектирования - Страница 204
- Многопрофильные команды - Страница 205
- Проектирующие программисты - Страница 206
- Откуда вы знаете? - Страница 207
- Руководства по стилю - Страница 208
- Конфликт интересов - Страница 209
- Фокус-группы - Страница 210
- Визуальное проектирование - Страница 211
- Промышленный дизайн - Страница 212
- Классная новая технология - Страница 213
- Итерации - Страница 214
- Глава 13Управляемый процесс - Страница 215
- Кто на самом деле самый влиятельный? - Страница 216
- Смертельная спираль: на поводу у клиента - Страница 217
- Концептуальная целостность – важное достоинство - Страница 218
- Фаустова сделка - Страница 219
- Прогнозирование - Страница 220
- Принятие ответственности - Страница 221
- Затраты времени - Страница 222
- Удержание управления - Страница 223
- Поиск основы - Страница 224
- Семь раз отмерь - Страница 225
- Производство фильмов - Страница 226
- Хорошая сделка - Страница 228
- Документируйте замысел, чтобы дать ему жизнь - Страница 229
- Проектирование влияет на код - Страница 230
- Проектировочные документы приносят пользу программистам - Страница 231
- Проектировочные документы идут на пользу маркетингу - Страница 232
- Проектировочные документы помогают в разработке документации и технической поддержке - Страница 233
- Проектировочные документы помогают руководителям - Страница 234
- Проектировочные документы выгодны компании в целом - Страница 235
- Кто отвечает за качество продукта? - Страница 236
- Включение проектирования в процесс - Страница 237
- Откуда берутся проектировщики взаимодействия - Страница 238
- Создание команд проектировщиков - Страница 239
- Глава 14Мощь и удовольствие - Страница 240
- Пример налаженного проекта - Страница 241
- Осознанное проектирование взаимодействия - Страница 243
- Польза от перемен - Страница 244
- Почему они не едят пирожных? - Страница 245
- Изменить процесс - Страница 247
Вождение на заднем сиденье
Показательна недавно опубликованная статья16, посвященная впечатляющему провалу высокотехнологической начинающей компании General Magic. Автор затрагивает глубинную причину провала продукта, когда упоминает, что Марк Порат (Marc Porat), президент компании, «бросил все силы своей инженерной команды на проектирование устройства их мечты». Мишель Куин пишет без всякой иронии. Кажется совершенно естественным, что проектированием занимается команда инженеров, однако именно это и есть причина проблем. Позже в статье она цитирует одного из инженеров:
«Мы так и не поняли, над чем работаем. Спецификация появилась лишь за восемь-двенадцать недель до завершения проекта».
И снова ни инженер, ни автор не замечают иронии. По общему тону статьи можно подумать, будто все сложилось бы лучше для General Magic, напиши инженеры черновики спецификации месяцем раньше.
Неважно, как рано в процессе разработки появляются спецификации, потому что они неспособны заменить проектирование взаимодействий, и неважно, насколько сильно программисты стараются, потому что они неспособны добиться успеха в проектировании взаимодействия. Кроме того, что их методы, опыт и способности не подходят для этой задачи, они еще и оказываются в центре конфликта интересов пользователя с трудоемкостью программирования. И тем не менее, раз за разом компании разрешают разработчикам программного обеспечения управлять процессом разработки, часто от начала и до конца проекта. Иногда этот контроль очевиден, но чаще осуществляется косвенно.
Я был свидетелем такого тонкого контроля в одной успешной, среднего размера компании Кремниевой Долины. На собрании присутствовал президент, весьма сведущий деловой человек, основавший компанию, а также ведущий программист, ответственный за создание продукта. Президент показал нам продукт и продемонстрировал его мощь, которая была для нас очевидна, как и то, что этой мощью сложно управлять – интерфейс продукта был чрезмерно сложен. Наша команда проектировщиков быстро поняла, что программисты «проектировали» этот продукт по ходу написания кода, – примерно так бобер «проектирует» свою плотину во время ее строительства.
Президент пожаловался, что конкурент с более слабым продуктом завоевывает рынок компании, но затруднился объяснить, почему это происходит, поскольку знал, что его собственный продукт мощнее. Президент пригласил нас, рассчитывая на нашу помощь в борьбе с конкурентом, но при этом наделил ведущего разработчика полномочиями делать то, что он сочтет уместным. Нам было ясно, что назрела отчаянная необходимость некоторой переделки поведения продукта, и мы рассказали, как мы себе это представляем. Для нас это была обычная и несложная работа по перепроектированию, в результате которой продукт этой компании за несколько месяцев стал бы гораздо более удобным и практичным, более мощным и приятным – более конкурентоспособным. Ведущий разработчик потряс нас просьбой не вносить изменения во взаимодействия продукта с пользователем. Он считал, что в этой области проблем нет. Ему казалось, что в положении продукта на рынке виноваты недостаточно сведущие в его применении маркетологи компании. Он хотел, чтобы мы подготовили внутренние рекламные материалы, позволяющие маркетологам работать эффективнее. Он полностью отрицал наличие недостатков в продукте, несмотря их на неопровержимые свидетельства – в виде наступающего «более слабого» конкурента.
Программисты затрачивают столь много времени и энергии на изучение программного обеспечения, что для инженера казалось непостижимым, как пользователи могут не желать тратить время на изучение плодов его труда. Он с готовностью принимал версию, что источником проблемы является его компания, но полностью отрицал свою роль в создании этой проблемы. Он винил продавцов за то, что они не помогают покупателям изучить продукт. Он был готов работать, чтобы решить проблему, скажем, путем создания новых обучающих материалов, однако совершенно не считал возможными даже намеки на его собственное участие в сложившемся положении продукта.
Самодовольство инженера было поразительным. Гордость за создание такого мощного продукта ослепила его, но хуже того, ослепила и президента, который не видел неспособность инженера спроектировать продукт таким образом, чтобы пользователи остались довольны.
Продукт данной компании открыл новую нишу на рынке, внедрив новые методы сопровождения систем производства. Компания была быстрорастущей любимицей Уолл-Стрита и весьма удачно выпустила на рынок свои акции пару лет назад. Ее превозносили в деловой прессе и осыпали наградами общественные и коммерческие организации. Казалось, компания делает все правильно, и ее рыночная капитализация лишний раз это подчеркивала.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176
- 177
- 178
- 179
- 180
- 181
- 182
- 183
- 184
- 185
- 186
- 187
- 188
- 189
- 190
- 191
- 192
- 193
- 194
- 195
- 196
- 197
- 198
- 199
- 200
- 201
- 202
- 203
- 204
- 205
- 206
- 207
- 208
- 209
- 210
- 211
- 212
- 213
- 214
- 215
- 216
- 217
- 218
- 219
- 220
- 221
- 222
- 223
- 224
- 225
- 226
- 227
- 228
- 229
- 230
- 231
- 232
- 233
- 234
- 235
- 236
- 237
- 238
- 239
- 240
- 241
- 242
- 243
- 244
- 245
- 246
- 247
- 248