blogu' lu' castraveţ

Rezumate:

• Человеку свойственно ошибаться, но чтобы провалить дело капитально, необходим компьютер.
• Компьютерный синдром Туретта – вариация на тему психического расстройства, известного как синдром Туретта. Некоторые из подверженных этому расстройству людей переживают неконтролируемые припадки сквернословия. Шутка в том, что можно пройти по коридорам практически любого современного офисного здания и услышать, как в целом нормальные люди, сидя за своими компьютерами и сжав зубы, постоянно и яростно ругаются. Кто знает, что вызвало такую вспышку: потерянный файл, недоступное изображение или же раздражающее взаимодействие. А может быть, программа просто вежливо стерла единственную копию пятисотстраничной рукописи пользователя, потому что он ответил «Да» на диалог с подтверждением, предположив, что ему предлагается сохранить изменения, когда в действительности предлагалось удалить работу.
• Для нашего зациклившегося на функциях мира мысль, наверное, непривычная – вы не достигнете своих целей, используя набор функций, как инструмент. Можно замечательно реализовать все функции из утвержденного набора и все равно попасть в беду. Для доказательства этого тезиса проектировщик взаимодействий Скотт Мак-Грегор на своих занятиях использует вот такой замечательный тест. Он описывает продукт с помощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет: 1) двигатель внутреннего сгорания; 2) четыре колеса с резиновыми покрышками; 3) трансмиссия, связывающая двигатель с ведущими колесами; 4) трансмиссия и двигатель смонтированы на ходовой части; 5) рулевое колесо. На этот момент времени каждый слушатель уже записал, что это автомобиль, но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя: 6) быстро и легко срезает траву; 7) на этом удобно сидеть. На основании пяти функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка. Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.
• Пока мы будем лететь к земле, я успею сшить парашют
• Суть хорошего программирования в отсроченном вознаграждении. Выкладываясь в начале, вы пожинаете плоды позже. Немного найдется задач, выполнение которых вручную обойдется дороже. Однако единожды написанную программу можно выполнять миллионы раз, не неся дополнительных затрат. Самая дорогая программа – та, что будет запущена только один раз. Самая дешевая – та, что будет запущена десять миллиардов раз. Самые дешевые программы с точки зрения пользователей дороже всего в разработке, а самые дорогие для пользователя, наоборот, дешевле в разработке.
• Програмисты сталкиваются с гобсоновским выбором – потратить время и силы на то, чтобы исправить все, с самого начала, или же решить проблему на месте, создав новый рубец в виде отклонения от плана.
• Программы следует выбрасывать и полностью переписывать каждые пару десятков лет.
• Ценность прототипа в знаниях, приобретенных в процессе его создания, а совсем не в коде.
• Движущийся, пусть и хромающий, прототип обладает опасной силой, не соответствующей своей действительной ценности.
• Программисты оказываются приговоренными к постоянной реанимации программы, дающей по мере своего развития смертоносные сбои.
• Планируйте выбросить одну версию.
• Проектирование взаимодействия должно предшествовать строительству, поэтому открытость программиста проектированию совершенно бесполезна. Точно так же оператор бетономешалки может сказать плотникам, что они смогут начать создавать каркас, как только он закончит заливать бетон.
• Три человека приговорены к казни: священник, адвокат, инженер. Первым на эшафот вступает священник. Палач дергает за рычаг, открывающий люк, но ничего не происходит. Священник заявляет, что это божественное вмешательство, и требует, чтобы его освободили, что и происходит. Выводят адвоката. Палач дергает за рычаг, и снова осечка. Адвокат заявляет, что еще одна попытка будет расценена как повторное привлечение к ответственности за то же преступление, и требует, чтобы его отпустили, – что и происходит. Наступает очередь инженера, который приступает к внимательному изучению механизма виселицы. Прежде чем палач успевает дернуть за рычаг, инженер поднимает взгляд и говорит: «А я понял, почему она не работает».
• Взаимодействие с программами имеет высокий показатель когнитивного сопротивления. Взаимодействие с физическими устройствами, пусть даже сложными, как правило, вызывает более низкое сопротивление, потому что механические устройства обычно имеют ограниченное количество состояний в сравнении с количеством внешних воздействий.
  Игра на скрипке крайне трудна, однако имеет низкий коэффициент когнитивного сопротивления, поскольку – несмотря на сложность в обращении и изощренность приемов игры – скрипка ни при каких обстоятельствах не входит в «мета»-состояние, в котором звучит, как, скажем, труба или колокольчик. Поведение скрипки всегда предсказуемо, хотя и сложно, и подчиняется физическим законам, несмотря на сложность в обращении. Напротив, микроволновая печь обладает высоким коэффициентом когнитивного сопротивления, потому что десять нумерованных кнопок на панели управления могут существовать в двух контекстах, или режимах. В одном режиме они контролируют интенсивность излучения, а в другом – длительность обработки. Такое серьезное изменение, наряду с отсутствием сенсорной обратной связи, указывающей на изменение состояния печи, и дает в результате высокое когнитивное сопротивление.
