エンタープライズ知識の共有?


20

私は最近、知識共有に関するこの記事を読み、自分の組織内で同じ問題をすぐに認識しました。私の現在の主な目標は、プライベートではないシステム関連の議論のためのデフォルトの通信方法として「ピアツーピアコラボレーションを殺す」ことです。そうしないと、個人の頭の中にすべての歴史的知識が残ったり、大規模な電子メールシステムで失われたりすることになります。

グループに関する私の質問は次のとおりです。

  • 開発者の間でより「公開された」議論を促すために、どのような方法/ソフトウェアを使用しましたか?

私が持っていたいくつかの最初のアイデア..フィードバックは素晴らしいだろう:

  • 内部ニュースグループ
  • 「より優れた」Wikiソフトウェア(今はSharepointを使用)
  • 伝言板

(StackExchangeの内部インスタンスが欲しいのですが、それがオプションだとは思わないでください!)

注:上記のように、我々はすでにウィキを持っているが、物事は通常は、事後のwikiに追加されたので、私はウィキのアイデアを嫌い、すべての場合

ありがとう!


7
いい質問ですね。同じ問題があります。これを「<挿入名>がバスに当たった場合」シンドロームと呼びます。これを聞いてくれてありがとう。
DevSolo

1
それ以外の場合は「トラック番号」として知られています。
フランクシェラー

これまでの回答に基づいて、私はほとんどの人がウィキとメールを使用してある程度の成功を収めていると考えています。これを行うにはもっと良い方法があるはずだと思ったとき、おそらく夢を見ていました。:|
mpeterson

1
鍵は技術ではなく、人々にあります。私が職場で見たように、ウィキを持っていることは、人々がそれを使用することを意味しません。それがあなたが行きたい方法であれば、それを奨励するよりも。人々は彼らが何をしているのかについて絶えず話し合っているので、効果的にコミュニケーションするためにコラボレーションツールを必要としない場所があると確信しています。Wikiなどは、知識の共有を効率化するためのものであり、作成するものではありません。
マイケルK

マイケル!開発チーム内で情報を共有する「文化」を変えようとしています。テクノロジーは考え方ほど重要ではありません。
mpeterson

回答:


3

大規模な社内Sharepointサイトと顧客向けのサポートサイトがあり、社内Sharepointサイトから多くのドキュメントを取得します。これは実装の詳細についてではなく、明らかにサポートについてですが、私は主にサポート容量で作業しているため、多くの実装情報にアクセスする必要があります。そのため、エンジニアリングチームが何をしているのか、そしてその理由を文書化するためのドライバーになります。詳細なバグ追跡システムは、問題の解決方法を追跡するのにも役立ちます。

当社では、開発がいくつかの場所に分散していることもあり、新機能やサポートの問題に関する多くの議論が電子メールを介して行われています。これを変更するのではなく、最も簡単なアプローチは、ディスカッションを検索および追跡可能にする電子メールアーカイブシステムであり、事実上、ニュースグループタイプのアプローチです。Sharepointを使用してこれを行うことができますが、リストサイズの制限に注意する必要がありますが、非常に大きなリストの並べ替えやそれらのビューの編集に関して実際にはあまりできない数百万のアイテムに成長します劇的にクラッシュします。


ああ..私たちにも多くのサポート義務があり、地理的に分散しています。Sharepointを介したアーカイブ/検索可能な電子メールは非常に興味深いものです。それが適切な妥協案かもしれません
...-mpeterson

うまくいくと思うのは、メールのアーカイブを3か月のチャンクに分割して、リストのサイズを管理しやすくすることです。明らかに期間は月ごとに異なり、SP2007を使用しました。2010年はより大きなリストをより適切に処理できる可能性があります。
グレナトロン

1
私はこれを非常に考慮しています。これをバグ追跡システムの使用とより多くのwikiの記入に重点を置いて組み合わせて、コンテンツの「転換点」に到達するようにします。これが私の質問に対する最良の答えだと思います。
mpeterson

1
あなたがウィキを使用している場合、私は同じ仕事をしてない吸ういくつかのかなり良いのアドオン...あると思い分の1を確認してくださいそれは、SharePointに組み込まれていない作る
glenatron

