Психбольница в руках пациентов
Добавить в закладки К обложке
- Отзывы на книгу Алана Купера - Страница 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
Любой бизнес, не связанный с программным обеспечением, начинается с исследований и заканчивается распространением продуктов или предложением услуг. Компания тщательно планирует время между этими двумя событиями, осознавая, что преждевременный выпуск непродуманного продукта опасен как для банковского счета, так и для ее репутации. Руководители знают, что время, размышления и деньги, вложенные в планирование, обернутся крупными дивидендами – гладким и быстрым процессом производства, популярностью и прибыльностью конечных продуктов.
Во всех других конструкторских дисциплинах инженеры создают стратегию, а ремесленники претворяют ее в жизнь. Инженеры не занимаются строительством мостов, этим занимаются другие специалисты. Только в области программного обеспечения перед инженером ставится задача создать собственно продукт. Только в области программного обеспечения перед «строителем мостов» ставится задача определить, как следует создавать продукт. Только в области программного обеспечения эти две задачи решаются не последовательно, а одновременно. Однако компании, создающие программы, похоже, не осознают существования такой аномалии. Инженерное дело и конструкторское дело так плотно пересекаются, что специалисты и руководители их не разделяют и, вероятно, не различают. Планированием любого рода здесь пренебрегают или откладывают его до тех пор, пока не станет слишком поздно. Считается нормальным откладывать решение очень сложных инженерных проблем до момента, когда уже экономически слишком накладно откатываться к фазе проектирования, потому что полным ходом пишется код для коммерческой версии продукта.
Проектирование архитектуры следует начинать на ранних стадиях инженерного планирования. Более того, именно оно должно быть движущей силой на этих стадиях, но такие разработки обычно откладываются до момента старта проекта и ведутся параллельно с созданием кода, поэтому не занимают должного места в процессе конструирования продукта. Компании нанимают проектировщиков взаимодействия и обучают эргономистов создавать персонажей, однако работа этих людей почти не влияет на стоимость разработки и качество завершенного продукта.
Решение проблемы – в руках президентов и исполнительных директоров корпораций. Делегируя решение своим техническим директорам или вице-президентам разработки, они поступают неверно. Эти достойные исполнители – технари, а проблема не имеет отношения к технике. Как сказал Дрюкер, инструменты для бухгалтерии, на которые полагаются директора компаний, попросту не отражают истинной природы этих компаний. Нельзя ведь на основе точных показаний спидометра утверждать, что автомобиль движется в нужном направлении. В мире бизнеса цифровых технологий такой подход не может быть эффективным.
Одна из серьезных проблем применения неверных методов бухучета и организации для разработки программ состоит в том, что руководители не осознают, во что обходится каждый доллар затрат на программирование. Точная система показала бы, что из каждого доллара около пятидесяти центов тратится неправильно и что еще два или три доллара требуется, чтобы исправить проблему, вызванную этим некорректным вложением средств. В любом другом бизнесе подобная статистика вызвала бы революцию, однако отрасль программного обеспечения продолжает жить в состоянии блаженного неведения.
За последние тринадцать лет фирма Cooper выступала в роли консультанта сотен компаний. Мои талантливые проектировщики создали для большинства клиентов «чертежи» продуктов, позволяющие коренным образом изменить ситуацию, но лишь немногие сумели воспользоваться всеми полученными преимуществами. В большинстве этих компаний проектирование взаимодействия и архитектуру программ считают лишь советом, в этих компаниях последнее слово всегда остается за программистами и инженерами. Ни один из президентов в этих компаниях не имеет ни малейшего понятия о том, что происходит в боксах инженеров, и потому расписание ужимается безо всякой причины. Программисты постоянно работают в условиях дефицита ресурсов и, прежде всего – времени на хорошее программирование, а также времени, чтобы определить, где вообще требуется программирование. Они вынуждены защищаться, отвергая советы, и изворачиваться, общаясь со своими менеджерами.
На мой взгляд, существует два типа руководителей: инженеры и запуганные инженерами. Первые множат знакомые проблемы, поскольку их точка зрения безнадежно испорчена конфликтом интересов. Вторые множат проблемы, поскольку не умеют говорить на языке программистов. И я не имею в виду языки Java и С#. Я имею в виду, что у деловых людей и программистов нет общих инструментов и общих целей. Человек разумный делегирует человеческие проблемы хомо логикус, не осознавая, что решение могло бы оказаться намного более приятным в случае применения – на исполнительном уровне – уместных финансовых и организационных моделей.
- 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