Как далеко мы зашли?

Как далеко мы зашли?

Моя программная речь на Agile08 в Торонто, Онтарио.

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

(Текст этого выступления был опубликован в январе 2018 года. Я добавил к нему исходные слайды PowerPoint в сентябре 2019 года. Примечание в конце этого сообщения объясняет, почему)

Многие из вас знают меня как дизайнера интерфейсов.

Но я еще и программист. Я начал программировать в 1974 году. Я изобрел программное обеспечение; спроектировал это; спроектировал это; построил это; задокументировал это; починил это; и изучил это. Некоторые из них были небольшими, но по большей части это были большие программы, которыми пользовались миллионы людей. Я всегда был независимым, но я продал свое программное обеспечение некоторым из крупнейших компаний, участвующих в игре, таким как CA и Microsoft. В наши дни мои навыки программирования довольно ржавые, но я люблю программы; Я понимаю программное обеспечение; и я хочу поговорить о программном обеспечении.

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

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

Люди, которые создают программное обеспечение, необычайны. Программисты - самые умные люди в человечестве. Программисты - одни из самых трудолюбивых людей. Любят решать сложные проблемы; чем сложнее, тем лучше. На самом деле По Бронсон говорит: «Они будут исправлять то, что не сломано, пока оно не будет сломано». Программисты, как правило, очень добросовестные, очень приятные и очень заинтересованные люди с сильным желанием доставить удовольствие.

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

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

Искусство не обязано делать ничего практического; программное обеспечение делает. Художник может изменить проблему, если решение становится слишком трудным; программист не может. Конечно, какой-то код настолько красив, что мы не можем не рассматривать его как искусство.

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

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

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

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

Самая важная часть программного обеспечения не существует. Самая важная часть программного обеспечения - это промежуток между программами. Такие промежутки называют «интерфейсами».

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

Есть человеческие интерфейсы, в которых программное обеспечение общается с людьми, и есть API-интерфейсы, сокращенно от Application Program Interfaces, где программное обеспечение взаимодействует с другими частями программного обеспечения. Хотя я посвятил большую часть своей профессиональной карьеры человеческим интерфейсам и написал несколько книг по этой теме, именно программные интерфейсы, API-интерфейсы, без сомнения, являются наиболее важными интерфейсами.

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

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

На протяжении всей истории цифровых технологий примерно каждые 7 лет сообщество программистов устраивает коллективную истерику, ломает все свои игрушки и переключает внимание на новую. В 60-х блок-схемы победили хаос. В начале 70-х структурированный код победил спагетти-код и goto. В 80-х доминировало объектно-ориентированное программирование. В конце 80-х модным словом был код многократного использования.
В 90-е годы, когда большое количество кода было готово к повторному использованию, все должно было быть основано на веб-технологиях, поэтому ничего не использовалось повторно. В нулевые гибкое программирование - новая игрушка. Все эти игрушки отличные. Все они продвинулись в программировании.

Все эти новые движения в методологии программирования имеют общий недостаток. Все они утверждают, что это единственный истинный метод, применимый во всех случаях. Но, как сказал мудрый программист Фред Брукс: «Серебряной пули не существует». Бесконечные споры об инструментах и ​​методах почти всегда лишены конкретного применения. Один программист утверждает, что Java лучше всего; другой утверждает, что C ++ лучше. Ни одна из сторон не говорит зачем. В Интернете бушуют великие пламенные войны, даже не упоминая контекста. Во всем мире программистов существует негласное, но универсальное предположение, что программирование однородно; что это цельная и единообразная практика; что достоинства данного метода - это его достоинства всегда, везде и для всех практикующих. Это просто неправда.

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

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

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

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

Waterfall не работает! Он просто производит неуместную ерунду, которую конечные пользователи неизбежно отвергают с отвращением.

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

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

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

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

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

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

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

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

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

