Каковы плюсы и минусы этих и других методов? любые хорошие инструменты для этой цели?
Если вы рекомендуете wiki, какой Wikis вы бы рекомендовали использовать? внутренний? принимал? свободно? платный?
Я бы рекомендовал использовать wiki. Он отлично работает как центральный источник документации и имеет встроенный контроль версий. Также вы можете ссылаться на документы в коде через URL.
Люди - это самый эффективный контейнер знаний в вашей компании. И самый эффективный способ передачи знаний - от людей к людям. Вики и документация также полезны, но если ваши сотрудники не являются отличными техническими писателями, письменная документация - это ужасный способ передать все, кроме самых тривиальных знаний. Писателям требуется много лет, чтобы написать книгу, поэтому вы не можете ожидать, что разработчики напишут качественную документацию через пару часов.
Лучший способ сохранить знания в вашей организации - заставить людей работать вместе. Убедитесь, что никто не работает один. Попросите людей провести пару программ и пересмотреть друг друга. Организуйте технические сессии и т.д.
Если вы действительно хотите хранить знания, попробуйте обогатить данные. Легко добавить фотографии досок и т.д. В wiki. Другая проблема с письменной документацией состоит в том, что люди, кажется, думают, что длинный изгиб абстрактного текста является "профессиональным". Убедитесь, что вы держите документацию коротким, понятным и точным, чтобы люди действительно ее прочитали.
Если вы можете получить поддержку, социальная среда, имеющая репутацию (например, этот сайт), может отлично работать в интрасети. Люди нуждаются в небольшом стимуле, чтобы накормить базу знаний.
Я бы рекомендовал MindTouch Deki. Это гораздо больше, чем вики, с интеграцией в ряд других источников, в том числе возможность интегрировать его в пользовательские источники данных в вашей организации.
Вики работают хорошо, но мы дополняем Wiki с помощью заклинаний Ignite и Camtasia. Это экономит время при отображении конфигурации и т.д. Скринкасты легко сделать, быстро, и вам не нужно беспокоиться, захватили ли вы правильные детали для своей аудитории, поскольку они перематывают/воспроизводят разделы, которые им нужно просмотреть.
Мы пробовали статьи базы знаний, и это делает людей ленивыми - "Я не понимаю этот раздел" означает, что вы переписываете целую группу. Дайте человеку скринкаст, и они могут сделать свои собственные заметки.
Единственная важная вещь в сохранении знаний в компании, независимо от решения, заключается в обеспечении того, чтобы люди использовали систему. Вики - мои любимые, но без принуждения от руководства или руководителей команд, трудно поддерживать этот уровень полезных знаний - люди ненавидят документацию, кажется, особенно когда это облегчает их замену.
Вики хороши, но одно из их самых больших преимуществ еще не упоминалось. Очень часто недостатки в документации не обнаружены человеком, который его написал, потому что автору не нужно или не читать документацию. Недостатки обнаруживаются, когда автор находится в отпуске или из-за болезни, а кто-то другой пытается следовать документации, а часть его не работает. Используя Wiki, любой бедный парень в конечном итоге обнаруживает недостаток в документах, может исправить его немедленно, вместо того, чтобы отправлять электронную почту автору, где он зарывается в других тысячах писем, которые автор получил во время отпуска, или пытался запомнить автор после того, как автор вернется.
Кроме того, убедитесь, что по крайней мере два человека знают, как делать все и поддерживать уровни укомплектования персоналом. Когда кто-то уходит, может быть очень заманчиво не заменять их, если у вас уже есть другие люди, которые могут делать все, что они сделали, но если у вас теперь есть несколько объектов инфраструктуры или кода, которые каждый понимает только один человек, тогда вы уязвимы, Передача знаний от одного человека другому требует времени и рук. Это непросто, но это бесконечно проще, чем пытаться изучить инфраструктуру или базу кода только из документов.
Я использовал оба метода в прошлом и нашел, что формат вики должен быть наиболее легко принят. Хранение документов в исходном управлении может иметь последствия для слияния версий (очевидно, в зависимости от используемого программного обеспечения для управления версиями и применяемых методологий). То же самое относится к вики-решениям, но по какой-то причине она никогда не представляла серьезной проблемы в реализациях, которые я использовал.
Поисковик основных вики-это еще один важный фактор для его успеха. Гораздо проще найти поисковый запрос в вики, чем найти ссылку на документ в потенциально несвязанной части кода.
< 2c/ >
Мне нравятся вики. Я даже использую их для своих собственных проектов хобби, документируя, как я обошел неприятные проблемы, с которыми я не хочу иметь дело, или поддерживая список ссылок на relavant ресурсы.
Наличие многих людей в такой вики еще более мощно, однако возможность обсуждения также очень важна.
Фактически я начал проект, который обращается к нему. Он все еще находится на этапах планирования, но я определил несколько областей, в которых технические знания хранятся в организациях. Теперь это не относится к каждой организации, но каждая организация использует хотя бы один из них.
Именно то, как вы используете каждый из них, отличается, но ключ заключается в том, чтобы заставить людей использовать статические и/или динамические веб-сайты для сбора информации или, по крайней мере, определить, где они находятся в книгах и хранилищах. Если люди не кормят дома знаний, то не имеет значения, какую технологию вы используете. Знание должно быть текущим, точным и глубоким или бесполезным, из того, что я смог собрать.
Еще одна ключевая концепция, которая важна, как отметил Винько Врсалович, - это возможность связать данные/информацию/знания с ней рассуждениями. Общей практикой в анализе требований является способность отслеживать требование к его источнику. То же самое нужно сказать о знании. Все в организации могут знать все в мире. Однако, если никто не знает, ПОЧЕМУ это знание полезно, или ГДЕ/КОГДА использовать эти знания, он расточился.
Если мне не хватает ни одного, не стесняйтесь редактировать это сообщение или отвечать как комментарий. Я думаю, что этот вопрос поможет моим проектам.
РЕДАКТИРОВАТЬ 1: добавил Винько Врсалович, что это не только знания, но и привязка данных к вопросам производства, к которым относится знание.
Я видел, что в рамках электронной почты внутри организации происходит много дискуссий о знаниях. Эти знания долго сохраняются в электронной почте и в конечном итоге теряются и недоступны для других, которые не были частью первоначальной дискуссии.
Использование таких инструментов, как http://grexit.com, поможет вам перенести эти знания из вашего почтового ящика в общий репозиторий coomon в вашей организации. В настоящее время это работает только для Gooogle Apps, но стоит попробовать.
Определенно wiki. Мы используем TWiki и используем некоторые превосходные плагины.
Изменить: я забыл добавить, что вы можете проконсультироваться с ответами на этот вопрос на документы и контроль версий.
Используйте wiki, но убедитесь, что у кого-то есть редакционная собственность на то, что происходит. Этот человек должен обеспечить соблюдение стандартов и иерархий документа - это очень просто для вики-компании стать разваливающимся беспорядком.
Я дам вам некоторые недостатки Wiki или где может потребоваться дополнительная мысль:
Я думаю, инструмент, который вы используете, не так важен. Самое главное, что все члены вашей команды объединены в одну сторону и одно место для документации.
Вы можете использовать wiki или базу данных заметок или приложение self- brew.
Я лично предпочитаю, чтобы все было в одном месте. Поэтому для технической документации система управления исходным кодом будет правильным местом. Для документации, которая используется не разработчиками, контроль источника определенно является неправильным местом. Для сторонних документов, возможно, сервер sharepoint - это инструмент, который вы должны использовать. Он имеет определенный контроль над версиями и доступен без специальных клиентских приложений.
Мы используем комбинацию блога проекта и вики.
Я думаю, что люди чувствовали себя немного отвлеченными вики - они считали, что им нужно было ввести несколько абзацев, по крайней мере, чтобы оправдать запись, поэтому мы начали блог, который полезен для захвата мелочей или вещей, которые происходят в в режиме реального времени, например: "Я изменил длину поля столбца от 40 до 50" или "очистил данные таблицы аудита старше, чем на прошлой неделе".
Я надеюсь (надеюсь), что некоторые записи в блогах станут исходным материалом для более длинных записей вики, поскольку проект продвигается.
В качестве альтернативы вики рассмотрите возможность использования SharePoint. Он позволяет обрабатывать события (например, собрания), задачи и документы. Он очень хорошо работает с нетехнической толпой, что может позволить техническим писателям и менеджерам взглянуть на происходящее. Это также часть Windows 2003, поэтому вам может не понадобиться дополнительная лицензия.
С другой стороны, я могу почти гарантировать, что будет luddite, который обвиняет вас в каждом незначительном мошенничестве. Более высокие версии, вероятно, будут любить его, хотя.
Возможно, вы можете взглянуть на Associativy. Он хранит куски знаний как узлы графа, где ребра представляют собой ассоциативное (в человеческом смысле) соединение. Граф можно искать и исследовать несколькими способами, учитывая набор условий поиска, которые программа может "думать" о подходящей ассоциации.
Я открываю исходный код и запускаю на Orchard CMS, проект с открытым исходным кодом.
Это был бесстыдный плагин (Associativy - мой проект), извините.
Изменить: просто узнал, сколько лет этот вопрос....