• Дороже разработки ПО обходится только разработка плохого ПО
• Пока мы будем лететь к земле, я успею сшить парашют
• Суть хорошего программирования в отсроченном вознаграждении. Выкладываясь в начале, вы пожинаете плоды позже. Немного найдется задач, выполнение которых вручную обойдется дороже. Однако единожды написанную программу можно выполнять миллионы раз, не неся дополнительных затрат. Самая дорогая программа – та, что будет запущена только один раз. Самая дешевая – та, что будет запущена десять миллиардов раз. Если не принимать во внимание крошечные программы, типа тех, что пишутся в школьные годы, экономика программного обеспечения странным образом полностью видоизменилась: самые дешевые программы с точки зрения пользователей дороже всего в разработке, а самые дорогие для пользователя, наоборот, дешевле в разработке.
• Углубляясь в работу, программисты неизбежно обнаруживают ошибки планирования и изъяны своих предположений. Они сталкиваются с гобсоновским выбором – потратить время и силы на то, чтобы исправить все, с самого начала, или же решить проблему на месте, создав новый рубец в виде отклонения от плана. Давать задний ход всегда очень дорого, однако рубцовая ткань в конечном итоге ограничивает размер программы – высоту кирпичной вертикали.
  При каждом изменении программы – будь то исправление ошибок или добавление функций – появляются новые рубцы. Именно поэтому программы следует выбрасывать и полностью переписывать каждые пару десятков лет. Рубцовая ткань с течением времени становится настолько толстой, что препятствует нормальной работе.
