knowledge-management - 組織内の技術的知識を覚える最良の方法は何ですか

Question

会社のウィキを使用しますか？
ソース管理の一部として技術文書を保存し、さまざまなソースファイルからそれらへのリンクを作成するのはどうですか（これがどのように機能するかを理解するには、ディレクトリ内の記事を参照してください...）

これらの方法と他の方法の長所と短所は何ですか？この目的のための良いツールはありますか？

ウィキを推奨する場合、 どのウィキを使用することをお勧めしますか？内部？ホストされていますか？自由？支払った？

score 20 · Accepted Answer

ウィキの使用をお勧めします。中央のドキュメントソースとして非常にうまく機能し、リビジョン管理が組み込まれています。また、URLを介してコード内のドキュメントを参照することもできます。

score 9 · Accepted Answer

人は、会社で最も効果的な知識の入れ物です。そして、知識を伝える最も効果的な方法は、人から人へです。Wiki とドキュメンテーションも有用ですが、従業員が優れたテクニカルライターでない限り、文書化されたドキュメンテーションは、最も些細な知識以外のすべてを伝達するためのひどい方法です。ライターは本を書くのに何年もかかるので、開発者が数時間で質の高いドキュメントを書くことは期待できません。

組織内に知識を維持する最善の方法は、人々が一緒に働くことです。誰も一人で作業しないようにしてください。ペアでプログラムし、お互いのコードをレビューします。テクニカルセッションなどを開催。

本当に知識をどこかに保存したい場合は、データを充実させてみてください。ホワイトボードなどの写真を wiki に簡単に追加できるようにします。文書化された文書のもう 1 つの問題は、人々が長々とした抽象的なテキストを「プロフェッショナル」だと考えているように見えることです。人々が実際にそれを読むことができるように、ドキュメントは短く、明確で、要点を保つようにしてください。

score 6 · Accepted Answer

あなたがサポートを集めることができれば、評判のあるソーシャルメディア（このサイトのように）はイントラネット上で非常にうまく機能することができます。人々は知識ベースを養うために少しのインセンティブを必要とします。

score 3 · Accepted Answer

MindTouch Dekiをお勧めします。組織内のカスタムデータソースに統合する機能など、他の多くのソースに統合されているため、単なる wiki ではありません。

score 2 · Accepted Answer

ソリューションに関係なく、企業内で知識を維持する上で最も重要なことは、人々にシステムを使用させることです。Wiki は私のお気に入りですが、経営陣やチームリーダーの強制がなければ、そのレベルの有用な知識を維持するのは困難です。

score 2 · Accepted Answer

Wiki はうまく機能していますが、Ignite と Camtasia のスクリーンキャストで Wiki を補足しています。これらにより、構成などを描写する際の時間を節約できます。スクリーンキャストは簡単にすばやく実行でき、視聴者が確認する必要のあるセクションを巻き戻し/再生するという点で、視聴者にとって適切な詳細をキャプチャしたかどうかを心配する必要はありません。

私たちはナレッジベースの記事を試しましたが、人々は怠け者になりました。「このセクションが理解できない」ということは、大量の記事を書き直すことを意味します。人にスクリーンキャストを与えると、彼らは自分のメモを作ることができます.

score 2 · Accepted Answer

Wiki は優れていますが、その最大の利点の 1 つはまだ言及されていません。作成者はドキュメントを必要としないか、読んでいないため、多くの場合、ドキュメントの欠陥はそれを書いた人によって発見されません。作者が休暇中や病気で外出しているときに欠陥が発見され、他の誰かがドキュメンテーションに従おうとして、その一部が機能しないことがあります。Wiki を使用すると、ドキュメントの欠陥を発見した可哀想な人は、著者に電子メールを送信する必要がなく、すぐに修正できます。休暇中に著者が受け取った他の何千もの電子メールに埋もれてしまったり、忘れずに伝えようとしたりする必要はありません。著者が戻った後の著者。

また、少なくとも 2 人がすべてを行う方法を知っていることを確認し、人員配置レベルを維持します。誰かが去った場合、その人が行ったすべてのことを実行できる他の人がすでにいる場合、その人を置き換えたくないという誘惑にかられるかもしれません。しかし、1 人の人しか理解できないインフラストラクチャまたはコードが複数ある場合は、脆弱です。 . ある人から別の人への知識の伝達には時間がかかり、手作業が必要です。簡単ではありませんが、ドキュメントだけからインフラストラクチャやコードベースを学ぼうとするよりもはるかに簡単です。

score 1 · Accepted Answer

私は過去に両方の方法を使用しましたが、wiki形式が最も受け入れられやすいことがわかりました。ドキュメントをソース管理に保存すると、バージョンのマージに影響を与える可能性があります（明らかに、使用中のソース管理ソフトウェアと適用されている方法に依存します）。同じことがウィキベースのソリューションにも当てはまりますが、何らかの理由で、私が使用した実装で大きな問題が発生したことは一度もないようです。

主要なウィキの検索可能性は、その成功のもう1つの主要な要因です。潜在的に無関係なコード内のドキュメントへの参照を見つけるよりも、Wikiで検索用語を検索する方がはるかに簡単です。

<2c />

score 1 · Accepted Answer

私はウィキが好きです。私は自分の趣味のプロジェクトにもそれらを使用し、二度と対処する必要のない厄介な問題をどのように回避したかを文書化したり、関連するリソースへの参照のリストを維持したりします。

