Клэй Ширки - Группа - сама себе злейший враг

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

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

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

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

IRC-каналы и списки рассылки регулируют размеры самостоятельно, поскольку едва соотношение "сигнал/шум" ухудшается, люди уходят или отписываются. Соотношение улучшается, люди возвращаются, и оно ухудшается снова. Такие колебания. Но они самокорректируются.

А теперь о моей любимой модели из MetaFilter. Она такова: едва появляются эффекты больших размеров, страница для новых пользователей закрывается. "Кто-то рассказал в прессе, какие мы замечательные? До свиданья!" Так повышается планка и создается порог для участия. Все, кто сделал закладку на страницу и сказал: "Знаете, я правда хочу попасть внутрь; я, наверное, позже зайду", - это и есть те пользователи, которым MeFi рад.

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

Заключение

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

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

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

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

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

Отчасти поэтому теория сообществ Джона Гегеля - от сообщества к контенту, от контента к торговле - никогда не работает. Потому что, подумать только, кто ни зайдет в чаты Clairol, все хотят поговорить о чем-то, помимо продуктов Clairol. "Но мы же за это заплатили! Это же сайт Clairol!" - Ну и что? Пользователи туда пришли ради друг друга. На оплаченное вами железо, на ваш софт, - но ради друг друга.

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

Большое спасибо.