• Гобсоновский выбор – Выбор из одной возможности: “или это, или ничего”. Назван по фамилии Томаса Гобсона (1544-1631), курьера и хозяина постоялого двора в Кембридже. Гобсон держал конюшню на 40 лошадей, в любую минуту готовых отправиться в путь; когда кто-либо являлся за лошадью, его препровождали в конюшню, где всегда был огромный выбор, однако перед клиентом ставили условие – брать лишь ту лошадь, что стоит ближе всех к входу; таким образом, все клиенты, независимо от звания и социального положения, имели равные шансы взять как хорошего, так и плохого скакуна, да и по отношению к лошадям была соблюдена справедливость. Дж. Мильтон посвятил Гобсону две шуточные эпитафии.
• Движущийся, пусть и хромающий, прототип обладает опасной силой, не соответствующей своей действительной ценности.
• Программисты оказываются приговоренными к постоянной реанимации программы, дающей по мере своего развития смертоносные сбои.
• Ценность прототипа в знаниях, приобретенных в процессе его создания, а совсем не в коде.
• Планируйте выбросить одну версию
• Писать код без проектирования – точно так же оператор бетономешалки может сказать плотникам, что они смогут начать создавать каркас, как только он закончит заливать бетон.
• Три человека приговорены к казни: священник, адвокат, инженер. Первым на эшафот вступает священник. Палач дергает за рычаг, открывающий люк, но ничего не происходит. Священник заявляет, что это божественное вмешательство, и требует, чтобы его освободили, что и происходит. Выводят адвоката. Палач дергает за рычаг, и снова осечка. Адвокат заявляет, что еще одна попытка будет расценена как повторное привлечение к ответственности за то же преступление, и требует, чтобы его отпустили, – что и происходит. Наступает очередь инженера, который приступает к внимательному изучению механизма виселицы. Прежде чем палач успевает дернуть за рычаг, инженер поднимает взгляд и говорит: «А я понял, почему она не работает».
• Разработчики смотрели на дизайнеров сверху вниз, поскольку считали их мышление нечетким и неструктурированным, а вкусы непостоянными. Дизайнерам казалось, что разработчики лишены воображения, консервативны, склонны отвергать предложения по дизайну сразу же, не пытаясь найти способ претворить их в жизнь. Поскольку программирование оставалось для разработчиков необъяснимым таинством, они не имели возможности оценить весомость доводов разработчиков о том, что нарисованное невозможно реализовать.
• Не я ответил неправильно, вы задали не тот вопрос (©По Бронсон)
• Программисты обожают сложности. Чем сложнее проблема, тем больше удовольствия в ее решении.
• Изумительно, но простой и очевидный факт, что компьютеры сегодня намного мощнее, дешевле и быстрее, чем всего несколько лет назад, не осознан до конца практиками разработки программ. Поэтому большинство приложений не слишком усердны в обслуживании пользователей. Наоборот, приложения встают стеной на защиту центрального процессора из-за ошибочного тезиса, гласящего, что он перегружен работой. В результате программные продукты перегружают работой пользователей. Идеолог проектирования Билл Могридж (Вill Moggridge) так говорит об этом подходе: «Будь добр к микросхемам и жесток к пользователю».
• Чем больше размер мишени, тем меньше вероятность попадания «в яблочко».
• Проектируйте для одного персонажа
• Изначально чемодан на колесиках задумывался для экипажей самолетов, то есть для очень узкой аудитории пользователей.
• Продумывая этапы проектирования, мы можем примерять их результаты к персонажам и видеть, насколько хорошо справляемся. Мы начинаем играть роли, действуем от имени и по поручению персонажей. И благодаря конкретным определениям это нетрудно. Примерив на персонаже продукт или задачу, вы сразу можете понять, удастся ли вам его удовлетворить.
• В сфере информационных технологий руководитель, покупающий продукт, часто оказывается не тем, кому придется продукт применять. Проектирование для покупателя – распространенная ошибка в компьютерном бизнесе. Разумеется, потребности руководителя в ИТ тоже нельзя игнорировать, но в конечном итоге руководителю больше понравится, если продукт сделает довольным конечного пользователя.
• инженеры продолжают чинить то, что не сломано, пока оно не сломается.
• Даже на стадии прототипа в интерфейсе уже была красивая трехмерная графика, высокохудожественные пиктограммы, а также метафорическая тема карты-глобуса – все атрибуты хорошего, но пустого интерфейса. Мы называем это «раскраской трупа».
• Сущность качественного проектирования взаимодействия заключается в изобретении таких взаимодействий, которые помогут пользователям достигать практических целей, не препятствуя достижению личных целей. Цели – не то же самое, что задачи. Цель – это конечное состояние, тогда как задача – переходный процесс, необходимый для достижения цели. Очень важно различать задачи и цели, ведь их так легко спутать.
• проектирование под задачи не всегда уместно, а проектирование под цели уместно всегда.
• Тед готов вложить дополнительные усилия в настройку своего телевизора, поскольку чувствует, что телевизор приложил усилия, чтобы доставить ему, Теду, удовольствие. Это я и называю принципом соразмерности усилий. Люди готовы постараться, решая задачи, потому что воспринимают это, как честный обмен между равными сторонами. Иначе говоря, пользователь готов приложить дополнительные усилия, потому что ожидает получить за эти усилия дополнительное вознаграждение.
• первый шаг к разрешению проблемы – признать, что проблема существует.
• ЛИЧНЫЕ ЦЕЛИ:
  Не чувствовать себя глупо
  Не совершать ошибок
  Выполнить адекватный объем работы
  Развлечься (или хотя бы не страдать от скуки)

  КОРПОРАТИВНЫЕ ЦЕЛИ:
  Увеличить прибыль
  Увеличить рыночную долю
  Победить конкурентов
  Нанять больше сотрудников
  Предложить новые продукты и услуги
  Выпустить акции компании в свободное обращение

  ПРАКТИЧЕСКИЕ ЦЕЛИ:
  Избегать собраний
  Удовлетворять требованиям клиента
  Сохранять информацию о заказах клиента
  Создавать математические модели бизнеса.

  ЛОЖНЫЕ ЦЕЛИ:
  Экономия памяти Уменьшение потребности в клавиатурном вводе Поддержка работы в броузере Простота в освоении Обеспечение целостности данных
  Ускорение ввода данных
  Увеличение скорости исполнения программы
  Применение супертехнологии или супервозможностей
  Улучшение внешнего вида
  Сохранение единообразия интерфейса на различных платформах