多くの人にそのようなウィキに貢献してもらうことはさらに強力ですが、議論の可能性も非常に重要です。

score 1 · Accepted Answer

私は実際にそれに対処するサイドプロジェクトを開始しました。まだ計画段階ですが、組織内で技術的な知識が保持されている領域をいくつか特定しました。現在、これはすべての組織に当てはまるわけではありませんが、すべての組織がこれらの少なくとも1つを使用しています。

人々
静的Web（インターネットおよびイントラネット）サイト
書籍（企業図書館）
本（個人の本）
動的Web（インターネットおよびイントラネット）サイト
データベースとリポジトリ

これらのそれぞれをどのように利用するかは正確には異なりますが、重要なのは、人々に静的および/または動的Webサイトを使用して情報を取得するか、少なくとも本やリポジトリのどこにあるかを特定することです。人々がナレッジハウスに食事を提供していなければ、どのテクノロジーを使用するかは問題ではありません。知識は、私が収集できたものから、最新で、正確で、詳細であるか、無駄である必要があります。

Vinko Vrsalovicが指摘したように、重要なもう1つの重要な概念は、データ/情報/知識をその推論にリンクする機能です。要件分析の一般的な方法は、要件をそのソースまで追跡する機能です。知識についても同じことが言えます。組織内の誰もが世界のすべてを知ることができます。ただし、その知識が有用である理由や、その知識を使用する場所/時期が誰にもわからない場合は、無駄になります。

足りない場合は、この投稿を編集するか、コメントとして返信してください。この質問は私のプロジェクトの取り組みに役立つと思います。

編集1：Vinko Vrsalovicに、知識だけでなく、知識が関係する制作の問題にデータをリンクすることを追加しました。

score 1 · Accepted Answer

組織内の電子メール内で多くの知識に関する議論が行われているのを見てきました。この知識は電子メール内に長くとどまり、最終的には失われ、元の議論に参加していない他の人がアクセスできなくなります。

http://grexit.comのようなツールを使用すると、これらの知識を受信トレイから組織内の coomon 共有リポジトリに移動するのに役立ちます。現在、これは Google Apps でのみ機能しますが、試してみる価値があります。

score 0 · Accepted Answer

wiki を使用しますが、誰かが編集権を持っていることを確認してください。その人は、命名基準と文書の系統性が守られていることを確認する必要があります。

score 0 · Accepted Answer

Wiki のいくつかの欠点、または追加の考慮が必要な場合について説明します。

Wiki にアクセスできない顧客または組織と技術知識/ドキュメントを共有する場合
ソフトウェアの特定のバージョンに関連付けられたドキュメントは、多くの場合、リリースに関連付けられたソースと一緒に使用するとより効果的です。多くの場合、Wiki には最新の情報が含まれていますが、ドキュメントを古いリリースにマップするのは (編集者の注意次第で) 難しい場合があります。

score 0 · Accepted Answer

プロジェクトのブログと wiki を組み合わせて使用します。

人々は Wiki に少し気が進まなかったと思います。エントリを正当化するには、少なくとも数段落を入力する必要があると感じていたからです。そこで、ささいなことやリアルタイムで起こっていることを記録するのに役立つブログを始めました。たとえば、「列フィールドの長さを 40 から 50 に変更しました」または「先週より古い監査テーブルデータを削除しました」。

プロジェクトが進行するにつれて、一部のブログエントリが、より長い wiki エントリのソースになることを期待 (希望) します。

score 0 · Accepted Answer

間違いなくウィキです。TWikiを使用し、いくつかの優れたプラグインを利用しています。

編集:ドキュメントとバージョン管理に関するこの質問の回答を参照したい場合があることを追加するのを忘れました。

score 0 · Accepted Answer

使用するツールはそれほど重要ではないと思います。本当に重要なことは、チームのすべてのメンバーがドキュメントの 1 つの方法と 1 つの場所に同意することです。

wiki、メモデータベース、または自作アプリケーションを使用できます。

個人的には、すべてのものが 1 か所にある方が好きです。したがって、技術文書については、ソース管理システムが適切な場所になります。開発者以外が使用するドキュメントの場合、ソース管理は間違いなく不適切な場所です。全般的なドキュメントの場合は、共有ポイントサーバーを使用する必要があります。ある種のバージョン管理があり、特別なクライアントアプリケーションなしでアクセスできます。

score 0 · Accepted Answer

Wiki の代わりに、SharePoint の使用を検討してください。イベント (会議など)、タスク、およびドキュメントを処理できます。テクニカルライターやマネージャーが何が起こっているのかを調べることができるようになる可能性があるため、非技術者の群れと非常にうまく機能します。また、Windows 2003 の一部であるため、追加のライセンスは必要ない場合があります。

マイナス面としては、小さな UI のちょっとした問題であなたを責める馬鹿がいるとほぼ保証できます。上層部はきっと気に入るだろうけど。

score 0 · Accepted Answer

おそらくAssociativyを見ることができます。知識の断片をグラフのノードとして保存し、エッジは連想 (人間の意味で) 接続を表します。グラフは、一連の検索用語が与えられると、ソフトウェアが適切な関連付けについて「考える」ことができるため、複数の方法で検索および探索できます。

私はオープンソースであり、オープンソースプロジェクトでもあるOrchard CMSで実行しています。

これは恥知らずなプラグインでした (Associativy は私のプロジェクトです)。

編集：この質問の古さを認識しました....

knowledge-management - 組織内の技術的知識を覚える最良の方法は何ですか

18 に答える 18

Related

Reference