«Психбольница в руках пациента»

Если вы когда-нибудь задумывались, почему компьютерные программы и всяческие электронные гаджеты ведут себя так, словно были созданы болваном или пытаются сделать болвана из вас, прочтите эту книгу. «Психбольница в руках пациента» – это манифест о том, как повысить качество жизни в век, когда мы проводим много времени во взаимодействии с технологиями. Издание адресовано не только программистам-бизнесменам, но всем, кто запускает новый продукт или проект. Мы публикуем саммари с ключевыми идеями книги Алана Купера с разрешения компании SmartReading.

Введение

Разработка программного обеспечения - самая гибкая отрасль производства, когда-либо существовавшая в истории. Программы не ограничены в сфере применения и могут воплощать в жизнь любые логические инструменты. Хозяева продуктов довольны - продажи идут отлично, и кажется, что нет смысла менять что-то. Парадокс, но сегодня эта сфера имеет целую армию раздраженных клиентов. Часто на рынке появляется «сырой» продукт нового игрока и отнимает долю у гигантов. Как это происходит? 

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

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

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

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

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

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

Цифровые продукты обладают своей спецификой в силу того, что не имеют физического воплощения. Когда человек видит молоток или музыкальный инструмент, он может быстро понять, как они работают — у этих вещей низкое когнитивное сопротивление. Программные продукты, наоборот, скрыты, неосязаемы. Более того, виртуальные элементы управления могут менять свое поведение в зависимости от контекста. Из-за этого понять, как они работают, бывает крайне сложно даже для «опытного пользователя». Эта особенность программных продуктов и вызывает то, что называется когнитивным сопротивлением. 

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

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

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

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

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

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

Для программистов характерна своя особая психология. 

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

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

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

4. Программисты грубы и прямолинейны. Их интеллектуальное превосходство — это предмет гордости. 

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

1.  Для программистов огромную ценность представляет код, написанный таким образом, чтобы его можно было легко использовать в другой программе. Важно не только то, что в следующем проекте надо будет меньше писать, но и то, что таким «модульным» кодом можно делиться с другими разработчиками. Это благотворно влияет на работу программистов целом, но порой наращивает программу рудиментарным кодом или незапланированными функциями, которые по логике программиста «все равно бесплатны». Это одна из причин инертности программ — в новых программах легко появляются плохие паттерны поведения из прошлых программ, потому что в них просто используется старый код. 

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

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

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

Неправильный процесс разработки — идеальный способ потратить кучу денег впустую. 

На рынке существует миф о срочном выпуске продукта на рынок. Якобы чем раньше программа будет готова, тем лучше. Разработку ПО принято осуществлять с фиксированным сроком сдачи. Фактически команда разработчиков очертя голову бросается в неизвестность и все время работает в атмосфере горящих сроков. При таком подходе никто не в состоянии определить текущий статус готовности проекта, и в итоге на рынок выходит сырой необдуманный продукт. 

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

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

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

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

Яркая иллюстрация этого правила — карманные компьютеры. Первые карманные компьютеры Penpoint появились на рынке еще в 1990 году, однако не имели успеха. Затем Apple Newton в 1992 и Magic Link в 1994 постигла та же участь. А в 1996 вышел первый PalmPilot и стал хитом продаж, первым успехом на новом рынке. Аналитики и эксперты объявили о возрождении рынка карманных компьютеров, и никто из них не догадался, что успех устройству был обеспечен длительным проектированием нового устройства. По сравнению с первым КПК, он опоздал на целых 6 лет.

Из-за необдуманного подхода к разработке программ даже стало популярным правило Паркинсона. Оно звучит пугающе, но из проекта в проект подтверждается на практике. Правило гласит: «90% кода программы отнимают 90% времени на ее разработку, остальные 10 % кода программы отнимают еще 90% времени». То есть, когда программисты написали 90% кода, оставшаяся часть работы занимает столько же времени. Умудренные менеджеры уже привыкли, что время разработки надо умножать в уме на два, а то и на четыре. 

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

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

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

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

1. Программы ничего не помнят о вас — не помнят, где вы всегда храните свои файлы, не помнят, какие инструменты вы используете чаще других.
   
   

2. Программы стараются угодить пользователю так, как будто пользователь — программист.
   
   

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

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

5. В случае проблем программа полностью возлагает вину на пользователя. Если что-то пошло не так, программа не возьмется устранять проблему самостоятельно. 
   
   

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

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

Ларри Кили из Dolphin Group предложил модель взаимодействия трех важнейших факторов в технологическом бизнесе. 

За первый фактор отвечают инженеры. Он отвечает на вопрос «Что возможно создать, каковы технические возможности и ограничения компьютеров?». 

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