• Если пользователь не может достичь личных целей, то он не способен эффективно достигать целей компании.
• Вежливая программа интересуется мной
  Вежливая программа относится ко мне уважительно
  Вежливая программа обходительна
  Вежливая программа ведет себя разумно
  Вежливая программа предвидит мои потребности
  Вежливая программа отзывчива
  Вежливая программа не склонна делиться своими личными проблемами
  Вежливая программа в курсе происходящего
  Вежливая программа проницательна
  Вежливая программа уверена в себе
  Вежливая программа всегда сосредоточенна
  Вежливая программа покладиста
  Вежливая программа дает мгновенное удовлетворение
  Вежливой программе можно доверять
• Программные продукты раздражают нас не отсутствием возможностей, но своей невежливостью. Как показывает этот перечень характеристик, вежливую программу обычно создать не сложнее, чем невежливую. Просто кто-то должен представить себе взаимодействия, эмулирующие качества восприимчивого и заботливого друга.
• В процессе разработки сценариев мы стараемся находить и вычеркивать задачи, существование которых обусловлено лишь исторической необходимостью.
• Сценарии создаются на основе информации, собранной в ходе первой фазы – исследования. Обычно в ходе интервью и непосредственного наблюдения за пользователями удается много узнать об их задачах. Цели стабильны и неизменны, задачи же неустойчивы, подвержены изменениям и часто оказываются ненужными в компьютеризованных системах. В процессе разработки сценариев мы стараемся находить и вычеркивать задачи, существование которых обусловлено лишь исторической необходимостью.
  Повседневные сценарии – самые полезные и важные. Они описывают основные действия, которые пользователь выполняет чаще всего. В общем случае для большинства пользователей репертуар повседневных сценариев оказывается весьма ограниченным.
  Повседневные сценарии нуждаются в самой надежной поддержке качественным взаимодействием. Новые пользователи должны быстро овладевать такими сценариями, а значит, требуется качественная поддержка быстрого обучения. То есть инструкции по применению должны быть написаны у программы «на лбу». Однако частота повторений вскоре приводит к ненужности инструкций, поэтому у пользователей быстро появляется потребность в ускоренных методах работы, таких как клавиатурные сокращения. Кроме того, по мере приобретения опыта пользователи начинают ощущать потребность в подгонке повседневных взаимодействий под индивидуальный стиль работы и личные предпочтения.
  Обязательные сценарии описывают все действия, выполняемые и нечасто, но неукоснительно.
  Обязательное взаимодействие также требует поддержки механизма обучения. Однако пользователь никогда не перейдет на более высокий уровень прохождения таких сценариев. Редкое применение означает, что любой пользователь согласится с механизмами, предложенными программой, поэтому индивидуализация не потребуется.
• сценарии для исключительных ситуаций – программисты, естественно, обращают особое внимание именно на них, но в процессе проектирования продукта эти сценарии можно игнорировать. Это не означает, что соответствующей функциональности нет места в программе, но означает, что взаимодействие для таких сценариев можно проектировать грубо и упрятывать в глубины интерфейса. Работоспособность кода может зависеть от того, обрабатываются ли исключительные ситуации, а успех продукта зависит от способности справляться со случаями, описанными в сценариях повседневных и обязательных.
• Наложив два графика, мы увидим, что сильнейшее влияние на проектирование взаимодействия оказывают антиподы, а самое главное, что ни те, ни другие не достигают цели. Программисты требуют взаимодействия, уместного только для специалистов, тогда как маркетологи требуют взаимодействия, уместного только для новичков, тогда как самую большую, самую стабильную и самую важную группу пользователей – вечных середняков – просто игнорируют.
• В пределах компании руководство, отделы продаж и маркетинга постоянно расхваливают продукт клиентам, журналистам, партнерам, инвесторам, то есть людям, с продуктом не знакомым. Эти профессионалы вынуждены постоянно контактировать с начинающими, поэтому их видение пользовательской аудитории искажено и определяется именно этой проблемной группой. Все эти влиятельные участники процесса естественным образом лоббируют упрощение интерфейса на благо новичков.
  Все программисты относятся к разряду экспертов, поскольку им приходится исследовать все, даже самые странные варианты и маловероятные ситуации, чтобы создать код для их обработки. Естественная склонность к проектированию на основе собственных предпочтений означает, что они создают код по модели реализации, назначая всем функциям равный вес во взаимодействии.
  Опыт людей, работающих с интерактивными системами, как и многие другие характеристики, тяготеет к классическому «колоколу» нормального статистического распределения.
  Новички на левом конце кривой либо мигрируют в центральную область, где обитают середняки, либо попросту исчезают с графика и находят другой вид деятельности, где способны превратиться в середняков.
  Новички на левом конце кривой либо мигрируют в центральную область, где обитают середняки, либо попросту исчезают с графика и находят другой вид деятельности, где способны превратиться в середняков. Однако популяция центральной части графика очень стабильна.
