—
Clay Shirky отчасти опередил свое время — в середине и даже в конце 2000-х массовое появление подобных «small-scale software», как описано в эссе, было мало реально. Всё-таки на рынка не хватало инструментов для этого. Да и про инерцию процессов в больших системах не стоит забывать (IT-индустрии и массовым пользователям требуется время, чтобы осознать всю глубину своего падения :0)
А вот примерно с 2014 года пошли первые явные подвижки, к ним отношу:
Это всё разноплановые инструменты, но основная идея в них заложена одна и та же ➜ упростить разработку приложений. И массово появляться они начали в один промежуток времени.
В настоящий момент, спустя 20 лет, идея «Situated software» похоже заново обретает смысл, но теперь в вариации «Local-first» конструкторов (фреймворков) 😀
—
Оригинал на сайте автора. Эссе впервые было опубликовано 30 марта 2004 г. в списке рассылки «Networks, Economics, and Culture».
Если текст заинтересовал, то лучше читать эссе в оригинале! Здесь перевод в немного сокращенном виде, выкинуто примерно 20%. Подобные тексты делаю для себя, поэтому оставляю только то, что считаю явно полезным.
Преамбула
Я преподаю в NYU's Interactive Telecommunications Program (ITP), где студенческое население примерно поровну разделено на технологов, заботящихся об эстетике, и художников, которые не боятся машин, что делает его довольно хорошим местом для того, чтобы увидеть будущее.
Часть будущего, которое, как мне кажется, я вижу, - это изменение в экосистеме программного обеспечения, которое на данный момент я называю «Situated software». Это программное обеспечение, разработанное для конкретной социальной ситуации или контекста. Этот способ создания программного обеспечения контрастирует с тем, что я называю «Web School» (парадигмой, в которой я учился программировать), где масштабируемость, универсальность и полнота были ключевыми достоинствами.
Я вижу, как мои ученики охотно игнорируют практики «Web School», но при этом выполняют интересную работу, и этот факт в течение года вызывал у меня стойкий когнитивный диссонанс, поэтому я хочу описать здесь эту закономерность, даже на ее зарождающейся стадии, чтобы посмотреть, видят ли другие люди то же самое в другом месте.
Пользователи десятками (Users By The Dozens)
У нас всегда было противоречие между корпоративными методами проектирования и способом создания программного обеспечения "из небольших, слабо связанных частей", если использовать удачное выражение Дэвида Уайнбергера. Преимущества последнего частично описаны в «Чем хуже, тем лучше» (Worse is Better) и «Собор и базар» (The Cathedral and the Bazaar). «Situated software» относится к категории небольших частей со следующей дополнительной характеристикой: оно предназначено для использования определенной социальной группой, а не для общего круга «пользователей».
Самое большое отличие, которое это создает по сравнению с классическими веб-приложениями, заключается в том, что становится проще создавать приложения для использования десятками пользователей, а это абсурдная целевая группа в современной практике проектирования. Разработка программного обеспечения, подходящего по форме для небольшой группы пользователей, как правило, была прерогативой банков и исследовательских лабораторий. Из-за связанных с этим затрат, «Web School приложения» концентрировались на привлечении широкой аудитории. А отдавая предпочтение ценности, связанной с масштабом, «Web School приложения» делают другие виды ценности, особенно социальной, недоступными.
Мы так долго прерывали разговоры о программном обеспечении фразой «Это не масштабируется», что забыли, что проблемы масштабирования не являются фатальными по своей сути. Проблема N-квадратов является проблемой, только если N велико, а в социальных ситуациях N обычно невелико. Группа чтения лучше работает с 5 участниками, чем с 15; семинар лучше работает с 15 участниками, чем с 25, тем более с 50 и так далее.
Это, в свою очередь, придает программному обеспечению, подходящему для конкретной группы, ряд желательных характеристик: оно дешевле и быстрее создается, имеет меньше проблем с масштабируемостью и более вероятно для восприятия целевыми пользователями. У него также есть несколько очевидных недостатков, в том числе меньшая вероятность использования за пределами исходной среды, большая хрупкость, если позже его потребуют для работы с большими группами, и потенциально более короткий срок службы.
Тем не менее, я вижу, что мои ученики идут на некоторые из этих компромиссов, потому что те проблемы, которые «Web School» должна была решить — стоимость адекватного оборудования, редкость талантливых программистов и разреженное распределение потенциальных пользователей — больше не являются теми ограничениями, которыми они когда-то были.
Класс (The Class)
На курсе «Социальное программное обеспечение», который я преподавал прошлой осенью, студенты работали в небольших группах над разработкой и запуском программного обеспечения, поддерживающего ту или иную форму группового взаимодействия. Чтобы закрепить успех занятия, я потребовал, чтобы любой проект, который они придумали, использовался другими студентами ITP. Преимущества первого порядка этой стратегии были просты: разработчики происходили из той же группы, что и пользователи, и, таким образом, могли считать свои собственные инстинкты обоснованными; бета-тестеров можно было набрать, пройдя по коридору; и это удерживало людей от грандиозных попыток «вскипятить океан».
Чего я не ожидал, так это преимуществ второго порядка. Снова и снова группы сталкивались с проблемами, которые они частично решали, используя преимущества социальной инфраструктуры или контекстно-зависимой информации, которая была бы недоступна приверженцам «Web School». Особенно выделяются две стратегии.
Первая была связана с системами репутации. Один проект, The Orderer, предназначался для координации групповых заказов в ресторане, что часто встречается во время ночных рабочих заседаний. Другой, WeBe, был инструментом для координации групповых закупок таких вещей, как чипы или двигатели. Поскольку речь шла о деньгах, подход «Web School» потребовал бы какого-то способа борьбы с угрозой неплатежа, использование таких вещей, как предоплата или экроу-счета, или формальные системы репутации.
Вместо этого в обоих проектах студенты решили, что, поскольку все пользователи являются частью сообщества ITP, они просто упростят отслеживание неплательщиков, при этом угрожая публичной трансляцией их имен. Возможность быть опозоренным перед сообществом стала частью дизайна приложения, хотя сообщество и предполагаемый стыд находились вне рамок самого приложения.
Общественное внимание (Communal Attention)
Другая стратегия была связана с общественным вниманием. Два других проекта, Scout и CoDeck в конечном итоге оказались в сообществе более буквальным образом. Scout указывает на физическое присутствие, позволяя учащимся зарегистрироваться как присутствующие где-то на этаже ITP и отображая эту информацию. CoDeck — это видеосервер на базе сообщества, предназначенный для того, чтобы видеохудожники могли делиться работами друг друга и комментировать их.
Обе группы столкнулись с классической проблемой уведомления: чтобы заставить пользователя настроиться, необходимо прервать его текущую деятельность, а это, как известно, не нравится пользователям. Миллиарды были потрачены на «Web School приложения», которые предполагали, что пользователи будут добавлять в закладки для повторного посещения или с радостью примут оповещения по электронной почте, но, несмотря на несколько широко разрекламированных успехов, таких как Schwab.com и eBay, пользователи в основном отказывались «часто заходить».
И Scout, и CoDeck пришли к одному и тому же решению: убрать большую часть интерфейса с экрана ПК и переместить его в физический объект в гостиной, в зале встреч / столовой / настольном футболе в центре этажа ITP. Scout и CoDeck построили в гостиной киоски с физическими интерфейсами вместо взаимодействия с клавиатурой и мышью. И у Scout, и у CoDeck есть веб-сайты, на которых пользователи могут вводить или получать данные, но ключевым элементом каждого из них является местоположение в физическом пространстве, которое помещает приложение в социальный контекст.
Все эти проекты взяли за основу первоначальный принцип курса — приложение должно быть полезно для сообщества — и начали работать с его следствием — сообщество должно быть полезно для приложения.
Возможности группы (Group Capabilities)
При разработке программного обеспечения мы постоянно полагаемся на когнитивные способности людей: мы предполагаем, что пользователь может связать мышь с курсором или что значки будут информативными. Однако мы редко полагаемся на когнитивные способности групп, хотя в реальном мире мы постоянно опираемся на эти способности.
Во время мозговых штурмов группа может генерировать не просто больше идей, но и больше их разновидностей, чем те же люди, работающие изолированно, и групповой консенсус часто оказывается более точным, чем предположение самого знающего человека в группе. Группы также многое знают о себе. Люди в рабочих группах знают, к кому обратиться за советом по дизайну или на кого в крайнем случае нельзя положиться, без какого-либо официального определения этих ролей. Члены социальных групп знают, с кем весело пойти выпить или кому не следует одалживать деньги (часто это один и тот же человек), без необходимости изложения этих знаний в FAQ.
«Web School software» игнорирует такого рода знания, потому что их трудно изложить явным образом. Например, в большинстве крупных списков рассылки лишь несколько авторов начинают обсуждение, в то время как большинство авторов просто поддерживают обсуждение; а на более высоком уровне лишь немногие члены вообще публикуют сообщения, а большинство просто наблюдают. Мы знаем об этих шаблонах уже несколько десятилетий, но программное обеспечение для создания списков рассылки по-прежнему не предлагает каких-либо функций, специфичных для запуска и продолжения веток, а также не различает людей с большими объемами постов и просто наблюдающих.
Однако существует другая стратегия, аналогичная предложению пользователю распознать значки; разработчик может просто предположить, что группа обладает определенными возможностями, без необходимости повторять их в коде. Если у вас есть неполученный платеж в общем пуле покупок, программное обеспечение может выдать сообщение «Предупреждение о неплательщике. Разберитесь с этим». Реальная группа будет иметь какой-то способ решения проблемы, обычно посредством морального убеждения или угрозы потери репутационного капитала, или даже, в крайних случаях, остракизма.
Это ничем не отличается от того, что происходит в офлайн-группах каждый день, но с точки зрения «Web School» это решение кажется неправильным, поскольку эти веб-приложения не могут предполагать, что существует негласная система репутации. Опираясь на существующую социальную структуру, «Situated software» гарантированно не будет работать в том же масштабе, что и «Web School приложение», но по той же причине оно может работать так, как не может «Web School software».
Взгляд со стороны (Outside Eyes)
В конце концов я начал рассматривать «Situated software» как практическую стратегию разработки, а не как ухудшенный вариант «реальной» разработки приложений, когда пригласил сторонних рецензентов на занятия по социальному программному обеспечению для промежуточной критики. Все эти люди зарабатывали на жизнь работой с социальным программным обеспечением, и сессия критики была чрезвычайно ценной. Однако две рекомендации рецензентов показались мне забавными.
Первым было предложение группе CoDeck сделать все функции своего видеоинструмента доступными через Интернет — загружать, скачивать, комментировать и так далее. Второй рекомендацией был призыв к группе WeBe рассмотреть сайты групповых закупок веб-школ, такие как Mercata и MobShop, как руководство к своей работе.
Для меня это был момент, когда когнитивный диссонанс окончательно стал невыносимым. Каждый из этих комментариев был а) именно тем, что я сказал бы, будь я сторонним рецензентом в чьем-то другом классе, и б) явно неправильным, учитывая проблему, с которой боролись соответствующие группы.
Предложение об общей веб-доступности интерфейса CoDeck прозвучало в форме риторического вопроса: «Почему бы не сделать его максимально доступным?» Поскольку в парадигме «Web School», бо́льше пользователей — это «Всегда Хорошая Вещь». Но у CoDeck было несколько веских причин не превращать свой проект в просто приложение для веб-видео.
WeBe маленький (WeBe Small)
Точно так же рекомендация WeBe обратить внимание на Mercata и MobShop содержала в себе предположение, что целью в конечном итоге должна стать работа в больших масштабах. Однако Mercata и MobShop потерпели неудачу, поскольку были созданы для масштабирования.
Этим сайтам требовался замкнутый круг, где чем больше пользователей, тем больше экономия. Увы, одной мысли о том, что где-то кто-то еще экономит на покупке конкретных товаров, было недостаточно для привлечения пользователей, а без критической массы этот "благотворный круг" становился порочным.
WeBe, с другой стороны, копировала мелкомасштабную модель, которую они впервые заметили, когда однокурсник Скотт Фицджеральд организовал покупку со скидкой 30 лицензий на программное обеспечение для редактирования мультимедиа Max. Он использовал список рассылки ITP, чтобы привлечь покупателей, а затем ходил по комнате, выкручивая руки и собирая чеки. Для этого требовалась реальная социальная структура — все знали Скотта и доверяли ему.
Старые дефициты исчезают (Old Scarcities Fade Away)
Там, где «Web School» работает хорошо, она работает, потому что это правильный ответ на некоторые проблемы. Существует нехватка средств: серверы стоят дорого, не говоря уже о маршрутизаторах для балансировки нагрузки, резервных копиях на магнитную ленту и других средствах, необходимых для бесперебойной работы. Существует нехватка талантов: Хороших программистов трудно найти, а великих программистов мало. И есть ограничения использования: Пользователи заняты, они люди привычки, и существует серьезная конкуренция за их внимание.
Однако устранение этих недостатков может придать «Web School» проектированию качество, напоминающее карусель. Вам необходимо масштабировать, потому что создание полезного веб-приложения обходится очень дорого, но большая часть расходов связана с требованиями масштабирования. Более того, эти недостатки усиливают друг друга: Вам нужен большой бюджет на оборудование, чтобы создать масштабируемое приложение, но вам нужны хорошие программисты и системные администраторы, чтобы справиться с нагрузкой, зарплата которых требует увеличения маркетингового бюджета, чтобы привлечь достаточное количество пользователей, чтобы оплатить все это.
Я думаю, что вижу, как мои ученики сходят с дистанции. Они могут это сделать, потому что ни один из недостатков, которые решает «Web School», не является таким значительным, как раньше. Прежде всего, закон Мура и его эквивалент для хранения данных, а также постепенное улучшение операционных систем означают, что настольный компьютер стоимостью 800 долларов также может быть довольно хорошим сервером прямо из коробки.
Во-вторых, внимание пользователей было недостаточным отчасти потому, что пользователей вообще было очень мало. В 90-х годах запуск приложения в Интернете означал отказ от любой прямой связи с конкретным реальным сообществом, поскольку пользователи Интернета были разбросаны, а за пределами ИТ-индустрии большинство реальных групп имели лишь небольшую часть членов, которые были онлайн.
Природа программирования (The Nature of Programming)
Наконец, меняется практика программирования. Недавно компания Gartner вызвала ажиотаж, заявив, что через десять лет в США будет на 235 000 программистов меньше. Это было бы похоже на предсказание, сделанное в 80-х годах, о том, что к 2004 году в США будет меньше машинисток. В некотором смысле такое предсказание было бы верным - офисный машинописный состав исчез, и большая часть работы по вводу данных переместилась за границу. Но сам процесс набора текста, когда пальцы ударяют по клавиатуре, никуда не исчез, он распространился повсеместно.
То же самое и с программированием; Хотя все внимание уделяется аутсорсингу, существует также и downsourcing, переход программирования от «типа должности» к широко практикуемому навыку. Если под программистами мы подразумеваем «людей, которые пишут код», а не «людей, которым платят за написание кода», то к 2015 году число программистов будет значительно расти, даже несмотря на то, что многие из людей, использующих Perl и JavaScript, Flash не считают себя программистами.
Программное обеспечение для вашей мамы (Software for Your Mom)
«Situated software» — это не столько технологическая стратегия, сколько отношение к тесному взаимодействию между программным обеспечением и его группой пользователей, а также отказ от масштабирования, универсальности или полноты как безусловных достоинств. В этом свете одержимость персонализацией «Web School software» является апологией очевидной истины: большинство веб-приложений по своей конструкции обезличены, поскольку созданы для обычного пользователя. Предоставление пользователю возможности настраивать интерфейс веб-сайта может сделать его более полезным, но это не делает его более личным, чем банкомат, выводящий ваше имя на экран и выплевывающий ваши деньги.
«Situated software», напротив, не нуждается в персонализации — оно индивидуально с самого начала.
Один из моих учеников упомянул о создании веб-приложения для своей матери, школьной учительницы, чтобы следить за своим классом. Если бы вы работали в одиночку, без оплаты, в свободное время, вы бы ни за что не смогли создать приложение, которое бы полностью удовлетворило потребности школьных учителей во всем мире. Однако вы могли бы создать приложение для своей мамы.
Конечно, небольшие специализированные приложения существовали всегда — изучение BASIC раньше было обрядом посвящения для владельцев ПК, а учреждения, занимающиеся интенсивной обработкой данных, такие как инвестиционные банки и исследовательские лаборатории, пишут программное обеспечение для небольших групп пользователей. Однако теперь сочетание хороших инструментов, талантливых пользователей и Интернета как социальной среды упрощает создание такого программного обеспечения, повышает качество результата и доставляет его пользователям так же просто, как клик по ссылке. Центр разработки с дюжиной пользователей, который в прошлом было так трудно обслуживать, может стать нормальной практикой.
Что дальше? (What Next?)
Итак, что же произойдет дальше? Если то, что я наблюдаю, не является временным и не ограничивается узким набором ситуаций, то мы увидим рост числа таких небольших «подходящих по форме» приложений. Это повлечет за собой некоторые очевидные недостатки, в том числе привязку разработчиков таких приложений к функциям поддержки сообщества и сокращение срока службы программного обеспечения, созданного таким образом.
Однако ожидания долговечности — это временная версия масштаба: мы предполагаем, что приложения должны работать длительное время отчасти потому, что их создание обходится дорого. Однако, когда создание приложения становится дешевым и простым, это обоснование ослабевает. Компании обычно просят команды хорошо оплачиваемых людей потратить сотни часов работы на создание одной презентации PowerPoint, которую можно будет рассмотреть на одной встрече. Идея о том, что программное обеспечение должно создаваться для многих пользователей или служить в течение многих лет, является культурным допущением, не требуемым самим программным обеспечением.
Действительно, большая часть программного обеспечения, созданного для большого числа пользователей или рассчитанного на неограниченное использование, в любом случае не достигает обеих целей. «Situated software» — это способ сказать: «Большинство программ получают лишь несколько пользователей на короткий период времени; почему бы не воспользоваться преимуществами проектирования с учетом этого?».
Как ни странно, это своего рода прогресс, но не потому, что «Situated software» заменит другие виды приложений, а потому, что в большинстве случаев этого не произойдет. Несмотря на всю ценность, которую мы получаем от нынешней экосистемы разработки ПО, она не включает в себя возможность создания приложений, созданных для горстки пользователей, которыми можно было бы пользоваться в течении всего нескольких месяцев. Однако сейчас, я думаю, мы начинаем видеть новую нишу программного обеспечения, в которой сообщества получают инструменты, подходящие по форме для очень конкретных нужд, инструменты, которые не проходят большинство предыдущих тестов на качество или успех проектирования, но которые, тем не менее, функционируют хорошо, потому что они так хорошо расположены в сообществе, которое их использует.