Четыре этапа требуют трех разных состояний ума. Этап Большой идеи уникален: невозможно предсказать, как он будет реализован. Часто это уединенный момент блестящего озарения, который случается в тот момент, когда вы просыпаетесь; опять же, это могло случиться на собрании персонала или в душе. Две средние стадии являются стадиями проектирования и по необходимости являются совместными; Характерно бурное развитие творческих умов, отталкивающее идеи друг от друга. Работа с другими в рамках эгалитарных компромиссов - вот что делает эти этапы такими продуктивными. Но последний этап, этап строительства, посвящен потоку; о том, чтобы войти в продуктивное состояние и оставаться в нем как можно дольше. Прекращение расследования или сотрудничества - это дорогостоящее прерывание процесса.

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

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

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

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

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

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

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

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

В течение многих лет метод водопада утверждал, что большой, полный, хорошо задокументированный дизайн, сделанный заранее, решает проблемы. Мы знаем, что это не так.
Программисты создали уничижительное выражение «Big Design Up Front» или «BDUF», чтобы описать документацию, необходимую для Waterfall. Agile побеждает BDUF, позволяя продолжать разработку программного обеспечения без какой-либо значительной проектной документации.

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

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

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

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

Установленная практика управления индустриальным возрастом основана на командовании и контроле. Когда ваш заводской персонал не имеет образования и не мотивирован, контроль жизненно важен. Обычно он иерархический; с делегированием на технические специальности (это мы). Основные инструменты руководства - это авторитет, деньги и престиж.

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

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

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

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

В ожидании неудачи неудивительно, что менеджеры мало верят в результаты программных проектов. Они видели, как гигантские, успешные, хорошо финансируемые компании годами запускали колоссальные провалы, такие как Windows Vista и Panama от Yahoo. Они также видели, как старшекурсники и неудачники с подержанными компьютерами добиваются колоссальных успехов, как, например, FaceBook и Flickr. Что ж, если вы не разбираетесь в программном обеспечении, это может показаться довольно случайным. И если вы думаете, что успех случаен, тогда разумнее тратить меньше на лотерейный билет, чем тратить больше. Именно эта неуверенность в результате наряду со знанием того, что размер инвестиций не коррелирует с успехом, заставляет менеджеров опасаться тратить деньги на программное обеспечение.

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

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

Нет никаких доказательств того, что выход на рынок первым дает бизнес-преимущества. Существует множество свидетельств того, что опоздание с выходом на рынок более качественного продукта действительно дает значительное преимущество для бизнеса. Например, Archos Jukebox был первым 6-гигабайтным портативным MP3-плеером с батарейным питанием и жестким диском. Он опередил iPod на рынке более чем на год, но потерпел неудачу, потому что был очень плохо спроектирован.

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

Когда менеджеры назначают вам крайний срок, спросите, почему он существует. Их ответ неизбежно перекладывает ответственность на своего начальника (помните, что такое командование и контроль). Спросите своего босса, хочет ли он успешный продукт или продукт в произвольный срок. Смело бросайте ему вызов.

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

Менеджеры часто требуют доказательств того, что стремление к качеству принесет определенную измеримую «окупаемость инвестиций». Это легко. Просто согласитесь предоставлять номера ROI, используя ту же систему, которую они используют в настоящее время. Такой системы не существует. Когда менеджер требует, чтобы вы оправдали свои усилия, просто попросите его то же самое в обратном порядке. Чем она оправдывает свои нынешние методы? Вы услышите один из трех ответов: мой босс сказал мне это сделать; снизит затраты; или какое-то расплывчатое, необоснованное обобщение о лучших продуктах. Возможно, вам не удастся сразу выиграть эти аргументы, но вы сможете посеять семена сомнения в уме менеджера. Вы можете начать медленный процесс превращения своего начальника в постиндустриального менеджера. И дизайнеры взаимодействия очень помогут с этой задачей.

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

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

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

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

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

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

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

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

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

Я не понимаю, почему дизайнеры взаимодействия не лучший друг Agile-программиста? Почему гибкие программисты не обращаются за помощью к дизайнерам взаимодействия?

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

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

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

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

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

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

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