• Каждый инженер представляет свой продукт в собственных терминах, но из-за необходимости программировать редко видит продукт в контексте конкретного пользователя. Мозговые штурмы позволяют нам избавиться от всех ограничений и ожиданий и начать проектирование с чистого листа, уделяя большое внимание персонажам и их целям. Мы часто проделываем упражнение на творческое мышление. Это упражнение называется «представь себе!» и заключается в прохождении сценария с «волшебным компьютером», не имеющим никаких ограничений.
  Это упражнение подчеркивает контраст между задачами и целями. Задачи обычно меняются вместе с технологией, тогда как цели остаются неизменными. Воображая волшебную технологию, мы принудительно изменяем все задачи, обнажая истинные цели. Несмотря на кажущееся притворство, процесс этот является весьма конкретным умственным упражнением. Иногда проектировщиков осеняет верным ответом, но не реже им приходится долго дискутировать и изучать проблему, прежде чем получить этот ответ.
• В процессе проектирования и особенно в ходе мозговых штурмов я отдельно подчеркиваю необходимость создания и применения подробного и точного словаря. Я считаю, что технический нюанс проектирования интерактивных продуктов настолько важен, что единственное неправильно истолкованное слово может стать причиной краха целого проекта.Если терминов недостаточно или они определены нечетко, люди начинают мыслить консервативно. Без хорошего набора точных терминов новые идеи невозможно защищать на должном уровне, и в результате идеи отметаются раньше времени.
• Типичный процесс разработки продукта начинается с перечисления ограничений и условий.
• Раз за разом мы находим способы обходить предполагаемые ограничения только потому, что отказываемся воспринимать их всерьез. Разумеется, встречаются и настоящие ограничения, которые обойти действительно невозможно, однако в попытках это сделать приобретается ценный опыт.
• Программисты – короли практичности. Прагматизм практически лишает их терпимости к фантазиям. Но эта сила может стать и слабостью, поскольку случается, что практичный подход не позволяет решить задачу. Изобретая, инженеры находят решение путем последовательного изучения практичных, возможных шагов. Как следствие, их решения всегда оказываются производными старых решении, а этого часто недостаточно.
• Платить за проектирование, исчисляя стоимость в экранах, все равно, что платить официанту за количество подходов к столику. Лучший официант меньше бегает, а лучший проектировщик всегда создает менее развесистые интерфейсы.
• Можно получить подготовку, пройти обучение, потратить многие часы на изучение задачи, но не найти ответа. Затем приходит человек со стороны, указывает на ключевую концепцию, и тут же вся головоломка складывается в полноценное изображение с естественной очевидностью, присущей колесу. Если вы закричите о своем решении во весь голос, другие ответят: «Ну разумеется, колесо круглое! Какое еще оно может быть?» Так что похвастать хорошей работой по проектированию очень и очень сложно.
• Пользователя не следует заставлять взаимодействовать с программой дольше, чем абсолютно необходимо для решения тои или иной задачи.
• Так появилась язвительная шутка: «Проектирование – то, чем программисты занимаются двадцать минут перед тем, как начать писать код».
• Потребуй Билл Гейтс публично от всех прочих компаний прекратить разработки в области проектирования взаимодействия, эти компании просто прогнали бы его со сцены. Однако документ Microsoft, озаглавленный «Interface Style Guide» (руководство по стилям интерфейсов), требует именно этого и является одним из самых сильных конкурентных преимуществ Мiсrоsоft.
• Microsoft и Apple продвигают руководства по стилям интерфейсов, превознося их мощь и пользу, и на первый взгляд может показаться, что эти компании являются самым компетентным источником подобной информации. Однако интересы владельцев платформы конфликтуют с интересами разработчиков программного обеспечения.
  Оба создателя платформ применяют скрытую форму принуждения, пытаясь заставить производителей придерживаться стандарта. Независимый разработчик программного обеспечения, не следующий рекомендациям руководства по стилю, не сможет заявить о «совместимости с платформой», лишая свой продукт важного плюса с точки зрения маркетинга. Таким образом, большинство компаний, создающих пользовательские приложения, готовы следовать рекомендациям разработчика платформы.
  Требуя, чтобы независимые разработчики следовали описанным принципам, разработчики платформ исподтишка подавляют инновации.
  Тем временем сами разработчики платформ вольны экспериментировать и давать ход новшествам, сколько пожелают. Они могут без угрызений совести пренебрегать собственными руководствами по стилям. Разумеется, никакие другие компании не нарушают эти руководства столь же часто и откровенно, как сами Microsoft и Apple.
