Страница 1 из 1

Social Software - Соцобеспечение

Добавлено: Ср янв 20, 2010 4:03 pm
Сингуляронавт
Я было собирался написать о последних тенденциях в области social software, но, к своему удивлению, обнаружил, что у нас об этом феномене практически ничего неизвестно. По крайней мере, ни Яндекс, ни Google (с ограничением выдачи запросов на русском языке) не смогли предоставить мне ни одной толковой ссылки, где бы объяснялось, что это такое. Поэтому статья, скорее, является маленьким ликбезом в области social software — самой перспективной и интересной парадигмы программного обеспечения на сегодняшний день.

Social software

Начать, наверное, следует с того, что ничего совершенно нового в social software1 нет. Social software — это программное обеспечение, главная цель которого — реализация эффективного взаимодействия нескольких пользователей между собой. Вы наверняка подумаете о разнообразных мессенджерах, клиентах электронной почты, многопользовательских ролевых играх — и будете правы. Все это social software. Равно, как и очень популярные в последнее время механизмы организации веб-сообществ (LiveJournal, Slashdot и др.).

Зачем тогда изобретать новый термин и в очередной раз обсуждать то, что уже давно известно и реализовано? Причин тому несколько. Одна весьма прозаическая. Как и любой индустрии, софтверной промышленности нужны яркие продукты, которые довольно давно не появлялись. Разумеется, были свои удачи, свои истории успеха, однако действительно инновационных программ, ставящих с ног на голову наше представление о том, как можно работать с компьютером, не было. Из того, что приходит в голову: ICQ, Napster, блоги… Всем этим новинкам уже несколько лет. Иных, как говорил поэт, уж нет, хоть и стали они родоначальниками целых софтверных династий — Napster породил Gnutella, Gnutella породила AudioGalaxy…

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

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

Больше трех не собираться

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

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

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

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

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

При всей своей изящности это решение не универсально, поскольку предполагает определенный уровень подготовки пользователей. Поэтому придумано множество других способов самоорганизации сообществ — правда, большинство из них накладывает более жесткие ограничения на свободу участников (как в самом популярном решении для форумов — выделенной модерации). В некоторых случаях группа, дабы выжить, должна явно ограничить приток «новой крови». Чтобы попасть в LiveJournal, нужно либо заплатить за сервис, либо попросить код у одного из действительных пользователей журнала. Иногда прием новых участников прекращается вообще — как, к примеру, на MetaFilter.com.

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

При этом опыт организаторов сообществ сугубо эмпирический. Все вводимые ограничения (или в терминах Клэя Ширки [Clay Shirky] — «конституции»4) продиктованы здравым смыслом, которого не всегда достаточно для создания эффективных барьеров. Никаких серьезных исследований юзабилити в контексте групп на сегодняшний момент не существует. А значит, не существует универсального механизма создания и поддержания жизнеспособного сообщества. Но вот правила создания правильного программного обеспечения, рассчитанного на индивидуальное использование, известны и широко применяются.

Кому, зачем и как


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

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

Редактор Tech Central Station Арнольд Кинг (Arnold King) выделил три основные задачи5, которые должно решать групповое ПО. Первая — задача соответствия или задача встречи, когда из множества вариантов мы должны выбрать лучший (the matching problem). Другими словами, проблема фильтрации трафика внутри группы. Очевидно, что эта задача распадается на две более простые: выбор максимального количества возможных вариантов и анализ полученной выборки по каким-то критериям с целью выделения наиболее подходящих вариантов. Сегодня эта задача худо-бедно решается, однако нет предела совершенству.

Задача принятия решений (the issue-resolution problem). Одна из главных проблем, решение которой может привести к радикальному повышению эффективности работы группы. Сама по себе группа неидеальна, и во многих случаях ей потребуется помощь специалистов, для которых участие в работе этой группы не является основным занятием. Задача social software — вовлечь этих специалистов в работу так, чтобы они затратили как можно меньше времени на экспертизу проекта. И — что не менее важно — позаботиться о том, чтобы их советы были услышаны. Понятно, что эта проблема (одна из главных, кстати говоря) не является исключительно софтверной. Даже идеальное social software не будет эффективным, если в компании не существует «реальных» способов привлечения специалистов из других отделов. Задача ПО — отразить существующую деловую практику, выставив определенные приоритеты. Разумеется, нельзя отрицать возможность подгонки бизнес-процесса под ПО — в случае с внедрением ERP-систем, например, это обычная ситуация. Правда, эффективность внедрения ERP достаточно низка, заставляя относиться к такому подходу со здоровым скепсисом.

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

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

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

Примечания:


1 К сожалению, мне не удалось найти подходящего русского термина. Все приходящие в голову переводы или слишком длинны, или не отражают сути понятия. Посему оставляю как есть.
2 Это сейчас много ума не надо, когда таких программ сотни. — Прим. ред.
3 Технология Wiki теоретически позволяет любому пользователю редактировать любые страницы ресурса. На практике это, конечно, не так — определенные ограничения имеются, дабы оградить ресурс от вандализма.
4 Social Software and the Politics of Groups, Clay Shirky (shirky.com/ writings/group_politics.html).
5 www.techcentralstation.com/1051/techwrapper.jsp? PID=1051-250&CID=1051-042103C.

Александр Карпов
Опубликовано в журнале «КОМПЬЮТЕРРА» http://offline.computerra.ru/offline/2003/494/27216/