Как заставить разработчиков использовать wiki

Некоторые советы:

Каждый раз, когда кто-то отправляет информацию по email, которая действительно должна быть в wiki, сделайте страницу для этой темы и добавьте то, что они поместили в email. Затем ответьте: "Спасибо за эту информацию, я поместил ее в wiki здесь, чтобы ее было легче найти в будущем."

Точно так же, если у вас есть информация, которой вы должны поделиться, которая должна быть в wiki, поместите ее туда и просто отправьте email со ссылкой на нее, а не email человек.

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

Если вы являетесь "чемпионом wiki", убедитесь, что другие люди знают, как его использовать, например: "я уже прошел через то, как создать новую страницу с вами?"

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

Используйте шаблоны стилей "nav box" на связанных страницах для облегчения навигации.

Поместите что-то вроде {{Special:NewPages/5}} на первой странице или последние изменения, чтобы люди могли видеть эту активность.

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

Как я уже упоминал ранее, a Wiki очень неорганизован.

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

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

Если кто - то посылает email, который содержит информацию, связанную с проектом, а затем услужливо указывает им в направлении wiki - и продолжает делать это-они должны получить подсказку.

У нас есть портал SharePoint и использовать wiki оттуда - мы настроили его с нашим собственным брендингом, так что это "looks the part" - я действительно чувствую, что это помогло улучшить понимание его.

Убедитесь, что все знают, что wiki является еще более неформальным, чем email.... потому что будет "fear factor", что люди могут подумать, что все, что они добавляют к wiki, будет чрезмерно проанализировано.

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

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

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

Тем не менее, люди, которые настаивали на wiki (например, вы), должны в первую очередь отвечать за его обновление, и у вас действительно будет много работы, если вы серьезно относитесь к этому.

Вы также можете попробовать ff:

• Вы говорите, что это не очень структурировано-многие люди отворачиваются от плохо структурированных (hard-to-search/browse) Вики. Так что, может быть, вы сможете исправить это в первую очередь
• Возможно, вы можете попросить ведущих разработчиков/менеджеров проектов заполнить его вещами, которые являются для них проблемами: такими как соглашения о коде и дизайн API для вашего конкретного проекта
• Приведите пример: религиозно документируйте свою часть системы. Создание прецедента может побудить других сделать то же самое

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

Пример преимущества от того, что такое Wiki

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

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

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

Я буду использовать wiki для документирования моей специализированной области независимо от того, как она действует в качестве удобного расширения мозга. Когда я начинаю новую разработку, я использую ее как блокнот для идей, которые я могу расширить по мере ее развития.

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

Если разработчикам все еще нужно поддерживать документацию 'real' (s.a. Word documents), я не вижу никакого способа значимо дублировать это на Wiki.

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

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

Это нормально. Работа с Wiki более утомительна, чем с Word, но, по крайней мере, doc находится в сети, и другие могут mix-and-match с ним работать.

Другим рабочим решением (imho) было бы хранить документы рядом с исходным кодом, на subversion. Но тогда система слияния должна быть в состоянии справиться с богатым текстом и т. д. также. Я не знаю, существует ли какое-либо решение для этого (кроме использования HTML или LaTex, что на самом деле не было бы плохим выбором).

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

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

Так что другие (users/volunteers) могут просто взять такое содержимое и поместить его на wiki.

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

Например такой вопрос как следующий:

как заставить git клонировать удаленный репозиторий???

Можно ответить примерно так:

Привет, Просто используйте git clone git://...

Но на вопросы также можно ответить в менее личном стиле:

Чтобы клонировать репозиторий git, необходимо использовать параметр clone для git: git клон git://....

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

Я был свидетелем нескольких случаев, когда проекты с открытым исходным кодом начали использовать этот подход в некоторой степени, и в то время как некоторые люди (в основном новые пользователи) жаловались, что ответы не были очень личными, объем документации неуклонно увеличивался, потому что другие люди просто следили за такими обсуждениями и начинали копировать/вставлять такие ответы в wiki.

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

Вообще здесь хороший совет. Я бы хотел добавить:

1. Вам действительно нужен Чемпион - кто - то, кто подталкивает это к разработчикам и управлению (не будучи настойчивым -это вызов!) и предоставление поддержки & учебников, когда это возможно. Этот человек также должен быть коллегой (то есть коллегой-разработчиком, а не кем-то из удаленного отдела IT) и действительно ориентированным на клиента, т. е. готовым вносить изменения по запросу.
2. Говоря об изменениях, некоторые люди здесь говорят, что Вики неструктурированы . Я не согласен. Наша установка MediaWiki структурирована с использованием категорий, в частности, с двумя расширениями: WarnNoCategories (чтобы требовать от пользователей добавлять категорию при сохранении страницы) и CategoryTree , чтобы показать, как все категории подходят друг к другу (это можно связать с боковой панелью). У меня есть еще несколько советов о том, как мы держим этот низкий порог, если вам интересно.

Просто чтобы добавить к некоторым из превосходных советов, предлагаемых здесь...

Будучи разработчиком в небольшой компании, которая в основном не занимается контрактной работой в диапазоне 6-24 месяцев, я обнаружил, что мое время часто разделяется между разработкой и написанием отчетов о состоянии (прямо там с написанием документации, только хуже!) Наличие wiki, чтобы шлепать неорганизованные мысли и заметки по ходу дела, сделало написание отчета намного менее болезненным (не боль-LESS, но все же лучше).

Далее, Если вы уже находитесь в мире Mediawiki, вы можете посмотреть на SemanticMediawiki . Это позволяет вам перевести организацию ваших данных на другой уровень, семантически помечая их. Я знаю, что это не так уж много значит само по себе, но я могу сказать вам (например), что это может значительно повысить релевантность данных, возвращаемых из поиска. Это определенно стоит посмотреть.

Найти "sticky" предметов (sub-3 pg. docs / diagrams / etc) что-то, что команда, кажется, создает снова и снова & разместить его на wiki. Убедитесь, что все имеют доступ к wiki и знают его там-установите механизм уведомления, если это возможно. Если повезет, в следующий раз, когда им придется получить доступ, а не выкапывать его из системы управления версиями или своих машин, они должны попасть в wiki. Если они все еще этого не делают, попробуйте посмотреть, есть ли у команды достаточно слабины, чтобы действительно использовать wiki - более тонкие проблемы могут лежать за их нежеланием.

Взгляните на совет по адресу http://www.ikiw.org/ Grow your Wiki