• Мы часто видим красивые продукты, эстетика которых великолепна, а функциональность или способы взаимодействия неадекватны назначению. Причина не в том, что продукт не проектировался, а в том, что он проектировался дизайнером, а не проектировщиком взаимодействия, имеющим инструменты для борьбы с когнитивным сопротивлением.
• Итеративный подход не позволяет создавать замечательные продукты.
  В 1986 году компания Мiсrоsоft поторопилась на рынок с первой версией Windows, которая была столь смехотворна, что заслуженно стала предметом шуток. Шесть месяцев спустя Мiсrоsоft выпустила версию 1.03 и исправила некоторые дефекты. Годом позже Microsoft выпустила версию 1.1, а затем версию 2.043. На каждом этапе развития продукта разработчики пытались разрешить проблемы, созданные в предыдущей версии. Если бы Microsoft достигла уровня качества Windows 3.0, пропустив пару промежуточных версий, она сэкономила бы миллионы на разработке и поддержке, при этом заработав дополнительные миллионы на продажах – на более раннем этапе жизни продукта. Позиция, защищающая неизбежность создания многочисленных версий продукта, – весьма дорогостоящее убийство здравого смысла.
  Стратегия измора эффективна, только если применяется компаниями, обладающими железобетонным именем, кучей времени, выдержкой игрока в покер и неисчерпаемыми финансами.
  Культура Мiсrоsoft уже привязалась к неэффективному «проектированию постфактум». Любая компания, готовая заниматься реальным проектированием взаимодействия, сможет побить Мiсrоsоft.
• Но как только продукт появляется на рынке, заинтересованность клиентов начинает увеличиваться, поскольку они вкладывают в продукт свое время и энергию. Естественно, что от них приходят запросы по изменениям и добавлениям. Существует большая разница между тем, чтобы выслушивать клиентов, и тем, чтобы за ними следовать. Выслушивать разумно.
  Подразумевается, что вы накладываете свой собственный фильтр на услышанное. Следовать требованиям клиента – плохо. То есть просто делать все то, что говорит клиент. Уже не вы играете с огнем, огонь играет с вами.
  В ложно понятом стремлении быть полезной, компания, слепо идущая на поводу у клиентов, вынуждена делать уступки. Компания одна, а клиентов у нее будут десятки и сотни. Если реагировать на всех (или хотя бы на самых крупных), кто возьмет на себя труд урегулирования этих противоречивых требований?
  Приняв чек, вы отдаете бразды правления клиенту. У клиента могут быть деньги, однако клиент не обладает двумя важнейшими качествами: 1) он не заботится о ваших интересах и 2) не знает, как проектировать ваш продукт. Продукты, создающиеся под дудку клиентов, не обладают ясным замыслом. Такие продукты не имеют качества, которое идеолог программного обеспечения Фредерик Брукс называет «концептуальной целостностью, всепроникающим видением программы», которое, по его мнению, и есть главный ингредиент успеха. В отсутствие концептуальной целостности могут случиться две вещи: клиенты начинают контролировать проектирование вашего продукта, а вы перестаете это делать.
  В конечном итоге продукт состоит из несовместимых фрагментов и случайно подобранных возможностей, продукт становится, по выражению Джона Зикера (John Zicker), «собачьим завтраком».