Такое противоречие создает трение во взаимоотношениях этих двух сил, и для успешного симбиоза разработчиков и бизнесменов работает третья сила — проектировщики, они отвечают за третье свойство программ — их привлекательность — и отвечают на вопрос «Что привлечет людей, что удовлетворит их?».

Проектирование создает продукт, который:

• а) может быть создан и может хорошо работать;

• б) может успешно продаваться;

• в) который будет действительно ценен и полезен.

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

Задача проектирования — разработать привлекательный продукт.

Модель Кили показывает, как добиться преданности клиентов. Лояльность клиентов, которую приносит хорошее проектирование продуктов, позволяет корпорации Apple переносить сильные потрясения и серьезные ошибки управления и экономить в других аспектах производства — преданные клиенты готовы долго терпеть и многое прощать. 

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

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

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

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

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

Преимущества ввода персонажа:

1. Он дает представление о реальном уровне подготовленности («компьютерной грамотности») потребителей. 
   
   

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

3. Персонажи дают всем участникам процесса разработки единую систему отсчета, точку опоры. Это дает представление о стадии работы и готовности продукта — продукт можно считать готовым, только когда цели персонажа удовлетворены. 

У процесса проектирования должны быть четкие цели. Проектирование без целей — все равно что отсутствие проектирования. Под целями проектирования понимаются цели персонажа. Цели (так же как и персонаж) — это твердая точка опоры для принятия решений в ходе разработки. Для проектирования важны все цели персонажа, как практические, так и личные.

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

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

• Не чувствовать себя глупо.
• Не совершать ошибок.
• Выполнять адекватный объем работы.
• Развлечься (или хотя бы не страдать от скуки).

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

Типичные корпоративные цели: 

• Увеличить прибыль.
• Увеличить рыночную долю.
• Победить конкурентов.
• Нанять больше сотрудников.
• Предложить новые продукты и услуги.

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

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

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

Естественно, при использовании нового устройства человек неизбежно должен будет приложить какие-то усилия. Чтобы сделать этот опыт безболезненным, необходимо соблюдать важный в проектировании принцип соразмерности усилий: человек с радостью приложит усилия, чтобы научиться пользоваться продуктом, если будет видеть, что продукт «идет ему навстречу» и «прилагает усилия», чтобы помочь разобраться. 

Так как люди часто эмоционально реагируют на «поведение» программы, вплоть до ведения словесной беседы с компьютером, проектировщикам необходимо делать поведение программ таким, чтобы взаимодействие с программой было похоже на общение с приятным (воспитанным, вежливым) человеком. «Вежливая» программа соответствует ряду характеристик: 

• Интересуется мной — тем, кто я такой, что мне нравится, запоминает мои прошлые предпочтения.

• Относится ко мне уважительно — предлагает, а не приказывает; предполагает, а не заключает. 

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

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

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

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

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

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

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

• Уверена в себе — компьютеру не следует постоянно спрашивать у меня подтверждения действий, вместо этого лучше давать возможность отменить их, если я действительно совершил ошибку.

• Всегда сосредоточена — такая программа не задает лишних вопросов, которые уводят меня от выполнения текущей задачи.

• Покладиста — цифровые системы часто требовательны к человеку, заставляя вводить точные и полные данные; люди привыкли (и это удобно) иметь возможность оставить какую-то работу на потом или перескочить какой-то шаг процесса, оставив его на потом. 

• Дает мгновенное удовлетворение — программа не должна откладывать вознаграждение пользователя на момент, когда он проделает огромное количество работы, она должна поощрять человека чаще. 

• Ей можно доверять — вежливая программа заслуживает доверия и избавляет меня от желания лишний раз проверять правильность ее работы.

Еще один важнейший инструмент проектирования — сценарии. Сценарии представляют собой описание ситуаций и поведения персонажа в этих ситуациях.

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

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

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

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

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

Есть еще ряд второстепенных инструментов и хитростей. 

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

• В ходе проектирования необходимо помнить, что подавляющее большинство пользователей можно считать «середняками» в обращении с техникой. Они редко бывают новичками или экспертами. 

• Полезно представлять себе ситуации и строить предположения, не думая о технических ограничениях. Если в процессе проектирования изначально задавать их, то будет невозможно сосредоточиться на целях — вы будете работать в контексте задач. 

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

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

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

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

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

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

Проектирование полезно всем:

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

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

• Проектирование помогает в разработке документации и в технической поддержке. Чем лучше проектирование — тем проще будет документация и тем проще будет работа технической поддержки. 
  
  

• Проектирование однозначно полезно для руководителей разработки — процесс обретает единую для всех участников плоскость координат, объединяет терминологию всех уровней компании. Для руководителя процесс создания программного продукта и его успех на рынке становятся более предсказуемыми и прогнозируемыми. 

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

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

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

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

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

Проектирование должно стать частью процесса разработки и непременно должно предшествовать написанию кода. 

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

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