4

あなたが言及した記事で説明されているような企業向けStackOverFlow?

私見それはひどいアイデアです。

コラボレーションの代わりに競争を強化します。

競合を増やすのではなく、部門/部門間のコラボレーションが必要です。

また、同僚(他の人の前)によってダウン投票されることの非常に高いマイナスの影響があなたの精神的健康に与える可能性があることを想像してください。

すべてを混ぜないでください。

ただし、従業員が(匿名で)アイデアを投稿し、他の従業員が(これも無名で)賛成するuservoice.comのアイデアボックスは、プラスの影響を与えます。私は数年前にこのようなプラットフォームを非常に大規模な銀行機関向けに開発しました。それは経営幹部が何を優先的に改善すべきかを特定するのに役立ちました。


1
@Pierre、コラボレーションではなく競争をどう見るか?私はあなたの意見を尊重しますが、私は正直にそれを見ません。私は興味がある。
DevSolo

ポイント=競争。ランキングがあるため競争。

おそらく私はもっと明確にすべきです...私はポイント/投票システムが欲しくありません。(少し緊張する可能性があることに同意します)
-mpeterson

Mpeterson、私はあなたが言及した記事でもっと男に返信していたのかもしれません。しかし、私の回答では、グローバルな大企業でうまく機能するアイデアを提案しました。

StackExchangeプラットフォームと投票のアイデアボックスはどのように異なりますか?
ロバートハーヴェイ

2

wikiのアイデアもとても気に入っていますが、そうです-人々に貢献してもらうのは難しいです。そして、貢献がなければ、十分な情報がないため、誰も実際に使用しません。しかし、ある時点で(おそらく必要なビジネスプロセスを介して)人々に投稿してもらうことができる「転換点」があります。これは、この素晴らしい情報リポジトリとしてwikiがちょうど出発するでしょう。


私の会社にはその問題があります。しかし、徐々に多くの人がwikiを使用しています。私のマネージャーは、人々がそこを見て、投稿することを奨励しています。彼は時々、彼が簡単にアクセスできるようにしたい特定の事柄をウィキに載せるようにさまざまな人々に割り当てました-私はそれが助けたと思います。
マイケルK

私たちもこれを行っていますが、それでも面倒です。まだ転換点に達していないのでしょうか?
mpeterson

1

ペアプログラミングは、暗黙の知識を広める素晴らしい方法です。

暗黙の知識の問題は、定義によってほとんど書き留めたり教えたりせず、経験するだけでよいということです。ペアプログラミング(特に無差別ペアリング)はそれを提供します。


1

企業にとって重要な知識は、適切に記述されたコード、アーキテクチャに関する高レベルのコメント、およびプロジェクトの目標とテクノロジで達成される方法に関する例外的なドキュメントの形で、プロジェクト自体に取り入れる必要があります。

リンクされた著者の結論にこれ以上異議を唱えることはできませんでした。チームのコラボレーションを妨げることにより、知識の獲得を促進しますか?申し訳ありませんが、それでは動作しません。共同作業が知識の富を生み出し、キュービクルでエンジニアを隔離するのではありません。


著者は完全にではなく、プライベートで1対1のコラボレーションを阻止しようとしているだけだと思いましたか?
mpeterson

また、ナレッジが独自のプロジェクトであるというコメントについては+1。それは、多くの内部プロジェクトを構築する際に忘れられていた資産のようです。:|
mpeterson

1
mpeterson:私の経験では、ほとんどの真のチームコラボレーションと創造的な知識の構築は、ミーティングではなく、アドホックで非公式な方法で行われます。
ロバートハーベイ

0

私の会社には内部のディスカッション掲示板があります。それらはほとんど使用されません。ほとんどの場合、私たちが持っている知識は、一般的すぎる(インターネットでよく議論されている一般的な技術の質問/トピック)か、あまりにも具体的です(同じ会社の他のアプリケーションチームではなく、アプリケーションにのみ適用されます)。ここでxyzをどのように達成すればよいかを人々に伝える場所を提供するという点で優れていますが、コミュニティはあまり感じていません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.