• Продавать мозг сложно. Человек, нанимающий вас в качестве мозга, должен вам очень сильно доверять, поскольку ожидает, что вы проделаете нечто, в чем ваша компетенция еще не доказана. Продавать опыт проще. Потенциальный клиент может увидеть, что вы уже прежде решали подобные проблемы, а значит, справитесь и с его трудностями.
  С приобретением репутации растет число клиентов, привлеченных опытом консультанта, и консультант обнаруживает, что опыт позволяет зарабатывать больше и легче. В конце концов, он ведь делает все ту же работу, что и раньше. По мере того, как консультант все меньше продает свой интеллект и все больше – опыт, исчезают именно те качества, которые и делали консультанта ценным. И он начинает отставать.
  Идущий на поводу у клиента получает легкие деньги сразу, но перестает расти и ставит крест на собственных перспективах. Он отказывается от своей роли лидера.
  Решение, предложенное Майстером, очевидно: больше участвовать в проектах, задействующих мозг. В контексте услуг необходимо убеждать существующих клиентов, привлеченных вашим опытом, давать больше задач для мозга, и Майстер подробно описывает, как это делать. Это означает, пишет он, что придется отказываться от легких заработков на опыте в пользу более тяжелых и не столь прибыльных проектов для мозгов.
• Краткосрочное планирование равносильно закладке тикающей бомбы в собственное сердце. Краткосрочной перспективы следует избегать, несмотря на возможные расходы. Долгосрочное прогнозирование означает отказ от некоторых очень привлекательных сделок. Делать это сложно, но необходимо для выживания в будущем.
• «если этого нет на бумаге, значит, это не существует»
  Хорошее и даже отличное проектирование бессмысленно, если не воплощается в жизнь. И оно никогда не воплощается в жизнь, не будучи описанным подробно, точно и со всеми деталями, причем в терминах, имеющих смысл для программистов.
  Если что-то не записано, более чем вероятно, что это будет неправильно истолковано или опущено.
  Проектировочный документ радикально снижает потребность в технической поддержке.
• Проектировщики взаимодействия играют роль посредников для профессиональных маркетологов. Проектировщик – это человек, способный переводить с языка маркетологов на язык программистов. Когда у маркетологов нет четкого понимания, они могут описать свои заботы проектировщикам, а те разовьют мысль в терминах персонажа. Затем проектировщик сможет перевести проблему в спецификацию взаимодействия. Более того, маркетолог увидит, как выполняются его запросы, и может быть уверен, что ему не придется искать покупателя для голого инженерного продукта.
• Качественное проектирование избавляет от необходимости писать невероятные объемы документации. Чем меньше сложного взаимодействия, тем меньше пространных объяснений. Авторы документации получают возможность больше времени потратить на более высокие уровни взаимодействия.
• Если за качество продукта отвечает каждый, это означает, что за качество продукта не отвечает никто. За качество продукта в конечном итоге должен отвечать проектировщик взаимодействия.
• Разумеется, создание программного обеспечения сразу для пяти ключевых персонажей – слишком крупный проект. В SHS это поняли, поэтому продукт проектировался и создавался поэтапно, по одному персонажу на этап.
• Ни архитектура, ни юридическая консультация для производственной компании не лежат в сфере основного занятия. Однако программирование – это создание продукта, а именно создание продукта, как правило, и считается занятием компании. Учитывая непосредственное влияние продукта на бизнес, можно ожидать, что любая компания будет вдвойне осторожна, чтобы бразды правления не попали в плохие руки, – еще более осторожна, чем в случае с рекламой, архитектурой или приобретением чего-либо.
• Стоимость кода не сильно растет с увеличением сложности, однако значительно растет с увеличением объема. Каждую лишнюю строку кода необходимо тестировать, отлаживать и поддерживать.
• Проще было убедить покупателей, что программами легко пользоваться, чем сделать так, чтобы программами было легко пользоваться.
• У компьютерной индустрии множество озадаченных, раздраженных, несчастных клиентов. Это гораздо более серьезная угроза благосостоянию сектора высоких технологий, чем азиатский кризис, ошибка двухтысячного года и большинство других угроз.
  В этих излияниях чувств кое-кого не хватает. Мне написали инженеры, программисты, гуру юзабилити. Однако проектировщики продуктов и маркетологи, принимающие ключевые решения по аппаратной и программной части, подозрительно промолчали. Да у вас тут полно злых клиентов. Как вы собираетесь отвечать?

