Стенгазета поддерживает сохранение версий и обработку вики-синтаксиса (используется диалект WackoWiki) при просмотре страницы. Кроме того, работает в real-time режиме: всем участникам и зрителям сразу отображаются все изменения, которые со страницей происходят.

Сейчас WikiWall можно использовать для того, чтобы:

• набросать прототип интерфейса или сайта;
• совместно подготовить презентацию и доклад;
• обсуждать элементы веб-страниц: можно указать адрес страницы, которую надо использовать в качестве фона, и создавать блоки текста и рисунки поверх нее.

По сути, вики-стенгазета — это пример того, что на WikiSym ’08 называли Spatial wiki — пространственным вики, которая оперирует не страницами текста, а блоками информации, произвольно по веб-странице раскиданными. И, пожалуй, первая прилично выглядящая реализация такого подхода.

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

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

Пока что выкладываю как есть:

Дневник хорош для того, чтобы:

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

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

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

В дневнике могут быть нелицеприятные штуки: провалы и неуспехи, прошпиленные сроки и невыполненные задания. Таких записей не надо бояться, стоит научиться признавать такие провалы, анализировать их причины и на них учиться.

Что надо вносить в дневник:

• сделанные дела;
• запланированные планы;
• принятые решения (в том числе и об отказах о реализации: «почему это сделано не будет»).

Где дневник вести:

• в блокноте, если команда проекта — только вы сами
• во внутреннем блоге, который виден только команде, например, клубе в Яру или комнате во Friendfeed‘е
• в вики, если есть вики, и не хочется заводить дополнительный инструмент.

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

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

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

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

Это все, конечно, прекрасно объясняется тем, что пишут (и потому заметны) в основном консультанты и прочие независимые эксперты. А люди, которые работают над этими вопросами у себя в компаниях каждый день, отсиживаются по офисам. То ли заняты, то ли сказать нечего.

В целом для публикации отчетов был сделан небольшой сайт в одну страницу.

И все равно надо идти.

Сама конференция будет проходить с 18 по 19 октября, в научной педагогической библиотеке имени К. Д. Ушинского, в Москве.

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

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

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

В-четвертых, документация была всегда у всех под рукой. Гибкая. Актуальная.

В-пятых, она активно росла. Было негласное правило: хочешь задать вопрос по теме, которая еще не описана? Впиши все, что ты помнишь, в той мере, какой считаешь нужным.

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

Я попросил у Марты исходую презентацию и постарался перевести на русский язык, аккуратно сохранив настрой и интонации автора. Получились слайды «Чо это такое — социальные медиа?»

Сначала перевел как «Социальное медиа» — в единственном числе. Потому что один сайт — совсем не медиа. И чем дальше, тем сильнее стираются границы между сайтами. Когда презентацию со Slideshare обсуждают во Friendfeed’е, запись в этом блоге — в ЖЖ оппонента, а главная страница Youtube выглядит вот так, назвать каждый отдельный сайт медиа не получается, зато всю эту систему — как раз. После пришлось исправить на множественное число, поскольку оно уже устоялось в языке, как единственная форма слова «медиа». Прости, Розенталь!

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

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

В вики (особенно в корпоративную) приходят люди, для которых она — привычный ежедневный инструмент. На сайт на друпалах — люди, которые на сайт во второй раз вернутся не скоро. 

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

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

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

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

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