Важные недавние работы в области эволюционной, поведенческой и когнитивной психологии в сочетании с нейробиологией пролили много света на эту проблему. Такие ученые, как Стивен Пинкер из Массачусетского технологического института; Клиффорд Насс и Байрон Ривз в Стэнфорде; Марк Герштейн из Колумбийской школы бизнеса, Pfeffer & Sutton в Стэнфорде; Млодинов в Калифорнийском университете Беркли; Абрахамсон в Колумбии; Linden в Johns Hopkins; Клэкстон в Оксфорде; Шварц из Свортмора и блестящий бабуинолог Роберт Сапольски много изучали и много писали о различных явлениях явно иррационального человеческого поведения. Все люди, программисты, менеджеры и разработчики взаимодействия подвержены широкому спектру искажений восприятия и ценностей.

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

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

Что более вероятно:
1. Линда - кассир в банке
2. Линда - кассир в банке и активна в феминистском движении.

Если вы похожи на меня и 85% остального человечества, вы выбрали № 2, но это не может быть правильным. По законам вероятности ответ №2 не может иметь большей вероятности, чем ответ №1. Но оказывается, что эта распространенная «ошибка конъюнкции» встречается и в диагнозах врачей, и в суждениях юристов. Существует множество документально подтвержденных когнитивных искажений.

Когнитивные психологи относятся к таким силам, как:

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

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

Хотя дизайнеры взаимодействия довольно хорошо изобретают пользовательские интерфейсы, многие программисты и менеджеры по продукту тоже умеют это делать. Там, где разработчики взаимодействий могут предоставить значительную уникальную ценность, является их способность извлекать полезные ответы из искаженных, сырых данных, извлеченных от людей или предоставленных ими. Дизайнеры взаимодействия используют этнографические исследования, пользовательские модели, построение сценариев, ролевые игры и другие специализированные инструменты для процесса дистилляции. Кстати, все эти методы Agile.

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

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

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

Как видите, дизайнерам взаимодействия предстоит проделать значительную работу до того, как начнется кодирование. Задолго до Day Zero, когда функции и интерфейс уже доступны, необходимо ответить на более серьезные вопросы о том, кто именно является пользователем и что именно сделает его счастливым. Эта работа состоит из наблюдения и интервьюирования пользователей и других заинтересованных сторон, а затем преобразования этих необработанных данных в полезные инструменты повествовательного дизайна. Выполненная здесь работа гарантирует, что команда создаст правильный продукт, а не просто набор предлагаемых функций. Если вы подождете, чтобы ответить на эти вопросы до тех пор, пока кодирование не начнется, вы можете потерять много недель работы вместо того, чтобы просто внести некоторые незначительные изменения или рефакторинг. Эту работу также можно выполнять параллельно с другими маркетинговыми усилиями, и при этом не нужно откладывать начало программирования.

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

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

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

Гибкие программисты в небольшой команде, компании, ориентированные на Интернет, тесно сотрудничают со всеми другими дисциплинами, и их программное обеспечение обычно рассматривается как продукт, предлагаемый внешнему миру. В этих компаниях Agile-программисты, маркетологи, дизайнеры и менеджеры по продуктам должны работать в демократических командах, чтобы провести мозговой штурм по идеям хороших функций продукта, чтобы знать, что им создавать. Хотя это правда, что хорошие идеи могут исходить от любого, кто участвует в Agile-процессе, эти идеи все же больше похожи на виноград, чем на вино.

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

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

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

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

Некоторые программисты настолько сбиты с толку этими трудностями, что разводят руками и плачут, дядя. Это было особенно верно в первые дни Agile.
Мой уважаемый коллега, Кент Бек, создатель Extreme Programming, говорит: «Вы не можете знать, что пользователи сочтут ценным в программном обеспечении». Такие люди, как Кент, знают, что единственное, на что они могут положиться, - это код, поэтому они начинают писать код как можно скорее. Затем они требуют множества корректирующих отзывов от своего скрытого пользовательского агента. Это успокаивает программистов, у которых возникает чувство, что они сами уходят в заросли, но часто это означает, что он просто утаскивает пользователя за собой в заросли.