Dicționar:

• Эрза́ц (нем. Ersatz), или суррога́т — неполноценный заменитель чего-либо[1].Понятие «эрзац» стало широко применяться во время Первой мировой войны, когда в Германии из-за огромного недостатка стратегических продуктов сливочное масло стали заменять маргарином, сахар — сахаринoм, a кофе — цикорием.
• APOLOGÉT, apologeți, s. m. Susținător fervent (și adesea exagerat) al meritelor cuiva sau a ceva.
• расторопный — Бойкий, быстрый, проворный в деле
• венчурный – (торг.) относящийся к финансированию новых, неапробированных проектов; связанный с коммерческим риском
• ANTAGONÍST, -Ă, antagoniști, -ste, adj. Care se află în opoziție; antagonic.
• ARHETÍP, arhetipuri, s. n. Model, tip inițial după care se călăuzește cineva; (în special) manuscris original al unei opere. ♦ (Psih.) Structură profundă a psihicului, înnăscută, care generează imagini simbolice și guvernează organizarea experienței umane.
• непреложный – такой, который нельзя нарушить, изменить; обязательный
• Катехи́зис (из лат. catechēsis от др.-греч. κατηχισμός — поучение, наставление ← κατηχεῖν — внушать, отвечать = κάτω — вниз + ήχος — звук) — официальный вероисповедный документ какой-либо конфессии, огласительное наставление, книга, содержащая основные положения вероучения, часто изложенные в виде вопросов и ответов.
• VIVISÉCȚIE, vivisecții, s. f. Disecare a unui animal viu (pentru a studia un fenomen fiziologic)
• SOHO – small office, home office
• AGNOSTICÍSM s. n. (Fil.) Punct de vedere potrivit căruia gândirea umană este incapabilă să ofere suficiente argumente raționale pentru a justifica existența sau neexistența lui Dumnezeu.
• Тигель (от нем. Tiegel — горшок) — это ёмкость для нагрева, высушивания, сжигания, обжига или плавления различных материалов.

Referințe:

• Alan Cooper – “About Face: The Essentials of User Interface Design”. (IDG Books, 1995).
• Джеффри Мур – “Crossing the Chasm” (Пересекая бездну)
• Ро Bronson – “The First $20 Million Is Always the Hardest” (По Бронсон – Тяжелее всего даются первые двадцать миллионов долларов)
• Gerald Weinberg – “The Secrets of Consulting: A Guide to Giving & Getting Advices Successfully” (Секреты консультирования: Руководство по успешному применению советов), Dorset House, 1985.
• Fred Moody – “I Sing the Body Electronic” (Фред Муди – Электронное тело пою)
• Paul Glen – “Leading Geeks: How to Manage and Lead the People Who Deliver Technology”, 2003, John Wiley & Sons, New York
• Фильм Чарли Чаплина “Новые времена” (Modern Times) распространяет мнение, что технология нас обесчеловечивает.
• Saul W. Gellerman – “Motivation and Productivity”, Amacom, New York, 1963.
• Byron Reevs, Clifford Nass – “The Media Equation; How People Treat Computers, Television, and New Media Like Real and Places”, Cambrige University Press, 1996.
• Steven Pinker – “How the Mind Works”, W.W. Norton & Company, 1997. (Recomended)
• Robert X. Cringely – “Accidental Empires, How the Boys of Silicon Valley Make Their Millions, Battle Foreign Competition, and Still Can’t Get a Date”, Addison-Wesley, 1991.
• Edward de Bono “Lateral Thinking, Creativity Step by Step” (Нестандартное мышление: Творчество шаг за шагом), 1970, Harper & Row, Publishers, New York.
• Мiсrоsоft – “Interface Style Guide” (руководство по стилям интерфейсов).
• Дэвид Майстер – “Managing the Professional Service Firm” (Управление компанией профессиональных услуг)