Все программисты знают, как тяжело давать пользователю то, о чем он просит, только для того, чтобы тот отклонил его при доставке. Программист думает: «Я дал им то, что они хотели, а они этого не захотели». Итак, они делают вывод: «То, что они хотели, должно быть изменилось». Видимо, считает программист, требования изменились. А если требования меняются, зачем вообще заниматься дизайном? Но это самоисполняющееся пророчество: если вы не проектируете, требования всегда будут меняться.

Я говорю, что вы можете знать! Дизайн взаимодействия позволяет вам с уверенностью узнать, что пользователь найдет ценным в программном обеспечении. Если рассматривать людей логически, знание невозможно. Но если у вас есть инструменты для деконструкции нелогичного поведения людей и разоблачения их когнитивных иллюзий, узнать, чего они хотят, не сложнее, чем написать программу на Java. Это означает, что дизайн взаимодействия может значительно снизить рабочую нагрузку Agile-программиста, не оказывая существенного влияния на методы работы программистов. Точно так же процесс проектирования взаимодействия убеждает деловых людей в том, что они принимают правильные решения, и что их команды продвигаются вперед более продуктивно. В то время как методы Agile позволяют менеджерам видеть техническую сторону процесса, дизайн взаимодействия дает менеджерам возможность увидеть человеческую сторону процесса.

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

Фредерик Брукс, возможно, самый мудрый человек в мире программного обеспечения. В основополагающем эссе, которое он впервые написал более тридцати лет назад, он сказал: «Планируйте выбросить одно», что означает, что вы выбросите одно, хотите вы этого или нет. Он узнал, что вы должны написать это один раз, чтобы узнать, что вы делаете и как это делать. Вы пишете его второй раз, чтобы он был достаточно хорош для публичного развертывания. По моему опыту, Брукс прав. До Agile программисты создавали программу, отправляли ее, а затем пытались построить ее правильно во второй раз. За исключением того, что они никогда не смогли построить его правильно во второй раз, потому что у них был весь неправильный устаревший код, с которым нужно было справиться. Не говоря уже о наследстве недовольных пользователей, которые попробовали его в первый раз и обожгли пальцы.

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

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

Первый, сбрасываемый, должен быть бережливым, поджарым и правильным.
Его цель - продемонстрировать правильность, поэтому его построение следует повторять, согласовывать и проверять. Вы должны потратить столько времени, сколько нужно, чтобы сделать это правильно; в конце концов, это инструмент обучения. Это должно быть Agile. Это минимум инженерных доказательств, предназначенных только для внутреннего использования, и никогда не отправляйте его.

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

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

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

Мир программного обеспечения имеет долгую и неоднозначную историю совершенствования процессов ради программистов, при этом никогда не облегчая жизнь нашим пользователям. Ничего особенного не изменилось с появлением всемирной паутины. Большую часть программного обеспечения стало проще использовать просто из-за того, что он стал менее мощным. И до сих пор Agile-методы в основном были направлены на то, чтобы упростить жизнь программистам, а пользователи по-прежнему в основном на словах. Хорошая новость заключается в том, что Agile-методы первыми действительно освобождают место для дизайнеров взаимодействия, единственная цель которых - сделать программное обеспечение лучше для пользователей. Это означает, что Agile может быть лучшим, что когда-либо случалось с дизайном взаимодействия. И это было бы лучшим, что могло бы случиться с пользователями программного обеспечения.

Спасибо!

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

Я был рад обнаружить - после повторной публикации текста этой речи здесь, на Medium в январе 2018 года, - насколько велик был интерес. Слайды PowerPoint в настоящей презентации были, скажем так, графически незрелыми, поэтому я исключил их из этой перепечатки.

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